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 <[email protected]>
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 <[email protected]>
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
