Re: Dumb SPARQL query problem

On 23/11/13 17:01, David Booth wrote:
> Hi Hugh,
>
> A little correction and a further question . . .
>
> On 11/23/2013 10:17 AM, Hugh Glaser wrote:
>> Pleasure.
>> Actually, I found this:
>> http://answers.semanticweb.com/questions/3530/sparql-query-filtering-by-string
>>
>>
>> I said it is a pig’s breakfast because you never know what the RDF
>> publisher has decided to do, and need to try everything.
>> So to match strings efficiently you need to do (at least) four queries:
>> “cat”
>> “cat”@en
>> “cat”^^xsd:string
>
> Is that still true in SPARQL 1.1?  In Turtle "cat" means the exact same
> thing as "cat"^^xsd:string:
> http://www.w3.org/TR/turtle/#literals
>
> But this section of SPARQL 1.1 Section 4.1.2 "Syntax for Literals" has
> no mention of them being the same:
> http://www.w3.org/TR/sparql11-query/#QSynLiterals
>
> Anyone (Andy?) know whether this was fixed in SPARQL 1.1?  I thought
> SPARQL 1.1 and Turtle had been pretty well aligned.

SPARQL 1.1 says nothing about it aside from (as in SPARQL 1.0) 
DATATYPE("abc") is xsd:string and DATATYPE("abc"@en) is rdf:langString 
(in 1.1).

What it should say, but does not because SPARQL 1.1 finished before RDF 
1.1 got near sufficiently stable, is

1/ parsing "abc" and "abc"^^xsd:string is the same thing.
2/ In results formats, it's "abc" or equivalent, and no ^^xsd:String.

For matching, it falls out in the matching over RDF but actually putting 
that in the text would be nice.


>> “cat”@en^^xsd:string or “cat”^^xsd:string@en - I can’t remember which
>> is right, but I think it’s only one of them :-)
>
> Neither is allowed.  You can have *either* a language tag *or* a
> datatype, but not both:
> http://www.w3.org/TR/sparql11-query/#QSynLiterals
> http://www.w3.org/TR/sparql11-query/#rRDFLiteral

Ditto in RDF syntax.

>
> But dealing with the difference between "cat" and "cat"@en is still a
> problem, as explained here:
> http://www.w3.org/TR/sparql11-query/#matchLangTags
>
> This would have been fixed if the RDF model had been changed to
> represent the language tag as an additional triple, but whether this
> would have been a net benefit to the community is still an open
> question, as it would add the complexity of additional triples.

Different.  Maybe better, maybe worse.


Do you want all your "abc" to be the same language?

    "abc" rdf:lang "en" .

or multiple languages:

    "abc" rdf:lang "cy" .
    "abc" rdf:lang "en" .


?

Unlikely - so it's bnode time ...

:x :p [ rdf:value "abc" ; rdf:lang "en" ] .

	Andy


>
> David
>
>>
>> Of course if you are matching in SPARQL you can use “… ?o . FILTER
>> (str(?o) = “cat”)…”, but that its likely to be much slower.
>>
>> This means that you may need to do a lot of queries.
>> I built something to look for matching strings (of course! - finding
>> sameAs candidates) where the RDF had been gathered from different
>> sources.
>> Something like
>> SELECT ?a ?b WHERE { ?a ?p1 ?s . ?b ?p2 ?s }
>> would have been nice.
>> I’ll leave it as an exercise to the reader to work out how many
>> queries it takes to genuinely achieve the desired effect without using
>> FILTER and str.
>>
>> Unfortunately it seems that recent developments have not been much
>> help here, but I may be wrong:
>> http://www.w3.org/TR/sparql11-query/#matchingRDFLiterals
>>
>> I guess that the truth is that other people don’t actually build
>> systems that follow your nose to arbitrary Linked Data resources, so
>> they don’t worry about it?
>> Or am I missing something obvious, and people actually have a good way
>> around this?
>>
>> To me the problem all comes because knowledge is being represented
>> outside the triple model.
>> And also because of the XML legacy of RDF, even though everyone keeps
>> saying that is only a serialisation of an abstract model.
>> Ah well, back in my box.
>>
>> Cheers.
>>
>> On 23 Nov 2013, at 11:00, Richard Light <richard@light.demon.co.uk>
>> wrote:
>>
>>>
>>> On 23/11/2013 10:30, Hugh Glaser wrote:
>>>> Its’ the other bit of the pig’s breakfast.
>>>> Try an @en
>>>>
>>> Magic!  Thanks.
>>>
>>> Richard
>>>> On 23 Nov 2013, at 10:18, Richard Light <richard@light.demon.co.uk>
>>>>   wrote:
>>>>
>>>>
>>>>> Hi,
>>>>>
>>>>> Sorry to bother the list, but I'm stumped by what should be a
>>>>> simple SPARQL query.  When applied to the dbpedia end-point [1],
>>>>> this search:
>>>>>
>>>>> PREFIX foaf:
>>>>> <http://xmlns.com/foaf/0.1/>
>>>>>
>>>>> PREFIX dbpedia-owl:
>>>>> <http://dbpedia.org/ontology/>
>>>>>
>>>>> SELECT *
>>>>> WHERE {
>>>>>      ?pers a foaf:Person .
>>>>>      ?pers foaf:surname "Malik" .
>>>>>      OPTIONAL {?pers dbpedia-owl:birthDate ?dob }
>>>>>      OPTIONAL {?pers dbpedia-owl:deathDate ?dod }
>>>>>      OPTIONAL {?pers dbpedia-owl:placeOfBirth ?pob }
>>>>>      OPTIONAL {?pers dbpedia-owl:placeOfDeath ?pod }
>>>>> }
>>>>> LIMIT 100
>>>>>
>>>>> yields no results. Yet if you drop the '?pers foaf:surname "Malik"
>>>>> .' clause, you get a result set which includes a Malik with the
>>>>> desired surname property.  I'm clearly being dumb, but in what way?
>>>>> :-)
>>>>>
>>>>> (I've tried adding ^^xsd:string to the literal, but no joy.)
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Richard
>>>>> [1]
>>>>> http://dbpedia.org/sparql
>>>>>
>>>>> --
>>>>> Richard Light
>>>>>
>>>
>>> --
>>> Richard Light
>>
>

Received on Saturday, 23 November 2013 17:21:55 UTC