Re: Simplified proposal for string literals

On May 18, 2011, at 5:28 AM, Nathan wrote:

> Hi Pat,
> 
> I admit I've lost track of this now very long thread, however is there a reason why we don't simply swap out language tags for IRIs which denote a string in a particular language, where each language resource is a subtype of xsd:string, where the @lang is syntax sugar, and where the lack of any @lang indicates that the type is xsd:string.
> 
> "foo"@en -> TypedLiteral( "foo", rdf-lang:en )

Problem is, this actually says that the string "foo" itself has rdf-lang en. That means *every* occurrence of "foo", not just this particular one. So we would need to introduce identifiers for the particular use of "foo" in one literal as opposed to another literal. We could use bnodes, sigh. 

>   entails -> TypedLiteral( "foo", xsd:string )
> 
> "foo" -> TypedLiteral( "foo", xsd:string )
> 
> Pretty sure I'll have missed a detail as to why this isn't possible / viable though.

See above.

Pat

> 
> FWIW, I did like your rdf:PlainLiteralString proposal, and failing that (B) from below.
> 
> Best,
> 
> Nathan
> 
> Pat Hayes wrote:
>> As my proposed extension to rdf:PlainLIteral seems to have fallen on deaf ears, allow me to suggest a simplified version of it which might be more acceptable. There are two versions. In the first, plain literals are no longer strings. so the current equivalence between "string" and "string"^^xsd:string no longer applies. The second keeps this equivalence. Veraion A
>> 1.  rdf:PlainLIteral is a unique special datatype, built into basic RDF (along with rdf:XMLLIteral) with a special, unique formulation. It applies to plain literal syntax, which is thought of as specifying a pair of a string and a language tag. If no language tag is present, then the language tag of the literal is 'NULL'. The L2V mapping of this datatype takes the pair <string, tag> to itself, ie it is the identity mapping on these pairs. Put another way, the datatype value of "string" is <string, NULL> and of "string"@tag is <string, tag>. Every plain literal in RDF has the datatype rdf:PlainLIteral, even though this name is not used explicitly in the literal syntax. 2. rdf:PlainLIteral MUST NOT be used as an explicit datatype name in any RDF literal of the form "string"^^datatype. LIterals of the form "string@tag"^^rdf:PlainLiteral MUST be rewritten as a plain literal "string"@tag or flagged as an error.
>> 3. "string" is no longer sameAs "string"^^xsd:string (the first has a NULL language tag, the second has no tag at all.) Version B
>> 1.  rdf:PlainLIteral is a unique special datatype, built into basic RDF (along with rdf:XMLLIteral) with a special, unique formulation. It applies to plain literal syntax, which is thought of as specifying either a character string, or a pair of a string and a language tag.  The L2V mapping of this datatype takes both strings and pairs <string, tag> to themselves, ie it is the identity mapping on strings and on pairs. Put another way, the datatype value of "string" is  string  and of "string"@tag is <string, tag>. Every plain literal in RDF has the datatype rdf:PlainLIteral, even though this name is not used explicitly in the literal syntax. 2. rdf:PlainLIteral MUST NOT be used as an explicit datatype name in any RDF literal of the form "string"^^datatype. LIterals of the form "string@tag"^^rdf:PlainLiteral MUST be rewritten as a plain literal "string"@tag or flagged as an error.
>> 3. "string" and "string"^^xsd:string are equivalent, so to avoid equality reasoning, the datatype xsd:string is deprecated in RDF. RDF SHOULD NOT use xsd:string as a datatype in typed literals, and applications MAY rewrite any literal typed with xsd:strong as a plain literal with no language tag. --------
>> Either way, this keeps existing plain literal syntax exactly as it is at present, does not require anyone to rewrite any up-front code, and retains the rdf:PlainLIteral typing without getting involved with the trailing-@ messiness. It  requires one exception in the RDF semantics to allow this slightly nonstandard datatype, but I don't think this is of any importance at all, especially as the L2V mapping is so trivial. It will require short changes to Concepts and Semantics, and a quick check over Testcases, but we will be doing this anyway. FWIW, I marginally prefer  version B, as it settles the xsd:string business once and for all. But only marginally.
>> Pat
>> ------------------------------------------------------------
>> 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 Wednesday, 18 May 2011 13:45:02 UTC