IT & gathering events
Historically, events have been created online much in the way they appear in the printed press; in the context of an article with a title, a sub-title, a date and text combined with images.
An event, like it is describe on the Home page is structured by five concepts :
- Event categories : Defines event subject from a general to a precise category.
- Event dates : Defines when the event will happen.
- Event places : Defines where the event takes place.
- Event prices : Defines how much it will cost to attend the event.
- Event people : Characterizes who are the attendees, organizers and participants.
ESS Definition by Q & A
As first assumption of many protocols there are several simple questions that need to be answered.
ESS has been created by starting with these questions because the current solutions do not can be improved.
- [ Q ] What exactly comprises an event? Is there any standard that handles all event aspects?
- [ A ] Events are complex. The web's way of presenting events is to divide them into different concepts:
- Metadata presentation : text, image, video, sound.
- Categorized all events to localize a particular event.
- Place the event in space: geographic place, area or virtual event.
- Place the event in time: precise time, time range or recurring dates.
- Define human interaction the event related to people: organiser, performer, attendee...
Based on all the components of an event there are currently no protocols or standards that links all the varied event components into one feed.
- [ Q ] Who needs to have access to web-based event information, now and in the future?
- [ A ] Three types of web users:
- First are event producers
- Second are: content publishers who need fast, validated, structured, updated and massive event information.
- All of them needs: "robots" to analyse event information and redirect it to the appropriate device or application (e.g. Event > Google Map, Event > Google Agenda, Event> Facebook friend...).
The necessity of transforming an existing format into a new one comes from the increasing volume of event information on the web and from an increasing volume of new applications that use this information (e.g. : web maps, web agendas, websites to pay event's entries, websites to rates events, share events with friends...).
RSS and Atom formats are not structured enough to be able to universally vinculate event data.
Starting from this necessity, satellite standards that use events already have a nomenclature to handle events in their own environment (e.g : web maps with KML, iCal with vCard).
ESS divides events into height separated concepts. These concepts are represented in ESS Documents by XML structures which are similar or equal to elements present in other standard structures.
As its historical predecessors RSS or Atom, ESS Documents are XML formatted plain text, the ESS document itself is relatively easy to read both by automated processes and by humans alike. The ESS file can be placed on any appropriate communication protocol for file retrieval, such as http or ftp, and reading software would use the information to present a neat display to the end user. ESS Document can also be analyzed by scripts and robots to extract information to be used according to client business models.
The need to have a separate event standard arose because third party applications that use events became more widespread. Satellite concepts like online calendars and maps still need to describe events according to their own standards. What ESS offers is a common standard structure.
Events and calendarsAn event is not only about calendar.
A fast answer was to assimilate events to a calendar element.
An event is both more simple and more complex.
Both events and calendars require dated, but an event is not only a date. Calendars have their own standards, those standards share some necessary points with ESS structure. By definition, a calendar element is a fixed point in time, but events have to be treated like growing feeds that change over time and share information with other parties. This information has to be sent and interpreted outside the calendar to include map, video, interaction with other events, webservice for event payment etc.
Events and maps
An event is not only a Map.
A major requisite for events and happenings published online has been the ability to be inserted into maps (Google Map). At the same time Map standards have implemented happenings description in their protocols (Google places, Google location, KML). This step was necessary to use events in a map but events are more then just a point on a map. ESS bridges the gap by implementing a complete description of events into space: geographical point, moving event or virtual event.
Events and prices
An event price is not only a sub-title.
Historical relation between events and prices in web environments come from the fact that to attend the majority of events a payment is required. Treatment of price information took three steps:
- 1 | First: Input of information as a text subtitle to inform readers about the event's price.
- 2 | Second: Contact web-services to make payment with 3rd party APIs.
- 3 | Third: Structure price information into textual XML feeds where the price is just a text with no special placement in the feed (RSS, Atome or 3rd party proprietary feeds).
- 4 | ESS direction : mix the three other steps into a event's determined feed structure..
Events and categories
An event is not only a text description.
Events categories means gathering event themes. Many events are placed on the web as a text. Textual representation make it harder for event information to be used by third party websites or applications.
Over time, the web's textual event representation moved to textual feeds representation where RSS and Atom defined only a few parts of what makes up events (name, title, subtitle, date and image).
For an efficient broadcasting effect, event feeds need to be standardized and universal.
Events and people
An event is not only about what people say about the event.
Interactions between events and people took several directions over time. First as we've distinguished in ESS XML People, there are three general kinds of people that interact with events and therefore three different way to desribe people in a web-based event interface:
- 1 | Organizers: Company, Association, State or Individual that create the event
- 2 | Performers: Person or group of person that actively participate to the event to be a component of the attraction (artiste, speaker, decorator...
- 3 | Attendees: People or group of people participate in the event. Visitors are the event's target.
People description already have several standards (vCard, xCard...), ESS started from this point and includes a similar structure that can be to matched with other environments.
Future of events using ESS
Standardizing events through ESS Feeds opens the door for many applications and consequently increases event use on a wide-scale. With ESS, events represent a new structured volume of information which are ready to be used, validated and promoted. The challenge is to analyze this new amount of information and use it in appropriate places.
Before ESS, events was mainly treated as texts, publishing/posting information about events through severals human actions.
The benets of ESS can clearly be seen in its ability act as a feed to a large information portal, Yahoo for example. Yahoo, with its various categorized portals in various languages across various countries needs to have local information that its users can interact and respond to.
ESS, with the target of widescale portals has five big advantages :
- 1 | Reduces the cost of event information.
- 2 | Reduces the time needed to reach this information.
- 3 | Increases the volume of event information.
- 4 | Increases the page value for the end-user and for the advertiser.
- 5 | Socializes the page content by adding local information.