Here's a more complete case that tries all the combinations of
rdf:plainLiteral and xsd:string. Note that str(concat(...)) works as
well as concat(str(...),...). Bardo, what happens if you use str("-")
instead of "-"?
prefix xsd: <http://www.w3.org/2001/XMLSchema#>
prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
select * where {
{
values ?str { false }
values ?x { "color"@en-us "colour"@en-gb }
values ?lang { "en"^^xsd:string "en"^^rdf:plainLiteral }
values ?delim { "-"^^xsd:string "-"^^rdf:plainLiteral }
values ?locale { "gb"^^xsd:string "gb"^^rdf:plainLiteral }
filter langMatches(lang(?x), concat(?lang, ?delim, ?locale))
}
union
{
values ?str { true }
values ?x { "color"@en-us "colour"@en-gb }
values ?lang { "en"^^xsd:string "en"^^rdf:plainLiteral }
values ?delim { "-"^^xsd:string "-"^^rdf:plainLiteral }
values ?locale { "gb"^^xsd:string "gb"^^rdf:plainLiteral }
filter langMatches(lang(?x), concat(str(?lang), str(?delim), str(?locale)))
}
}
----------------------------------------------------------------------------------------------------
| str | x | lang | delim
| locale |
====================================================================================================
| false | "colour"@en-gb | "en"^^xsd:string | "-"^^xsd:string
| "gb"^^xsd:string |
| true | "colour"@en-gb | "en"^^xsd:string | "-"^^xsd:string
| "gb"^^xsd:string |
| true | "colour"@en-gb | "en"^^rdf:plainLiteral | "-"^^xsd:string
| "gb"^^xsd:string |
| true | "colour"@en-gb | "en"^^xsd:string |
"-"^^rdf:plainLiteral | "gb"^^xsd:string |
| true | "colour"@en-gb | "en"^^rdf:plainLiteral |
"-"^^rdf:plainLiteral | "gb"^^xsd:string |
| true | "colour"@en-gb | "en"^^xsd:string | "-"^^xsd:string
| "gb"^^rdf:plainLiteral |
| true | "colour"@en-gb | "en"^^rdf:plainLiteral | "-"^^xsd:string
| "gb"^^rdf:plainLiteral |
| true | "colour"@en-gb | "en"^^xsd:string |
"-"^^rdf:plainLiteral | "gb"^^rdf:plainLiteral |
| true | "colour"@en-gb | "en"^^rdf:plainLiteral |
"-"^^rdf:plainLiteral | "gb"^^rdf:plainLiteral |
----------------------------------------------------------------------------------------------------
On Thu, Jan 28, 2016 at 9:56 AM, Joshua TAYLOR <[email protected]> wrote:
> This just happened to catch my eye, and while I don't have a solution,
> it does look like there could be something going on with datatypes.
> If nothing else, here's some short code that might help in testing.
> Using just ?locale:
>
> prefix xsd: <http://www.w3.org/2001/XMLSchema#>
> prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
>
> select * where {
> values ?x { "color"@en-us "colour"@en-gb }
> values ?locale { "gb"^^xsd:string "gb"^^rdf:plainLiteral }
>
> filter langMatches(lang(?x), concat("en","-", ?locale))
> }
> -------------------------------------
> | x | locale |
> =====================================
> | "colour"@en-gb | "gb"^^xsd:string |
> -------------------------------------
>
>
> And now, using str(?locale)
>
> prefix xsd: <http://www.w3.org/2001/XMLSchema#>
> prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
>
> select * where {
> values ?x { "color"@en-us "colour"@en-gb }
> values ?locale { "gb"^^xsd:string "gb"^^rdf:plainLiteral }
>
> filter langMatches(lang(?x), concat("en","-", str(?locale)))
> }
> -------------------------------------------
> | x | locale |
> ===========================================
> | "colour"@en-gb | "gb"^^xsd:string |
> | "colour"@en-gb | "gb"^^rdf:plainLiteral |
> -------------------------------------------
>
> This is in Jena 2.12, though:
>
> $ sparql --version
> Jena: VERSION: 2.12.1
> Jena: BUILD_DATE: 2014-10-02T16:36:17+0100
> ARQ: VERSION: 2.12.1
> ARQ: BUILD_DATE: 2014-10-02T16:36:17+0100
> RIOT: VERSION: 2.12.1
> RIOT: BUILD_DATE: 2014-10-02T16:36:17+0100
>
> On Thu, Jan 28, 2016 at 9:29 AM, Bardo Nelgen
> <[email protected]> wrote:
>>
>> Hi Rob,
>>
>> thanks for the hint – seems you hit something here:
>>
>> The binding you described works properly as
>>
>> BIND(concat(str(?lang),"-",str(?locale)) AS ?langMatch) .
>>
>> indeed returns "de-de" for the ?langMatch variable.
>>
>> However simple string-making via
>>
>> langMatches( (lang(?mailHeaderSubject)) ,
>> (str(concat(str(?lang),"-",str(?locale))) ) )
>>
>> still won't match.
>>
>> Also tried to get around possibly implied datatypes in SPARQL by explicitly
>> making the values for ?lang and ?locale to be of xsd:string in the RDF
>> datamodel already.
>>
>> But unfortunately with no changes in the (not) matches.
>>
>> Any ideas ?
>>
>> As Andy already suggested, I'll try to compile a minimum working model
>> (which may take some time, as the original is rather complex…) or set up a
>> trial account on the test machine.
>>
>> Best,
>>
>> Bardo
>>
>>
>> On 28.01.16 12.48 Uhr, Rob Vesse wrote:
>>>
>>> I wonder if the problem is to do with the datatype of the string resulting
>>> from concat()?
>>>
>>> Can you try doing a BIND(concat(str(?lang),"-",str(?locale)) AS
>>> ?langMatch) in your query and selecting that variable out to see what
>>> value you get, in particular I'm wondering if you are getting a typed
>>> literal?
>>>
>>> langMatches() wants a simple literal as the second argument and it is
>>> possible that concat() is produced a typed literal
>>>
>>> One possibility is simply to put str() around the concat() call and see if
>>> that resolves things
>>>
>>> There may also be some RDF 1.1 interaction going on here (if this is Jena
>>> 3.x) since literals without a type have an implicit type in RDF 1.1 that
>>> may be causing the function evaluation to do the wrong thing which would
>>> be a bug
>>>
>>> Rob
>>>
>>> On 28/01/2016 10:32, "Bardo Nelgen"
>>> <[email protected]> wrote:
>>>
>>>> Hi Andy,
>>>>
>>>> thanks for the immediate reply.
>>>>
>>>> We actually use "en-gb" for UK English in our model – but anyway…
>>>>
>>>> My test-Scenario looks like
>>>>
>>>> ?lang = "de"
>>>> ?locale = "de"
>>>>
>>>> which in
>>>>
>>>> langMatches(lang("wort"@de-de),(concat(str(?lang),"-",str(?locale))) )
>>>>
>>>> unfortunately does not evaluate as true, althoughthe "hard-coded" variant
>>>>
>>>> langMatches(lang("wort"@de-de),"de-de")
>>>>
>>>> indeed does…
>>>>
>>>> Since we *always* deploy language-locale *combinations* throughout the
>>>> data model – for fine grained targeting – using an adaption of your
>>>> other example
>>>>
>>>> langMatches(lang("wort"@de-de),(concat("de","-","de")) )
>>>>
>>>> evaluates to "true" as well – outputting "wort"@de-de
>>>>
>>>> So the problem seems do lie in the string-making via str(?lang) and
>>>> str(?locale).
>>>>
>>>> I also output both variables separately with the same query (for further
>>>> processing) which tells me they are filled correctly; also being quoted
>>>> in the result to demonstrate the string-property on both.
>>>>
>>>> What else could possibly go wrong with a simple to-string conversion ?
>>>>
>>>> Slightly confused greets,
>>>>
>>>> Bardo
>>>>
>>>> On 28.01.16 10.25 Uhr, Andy Seaborne wrote:
>>>>>
>>>>> On 27/01/16 20:35, Bardo Nelgen wrote:
>>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> most likely I am missing something here, but maybe I am simply doing it
>>>>>> the wrong way:
>>>>>>
>>>>>> I need to match a language-locale value where both language and locale
>>>>>> come from different branches in the data model.
>>>>>>
>>>>>> So what I came up with in my FILTER clause is
>>>>>>
>>>>>> langMatches(lang(?Headline),(concat(str(?lang),"-",str(?locale))) )
>>>>>>
>>>>>> Is it meant to work this way or is the approach doomed by itself ?
>>>>>>
>>>>>> Any suggestions very welcome. :-)
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Bardo
>>>>>>
>>>>> If ?Headline, ?lang and ?locale are right it will work but did you
>>>>> mean the arguments the other way round?
>>>>>
>>>>> langMatches(lang("word"@EN-uk),(concat("en","-","uk")) ) ==> true
>>>>>
>>>>> But
>>>>> langMatches(lang("word"@EN),(concat("en","-","uk")) ) ==> false
>>>>>
>>>>> The second argument is the language range,
>>>>>
>>>>> langMatches("en-UK","EN") => true
>>>>>
>>>>> Andy
>>>>>
>>>
>>>
>>>
>>>
>>
>
>
>
> --
> Joshua Taylor, http://www.cs.rpi.edu/~tayloj/
--
Joshua Taylor, http://www.cs.rpi.edu/~tayloj/
