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/2002JulSep/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.

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

>
> The question is whether the persons submitting the comments would be
> agreeable to the revision.
>

Tim and Massimo were the submitters.

> > b) how difficult would it be for Pat to go back and rework
>
> Good question. Pat?
>
> > c) impact on OWL support for XML Literals - webont are
> generally negative
> > about them, the more work they have to do, the less support
> there will be in
> > OWL for these.
>
> In a sense, we're not really changing the bulk of what is said about
> XMLLiterals:
>
> 1. the RDF/XML syntax remains the same
> 2. the NTriples syntax is analogous to the the present representation
>    (just moving a datatype URI 'rdf:XMLLiteral' at the end to an 'XML'
>     flag at the start)
> 3. canonicalization and equality tests remain the same
> 4. the semantics essentially remain the same in that one has a pair
>    of lexical form and (optionally absent) lang tag mapping to an
>    XML literal value
>
> It's simply the disassociation of XML Literals with the RDF Datatyping
> machinery that needs to be done -- and doing so notably simplifies
> RDF Datatyping (which I would presume OWL would be happy about).

I believe Peter at least would welcome simplifications to RDF datatyping -
it is only option 2 that does not give him that (XMLLiterals are
syntactically special typed literals as well as semantically special).

Jeremy

Received on Monday, 5 May 2003 10:00:13 UTC