- 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