Impact of monotonicity in RDF (was: Social Meaning and RDF)

[Switched thread to RDF-interest]

At 06:57 AM 2/6/03 -0800, Seth Russell wrote:
>       And this is a real constraint, not just a form of words:
>       for example, RDF really is monotonic, and that imposes
>        some nontrivial conditions on *any* notion of RDF
>        meaning, social or otherwise. " .
>
>I can't seem to wrap my pee brain around the idea that this restraint is 
>useful in a nonmonotonic social world where truths are always popping in 
>and out of existance.   From a layman's perspective could you elaborate on 
>what this restraint really entails ?  How should we think about this as we 
>are reading and writing RDF assertions ?

I have some recent experience of how this impacts RDF design for a "real" 
application.  You need to be aware of the monotonicity constraints when 
defining new vocabulary terms.

My example comes from defining network access policies, in which I need to 
define a collection of Internet services that a person may be allowed to 
use.  An Internet service is typically defined in  terms of an IP protocol 
number (usually indicating UDP or TCP) and a port number.  So a web access 
service using HTTP is (usually) accessed using the TCP (IP protocol number 
6) on port number 80.

Using my vocabulary and Notation3, this would be expressed as:

[[
homenet:HTTP a user:ServiceProtocol ;
     rdfs:label           "HTTP service" ;
     user:ipProtocol      "TCP" ;
     user:includePort     "80" ;
     rdfs:comment
         """
         Web access using HTTP.
         """ .
]] -- EXAMPLE 1
adapted from http://www.ninebynine.org/SWAD-E/Scenario-HomeNetwork/Users.n3


It is also useful to be able to express multiple protocols in a single 
service description:
[[
homenet:P2PTCP a user:ServiceProtocol ;
     rdfs:label           "P2P TCP services" ;
     user:ipProtocol      "TCP" ;
     user:includePort     "1214" ;
     user:includePort     "6346" ;
     user:includePort     "6347" ;
     rdfs:comment
         """
         All peer-to-peer TCP services:
         FastTrack (1214), GnuTella (6346, 6347)
         """ .
]] -- EXAMPLE 2
excerpted from http://www.ninebynine.org/SWAD-E/Scenario-HomeNetwork/Users.n3

It is further sometimes useful to be able to specify that all port numbers 
*except* some specified values will be allowed.  An "obvious", but 
incorrect, way to code this might be:
[[
homenet:NonP2PTCP a user:ServiceProtocol ;
     rdfs:label           "Non-P2P TCP services" ;
     user:ipProtocol      "TCP" ;
     user:excludePort    "1214" ;
     user:excludePort    "6346" ;
     user:excludePort    "6347" ;
     rdfs:comment
         """
         All TCP services excluding peer-to-peer protocols:
         FastTrack (1214), GnuTella (6346, 6347)
         """ .
]] -- EXAMPLE 3
adapted from http://www.ninebynine.org/SWAD-E/Scenario-HomeNetwork/Users.n3

So why is this wrong?  The RDF subgraph lemma requires that if some RDF 
graph is interpreted as expressing a truth, then any subgraph must also be 
a truth.

In the case of EXAMPLE 2 above, if it is true that the three ports 
enumerated can be accessed, then it is also true that any two of them can 
be accessed.  E.g., the following is also true:
[[
homenet:NonP2PTCP a user:ServiceProtocol ;
     user:ipProtocol      "TCP" ;
     user:includePort    "6346" ;
     user:includePort    "6347" ;
]] -- EXAMPLE 2A

But, looking to EXAMPLE 3, if it is true that any but the three ports 
mentioned can be accessed, we cannot safely assert that this is true:
[[
homenet:NonP2PTCP a user:ServiceProtocol ;
     user:ipProtocol      "TCP" ;
     user:excludePort    "6346" ;
     user:excludePort    "6347" ;
]] -- EXAMPLE 3A

So we need to find another way of describing all but some specified 
ports.  (My solution is in the file cited.)

...

Above, I've tried to answer your question "could you elaborate on what this 
restraint really entails" (or maybe what it does not entail?).  One has to 
choose the meaning of one's terms with a little care.

You also ask how this is "useful";  my explanation above suggests the 
reverse -- monotonicity is in some respects an impediment.  But in an 
open-world environment, in which one can *never* be sure of having all of 
the facts to hand, no conclusions can be drawn without an assumption of 
monotonicity.  So if we are to make inferences in such circumstances, we 
must have a monotonic framework.

Having an monotonic, open-world framework does not, in my view, mean that 
one cannot also have a locally applied closed-world assumption for some 
applications, but this strays outside the globally specified behaviour for 
RDF.  And the conclusions drawn by such an application cannot be returned 
to the global semantic web (unless somehow qualified by some expression of 
the closed world assumption used -- which might be presented as a "context").

#g


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

Received on Thursday, 6 February 2003 11:51:27 UTC