<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	>
<channel>
	<title>Comments on: Overview of Events and Reviews</title>
	<atom:link href="http://blog.broadbandmechanics.com/2005/08/overview_of_eve/feed" rel="self" type="application/rss+xml" />
	<link>http://blog.broadbandmechanics.com/2005/08/overview_of_eve</link>
	<description>Digital Lifestyle Aggregation - helping to establish open source infrastructure</description>
	<pubDate>Thu, 20 Nov 2008 09:41:29 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.6</generator>
		<item>
		<title>By: Downes</title>
		<link>http://blog.broadbandmechanics.com/2005/08/overview_of_eve#comment-2184</link>
		<dc:creator>Downes</dc:creator>
		<pubDate>Tue, 30 Nov 1999 00:00:00 +0000</pubDate>
		<guid isPermaLink="false">http://marc_blogs_it.myelin.co.nz/?p=2367#comment-2184</guid>
		<description>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&#038;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. &#60;link rel="event"&#62;http://www.thing.com/event_metadata.xml&#60;/link&#62;

   - the event metadata refers to the resource URI
     eg. &#60;link rel="agenda"&#62;http://www.thing.com/agenda.doc&#60;/link&#62;

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.

&#60;dc:contributor role="chair"&#62;&#60;link rel="foaf"&#62;http://www.downes.ca/my.foaf&#60;/link&#62;&#60;/dc:contributor&#62;

or some such thing. Optionally:

&#60;dc:contributor role="chair"&#62;&#60;link rel="foaf"&#62;http://www.downes.ca/my.foaf&#60;/link&#62;&#60;title&#62;Stephen Downes&#60;/title&#62;&#60;/dc:contributor&#62;

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:

&#60;rdf:haspart&#62;&#60;item&#62;&#60;link&#62;http://URI_of_sub-event&#60;/link&#62;&#60;/item&#62;&#60;/rdf:haspart&#62;


&#60;rdf:ispartof&#62;&#60;link&#62;http://URI_of_sub-event&#60;/link&#62;&#60;/rdf:ispartof&#62;

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. 

</description>
		<content:encoded><![CDATA[<p>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.</p>
<p>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.</p>
<p>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: <a href="http://www.downes.ca/cgi-bin/website/view.cgi?dbs=Article&#038;key=1122488147" rel="nofollow">http://www.downes.ca/cgi-bin/website/view.cgi?dbs=Article&#038;key=1122488147</a></p>
<p>In summary&#8230;</p>
<p>A *simple* event is considered as an RSS core (title, description, link plus optional Dublin Core elements, such as &#8216;contributor&#8217;), plus:<br />
   - date/time<br />
   - location</p>
<p>There are good standards for expressing date/time and the people at microformats.org are discussing this.</p>
<p>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)</p>
<p>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.</p>
<p>Some examples of associated resources include:<br />
   - agenda<br />
   - PowerPoint<br />
   - MP3 recording<br />
   - blog post summary</p>
<p>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):</p>
<p>   - the resource metedata refers to the event URI<br />
     eg. &lt;link rel=&#8221;event&#8221;&gt;http://www.thing.com/event_metadata.xml&lt;/link&gt;</p>
<p>   - the event metadata refers to the resource URI<br />
     eg. &lt;link rel=&#8221;agenda&#8221;&gt;http://www.thing.com/agenda.doc&lt;/link&gt;</p>
<p>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.</p>
<p>&lt;dc:contributor role=&#8221;chair&#8221;&gt;&lt;link rel=&#8221;foaf&#8221;&gt;http://www.downes.ca/my.foaf&lt;/link&gt;&lt;/dc:contributor&gt;</p>
<p>or some such thing. Optionally:</p>
<p>&lt;dc:contributor role=&#8221;chair&#8221;&gt;&lt;link rel=&#8221;foaf&#8221;&gt;http://www.downes.ca/my.foaf&lt;/link&gt;&lt;title&gt;Stephen Downes&lt;/title&gt;&lt;/dc:contributor&gt;</p>
<p>I&#8217;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.</p>
<p>A *complex* event consists of a collection of simple events. For example, a &#8216;conference&#8217; may consist of individual &#8217;sessions&#8217;.</p>
<p>Complex events obtain their structure by referencing simple events to each other. Two mechanisms, both derived from RDF, suggest themselves:</p>
<p>&lt;rdf:haspart&gt;&lt;item&gt;&lt;link&gt;http://URI_of_sub-event&lt;/link&gt;&lt;/item&gt;&lt;/rdf:haspart&gt;</p>
<p>&lt;rdf:ispartof&gt;&lt;link&gt;http://URI_of_sub-event&lt;/link&gt;&lt;/rdf:ispartof&gt;</p>
<p>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 &#8216;official&#8217; event but in addition for unofficial associated events to be added on an ad hoc basis.</p>
<p>That&#8217;s pretty much it.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
