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

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

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

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.

The closure rule is not introducing this problem, though in
some cases it encounters it or makes it more evident.

The real problem is that we allow both lexical forms and datatype
values to occupy the same property object space.

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

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. 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, and that is a characteristic of the datatyping proposal itself,
not my proposed closure rule.

You will encounter that 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. 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.


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

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.

Though, this is I think an orthogonal issue to that captured by
Pat's counter example to my closure rule.

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

Touching the stake in the ground and allowing literals to denote
datatype values would remove all of these problems (yes, I know we're
not ready to do that, but it's good not to keep our heads too buried
in the present proposal as we examine its suitability).

Cheers,

Patrick 

--
               
Patrick Stickler              Phone: +358 50 483 9453
Senior Research Scientist     Fax:   +358 7180 35409
Nokia Research Center         Email: patrick.stickler@nokia.com

Received on Thursday, 2 May 2002 02:53:14 UTC