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
<[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/
