- From: David Booth <david@dbooth.org>
- Date: Sat, 23 Nov 2013 12:01:18 -0500
- To: Hugh Glaser <hugh@glasers.org>, Richard Light <richard@light.demon.co.uk>, Andy Seaborne <andy@apache.org>
- CC: public-lod community <public-lod@w3.org>
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.
> “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
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.
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:01:48 UTC