RE: language tags in typed RDF literals

>On Mon, 24 Feb 2003, Patrick.Stickler wrote:
>
>>  Get rid of them.
>>
>>  --
>>
>>  This means that my proposal scores on all three points.
>>
>>  1. By not changing XML literals as defined by M&S it's fully
>>  backwards compatible. Nothing whatsoever will break, because
>>  neither plain literals nor XML literals have changed at all.
>>
>>  2. By restricting the interpretation of datatyped literals to
>>  involve only lexical forms and datatype URIs, both of which
>>  are manditory, the semantics is simpler and more consistent.
>>
>>  3. By leaving out lang tags from typed literals, there's
>>  no more floatsom in the abstract syntax which is not
>>  relevant to the semantics.
>
>In other words, "punt the junk" into an old-style RDF literal?
>
>The "old school" literals become (in the abstract syntax), what: a
>triple of unicode string, language, "xml bit"?
>
>And the value space is the union of unicode strings, unicode string .
>lang tag pairs, canonical xml with the trickery used accoring to the
>current concepts definition?
>
>The datatyped literals in the abstract syntax are URIref x unicode
>string, with the syntax modified to make lang tags illegal (or
>irrelevant - they never make it out of rdf/xml)?
>
>I suspect there's quite a high editorial impact, but (as I'd expect/hope
>to see a move to datatyped literals in the longer run) I quite like
>this.

Speaking for semantics, there is an editorial impact whatever we do, 
even stick to the status quo, since the LC version didn't handle lang 
tags in typed literals (mia culpa) and trying to fix it is what led 
me to make the suggestion.

On balance the entire semantic framework would be simpler, and the 
'correct' text easier to write, if
1. we ban lang tags from all non-XML typed literals (change the 
syntax, that is)
and
2. make the XML case syntactically special.

Exactly how it is made special I really don't care, but I have to 
treat it specially in any case since it has to be incorporated into 
the RDF semantics early on in the document before I refer to the 
datatyping stuff, so having it be a datatype doesn't really help the 
Semantics editor at all.  The XML bit would be easier to talk about.

On the other hand, I have no real objection to handling it as a 
datatype if people feel this is useful. But I do NEED some input from 
the Concepts editors on some terminology I can use to refer to the 
things in the lexical and value spaces of this datatype.

>The flip side is the "editorial impact" call, and the question of
>whether Pat sees this as a "technical goer".

Yes, he does.

>This change would certainly
>require a second last call, since the close scrutiny of semantics,
concepts, syntax, plus a rundown of test cases would be necessary.

>
>I wouldn't object to this, but I'd understand a veto on the basis of
>"too much, too late", particularly if a second last call is not
>otherwise required, and also since the benefit doesn't extend to a
>completely uniform treatment of literals.
>
>jan
>
>PS. Another option: make _all_ literals typed.

Yes, the current position is that untyped literals can be seen as 
typed with the 'invisible' datatype whose lexical and value spaces 
are identical and whose L2V map is the identity. You could think of 
this as a default datatype, in fact: unless some other is mentioned, 
this is the one you get.

Pat

>We've invented a datatype
>for XMLLiterals, why not one for "plain" RDF literals. This still leaves
>te abstract syntax with one literal in the form of a triple:
>
>	unicode string, type, (lang tag /union /null)
>
>and requires lang tags to be available to l2v:
>
>- The road to lang tag deprecation is straightforward;
>- we can even prevent non-null lang tags on "normal" datatypes via
>	syntax restrictions in rdf/xml
>- there is a uniform treatment of all literals.
>
>
>--
>jan grant, ILRT, University of Bristol. http://www.ilrt.bris.ac.uk/
>Tel +44(0)117 9287088 Fax +44 (0)117 9287112 http://ioctl.org/jan/
>Don't annihilate, assimilate: MacDonalds, not missiles.


-- 
---------------------------------------------------------------------
IHMC					(850)434 8903 or (650)494 3973   home
40 South Alcaniz St.			(850)202 4416   office
Pensacola              			(850)202 4440   fax
FL 32501           				(850)291 0667    cell
phayes@ai.uwf.edu	          http://www.coginst.uwf.edu/~phayes
s.pam@ai.uwf.edu   for spam

Received on Monday, 24 February 2003 17:43:37 UTC