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