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 <mailing.list.in...@bnnperformances.de> 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" >> <mailing.list.in...@bnnperformances.de> 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/
