RE: RDF semantics, access control description and timeranges

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