- From: Dan Connolly <connolly@w3.org>
- Date: Tue, 23 Mar 2004 18:05:44 -0600
- To: Tim Berners-Lee <timbl@w3.org>
- Cc: www-rdf-calendar@w3.org
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