- From: Geoff Chappell <geoff@sover.net>
- Date: Sun, 15 Dec 2002 10:17:22 -0500
- To: "'Graham Klyne'" <GK@NineByNine.org>, "'www-rdf-calendar'" <www-rdf-calendar@w3.org>
> -----Original Message----- > From: www-rdf-calendar-request@w3.org [mailto:www-rdf-calendar- > request@w3.org] On Behalf Of Graham Klyne > Sent: Sunday, December 15, 2002 8:33 AM > To: www-rdf-calendar > Subject: RDF semantics, access control description and timeranges > > [...] > ... > > I think there may be pitfalls here for some RDF usage for time intervals > based on iCalendar. > > This example is excerpted (somewhat randomly) from > http://www.ilrt.bris.ac.uk/discovery/2001/06/content/track1.rdf: > > [[ > <ical:VEVENT rdf:about="http://test.example.com/events/116"> > <ical:DTSTART> > <ical:DATE-TIME> > <util:hour>09</util:hour> > <util:minute>45</util:minute> > </ical:DATE-TIME> > </ical:DTSTART> > > <ical:DTEND> > <ical:DATE-TIME> > <util:hour>10</util:hour> > <util:minute>30</util:minute> > </ical:DATE-TIME> > </ical:DTEND> > </ical:VEVENT> > ]] > > (I've removed statements to focus on a simple core example.) > > Suppose this is being used in an access permission scenario like that > described above, to indicate a time period during which access is to be > permitted. Asserting a graph containing this to describe some access > permission would also mean that a graph otherwise the same but containing > the following would also be true: > > [[ > <ical:VEVENT rdf:about="http://test.example.com/events/116"> > <ical:DTSTART> > <ical:DATE-TIME> > <util:hour>09</util:hour> > </ical:DATE-TIME> > </ical:DTSTART> > > <ical:DTEND> > <ical:DATE-TIME> > <util:hour>10</util:hour> > </ical:DATE-TIME> > </ical:DTEND> > </ical:VEVENT> > ]] > > What is this to mean? Does this include the time instant 9:30? Is access > granted at 09:30? Looking at the previous access control example, the > subgraph lemma would suggest not. Now consider we wish to make timings > accurate to a second, and add a <util:second> property thus: > > [[ > <ical:VEVENT rdf:about="http://test.example.com/events/116"> > <ical:DTSTART> > <ical:DATE-TIME> > <util:hour>09</util:hour> > <util:minute>45</util:minute> > <util:second>0</util:second> > </ical:DATE-TIME> > </ical:DTSTART> > > <ical:DTEND> > <ical:DATE-TIME> > <util:hour>10</util:hour> > <util:minute>30</util:minute> > <util:second>59</util:second> > </ical:DATE-TIME> > </ical:DTEND> > </ical:VEVENT> > ]] > > It seems that, using RDF, it is difficult to construct usage scenarios in > which adding additional properties can be used to refine the precision of > what is specified. To do that requires a form of default reasoning, which > is non-monotonic. > > I'm left thinking that some practical guidelines are required to avoid > such > potential problems in general RDF use. > Don't these problems only arise when you assume defaults based upon the absence of information? You really don't have the right to assume that a missing util:minute value means that the value is 0, do you? (I guess you do within the confines of an application but at that point you are assuming a closed world.) By just specifying the hour you've constrained the interpretations some but not enough to select a single one. A cardinality constraint on util:minute (i.e. cardinality=1) would help to inform the app that there's some value for this thing even if you don't know what it is. Absent a vocabulary for specifying that in rdf (e.g. owl), I guess that knowledge must reside within the application code. -Geoff Chappell > #g > > > ------------------- > Graham Klyne > <GK@NineByNine.org>
Received on Sunday, 15 December 2002 10:17:56 UTC