Changes to iCalender ontology to make calendar files diffable

To make the graph labelled enough for doing a diff,[1], with calendar 
data, here are the fixes I had to make (a copy of) to the ontology:

1.  One needs to identify the calendar itself - I suggest by
giving an inverse functional property (IFP)  :publishedAs  
<http://whatever/...>.
This allows one to say which calendar has changed.
It is also useful information.

2. Same problem with a alarms - I suggest adding an alarm id as 
evolution does,
a functional property.

3. tzid is tricky.  When used to in a timezone definition it acts as a
an identifier of the timezone, but then the tzid property turns up on 
the events too.
This implies that they are all timezones, if we make tzid an ifp.

Solution:    instead of
	 timething   :tzid "whatver";
write
	 timething   :timezone  [ :tzid "whatver" ]

where timezone is FP and tzid is IFP.
This does the right thing

With these changes, a file like
http://www.w3.org/2000/10/swap/test/delta/ical/patch.n3
can be generated from an old calendar
http://www.w3.org/2000/10/swap/test/delta/ical/from.n3
and a new calendar
http://www.w3.org/2000/10/swap/test/delta/ical/to.n3
and the patch (a) makes sense when you look at it and (b) can be used 
to regenerate the new file given the old file and (c) won't 
accidentally patch the wrong thing in the case where the calendar being 
patched has extra triples from other (consistent) information received.

Could the calendar ontology folks please make the changes? I think that 
sync is really important for calendars, and it needs.

(The fact that this makes this OWL full.
That does not worry me personally, but if there is a conflict then this 
makes it a
point of discussion, I suppose.)

Tim

Received on Tuesday, 23 March 2004 16:36:41 UTC