Hi,
What you are saying is perfectly justified by the RDF/SPARQL background theory.
However, let us take a look at a practical scalability issue for a moment. Let
us given a triplestore with N triples where N is a large number and the two
queries:
Q1:
SELECT *
WHERE
{
?Version cnt:il8nslug ?slug .
FILTER(SAMETERM(STR(?slug), "home"))
}
and
Q2:
SELECT *
WHERE
{
?Version cnt:il8nslug "home" .
}
My believe is that complexity of the first query Q1 is O(N) while, subject on
the particular triplestore technology, complexity of the second query Q2 is <=
O(log(N)). So, regardless of being formally equivalent, the two queries are on
two different sides of feasibility in practice.
My point here is simply to raise the flag, but not to suggest any solution to
the original question other then ones already suggested.
Regards,
Milorad
>________________________________
> From: Rob Vesse <[email protected]>
>To: [email protected]
>Sent: Tuesday, October 29, 2013 11:16 AM
>Subject: Re: On how to miss a language tag
>
>
>This is how the SPARQL specification does basic graph pattern matching.
>Only variables act as wildcards, RDF Terms must match exactly.
>
>So "home" only matches the literal "home", it is not considered to be
>equal to "home"@en-us or any other language tagged or data typed literal.
>
>If you want to match regardless of language tag then you will need to use
>a variable and then a FILTER like so:
>
>SELECT *
>WHERE
>{
> ?Version cnt:il8nslug ?slug .
> FILTER(SAMETERM(STR(?slug), "home"))
>}
>
>Rob
>
>On 29/10/2013 09:27, "Bardo Nelgen"
><[email protected]> wrote:
>
>>Hello,
>>
>>this time I'm asking for help with a (to meŠ) seemingly strange SPARQL
>
>>matching behavior:
>>
>>When trying to match a statement using a language tag, something like
>>
>><cnt:versionedContent
>>rdf:about="http://resources.semaworx.eu/timed/version#versioncrediblyuniqu
>>eid001">
>><cnt:i18nslug xml:lang="en-us">home</cnt:i18nslug>
>></cnt:versionedContent>
>>
>>this works quite well with
>>
>>?Version cnt:i18nslug "home"@en-us .
>>
>>Though, now, when I target a broader match with
>>
>>?Version cnt:i18nslug "home" .
>>
>>(intending to match *any* ?Version having a cnt:i18nslug named "home",
>>regardless of the language/locale used) it unfortunately does *not*
>>match *any* of the respective statements.
>>
>>So: Why does leaving away the language tag in the query obviously imply,
>>the result *must not* have one, rather than just ignoring the existing
>>one(s)?
>>
>>And: How can this effect be avoided?
>>
>>As always, every hint is highly appreciated.
>>
>>Greets,
>>
>>Bardo
>>
>>
>
>
>
>
>
>