Re: Explanation? of difference between Patrick and Brian [was: Re: Intentions of XMP]

[Patrick Stickler, Nokia/Finland, (+358 40) 801 9690, patrick.stickler@nokia.com]


----- Original Message ----- 
From: "ext Brian McBride" <bwm@hplb.hpl.hp.com>
To: "Patrick Stickler" <patrick.stickler@nokia.com>; "RDF Core WG 7332#" <w3c-rdfcore-wg@w3.org>
Sent: 27 September, 2002 10:17
Subject: Explanation? of difference between Patrick and Brian [was: Re: Intentions of XMP]


> At 08:45 27/09/2002 +0300, Patrick Stickler wrote:
> 
> [...]
> 
> >I'd have preferred the question be asked in terms of neutral names as in
> >the original:
> >
> >    <a> <b> "foo" .
> >    <c> <d> "foo" .
> >
> >As expressed, knowledge about the properties you have picked, built into
> >XMP may have influenced the answer.
> >
> >         But Brian, it is *precisely* that built in knowledge we are
> >         testing! Does XMP interpret those literals as denoting
> >         stings or values.
> 
> Eureka!  That is the test *you* are applying.  I think I may have 
> understood why we don't seem to be understanding each other here.  How is 
> this for a description of the test you are applying:
> 
> Does:
> 
>    <a> <b> "10" .
>    <b> rdfs:range xsd:int;
>    <c> <d> "10" .
>    <d> rdfs:range xsd:string .
> 
> entail
> 
>    <a> <b> _:l .
>    <c> <d> _:l .
> 
> A system for which this entailment holds is Patrick-tidy.  A system which 
> does not is Patrick-untidy.

Right.

Or to use the "new" terms, a MT for which the above entailment
holds is employing string-based semantics for inline literals whereas
a MT for which it does not hold is employing value-based semantics
for inline literals.

Also, I would expect that if the MT is asserting a string interpretation
on inline literals, then the xsd:int range assertion would represent
a type clash. Thus, I see a tidy MT to introduce a fundamental conflict
between the interpretation of inline literals and the semantics of
rdfs:range -- unless of course the MT did some special tricks to keep
the semantics of the two disjunct.

> The test I (the wg?) have been using is (modifying the literal in a neutral 
> way) is does:
> 
>    <a> <b> "10" .
>    <c> <d> "10" .
> 
> entail
> 
>    <a> <b> _:l .
>    <c> <d> _:l .

I consider the first entailment test to be compatable
with the second, but that the second is not sufficiently
precise to serve its real purpose. We could have another 
compatable test

Does:
 
   <a> <b> "10" .
   <b> rdfs:range xsd:int .
   <c> <d> "10" .
   <d> rdfs:range xsd:int .

entail

   <a> <b> _:l .
   <c> <d> _:l .

where you would always get a 'yes' answer yet miss the crucial
point of *why* it is compatable with either a Patrick-tidy
or Patrick-untidy MT. Because the non-mnemonic test with
no indication of any property-bound datatyping does not
make this clear, the results of such a test are ambiguous.

This is why I added clear, and conflicting, datatyping
assertions to the test, so that the basis of the answer
would be brought to the fore. If Adobe had answered 'no'
to my test, then it would have been unquestionably clear
that they were basing equality on string-equality rather
than value-equality. If, however, they would have answered
'yes' to your test, it would still have remained unclear
why, and whether they were perhaps presuming the same
datatype assertion for both properties, since after all
"10" surely looks like an integer, so they're probably
the same, eh?

I tried to point out this concern about the query to the
RDF community, and I did not think it was understood then,
and I'm not sure it is yet understood.

> It is possible for a system to be both tidy (in the sense above) and 
> Patrick-untidy, but only if it is non-monotonic.

Well, seeing as monotonicity has been a presumed requirement, I would
say that the above test does not allow one to clarify whether or
not it is Patrick-untidy. It might be. It might not be. It depends
on what the datatype assertions are for the properties, if they
are known.

I would not want to say that two literals are considered equal
if they are string-equal, unless later some datatyping assertion
changes the meaning of one or the other.

> This is actually a plausible implementation strategy for some systems, but 
> I believe would not be acceptable in the model theory.

I agree that having non-monotonicity between the RDF and 
application layers, or based on default interpretations
as strings which are overridden by range assertions as
values would not be acceptable.

> Does that bring us any closer to understanding?

I hope so, if you now understand why the non-mnemonic test with
no range assertions is insufficient to clarify a tidy versus
untidy MT.

Patrick

Received on Friday, 27 September 2002 04:31:53 UTC