- From: Pat Hayes <phayes@ihmc.us>
- Date: Thu, 2 Jun 2011 09:52:02 -0500
- To: Andy Seaborne <andy.seaborne@epimorphics.com>
- Cc: public-rdf-wg@w3.org
Brief comments inline. On Jun 2, 2011, at 4:51 AM, Andy Seaborne wrote: > I support for the direction this is taking. > > Some details to consider below inline: most important is that in SPARQL DATATYPE("foo@en) should be rdf:LTS. > > On 01/06/11 16:04, Lee Feigenbaum wrote: >> I'd just like to reiterate my strong support for this proposal from Pat >> and Richard. >> >> Lee >> >> On 6/1/2011 10:45 AM, Pat Hayes wrote: >>> 1. We retain the current surface syntax for plain literals with and >>> without language tags. Nothing in RDF/XML or TURTLE or N-triples or >>> any other actually used syntax for RDF changes in any way. > > Strong +1 > > We also recommend that the plain literal form is used, not ^^xsd:stringm on output in all serializations (including RDF graphs and SPARQL result sets) > > """ > libraries SHOULD output untagged plain literals in preference to literals with explicit datatype of xsd:string and SHOULD output tagged plain literals in preference to literals with datatype rdf:LTS > """ > >>> 2. Every literal has a type, which is a class name for the class of >>> possible values of all literals with that type. The type of a >>> datatyped literal is the datatype. Plain literals without language >>> tags are considered to have the type xsd:string (as SPARQL currently >>> assumes). Plain literals with language tags are considered to have a >>> new type rdf:LangTaggedString (or something shorter, to be decided. I >>> will use rdf:LTS for brevity). rdf:LTS is not, strictly speaking, a >>> datatype, since its 'lexical space' is<string, tag> pairs rather than >>> strings. but it is remarkably similar to a datatype and nothing would >>> break if you were to consider it a datatype, with the lexical space of >>> strings formed as<string>@tag and the L2V mapping L2V("sss"@ttt) >>> =<sss, ttt> > > The function in SPARQL that's affected is DATATYPE(literal) > > The problem is the name used is "datatype" "not "type". > > DATATYPE("foo"@en) should be rdf:LTS > > My preference is that L2V extended is defined to work on "sss"@ttt or ("sss", "ttt") -- either form -- > > I'm happy for SPARQL is slightly misuse the word DATATYPE and return the type. > > The STR(literal) function will still return the string part of the value or lexical form. > >>> 3. rdf:PlainLiteral is the superclass of xsd:string and rdf:LTS. > > As we are not invoking the fact it's a datatype, I still think its confusing to use rdf:PlainLiteral just for it's class-feature, not it's datatype-feature. > > The datatypes are xsd:string and rdf:LTS and rdf:PlainLiteral can't be a super-datatype because the lexical spaces are not compatible. > > Or to put it another way rdf:PlainLiteral works perfectly well for OWL and RIF so leave it alone. I am leaving it alone. But this use as a class name just comes out in the wash, with existing specs. So I am just noting it. >>> 4. The only change to the current specs is to distinguish 'type' from >>> 'datatype' and for clarity, maybe, change the terminology of 'typed >>> literal' to 'datatyped literal'. But even that is not really >>> necessary. All of this hassle comes from our insisting that the syntax >>> "foo"@baz must be a string paired with a tag, ie two syntactic items >>> rather than one. > > I don't consider it two syntactic items - I see it as one item with some (internal) structure. Better still. I guess I should have said, two character strings. > > We could even make this so in Turtle and define > <LTS> = <STRING>'@'[a-zA-Z]+ ( "-" [a-zA-Z0-9]+ )* > as a parser token. > > (At the moment, langtag is a grammar rule - you can have space between the " and @ unfortunately.) > >>> If we simply say that it represents the string >>> "foo@baz", which encodes a string and a tag and is to be used in a >>> special way determined by the datatype rdf:LTS, a way that follows the >>> existing rdf:PlainLIteral but is restricted to the tagged case, then >>> every type is a datatype and everything works smoothly, and we can >>> stop discussing this INCREDIBLY TRIVIAL matter and move on to more >>> important things. Ahem, sorry about the slight loss of control there. > > I prefer extending the range of L2V to cover "sss"@ttt and define the RDF/XML output of xml:lang="ttt" to be "sss"@ttt Whatever. Both ways work. Pat > > Andy > >>> >>> 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 Thursday, 2 June 2011 14:52:40 UTC