- From: Pat Hayes <phayes@ihmc.us>
- Date: Wed, 18 May 2011 13:54:16 -0500
- To: Pierre-Antoine Champin <pierre-antoine@champin.net>
- Cc: RDF Working Group WG <public-rdf-wg@w3.org>
On May 18, 2011, at 12:32 PM, Pierre-Antoine Champin wrote: > I think I like proposal B as well. > > Just a thought, though: > > shouldn't we use another name than PlainLiteral for "literals with > language tag" ? Yes, I (now) tend to agree. I was trying to avoid terminology-bloat, but the confusion isnt worth it. How about rdf:Word or rdf:Text for a literal with a language tag? To distinguish a word in a language from a mere string, is the idea. Pat > > First, this is not exactly the same as the actual rdf:PlainLiteral datatype. > > Second, the term "plain literal" currently applies to both literals with > and without a language type, and I don't think changing that is a > reasonable option (will conflict with common use, existing documents, > not to mention recommendations such as SPARQL). > > pa > > > On 05/18/2011 12:57 AM, 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 18:54:51 UTC