RDF Calendar Model
Ok, just some stuff I've put down. See if it makes sense...
Basic Events
Events are complicated, but I think we might as well see sense and
take the view from physics that events are points in spacetime:
<x,y,z,t>, that is position (x,y,z) at time t.
Ok, so already that seems wrong. Bear with me. I'll go through
some cases so it will seem less wrong, maybe even more right.
1. Events have duration
No they don't. But alright, for all practical purposes the events
we want to discuss here (in calendaring) have duration. I
suggest calendar events will be bounded by a start event and end
event. In what follows I'll use 'events' for calendar events, and
leave it at that.
2. An event can have no location
Name one. Well, there are events one may wish to schedule which
lack a specified location, eg 'Do expenses'. So perhaps
there should exist the possibility to leave locations undefined.
3. An event can have many locations
This is more interesting. A good example is teleconferencing.
Suppose Jack and Jill want to schedule a chat over a 'phone. That
chat is an 'event', but two locations are involved. Oh dear.
How about this. This is really two events: Jack at one 'phone at
time t, and Jill at another 'phone at time t. FAPP that is enough.
So this is a composite event, an event made of two (or more)
events. As far as I can see we don't need to make this type of
event qualitatively different from individual events: simple events
just don't have any sub-events.
We can take this further. Consider a conference with several
'tracks', which consist of individual talks. The conference is an
event, consisting of sub-events (the tracks) which have sub-events
(the individual talks).
Another example of multiple locations is a plane flight 'event'.
This is actually pretty easy. It has a start event (take off at
time t, place p) and end event (land t1, place p1). So it's a
simple calendar event. This isn't very rich (no path) but would
suffice. If there are transfers we have a composite event,
consisting of several individual flights.
There are issues with all of this, however.
- Do composite events have beginning and end events? I think they
should be able to. But then there's a problem - I introduced them
for multiple located events. So locations can be dropped for
composite events.
- Jack and Jill can have a 'phone conference at different times
from one another! That's dumb! (Enough with the exclamation points)
Similarly a composite event could have a time range which
contradicts the sub-events (i.e. they aren't contained within it).
Perhaps the best response is: who cares? It's a simple format, and
can't be expected to correct your dumb mistakes. One suggestion for
the former is to have only positions for Jack and Jill, and just
times (as above) for the composite event. Jack's individual event
inherits the time range from the containing event (and mutardis
mutandis for Jill). This is a bit nasty (and doesn't solve the
other problem). Maybe we should just let tools which produce the
rdf do the checks and the inheritance.
Beyond Events
Hopefully this is reasonably useful for an event structure, but it
isn't very rich. What we want to add are things like human-readable
descriptions, and data about the event like type, and possibly
organiser, organisation etc, whatever. One important class is what
I'll call 'essential resources', resources required for an event.
This might include people, hardware (OHPs, computers, 'phones), and
(oddly) rooms. I add rooms, even though these might be used to
indicate the event location. Essential resources might need to be
booked, so I'll include rooms, and (more generally) locations.
The final addition required are 'accidental' (as opposed to
essential) features of an event. Attendees at an event might not be
essential, but shouldn't we add them to an event? I suggest that
this isn't the best way to do it. How about a relation 'x attends
(event)y'? It seems more natural. One nice example is a plane
flight. Suppose Laker (to take a non-refering airline) exposes
flight details using rdf. Then I can express the fact that I will
be on this flight by saying I'll attend the flight event.
Further Issues
These divide into two cases, I think:
- Querying
- Exotic events, like repeating events