W3C home > Mailing lists > Public > public-rdf-wg@w3.org > June 2011

Re: keeping issue-12 simple

From: Pat Hayes <phayes@ihmc.us>
Date: Thu, 2 Jun 2011 09:52:02 -0500
Cc: public-rdf-wg@w3.org
Message-Id: <CC9A8117-1E80-4379-B33B-88D2280CEC28@ihmc.us>
To: Andy Seaborne <andy.seaborne@epimorphics.com>
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 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:25:44 GMT