Re: ISSUE-12: xs:string VS plain literals: proposed resolution

It was Sandro who introduced SPARQL into the thread.  I don't agree that 
its a "grave mistake" in SPARQL.  Treatment should be uniform whether 
using SPARQL or some other way of accessing the data (SPARQL engines are 
often written over a base API anyway).

The proposed text is:
"""
Recommend that data publishers use plain literals instead of xs:string 
typed literals and tell systems to silently convert xs:string literals 
to plain literals without language tag
"""

This is an RDF-as-data view; this is not D-entailment.  It is not 
necessarily a change to SPARQL query, which has to work with old and new 
data.

:x :p "foo" .
:x :p "foo"^^xsd:string .

One triple or two? The proposal says (ideally) one.

[[
The strongest I can find in the RDF docs is in Concepts: sec 6.5.2 as a 
note.
]]

	Andy

On 06/05/11 15:35, Pat Hayes wrote:
>
> On May 6, 2011, at 9:09 AM, Andy Seaborne wrote:
>
>> See
>>
>> http://www.w3.org/TR/sparql11-entailment/#id35808654
>
> OK, so how many SPARQL engines support D-entailment? How do they indicate to the world which form of D-entailemnt they use (ie what D is, exactly) ?
>
> Why not include xsd:string into the basic SPARQL entailment regime? It wouldnt be difficult to make this change in the specs wording, though the test cases would need some revision.
>
> BTW, if the answer is, it would screw up existing implementations, then this is also an argument against RDF making any changes.
>
> Pat
>
>>
>> which depends on RDFS entailment
>>
>> 	Andy
>>
>> On 06/05/11 14:57, Pat Hayes wrote:
>>> This discussion illustrates in a nutshell the essential tension at the core of SPARQL. Should a query be 'semantic', entirely about meanings, or should it be basically a process of syntactic matching? If one believes the semantic position, then it is natural to express the basic process in terms of entailment (the graph entails the query instance) and natural to treat semantically equivalent things as indistinguishable. However, it is also natural to not have such things as answer counts, no-match filters, and most of the actual apparatus of SPARQL, since none of this is *entailed* by the query graph, indeed by any graph at all. All of this is essentially syntactic information *about* the graph. Which is why I slowly came to the realization that to even talk about entailment in the context of querying is wrong. Querying is not a semantic operation, it is about the syntactic form of the graph.
>>>
>>> OK, we can always talk about simple entailment to make us feel warm and fuzzy, but simple  )entailment is so simple that it amounts to a syntactic match anyway. But consider the following resolution of this meaningless issue: SPARQL should use {xsd:string}-entailment rather than simple entailment. (That is, D-entaiment where D is {xsd:string}. This will give exactly the behavior Sandro wants, and the required ideas and definitions have been in the RDF spec since 2004. So why are we, the RDF WG, even discussing this at all? We have already given SPARQL enough room in the RDF specs to do it properly.
>>>
>>> Now, this resolution will not fly, I predict, because SPARQL does not want to get into any richer kind of entailment than simple entailment, but wants RDF to make things work out nicely even while it is doing simple syntactic matching. Because simple *syntactic* matching is the only kind of matching that is fine-grained enough to satisfy people who want to write filters on query results.
>>>
>>> Pat
>>>
>>>
>>>
>>> On May 6, 2011, at 7:32 AM, Andy Seaborne wrote:
>>>
>>>>
>>>>
>>>> On 06/05/11 13:16, David Wood wrote:
>>>>> On May 6, 2011, at 7:44, Sandro Hawke<sandro@w3.org>    wrote:
>>>>>
>>>>>> On Fri, 2011-05-06 at 09:33 +0100, Andy Seaborne wrote:
>>>>>>>
>>>>>>> I wonder if most people would be happen if we emphasised that it's
>>>>>>> the
>>>>>>> value that matters.  xsd:string and simple literal have the same
>>>>>>> value,
>>>>>>> as do 00123 and +123.
>>>>>>
>>>>>> I guess it depends what you mean by 'emphasise'...
>>>>>>
>>>>>> I was shocked to discover SPARQL cared about the difference, and thought
>>>>>> it was a grave mistake at the time (but I didn't notice until it was too
>>>>>> late).  I had assumed everyone already knew you should just care about
>>>>>> the value, and that every API should convert for you, hiding the
>>>>>> difference.  But I was wrong, and I don't really know how to get people
>>>>>> to use the "Semantic Web" technologies at a "semantic" level.
>>>>>
>>>>> +1. Of course, it would help if we standardized it that way :)
>>>>
>>>> And better
>>>> "if we *had* standardized it that way"  :-)
>>>>
>>>>> Regards,
>>>>> Dave
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>>     -- Sandro
>>>>
>>>> There are a couple of factors that matter here:
>>>>
>>>> 1/ Users expect what goes to be the same as what comes out.
>>>> (tools do as well sometimes)
>>>>
>>>> If they read in
>>>>
>>>> :x :p "foo"^^xsd:string .
>>>>
>>>> and get back:
>>>>
>>>> :x :p "foo" .
>>>>
>>>> enough of them are surprised (=>   they send email to support lists asking about it).
>>>>
>>>> 2/ SPARQL FILTERs don't care - it's graph matching that does because graph matching is simple entailment.  And that's what most toolkit provide - the direct manipulation of the RDF terms, lexical form, datatype and all.
>>>>
>>>> :x :p "foo" .
>>>> :x :p "foo"^^xsd:string .
>>>>
>>>> One triple or two?
>>>>
>>>> 	Andy
>>>>
>>>> (For the record : "foo"^^xsd:string matches "foo" in a Jena memory model -- there would be two triples.)
>>>>
>>>>
>>>
>>> ------------------------------------------------------------
>>> 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 Friday, 6 May 2011 17:11:51 UTC