- From: Peter F. Patel-Schneider <pfps@research.bell-labs.com>
- Date: Fri, 28 Sep 2001 12:36:37 -0400
- To: phayes@ai.uwf.edu
- Cc: www-rdf-logic@w3.org
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