Re: Language tags as values - document consequences (Concepts and MT)

On May 10, 2013, at 12:38 PM, Andy Seaborne wrote:

> 
> 
> On 10/05/13 17:39, Pat Hayes wrote:
>> 
>> On May 10, 2013, at 8:18 AM, Andy Seaborne wrote:
>> 
>>> I think the consequences for treating language tags as values or as
>>> lower case string in the value space are:
>>> 
>>> Concepts: 1/ Remove ", and must be normalized to lowercase."
>>> 
>>> 2/ Put in, after 5.1, a datatype description for rdf:langString.
>>> 
>>> I think this should go in anyway so that concepts has more on
>>> rdf:langString.
>>> 
>>> 3/ Add rdf:langString as a to section 5.4 as recognized Datatype
>>> IRI.
>>> 
>>> MT: 4/ Remove requirement for rdf:langString.
>>> 
>>> MT currently says that RDF processors "MUST recognize
>>> rdf:langString and xsd:string".
>>> 
>>> Instead, RDF processors are not required to recognize any datatype
>>> IRIs.
>> 
>> I like that, but please can we have a DECISION on this quickly, as it
>> would need a major edit to Semantics. (It would make it a lot
>> simpler. It is really a host of minor edits which I can do in one
>> day.)
>> 
>> Also, we still need to decide whether or not
>> "Ilovelanguagefivehundred"@500^^rdf:langString  is just silly, or an
>> ill-formed literal, or a syntax error. Its going to be a probem for
>> someone, for sure, but if its ill-formed then it is a problem for
>> me.
> 
> IMO
> 
> "Ilovelanguagefivehundred"@500
> 
> should be treated like "thenumber14"^^xsd:integer - fails as a D-entailment because the (generalised) lexical form ("Ilovelanguagefivehundred", "500") has a language tag not matching the rules of BCP47.

I know it doesnt match the rules of BCP47. So what does this mean for RDF? Do we say it is a parse error, so this triple simply does not exist (cannot possibly occur) in the abstract syntax? Or do we say, it is legal syntax, but (like "abc"^^xsd:integer ) it is an ill-typed literal? The semantics needs to know. 

If it is syntactically legal but ill-typed, then I need to do extensive editing of the semantics document, because that will mean that a graph can be RDF-inconsistent. RIght now that is impossible, and I have been relying on that impossibility to keep things simple. 

Pat


> 
> This is independent of registration of language tags - we could add that it must be any current or previously registered language tag but the grammatical rules of BCP47 are enough and look to be the best future proof approach.
> 
> FWIW: The syntax rules of Turtle forbid it at the character-parsing level - not so for RDF/XML - but they do pass @XX-500.
> 
> 
> 	Andy
> 
>> 
>> Pat
>> 
>> PS. For the record, built-in (required) datatypes are a royal PITA
>> for the Semantics editor. rdf:XMLLiteral was a PITA in 2004 and
>> xsd:string and rdf:langString are a PITA now. In Semantics they are
>> like heavy sacks that you have to keep strapped to your belt all the
>> time because regulations say you must, but all they do is get in the
>> way and trip you up when you are in a hurry. But thats just from the
>> editor's point of view.
>> 
>> 
>> 
>>> 
>>> This licenses current systems.
>>> 
>>> Recognizing xs:string is about bad characters in the lexical form.
>>> This isn't what all systems do for, say, control characters.
>>> 
>>> 
>>> 
>>> 
>> 
>> ------------------------------------------------------------ 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
>> 
>> 
>> 
>> 
>> 
>> 
> 
> 

------------------------------------------------------------
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 Saturday, 11 May 2013 01:31:01 UTC