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

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 14:36:09 UTC