Overview of Events and Reviews
In our efforts to be friend to all, we’re undertaking a survey of ALL existing Events and Reviews schemas.
This is for the purpose of creating an open source tool which will support ALL formats - as I’ve never met a customer who cares about what’s under the hood.
Bob Wyman has this theory that if you support TOO MANY standards, you in danger of dissipating the energy and dilute the strength of what a standard means in the first place.
But we see it like this:
- no matter what we gotta support certain peeps (hey Tantek & Matt!)
- then there is the extension of the leading brand, which needs to get extended (RSS 2.0)
- then there are the cutting edge, really interesting standards - which give us new functionality
- and of course - whoever is paying the bills gets THEIR standard supported
So how do you decide which standard to support?
Well - first of all - you can only do so much, so fast - so there’s always time to put a reality jolt into this scenario - but I’d say the most important thing - is how humans use this stuff.
We can assume that folks will want to subscribe to micro-content in all sorts of ways, but do we think folks want files?
YES! I say!
So what file formats to support?
xHTML and OPML I say.
Needless to say we’re also shooting for supersetting and encompassing everyone’s innovations, great ideas and flexibility. So that leaves us with a giant black box of compatiblity, able to not only satisfy everyone’s needs and perceived wants - but this would ALSO give someone (probably not us) the opportunity of providing a giant converter utility service, to take care of peeps who care about moving their stuff from one format to another.
Remember it’s all open source - baby.
August 27th, 2005 at 1:13 pm
While a review is a good idea, it is important, especially for events, to keep in mind that practice thus far has not been exemplary.
In particular, I would like to observe that while events are complex entities, practice thus far has tended to represent them in single self-contained documents.
My own approach to events is based on the principle of RSS referencing, which I outlined on the RSS-Dev list and on my website here: http://www.downes.ca/cgi-bin/website/view.cgi?dbs=Article&key=1122488147
In summary…
A *simple* event is considered as an RSS core (title, description, link plus optional Dublin Core elements, such as ‘contributor’), plus:
- date/time
- location
There are good standards for expressing date/time and the people at microformats.org are discussing this.
There are less good standards for location, though most of us can figure out the basic elements (country, city, street, number). I will take it as a given that a location standard will be (more or less) agreed upon (and mapped to Google Map / Earth, for map inserts)
This simple event is in addition *associated* with various resources. Such resources should have their own metadata, and hence (in principle) should be referenced rather than described.
Some examples of associated resources include:
- agenda
- PowerPoint
- MP3 recording
- blog post summary
It should be noted that such associated resources will often be generated independently of the event. Hence, one of two possibilities exists (and both must be supported):
- the resource metedata refers to the event URI
eg. <link rel=”event”>http://www.thing.com/event_metadata.xml</link>
- the event metadata refers to the resource URI
eg. <link rel=”agenda”>http://www.thing.com/agenda.doc</link>
In a similar manner, while some formats include all manner of metadata about people in event metadata, it is best to refer to personal metadata rather than describe people within the event metadata. Eg.
<dc:contributor role=”chair”><link rel=”foaf”>http://www.downes.ca/my.foaf</link></dc:contributor>
or some such thing. Optionally:
<dc:contributor role=”chair”><link rel=”foaf”>http://www.downes.ca/my.foaf</link><title>Stephen Downes</title></dc:contributor>
I’m not so concerned with the details here as with the principle that events metadata consist in large part of *references* to other resource metadata.
A *complex* event consists of a collection of simple events. For example, a ‘conference’ may consist of individual ’sessions’.
Complex events obtain their structure by referencing simple events to each other. Two mechanisms, both derived from RDF, suggest themselves:
<rdf:haspart><item><link>http://URI_of_sub-event</link></item></rdf:haspart>
<rdf:ispartof><link>http://URI_of_sub-event</link></rdf:ispartof>
Again, I am not so concerned with the exact syntax as I am with the basic mechanism. Creating events using referencing allows not only for an ‘official’ event but in addition for unofficial associated events to be added on an ad hoc basis.
That’s pretty much it.