Representing Events, Representing Knowledge

Two comments to blogs, that at first glance appear to address very different topics, but are in fact saying exactly the same thing.

Specifically, that knowledge is represented (conceptually, in web pages, as metadata) as a series of connections between entities or resources.

No connections: no knowledge.


Comment to David Weinberger

Hm. There is a long history of taxonomy, organization, and encyclopedia. The latter, for example, is a French invention, the Encyclopédie of Denis Diderot (1750-1772). Meanwhile, a product of the Scottish enlightenment, the Encyclopedia Britannica begins in 1768, more than a hundred years before Adler's birth in 1902.

A Propaedia is an attempt to make some sense of this body of knowledge, to, as suggested above, to organize knowledge. The rude response, that "we don't need old white men to tell us how knowledge is organized," and the more polite response, that "we don't have to organize the physical containers of knowledge," miss the nature and objective of what is being attempted. We may grant that a map is not (always) the best metaphor, but to do away with all organization sounds naive at best and dangerous at worst.

"Findability counts." For what? What is the purpose of knowledge, of information, if it belongs nowhere, if it is not part of a coherent understanding of the world. If not a map, then what: a pyramid? a pile? a hierarchy? chaos?

Understanding entails not merely finding but connecting, not merely knowing but applying in context; and of the mechanisms representing this, a map is as welll construed and robust as anything else. Or perhaps a collection of maps, each one charting the world as seen from a point of view.

Adler was neither as groundbreaking as suggested above, nor as easily dismissed as suggested above. The simple remedy of tagging is neither as original nor as robust, either. RDF, for all its syntactical flaws, demonstrates a deeper understanding of how knowledge is to be organized, so that we can not merely find but relate.

And ultimately, I believe that we will find our understandings based not merely in association one word to another, but rather, in a more detailed multivaried set of connections between words, objects, and representations, a tapestry that, more often than not, will be comprehensible by our three-dimensional minds best with the aid of a map.

Comment to Marc Canter:

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.

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.