RDF semantics, access control description and timeranges

I'm writing this note because I've managed to confuse myself about 
semantics of RDF expressions.  I hope what I am saying is simple and 
obvious, but I'm finding it difficult to be sure.  The underlying point of 
all this is that care must be taken when defining RDF vocabulary to ensure 
that RDF's formal semantics are properly honoured.

My scenario is this:  I wish to write an RDF statement that describes some 
kind of access permission, for example that a network host can use HTTP, 
FTP and SSH protocols.

So I might write something like:

   ex:Host ex:access                         (1)
      [ a ex:AccessPermission ;
        ex:allowProtocol ex:HTTP ;
        ex:allowProtocol ex:FTP ;
        ex:allowProtocol ex:SSH ] .

which may be intended to mean that the host ex:Host is permitted to use 
protocol HTTP _or_ FTP _or_ SSH.  So far, so good, and this seems to be 
fully in conformance with the RDF formal semantics which says that if the 
above expression is true, then so is:

   ex:Host ex:access                         (2)
      [ a ex:AccessPermission ;
        ex:allowProtocol ex:HTTP ;
        ex:allowProtocol ex:FTP ] .

(See the "Subgraph Lemma" in http://www.w3.org/TR/rdf-mt/#entail )

So now I turn to my definition of the HTTP protocol, which might be:

   ex:HTTP  a ex:AccessProtocol ;            (3)
        ex:ipProtocol ex:TCP ;
        ex:portNumber "80" .

So now we may have this graph asserted to be true:

   ex:Host ex:access                         (4)
      [ a ex:AccessPermission ;
        ex:allowProtocol ex:HTTP ] .
   ex:HTTP  a ex:AccessProtocol ;
        ex:ipProtocol ex:TCP ;
        ex:portNumber "80" .

Then, by the subgraph lemma, this is true:

   ex:Host ex:access                         (5)
      [ a ex:AccessPermission ;
        ex:allowProtocol ex:HTTP ] .
   ex:HTTP  a ex:AccessProtocol ;
        ex:ipProtocol ex:TCP .

But what does this mean?  It would be tempting to say that by omitting the 
port number that no port-number constraint is given.  But clearly, it is 
not true that by permitting use of HTTP that we mean to permit use of all 
TCP protocols on all port numbers.  So this new subgraph must be 
interpreted as granting permission to nothing more than HTTP, and probably 
less.  Absent specification of a port number (which all TCP protocols must 
use) I think it should mean that no permissions are granted.

(So, in this scheme, by expressing an access permission in RDF, under open 
world assumptions, says nothing about what access is not permitted;  by 
saying that HTTP is permitted, we don't say whether or not FTP is 
permitted.  At some stage, to be useful, an access permission description 
may need to be closed off, so that all access not explicitly permitted is 
denied.  This may involve mechanisms that go beyond basic RDF core semantics.)

What has confused me in all this is that it appears to muddle conjunctive 
and disjunctive semantics semantics for RDF statements;  e.g. example (1) 
above meaning that permissions to use HTTP, FTP *or* SSH, but example (3) 
describing a protocol for which the IP protocol is TCP *and* the port 
number is 80.  Considered from the point of view of semantic 
interpretations, it's all conjunctive semantics, but that hasn't prevented 
me from getting confused about the details at times.

...

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.

#g


-------------------
Graham Klyne
<GK@NineByNine.org>

Received on Sunday, 15 December 2002 08:28:19 UTC