- From: patrick hayes <phayes@ai.uwf.edu>
- Date: Thu, 2 May 2002 15:11:25 -0700
- To: Patrick Stickler <patrick.stickler@nokia.com>
- Cc: w3c-rdfcore-wg@w3.org
Let me go through the counterexample again more carefully, then respond to the points made. >On 2002-04-30 17:22, "ext Brian McBride" <bwm@hplb.hpl.hp.com> wrote: > >> At 16:54 30/04/2002 +0300, Patrick Stickler wrote: >>> On 2002-04-30 16:30, "ext Brian McBride" <bwm@hplb.hpl.hp.com> wrote: >>> >>>> At 09:58 30/04/2002 +0300, Patrick Stickler wrote: >>>> [...] >>>> >>>>> If the above answers are correct, then: >>>>> >>>>> 1. The addition of the following closure rule, IMO, resolves my objection >>>>> to the present datatyping specification: >>>>> >>>>> IF >>>>> >>>>> ?p rdfd:datatype ?d . >>>>> ?s ?p ?l . >>>>> ?l rdf:type rdfs:Literal . >>>>> >>>>> THEN >>>>> >>>>> ?s ?p ?x . >>>>> ?x rdfd:lex ?l . > >>> My point was only that under the current 'stake' version of the MT, this inference is not valid. To show that its not, I have to define an interpretation which makes the IF true and the THEN false. Just one interpretation is enough, and I can define it any way I like as long as it complies with the MT rules. So I chose an interpretation where ?d was a datatype which gave a different value to ?l than the string ?l itself. That allows me to define an interpretation for ?p which satisfies the IF part by having ?l be the lexical form, but doesn't satisfy the THEN part (without violating the datatyping). > >>> I had thought this suggestion was refuted by Pat supported by Jeremy >>>> and by Jos. >>>> >>>> http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2002Apr/0341.html >>>> http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2002Apr/0348.html >>>> >>>> Hmm, can't find Jos's message in the archive - am I halucinating again. >>>> >>>> [...] >>> >>> There seems to be some question as to the semantics and nature of >>> rdfs:Literal -- such that, as Pat understands it, my proposed >>> closure rule has a problem (though I still don't see where "10" >>> and 10 are required to be equal); but as I understand rdfs:Literal, >>> there does not seem to be a problem. >> >> Lets check our understanding of the counterexample. >> >> Pat defines a property PPP which is basically identity, i.e. >> >> _:x <PPP> _:x . > >Hmmm... OK, I did not understand that identity = equality. Why >didn't he just use daml:equivalentTo...? anyway... I could have done, but there was no need to impose that 'identity' on all interpretations; I only need to give a single counterexample to show non-entailment. > > is always true, by definition of the property. There is nothing to stop >> anyone doing that. > >Fair enough. > >> He then goes on to say that PPP is a datatype property: >> >> <PPP> <rdfd:datatype> <integer> . > >This does not say that <PPP> is a datatype property. It says >that the values of <PPP> are interpreted in terms of the >datatype <integer>. I.e. the datatype <integer> is associated >with the property <PPP>. True, Brian mis-spoke there. But the key point is that in the current MT, that 'associate with' carries a different meaning in the IF part (where it only checks lexical conformity, so everything comes out true) from in the THEN part (where it requires the bnode to denote the value 10, making the first triple false in this interpretation.) > >To say that <PPP> is a datatype property, one would have to >say > > <PPP> rdf:type rdfd:Datatype . > >> That is legal too. > >Yes, both of the above are legal, namely associating a datatype >with the <PPP> property and also declaring <PPP> to be a datatyping >property (though the latter is not what Pat is doing). > >> Now if I have: >> >> _:x <PPP> "10" . >> >> which again is legal: it says that _:x denotes "10", > >Right > >> then when your rule >> fires we also get: >> >> _:x <PPP> _:y . >> _:y <integer> "10" . >> >> Here _:y denotes 10, so we have: >> >> Since PPP is the identity function, 10 must equal "10", which it doesn't. > >But this is due to the same problem that causes trouble for >daml:uniqueProperty with the current datatyping proposal, that >a given property that has a datatype interpretation may have >either a lexical form (inline idiom) or datatype value (lexical >form or datatype property idiom) as its object. First, that isn't a *problem*, in my view. But in any case, the example interpretation does not have both lexical forms and datatype values as its object: it only has lexical forms, which is why the THEN part is false in this interpretation. >The closure rule is not introducing this problem, What problem? >though in >some cases it encounters it or makes it more evident. The closure rule is just plain invalid. Its easy to write invalid rules: what does that make evident? >The real problem is that we allow both lexical forms and datatype >values to occupy the same property object space. ? Of course we ALLOW them to. How could we possibly prevent them? > > This does not arise from the model theory; this arises from the definition >> of PPP. > >Well, actually it arises from the combination of the equality semantics >of <PPP>, the semantics of rdfd:Datatype which allows two variant types >of object that can never be equal They cannot be equal, but they can both be objects. RDF properties are not required to be single-valued. >, and the error of using a bnode datatyping >idiom in conjunction with a subject that denotes a literal and must >be equal with its object. Right, that is my point: this is an *error*. But notice that if someone writes the antecedent of your rule they are not using the bnode idiom; the closure rule introduces that idiom. The rule is a statement of an error. >I.e. knowing that (a) the lexical forms of <integer> can never equal >the datatype values of <integer> and (b) that the blank node of the >datatype property idiom denotes a datatype value, and (c) that <PPP> >is the identity/equality relation, then it is simply *wrong* to >make the statements in Pat's example. In this example, the 'IF' part is right, but the 'THEN' part is wrong. That is why the rule is not valid; that was the point of the example (which conforms to the pattern used in your rule. ) >It is no different from stupidly >saying > > _:x daml:equivalentTo "10" . > _:y daml:equivalentTo _:z . > _:z integer "10" . > _:x daml_equivalentTo _:y . > >Duh... Since _:x is a lexical form and _:y and _:z are both >datatype values and for integers these spaces are disjoint, >the above is simply wrong. > >RDF let's one say stupid and incorrect things. The ability to do >so is not (necessarily) a shortcoming of RDF. > >There is a prohibition against equality between the local and global >idioms, Not sure what this means, but I don't think it is correct. That is, the local and global idioms can be mixed together in any combination and are always consistent, in the current MT. (Some combinations are not compatible with a daml:uniqueProperty assumption, admittedly, but they are consistent in RDF.) >and that is a characteristic of the datatyping proposal itself, >not my proposed closure rule. > >You will encounter that problem What problem? >even without the closure rule, just >as you encounter problems with daml:uniqueProperty when both local >and global idioms are used with such a property. Well, you will be inconsistent with daml:uniqueProperty if you use both local idioms with the same property and object. I don't see this as being a problem, however. It seems to me to be exactly like the fact that this: ex:a ex:p "1" . ex:a ex:p "2" . ex:p rdf:type daml:uniqueProperty . is inconsistent in DAML. >The closure rule >does not introduce any form of expression that cannot be explicitly >made by a user. So if there is a problem here, it is with the core >proposal, not the closure rule. I don't see any problem. The rule asserts that one thing follows from another. It doesn't follow from it, however, so the rule is wrong. A user can assert either part of that rule (of course), but a competent user would know that they were saying different things and therefore would not expect one of them to be derivable automatically from the other. So where is the problem (other than, maybe, educating users to be competent users) ? The use of the various idioms is not inconsistent in RDF. If you allow the use of DAML primitives then you can express inconsistencies in new ways, of course; but any inconsistencies will have to be spelled out explicitly. > >> Your defense to this is not to attack the definition of Literal, a subject >> we (ok I) >> really don't want to reopen, > >Well, Brian, to be honest I don't see that it has been actually closed, >since I've be unnable to get a clear and definite set of answers to my >specific questions which would reflect a general understanding of the >issue by and concensus of opinion about the relationship between literal >nodes, rdfs:Literal, and rdf:Resource. Ive tried to answer them. The current MT (just published) answers them fairly explicitly (and slightly differently from the previous version of the MT) , but in English: (1) literal nodes denote 'bare' literals (ie character strings.) In effect, literals denote themselves, since literal nodes = literal values = literals (ignoring the XML bit and the lang). (2) rdfs:Literal is the class of literals. (3) rdfs:Resource is the universe, ie the set of all things that can be denoted by urirefs. There is no assumption that a uriref *cannot* denote a character string. The current MT is agnostic about whether rdfs:Literal is a subset of rdfs:Resource. It wouldn't be a great change to insist that it was, ie that rdfs:Literal rdfs:subClassOf rdfs:Resource . was true in all interpretations. If the WG want, we could make this change to the MT in the next version. It would still be possible to assert something like <ex:someURIref> [rdf:type] [rdfs:Literal] . [added later] It occurs to me that if we did do this, then Jeremy's entailment would be valid without datatyping but would still not be valid when datatyping was added, ironically. Specifically: A: <ex:Jenny> <ex:age> "10" . B: <ex:Jenny> <ex:age> _:xxx . _:xxx <rdfd:lex> "10" . C: <ex:Jenny> <ex:age> "10" . <ex:age> <rdfd:datatype> <xsd:number> . D: <ex:Jenny> <ex:age> _:xxx . _:xxx <rdfd:lex> "10" . <ex:age> <rdfd:datatype> <xsd:number> . Then (with this change to the basic MT), A entails B (since we can make B true by mapping _:xxx to the literal itself, which would satisfy the bare rdfd:lex truth-conditions in B) but C does not datatype-entail D (since the extra datatyping condition now rules out that possibility.) So with this change, adding datatyping information could make RDF slightly non-monotonic. >If those questions were 'closed' then I should have recieved immediate >answers from multiple people, all in agreement, and referencing various >posts or minutes. > >I don't see anything even close to that level of clarity or closure. I expect people thought it was obvious. > >Though, this is I think an orthogonal issue to that captured by >Pat's counter example to my closure rule. I agree. > >> but to say PPP is not a good datatype >> property; don't >> write things like that. > >I never said that, since PPP has never been asserted to be a datatype >property. > >> Maybe, if we need to talk further about this, you should call me +44 117 >> 312 9560. >> >> >> >> >>>>> >>>>> 4. Conflicts with daml:uniqueProperty will remain when both the >>>>> inline idiom and either the lexical form or datatype property >>>>> idioms are used for such a property in the same graph. >>>> >>>> >>>> Well, there is some wiggle room with the Cannes entailement as specified. >>>> <age> isn't unique, but ageA and ageB can be. >>> >>> I find it difficult to comment on the Cannes entailment specifically >>> because of the ambiguity of whether ageA or ageB are or are not >>> the same property. Jeremy himself said that they are not necessarily >>> different properties >> >> True. He was saying that he would be satisfied if it could be done with >> different properties. That's the issue the WG has agreed is a problem. >> It would be nice if it could be solved with just one property, but the >> problem as framed would allow two. You don't agree with that; fair >> enough; you are entitled to your opinion. But please respect the WG's >> decision on this. > >I think we are both reading into what the WG's decision was on this >issue. I don't think it is completely clear that the WG decided anything >other than "there's something important there" that needs clarification. > >I recall that we re-wrote it at the f2f with the presumption of a single >property, and that we discussed the issue of whether or not there was >an associated datatype with the inline idiom (not present in Jeremy's >original example) and never reached concensus other than "it's important". > >But let's drop it for the moment. I'd rather focus my energies on the >issue of equality (or prohibition of) between inline and bnode idioms, >which seems more and more to be a flaw in the present MT (or at least >something that will prove to be very inconvenient in alot of cases). >In a way, it constitutes a kind of incompatability between the local >and global idioms. I fail to see how. The chief utility of this version of the datatyping MT, seemed to me, was precisely that it removed all incompatibilities between the various idioms. >Touching the stake in the ground and allowing literals to denote >datatype values would remove all of these problems ....but create many problems elsewhere, and re-open several closed issues (untidy literals in the graph syntax and ambiguity of literal meanings in non-datatyped RDF, to name two.) Pat PS. Patrick: let me make a suggestion. I largely agree with your intuitions about what the in-line idiom ought to mean. However, I don't think it is feasible for this WG to make the required changes to RDF to accommodate these intuitions. So I decided some time ago to give up on this issue and think of it as a recommendation for RDF-2, rather than trying to make the required changes to RDF. Would you find that strategy acceptable as a compromise? -- --------------------------------------------------------------------- IHMC (850)434 8903 home 40 South Alcaniz St. (850)202 4416 office Pensacola, FL 32501 (850)202 4440 fax phayes@ai.uwf.edu http://www.coginst.uwf.edu/~phayes
Received on Thursday, 2 May 2002 18:11:48 UTC