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/27 21:35:29 UTC
Concatenating language and locale in SPARQL 1.1
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
Re: Concatenating language and locale in SPARQL 1.1
Posted by Andy Seaborne <an...@apache.org>.
Works for me: (jena 3.0.1)
langMatches(lang("wort"@de-de),(concat(str("de"),"-",str("de"))) )
so it looks like ?lang or ?locale.
Try adding ?lang and ?locale
Just the results don't provide a complete minimal example though I note
they do not have ?Headline
If you have some short, sample data and a short query then it would be
very helpful in understanding the issue.
Andy
On 28/01/16 11:48, 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
>>>
>>
>
>
>
>
Re: Concatenating language and locale in SPARQL 1.1 – SOLVED
Posted by Bardo Nelgen <ma...@bnnperformances.de>.
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/
>>>
>>>
>>>
>>
>>
>
>
Re: Concatenating language and locale in SPARQL 1.1
Posted by Bardo Nelgen <ma...@bnnperformances.de>.
Damn, you’re right – I missed the 2 brackets in the middle of the query !!!
Shame on me.
Thanks a lot, James !!
And the rest of you as well, of course – might never have learned that
much about string datatypes in SPARQL 1.1 otherwise… ;-)
My very best,
Bardo
P.S. As it‘s solved now: Will then lock-in my test-fuseki again…
On 28.01.16 23.07 Uhr, james anderson wrote:
> good evening;
>
>> On 2016-01-28, at 22:41, Bardo Nelgen
>> <mailing.list.inbox@bnnperformances.de
>> <ma...@bnnperformances.de>> wrote:
>>
>>
>> […]
>> 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. ;-)
>
> in your original query, neither of the variables which you intend to
> use to construct the language tag are in the scope of the bindings
> higher up in the query.
>
> as written it returns no result.
> if you move the brace to be above the filter, to put the filter
> outside of the bgp, it returns one result.
>
> is that what you intended?
> ---
> james anderson | james@dydra.com <ma...@dydra.com> |
> http://dydra.com
>
>
>
>
>
Re: Concatenating language and locale in SPARQL 1.1
Posted by Bardo Nelgen <ma...@bnnperformances.de>.
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/
>>
>>
>>
>
>
Re: Concatenating language and locale in SPARQL 1.1
Posted by Andy Seaborne <an...@apache.org>.
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/
>
>
>
Re: Concatenating language and locale in SPARQL 1.1
Posted by Bardo Nelgen <ma...@bnnperformances.de>.
Hehe, may I offer you a REAL "-", Sir ? We got them fresh today from
ANSI… ;-)
Just double-checked the character: Nope, that wasn't it.
On 28.01.16 17.40 Uhr, Andy Seaborne wrote:
> In Brando's code, everything is str()'ed. Only unbound will defeat that.
>
> (It is on a Mac though and "-" may not be "-" somewhere :-)
>
> Substituting from the srj file:
>
> arq.qexpr 'langMatches( (lang("Unsere Lieblings-Testmail"@de-de))
> , (str(concat(str("de"),"-",str("de"))))) '
> ==> true.
>
> (Jena 3.0.1)
>
> Andy
>
> 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 "-"?
>>
>> 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
>> <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/
>>
>>
>>
>
>
Re: Concatenating language and locale in SPARQL 1.1
Posted by Andy Seaborne <an...@apache.org>.
In Brando's code, everything is str()'ed. Only unbound will defeat that.
(It is on a Mac though and "-" may not be "-" somewhere :-)
Substituting from the srj file:
arq.qexpr 'langMatches( (lang("Unsere Lieblings-Testmail"@de-de)) ,
(str(concat(str("de"),"-",str("de"))))) '
==> true.
(Jena 3.0.1)
Andy
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 "-"?
>
> 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 <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/
>
>
>
Re: Concatenating language and locale in SPARQL 1.1
Posted by Joshua TAYLOR <jo...@gmail.com>.
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 <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/
--
Joshua Taylor, http://www.cs.rpi.edu/~tayloj/
Re: Concatenating language and locale in SPARQL 1.1
Posted by Joshua TAYLOR <jo...@gmail.com>.
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/
Re: Concatenating language and locale in SPARQL 1.1
Posted by Bardo Nelgen <ma...@bnnperformances.de>.
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
>>>
>
>
>
>
Re: Concatenating language and locale in SPARQL 1.1
Posted by Rob Vesse <rv...@dotnetrdf.org>.
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
>>
>
Re: Concatenating language and locale in SPARQL 1.1
Posted by Bardo Nelgen <ma...@bnnperformances.de>.
The result I get from the
langMatches(lang("wort"@de-de),(concat("de","-","de")) ) - approach
in JSON. (attached)
On 28.01.16 11.32 Uhr, Bardo Nelgen 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
>>
>
>
Re: Concatenating language and locale in SPARQL 1.1
Posted by Bardo Nelgen <ma...@bnnperformances.de>.
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
>
Re: Concatenating language and locale in SPARQL 1.1
Posted by Andy Seaborne <an...@apache.org>.
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