Re: Semantics issues

From: pat hayes <phayes@ai.uwf.edu>
Subject: Re: Semantics issues
Date: Tue, 21 Jan 2003 12:07:49 -0700

[...]

> >>  >No.  Now typed literals are handled somewhat better, but untyped literals
> >>  >are still rather strange, because the denotation of "a" is not necessarily
> >>  >in CEXT(I(rdfs:Literal)).
> >>
> >>  True, it is not necessarily in that class extension. Why does that
> >>  bother you? There is no way in any piece of RDF syntax to assert that
> >>  it (or any other particular literal) is or is not in that class, so
> >>  to impose a semantic condition which cannot be expressed
> >>  axiomatically would serve no purpose other than to guarantee
> >>  incompleteness of any inference system.
> >
> >Well, so what?  Is this any different than the situation with respect to
> >RDF datatypes?  How is this any different from the situation with respect
> >to rdf:XMLLiteral?  It seems to me that if you can handle rdf:XMLLiteral
> >you should be able to handle untyped literals being in
> >CEXT(I(rdfs:Literal)).
> 
> Well, we could handle them, as you put it, by insisting that 
> ICEXT(I(rdfs:Literal)) = LV. I did consider that alternative, and it 
> would be easy to make the modification. I presume you would prefer 
> that.

Not only do I prefer it - I also don't see any rationale for having it
otherwise.  Note, however, that there are noticeable consequences of this
decision.

> >>  >[...]
> >>  >
> >>  >In the LCC document, datatypes are still broken.  For starters, the
> >>  >document is inconsistent with respect to just what is a datatype; sometimes
> >>  >it is a member of the domain, sometimes it is a URIref.
> >>
> >>  I have not detected that inconsistency, can you point me at where it
> >>  occurs? The document uses datatype urirefs to refer to datatypes,
> >>  which seems consistent to me.
> >>
> >>  The intent is that recognized datatypes are always members of the domain.
> >
> >Then how do you justify
> >
> >      The set of recognized datatypes always includes rdf:XMLLiteral
> >
> >in Section 3.4?
> 
> Er.. What kind of justification do you need? rdf:XMLLiteral *is* a 
> member of the domain, that follows from the general assumption that 
> URIrefs always denote. The quote that you want justified is supposed 
> to be part of the definition of 'recognized', not a lemma that needs 
> to be established.
> 
> I didnt say 'rdf:XMLLiteral' was a member of the domain, notice 
> (though it is, as a matter of fact.)

I get very uneasy when formal tokens are written down as if they stood in
for their denotation.  What happens if there are two interpretations under
consideration, for example?  

The text of the RDF Semantics document sometimes uses tokens of the form
aa:bb as if they meant URI references, e.g., ``IEXT(I(rdf:subject)'', and
sometimes as if they meant elements of domain, e.g., ``the rdf:subject
property''.  

I remain confused as to just what datatypes are.

> >>  >The treatment of
> >>  >rdf:XMLLiteral is very suspect, for example what happens to "a"^^ex:foo if
> >>  >I(rdf:XMLLiteral) = I(ex:foo)?
> >>
> >>  If that identity holds (which would be rather extraordinary) then
> >>  ex:foo would in fact be rdf:XMLLiteral, ie
> >>
> >>  owl:sameIndividualAs ex:foo rdf:XMLLiteral .
> >>
> >>  would be true. So in that case indeed, the typed literal you have
> >>  written would have the same value as "a"^^rdf:XMLLiteral in that
> >>  interpretation.
> >
> >Not according to the RDF model theory.  In this model theory rdf:XMLLiteral
> >is handled very differently than other datatypes.
> 
> The intention is that it should be handled exactly similarly (apart 
> from the lang tags complication) . But I see that there is a crack, 
> indeed, since I do not define L2V for XML literals.  See below.
> 
> >rdf:XMLLiteral is
> >handled (in Section 3.1) by
> >
> >	if xxx is a well-formed XML document,
> >	then IL("xxx"^^rdf:XMLLiteral) is the XML canonical form of xxx
> >	...
> >
> >Other datatypes are (very awkwardly) handled in Section 3.4, by
> >
> >	... satisfies the following extra conditions on all datatypes other
> >	than the built-in datatype:
> >	...
> >	For any typed literal "sss"^ddd or "sss"@ttt^^ddd, if I(ddd) is in
> >	D and 'sss' is a valid lexical form for I(ddd) then IL("sss"^^ddd)
> >	= L2V(ddd)(sss)
> >
> >(By the way, this appears to imply that the only lexical forms that matter
> >are ones that start and stop with a single quote.
> 
> Yes, the use of those single quotes is a mistake, I will remove 
> those. And you are right, I should have said IL("sss"^^ddd) = 
> IL("sss"@ttt^^ddd) = L2V(ddd)(sss), an editorial slip, sorry.
> 
> >  Also, this is missing
> >the interpretation of "sss"@ttt^^ddd.)
> >
> >So "a"^^ex:foo falls through the cracks.  It doesn't match the conditions
> >in Section 3.1 because it has the wrong URI ref and it doesn't match the
> >conditions in Section 3.4 because they don't hold for I(rdf:XMLLiteral).
> 
> They do if the L2V mapping of rdf:XMLLiteral is defined properly. I 
> see that there is a editorial crack here, in that I do not mention 
> the L2V mapping when describing rdf:XMLLiteral, since the concept of 
> a lexical-to-value mapping is not introduced until the section on 
> datatyping. This needs to be fixed, indeed, but its purely an 
> expository point.

I disagree.   The meaning of literals typed with rdf:XMLLiteral is defined
very differently from the meaning of other typed literals.  Fixing this is
more than an expository point.  

> (The reason for this is the decision, taken rather late in the day, 
> to treat XML literals as a built-in datatype rather than a 
> syntactically distinct form of literal. Unfortunately this screws up 
> the expository structure of the document somewhat.)

This does make for a rather difficult time for the document editor.
However, would it not be possible to just *change* how rdf:XMLLiteral is
handled to make it work more like the other datatypes?  

[...]

> >>  >The translation into Lbase is still broken with respect to rdf:XMLLiteral.
> >>
> >>  Can you be more specific?
> >
> >TR("sss"@ttt^^rdf:XMLLiteral) = L2V(TR["sss"],TR[ddd])
> >which incorrectly ignores the language tag
> >
> >I have pointed this out at least one before in a message to w3c-rdfcore-wg
> 
> Right, sorry. There is at least one version in which this has been 
> fixed, but it might have got lost in the last-minute document flurry. 
> Mia culpa. The best version of the translation gives the explicit 
> translation from Jeremy's document for each distinct type of literal, 
> which is obviously what should have been done in the first place.

I await a correct version of the Lbase appendix.


Peter F. Patel-Schneider
Bell Labs Research
Lucent Technologies

Received on Friday, 24 January 2003 13:02:53 UTC