Re: Changes to iCalender ontology to make calendar files diffable

On Tue, 2004-03-23 at 15:36, Tim Berners-Lee wrote:
> 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.

The schema we're working on is designed to capture the semantics
or RFC2445. RFC2445 doesn't have such a notion, so it would
be... hmm... new and different at least, to add it.

Calendar sync is a pretty compelling use case, but I wonder
if it really requires changes to the icalendar-in-rdf schema.

I suggest using foaf:primaryTopic
  http://xmlns.com/foaf/0.1/#term_primaryTopic
oops; that goes the other way. I guess foaf:homepage is
what you need. Can you try that?

The toIcal.py will ignore it, but I suppose that's what you'd want.

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

the X-EVOLUTION-ALARM-UID should go in the evolution schema.
http://www.w3.org/2002/12/cal/prod/Ximian_NON_f7c377930cb82492.rdf

Hmm... I don't think toIcal.py preserves X- properties.


> 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.

Yes, RFC2445's modelling of timezones leaves a lot to be desired.

So far, we've preserved it, warts and all, in RDF.

Note that tzid isn't really inverse-functional: I can
use "America/Chicago" in one file as a tzid for U.S. central
time, but in another .ics file, I can use the same string
as a tzid for a completely different timezone.


> 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.)

Yes... OWL-DL can't handle inverse-functional datatype properties.

(see NOTE in section
http://www.w3.org/TR/2004/REC-owl-ref-20040210/#InverseFunctionalProperty-def)

> 
> Tim
-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/
see you at the WWW2004 in NY 17-22 May?

Received on Tuesday, 23 March 2004 19:12:55 UTC