Re: model theory for RDF/S

From: Pat Hayes <phayes@ai.uwf.edu>
Subject: Re: model theory for RDF/S
Date: Fri, 28 Sep 2001 10:57:10 -0500

[...]

> >>  If we are dealing with untidy graphs, the graph syntax has no
> >>  structural advantages over a lexical syntax, and it would then be
> >>  preferable to simply attach the model theory directly to the
> >>  N-triples notation (which in an earlier version of the model theory
> >>  is what we in fact did, but that had problems of its own.).
> >
> >There may be advantages to untidy graphs when looking at complex strategies
> >for literals.  In particular, in the model theory for DAML+OIL, merging
> >nodes whose labels are literals may change the meaning of the graph.  (Of
> >course the model theory for DAML+OIL doesn't use graphs, but if it did,
> >such merging would not necessarily be meaning-preserving.)
> 
> Ah, I had not thought of that in the DAML+OIL context.  Can you give 
> a simple example?

Consider the following, where one allows ranges to be XML Schema datatypes.
(I hope that this is more-or-less valid N3.) 

John age 0000025 .

Susan phone-number 0000025 .

age rdfs:range xsd:int .

phone-number rdfs:range xsd:string .

If there is a unique node for the literal 0000025, then what is the literal
value that it maps to?  Is it the string "0000025" or the integer 25?

[...]

> >>  However, Peter, a question for a professional Description Logician:
> >>  this would allow literals to be assigned non-literal property values
> >>  by an RDF assertion. Wouldn't that break DAML+OIL?
> >
> >DAML+OIL depends somewhat on the separation between resources and
> >literals.  Some Description Logics may break severely if their separation
> >between abstract (resources) and concrete (literals) domains is breached.
> 
> Right, that is what worries me. I recall this being a sticking point 
> in the DAML discussions for some people, so I presume it is fairly 
> critical there also, no?

Right now, it is probably the case that the theory of XML Schema datatypes
is weak enough and the constructs that use them in DAML+OIL are also weak
enough that no undecidabilities would arise if literals were also
resources.  (Implementation headaches do arise, however!)  If you want to
have a stronger theory for datatypes or more DAML+OIL constructs that use
them, you can easily introduce undecidabilites.  Combining two formalisms
requires great care!

[...]

> >>  >Taking care of rdf:type:
> >>  >
> >>  >A core RDF interpretation, i.e., RDF without reification or containers, is
> >>  >an interpretation over a vocabularly that includes rdf:type with the
> >>  >following extra conditions
> >>  >
> >>  >      1. IS(rdf:type) is in IP
> >>  >      2. IEXT(IS(rdf:type)) <= IR x IR
> >>
> >>  Is there any real need for condition 2 here in RDF?
> >
> >I don't know.  The condition is directly stated in M&S.  It says that
> >literals cannot have instances, which is probably a good thing.  I'm not sure
> >what the instance of "2" could be.
> >
> >>  I hope it can be
> >>  avoided, since it would mean that a triple
> >>
> >>  aaa rdf:type LLL .
> >>
> >>  where LLL is a literal, comes close to being a contradiction. Right
> >>  now, all it implies is that IR and LV overlap, but if anyone were to
> >>  ever claim that they didn't overlap, then it would be. I don't like
> >>  having land-mines concealed in the model theory.
> >
> >I'm not sure how you get this implication,
> 
> from your condition 2 on rdf:type, which would be
> rdf:type rdfs:range rdfs:Resource .
> in RDFS.
> 
> >  nor am I sure why literals need
> >to have instances.
> 
> I tend to agree, but there would be nothing in the syntax to prevent 
> someone writing a triple that says they do, so we would have to give 
> it a meaning.
> 
> Pat

Sure.  Doing this in DAML+OIL would result in a contradiction, because
DAML+OIL makes literals and resources disjoint.

However, I don't see that this is a problem in any case.  You can get a
similar situation as follows:

foo rdfs:range rdfs:Resource .

foo foo 7 .


peter

Received on Friday, 28 September 2001 12:35:55 UTC