You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jena.apache.org by Bardo Nelgen <ma...@bnnperformances.de> on 2016/01/28 23:37:59 UTC
Re: Concatenating language and locale in SPARQL 1.1 – SOLVED

Though, seems, the solution was held for moderation… ;-)

On 28.01.16 22.41 Uhr, Bardo Nelgen wrote:
>
> Alright: For further testing I prepared us a Fuseki on one of our test 
> servers (as extracting a meaningful part of the datamodel may end up 
> quite cumbersome…).
>
> This is a TEST environment filled only with sample data. The model 
> resets itself completely from time to time, so don't be afraid to try 
> weird things – even killing the entire default graph won't hurt anyone…
>
> You will find your way towards it at CityAPI _fullstop_ EU on 
> thirty-thirty. Best deployed using lOSufsoCASNpii0 and 5phxdMPklLaPh5P .
>
> In Control Panel there's all you need to open yourself a session.
>
> Please also find the original full Query here:
> sameserver:80 /downloadables/example.rq
>
> The experiment runs from line 42… – simply replace 
> (str(concat(str(?lang),"-",str(?locale))) ) by "de-de" and you'll see 
> (how) it basically works. ;-)
>
> The BIND example still lives in 25 if that helps.
>
> Thank you so much for looking into this.
>
> — Bardo
>
> On 28.01.16 17.54 Uhr, Andy Seaborne wrote:
>> On 28/01/16 15:04, Joshua TAYLOR wrote:
>>> 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 "-"?
>>>
>>
>> Joshua - Nice way to test all the possibilities.
>>
>>> 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 }
>>
>> but aargggg!!!
>>
>> For the record:
>>
>> rdf:PlainLiteral is illegal in RDF
>>
>> It's not even a plain literal - it's a literal with a datatype of 
>> "rdf:PlainLiteral"
>>
>> https://www.w3.org/TR/rdf-plain-literal/
>> """
>> Therefore, typed literals with rdf:PlainLiteral as the datatype are 
>> considered by this specification to be not valid in syntaxes for RDF 
>> graphs or SPARQL.
>> """
>>
>>     Andy
>>
>> PS I did tell them at the time it was confusing ...
>>
>> :-)
>>
>>>      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 
>>> <jo...@gmail.com> 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
>>>> <ma...@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"
>>>>>> <ma...@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/
>>>
>>>
>>>
>>
>>
>
>