Re: status of rdf:langString

On Feb 27, 2013, at 8:53 AM, Peter F. Patel-Schneider wrote:

> 
> On 02/27/2013 02:06 AM, Antoine Zimmermann wrote:
>> Le 26/02/2013 21:08, Peter Patel-Schneider a écrit :
>>> Is rdf:langString a datatype?  It sure looks as if it should be, but it
>>> isn't.
>> 
>> It is.
> 
> There is lots of wording strongly suggesting otherwise.

I think the resolution we have is, it is a datatype (Concepts refers to it as a "type", which what I would like cleared up) but it has an empty "throw-away" L2V mapping, and the actual interpretation of language-tagged strings is defined independently of the datatype, i.e. does not use the standard datatype machinery. So a literal with this datatype is not treated as a datatyped literal, but should be referred to as a "language-tagged string". Richard argued strongly that this was the only sensible way to proceed. 

Whatever we do, language tags are clearly an exceptional case, and the only decision to make is how best to handle this exception. My own preference in semantics is to define their semantics independently of datatyping, but treat "rdf:langString" as being a datatype name in all other respects. 

>>> The OWL WG finessed this issue a different way, that was consistent with
>>> datatypes.  This could be done here as well (the datatype rdf:langString
>>> takes strings of the form "xxx@ll", ...), but maybe my proposed fix for
>>> the Semantics could be made visible in Concepts.
>> 
>> We have debated this extensively and we reach an agreement. What you propose was proposed then, was rejected then (personally, I was in favour of it).
> 
> I'm not arguing (any more) for this solution, just a resolution on the status of rdf:langString that is carried through in the documents.  I suppose that it could be an instance of rdfs:Datatype without being a datatype, but that seems a bit strange (although not semantically ill-formed).

It is a datatype, but the semantics of those literals do not use the standard datatyping machinery. If we do not generalize datatypes to allow multiple strings (a decision that would mean RDF parsers would be obliged to use a one-character lookahead, Oh Woe), then this is about the best we can do, IMO.

Pat



>> 
>> AZ
>> 
>> 
> peter
> 
> 
> 
> 

------------------------------------------------------------
IHMC                                     (850)434 8903 or (650)494 3973   
40 South Alcaniz St.           (850)202 4416   office
Pensacola                            (850)202 4440   fax
FL 32502                              (850)291 0667   mobile
phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes

Received on Wednesday, 27 February 2013 16:00:43 UTC