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