RE: Languageless Typed Literals

> -----Original Message-----
> From: ext Jeremy Carroll [mailto:jjc@hplb.hpl.hp.com]
> Sent: 05 May, 2003 15:04
> To: Stickler Patrick (NMP/Tampere); jjc@hplb.hpl.hp.com;
> w3c-rdfcore-wg@w3.org
> Subject: RE: Languageless Typed Literals
> 
> 
> 
> 
> Patrick makes a fair case here -
> whichever we jump we are not really talking about large 
> substantive change,
> more details about how to present things.
> 
> The differences are displayable by test cases but, other than 
> one showing
> that language is relevant to XML Literals, not test cases 
> that are very
> compelling one way or another.
> 
> I'll try some in-line comments, with snips ...
> 
> 
> > > Jeremy:
> > > > Option 1:
> > > > XMLLiteral ceases to be a typed literal but we revert to the old
> > > > treatment  where it was simply a special.
> > >
> > >
> 
> > > I have three concerns about this option:
> > >
> > > a) we had comments
> > >
> > 
> http://lists.w3.org/Archives/Public/www-rdf-comments/2002JulSe
> p/0092.html
> > > linking to
> > > http://www.w3.org/2002/07/29-rdfcadm-tbl.html#xtocid103643
> >
> > The key argument here is that RDF applications shouldn't 
> have to have
> > XML infoset processors in order to compare XML literals. I don't see
> > how the proposed change affects that. If one is going to compare XML
> > literal values, one must canonicalize them. That is true whether the
> > values are treated as datatype values or built in XML 
> literal values.
> >
> > So the requirements on RDF processors appear to be 
> equivalent whether
> > we treat XML literals as typed literals or M&S like XML literals.
> 
> I agree concerning the bulk of the work .. with the reagle 
> resolutions we
> are sort of suggesting (but only sort of) that the parser 
> should do the
> canonicalization. Assuming this, then with the XMLLiteral is 
> just another
> datatype (option 3), the rest of the processing does nothing 
> special with
> them.
> With option 1, however, the API between the parser and the rest of the
> system needs to know about them, the internal representation 
> of literals
> needs an isXML bit etc. i.e. there is additional complexity 
> (not a lot, but
> not nothing) for the rest of the system concerning XMLLiterals.

Hmmm... I don't see option 1 as any different than the current approach.

The parser need not concern itself about canonicalization, nor does
the canonicalization need to be reflected in the graph. The XML literal
can be stored in the graph exactly as it occured in the RDF/XML
and only those applications that need to compare XML literals will
need to perform canonicalization.

But that is precisely the same for datatype values. Any application
that wants to compare datatype values needs to grok the datatype
and know how to perform the comparison.

The same for XML literals. Any application that needs to compare
XML literals will need to grok canonicalization and thus know how
to compare them.

So just as a datatype entailment may not be an RDFS or RDF entailment.
Likewise an XML Literal entailment may not be an RDF or plain literal
entailment.

Whether a given application chooses to perform canonicalization as
part of its own internal graph representation solution is a secondary
issue entirely. There is no requirement whatsoever that any triples
store would canonicalize XML literals -- just as there is no requirement
that any triples store would intern xsd:integer values as actual
integer values rather than typed literals.

As to having the XML bit, yes, it's needed, but it's really 
there already now as rdf:XMLLiteral. In either case, there is
an indication in the graph syntax that the literal is XML. We're
just changing that indication from a datatype to a simple bit.


> >
> > > and
> > >
> > >
> > 
http://lists.w3.org/Archives/Public/www-rdf-comments/2002JulSep/0165.html
> >
> > If I understand what is being said here (and I'm not 100% sure I do), the
> > key concern relevant to option 1 is about why we would have a special
> > type of literal to handle XML literals rather than just a
> > built-in datatype.
> >
> > The answer (now, presuming we nuke lang tags in typed literals) is that
> > per M&S, XML literals can be qualified by lang tag just as can plain
> > literals and the lang tag is significant to equality tests, so
> > XML literals
> > can't be addressed by a datatype, because typed literals don't take lang
> > tags.
>
>
> That's a fair answer, except that option 3 shows that we can hack around the
> problem, if we try hard.

Well, my answer was actually being a little sneaky in that it presumes
we first have decided that typed literals do not take lang tags, in which
case, it would not be possible (or very feasible) to hack around having
lang tags being valid for rdf:XMLLiteral  ;-)

Still, if we take it all as one package, I think option 3 is alot more
convoluted and potentially confusing than option 1, so taking a long
term view, option 1 is better -- and also is truer to M&S, leaving 
XML Literals as they were, but clarifying the issues relating to
equality (i.e. canonicalization).

Patrick

Received on Monday, 5 May 2003 09:11:00 UTC