- From: <Patrick.Stickler@nokia.com>
- Date: Mon, 5 May 2003 15:56:25 +0300
- To: <jjc@hplb.hpl.hp.com>, <w3c-rdfcore-wg@w3.org>
> -----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