RDF Calendar Issues List

Libby Miller 2001-08-10

About this document

This is a first draft of the first tranche of issues for the RDF calendar. I've been trying to split up the iCalendar RDF schema into smaller more manageable sections and write examples for each. I've also been discussing the model with Damian Steer and Greg Fitzpatrick. This is only a few of the issues there are likely to be: there's also recurrence (a biggy), todo, journal, freebusy, timezones. There's a mix of important and difficult modelling questions, terminological questions and things to think about in this document.

Comments are gratefully recieved - send them to www-rdf-calendar@w3.org or libby.miller@bristol.ac.uk

Contents

  1. Subclassing xml schema datatypes into the calendar namespace
  2. Instants and intervals - DAML and XML schema datatypes
  3. How do we model resources/locations/date-times?
  4. Period
  5. Text/literals and DAML
  6. Cal-user/cal-address
  7. Vcalendar
  8. Is calendar component a good name?
  9. Events within events
  10. Simplicity
  11. Is Duration a good name?

1. Subclassing xml schema datatypes into the calendar namespace

Do we need to?

probably not: float, boolean, binary, int, uri

probably: date, time, date-time, duration (as a class)

2. Instants and intervals - DAML and XML schema datatypes

DAML: see http://www.daml.org/services/daml-s/2001/05/daml-s.html

A date-time is an instant according to xml schemas datatype of dateTime

[[
[Definition:] dateTime represents a specific instant of time. The ˇvalue
spaceˇ of dateTime is the space of
       Combinations of date and time of day values as defined in § 5.4 of
[ISO 8601].
]]

http://www.w3.org/TR/xmlschema-2/#dateTime

However, a date seems to me to be an interval, although xml schema datatypes regards it as a specific sort of instant

[[
[Definition:] date represents a calendar date. The ˇvalue spaceˇ of date
is the set of Gregorian calendar dates as
       defined in § 5.2.1 of [ISO 8601]. Specifically, it is a set of
one-day long, non-periodic instances e.g. lexical
       1999-10-26 to represent the calendar date 1999-10-26, independent
of how many hours this day has. 
]]

http://www.w3.org/TR/xmlschema-2/#date

In XML schema datatypes a time is more than one instant:

[[
[Definition:] time represents an instant of time that recurs every day.
The ˇvalue spaceˇ of time is the space of
       time of day values as defined in § 5.3 of [ISO 8601]. Specifically,
it is a set of zero-duration daily time
       instances. 
]]

http://www.w3.org/TR/xmlschema-2/#time

From a modeling point of view this looks like a mess!

Saying the start of something is at a datetime is straightforward. Saying it is a date is still fairly unambiguous. But saying it is a time introduces recurrence into the model implicitly. SKIcal have new some work which seems similar to this, where recurrence context is implicit, e.g. the obvious recurrence context for a time is a day @@no reference yet@@.

For meetings, dates and date-times do fine. For opening hours, times are useful.

For RDF calendar:

TimeEntry is probably the wrong term for superclass of date and date-time; we probably want something like daml:instant (although I'm still not convinced that this really covers the XML schema datatypes date).

Time should be defined differently (in fact we don't have it as a subclass of TimeEntry, so that's right).

The problem I see is that time is so useful as to imply that recurrances are too important to move completely to another part (i.e. an RSS 1.0 user might find this very useful).

See also: issue 9: Simplicity

Actions:

3. Period

I'm not sure how useful/confusing Period is. Period implies that you could have a different structure for events, namely

<Vevent> 
	<duration> 
		<Period> 
			<dtstart> 
				<Date-Time /> 
			</dtstart> 
			<duration> 
				<Duration /> 	
			</duration> 
		</Period> 
	</duration> 
</Vevent> 

rather than

<Vevent> 
	<dtstart> 
		<Date-Time /> 
	</dtstart> 
	<duration> 
		<Duration /> 
	
	</duration> 
</Vevent> 

Does this imply that a Vevent is a Period? or maybe a specific sort of Period (at a certain location maybe)?

See Also: issue 10: is Duration a good name?

Actions:

4. How do we model resources/locations/date-times?

Requirement:

We want to be able to say, Dan attends meeting x; Eric attends meeting x; x is a teleconference; Dan has location Bristol; Eric has location Boston. Dan leaves the meeting early.

This means that we need to attach locations and potential date-times to people and resources as well as to events. SKICal has something like this for resources. Related is the rfc 2445's use of freebusy properties. Freebusy chunks of time pertain to people or possible resources, not to events. the attendee property specifies the person whose time is free or busy.

Resource-slices versus events

We can look at events primarily as events with attendees, locations etc or as resources and people whose time is taken up with events and who are situated at locations; or as locations who have people and resources at them at particular times.

Damian Steer suggested that we

[[
take the view from physics that events are points in spacetime: , that
is position (x,y,z) at time t. 
]]

http://swordfish.rdfweb.org/~pldms/addition.html

I'd say that we need to talk about things - people and resources - at points in space-time ('resource-slices'). In fact I'd say that these are the only things about which we can talk about with any certainty in terms of time and location.

To clarify - what we talk about as events are vaguely defined. An event is many different things to different people - meeting, hours of opening, conference, holiday, lunch, flight, and they often seem to have very little in common, which is why defining them is so difficult. Moreover, events of thse kinds cannot be defined by location (teleconferences, flights), people or resources (people can leave the meeting and it's still the same meeting), or even time (for example modelling events like conferences in terms of a single event which stops and starts for sleeping etc, or as many events).

My suggestion is that events of the sort we are talking about (not the physics kind) are vague, socially determined constructs. These events encompass a vast number of things we might want to talk about which are not points in space time as Damian suggests. Instead they are vague groupings often at rough locations, approximate times, with varying resources and people attending.

Attaching date-times and locations to resource-slices

If we go along with this point of view then resource-slices are _defined_ as resource-datetime-locations. The difficulty is quite how we express this, and also how locations and date-times attached to events relate to resource-slices.

Maybe the practical solution is to attach different properties to calendar users than those we attach to events, which specify the portions of their time taken up. For archiving we need to have at least the possibility of stating this (e.g. alibis!)

An example of attaching locations and datetimes to people:

<Vevent>

<dtstart>
	<Date-time rdf:value="2001-08-09T:20:00:00Z" />
</dtstart>

<dtend>
	<Date-time rdf:value="2001-08-09T:21:00:00Z" />
</dtend>

<participant>
	<Cal-user>
		<foaf:name>dan</foaf:name>
		<dtend>
			<Date-time rdf:value="2001-08-09T:20:30:00Z"/>
		</dtend>

		<location>
			<Geo>
				<cn>Bristol</cn>
			</Geo>
		</location>
	</Cal-user>
</participant>

<participant>
	<Cal-user>
		<foaf:name>eric</foaf:name>
		<location>
			<Geo>
				<cn>Boston</cn>
			</Geo>
		</location>
	</Cal-user>
</participant>

</Vevent>

See also issue 6: Events within events

Possible actions:

5. Text/literals and DAML

Following the DAML examples at

http://www.daml.org/2001/03/reference.html#Values

RDF calendar has been modelling all datatypes as objects with rdf:values and not as literals. In the case of Text, I think there's a case for allowing literals or Text. Text is the better option since it allows for internationalization. However for description, name etc, a literal would do just as well in most cases.

so - do we have to have one or the other? which is better? (especially from the point of view of, say. RSS 1.0 users)

See also issue 9: simplicity

Actions:

6. Cal-user/cal-address

Cal-address is a misleading term for the object or resource referred to in rfc 2445. Often the identifier for the object is confused with the object itself, e.g. cal-address has a common name.

Cal-user is better, but I'm still not sure it's correct, given the discussion above about people-time-place slices. I'm beginning to think that we should distinguish between a person or resource and a time and place located part of a person or resource. Cal-user doesn't seem like quite the right term for this. its too connected with the notion of using an application rather than a resource-slice or person-slice. Slicing isn't particularly good either though...

Action

7. Vcalendar

A Vcalendar is an arbitrary group of events. It has no modeling significance at all, and is akin to a document in RDF in that sense. I think it is misleading to talk about events which may be related or unrelated grouped in this way.

Action

8. Is calendar component a good name?

Calendar component is strongly attached to the idea of a calendar as a document, which isn't too helpful because the things we are interested in are the events, and not in their arbitrary container. Vevents are in fact rather different from Vtodos and Vjournals in this respect - we need to distinguish between something like a dated document (a Vjournal or Vtodo) and a description of an actual occurence (a Vevent). Currently cal-component is a superclass of all of these.

See also issue 7:Vcalendar

Action

9. Events within events

Connected to the notion of events as social constructs is the idea that we can be at more than one event at a time: a conference and a particular presentation for example. This is rather like locations: I'm in England and in Bristol and in 8-10 Berkeley Square and in room T11. Some events are not exclusive of each other. The only thing that does create constraints is the date-time-location of resources (and people) - the atoms that we can be definite about. [This reminds me of the vagueness literature in economics]

so...

Practically (see Damian's notes) we want to be able to connect two events together in a hasPart type of relationship (icalendar rdf 2445 has a parent/child relationship for this). This causes problems for query engines which cannot do transitive closure (am I at conference A? all I can find out is that I'm at presentation B - which happens to be part of conference A).

If we attach date-times to resource-slices a similar problem arises for querying, although I don't think this is too important.

We should note though that there are implicit semantics. If I'm at a meeting that means my person-slice is busy for that period (I would suggest) _unless_ date-times attached to my person-slice specify otherwise. However, there are cases in which this is not true: for example I am at a parent conference event but that doesn't mean that I'm busy at the time of a particular presentation.

I can think of two ways to distinguish the former case from the latter:

1. where there's a child-parent relationship attendance at either is not exclusive

2. some events are of a different type and allow attendance at other events at the same time.

Action

10. Simplicity

RDF calendar schema is much too long and complex.

Action:

11. Is Duration a good name?

In the current RDF calendar schema, there is both a duration property and a Duration class. I would suggest that Time-quantity or somesuch would be a better name for the class

Action