- From: Pat Hayes <phayes@ihmc.us>
- Date: Wed, 18 May 2011 13:51:02 -0500
- To: Richard Cyganiak <richard@cyganiak.de>
- Cc: RDF Working Group WG <public-rdf-wg@w3.org>
On May 18, 2011, at 12:26 PM, Richard Cyganiak wrote: > > Please, Pat, if you say “syntax”, then say “abstract syntax” or “concrete syntax”. These are completely different things. I read you proposal above as saying that rdf:PlainLiteral *would* be in the abstract syntax, but *not* in the concrete syntax. It's really hard to understand what you're trying to say if you don't keep those apart. By 'abstract syntax' you mean the graph syntax, right? As far as the internal form of URIs and literals is concerned, the graph syntax and surface syntaxes are virtually the same. In the graph syntax, literals are described as a string 'combined with' a language tag or datatype URI. The surface syntax we use here uses infix '@' for the first combination and '^^' for the second, but the URIs and strings and tags are identical. So I have been assuming that this close similarity between surface and graph syntaxes, at least at this sub-node level, would continue. >> ut that proposal, as I understand it, requires language tags in literals where language tags make no sense at all. I do not think this will fly, frankly: the user push-back will be overwhelming. > > So I write "chat"@en in Turtle, and that is interpreted as: has a datatype xsd:string, and a language tag "en". What about this is it that makes no sense at all? What do you see as triggering user pushback? I thought that the proposal added language tags even to things like "123"^^xsd:number, etc.., which was what I was referring to. But maybe that was a misapprehension. It is hard to keep track of the many proposals :-) > (AndyS and SteveH gave some examples of implementation difficulties that I still have to respond to, but I don't think those are what you are talking about?) > > Here's a clarified version of the proposal: > > 1) every literal has *both* a datatype and a (possibly empty) language tag; > 2) only xsd:string can have non-empty language tags; ?? Why do we want to hallucinate tags which are required to be empty on all typed literals? This seems weird to me. > 3) plain literals don't exist; > 4) rdf:PlainLiteral only for use inside systems that can't do language tags; ?? Are there any such systems? I thought the point of this datatype was to provide a type for 'untyped' , ie plain, literals. > 5) "foo" in concrete syntaxes is syntactic sugar for "foo"^^xsd:string. OK, but... > 6) "foo"@en in concrete syntaxes is syntactic sugar for "foo"^^xsd:string@en. ... why change the literal syntax in this way? > 7) the value of "xxx"^^yyy is L2V_yyy(xxx) > 8) the value of "xxx"^^yyy@zzz is <L2V_yyy(xxx), zzz> But that surely means that the type of such al literal should *not* be xsd:string, since strings cannot contain language tags. And so we still do not have a type for the values of plain tagged literals. The problem, seems to me, is that a "language-tagged string" really is not a string. What are the equality (sameAs) rules for tagged literal values, in this proposal? Is this consistent: _:x owl:sameAs "chat"@en . _:x owl:sameAs "chat"@fr . ? I think it should not be. Pat > > Best, > Richard > > > > > >> >> Pat >> >> >>> >>> So I'd argue that the proposal linked above, amended according to footnote 1, is preferable over Version B. >>> >>> Footnote 1: The proposal linked above suggests to completely remove rdf:PlainLiteral. That doesn't work, it has to be kept as a compatibility band-aid, like it is now. >>> >>> Best, >>> Richard >>> >>> >>>> >>>> -------- >>>> >>>> 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 >> >> >> >> >> > > ------------------------------------------------------------ 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:51:35 UTC