Re: keeping issue-12 simple

Pat, Richard, all,

I'm tempted to put this on the agenda as we appear to have consensus. Any need 
to amend the proposed resolution?

Guus


On 03/06/2011 00:47, Pat Hayes wrote:
>
> On Jun 2, 2011, at 2:33 PM, Richard Cyganiak wrote:
>
>> Hi Pat,
>>
>> Your proposal below is different from mine.
>
> Sorry, it was intended to be simply an alternative way of phrasing the same proposal.
>
>> I want to make "foo" and "foo"^^xsd:string result in one triple in the abstract syntax.
>>
>> Your proposal keeps it as two triples.
>
> Actually, my text does not mention the abstract syntax, so is agnostic on this, but I am quite happy to have it interpreted your way. One triple in the abstract syntax, yes. Presumably of the form "foo"^^xsd:string (or, more exactly, the abstract syntax form of such a typed literal.)
>
>> You say: “ABC is considered to have type XYZ.” I think that phrase is everything but helpful.
>
> Sorry :-)
>
>> Either XYZ is in the abstract syntax, or it is not. If it is not, then where does it come from?
>
>  From the specification that we write. We have complete control over this entire language, we can make it be any way we like. But if you want this to all be explicit in the abstract syntax, that is fine with me. So when I write "is considered to be XXX", read that as saying "is XXX in the abstract syntax."
>
> The current abstract syntax defines a simple tagged literal as *being* a pair of a string and a tag, and to be self-denoting. Which works out very nicely, if we are happy to have rdf:LTS be a datatype-that-works-on-pairs with the identity map as its L2V; or, alternatively, if we don't want any datatypes which work on anything but strings, then we can say that the abstract syntax form of these literals is (the abstract syntax form of)
> "string@tag"^^rdf:LTS.
> Personally I prefer the former, but I can live with the latter.
>
> Pat
>
>>
>> Best,
>> Richard
>>
>>
>>
>>
>> On 1 Jun 2011, at 15:45, Pat Hayes wrote:
>>
>>> As we have been (re) considering a wide range of possible ways to handle language tags, I would like to reiterate how simple the earlier proposals which Richard outlined is. Allow me to rephrase it in alternative language which might emphasize its harmlessness.
>>>
>>> 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.
>>>
>>> 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>
>>>
>>> 3. rdf:PlainLiteral is the superclass of xsd:string and rdf:LTS.
>>>
>>> 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. 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.
>>>
>>> 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
>
>
>
>
>
>

-- 
Prof. Guus Schreiber
Web & Media, Computer Science
VU University Amsterdam
http://www.cs.vu.nl/~guus

Received on Tuesday, 7 June 2011 18:01:02 UTC