W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > May 2002

Re: Specific questions regarding rdfs:Literal, possible closure...

From: patrick hayes <phayes@ai.uwf.edu>
Date: Thu, 2 May 2002 15:11:25 -0700
Message-Id: <p05111702b8f74fc7df87@[]>
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
>    <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",
>>  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
>   _: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

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 

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:

<ex:Jenny> <ex:age> "10" .

<ex:Jenny> <ex:age> _:xxx .
_:xxx <rdfd:lex> "10" .

<ex:Jenny> <ex:age> "10" .
<ex:age> <rdfd:datatype> <xsd:number> .

<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
>>  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.)


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
Received on Thursday, 2 May 2002 18:11:48 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:53:57 UTC