On 10/04/2020 05:29, Irene Polikoff wrote:
Yes, the key limitation to using custom datatypes is that SPARQL query
engines will not understand how to compare values of such types. The
specification only defines the precise meaning of a literal when the
datatype IRI is one of the standard, pre-defined datatypes. Any
operations on custom datatypes are implementation specific.
Literals in RDF have datatypes and language tags. In this particular
case, for languages, why not use the traditional approach of language
tags? In EDG, you would then be able to query for “fre” irrespective
of the language. And if you want to limit it to a specific language,
you could do it as well.
Coming back to datatypes, any matching is datatype sensitive. So, if
you are querying for n = 1, it matters whether 1 is an integer or a
string.
Thus two literals (“1”, xsd:int) and (“1”, xsd:decimal) will test as
the same but neither will test as the same as (“1”, xsd:string).
Similarly, with custom datatypes.
"fre"^^euvoc:ISO_639_2B is not the same as"fre"^^euvoc:ISO_639_2A
You can read a bit more on Jena’s handling of custom
datatypes:https://jena.apache.org/documentation/notes/typed-literals.html.
With respect to the BIND statement #3 (below), it will result in ?n
being unbound unless euvoc:ISO_639_2B is a function. As I understand
it, it is not a function, but just a plain predicate. How did you
expect it to work?
Probably like BIND (spif:cast("42", rdf:dummyDatatype) AS ?x)
Holger
#3 BIND ( euvoc:ISO_639_2B("fre") AS ?n )
I could think of may be a function that would accept a value and a
custom datatype as parameters - something like BIND (
ex:customDatatypeValue (“fre”, euvoc:ISO_639_2B) AS ?n).
Under the covers it would just do BIND ( "fre"^^euvoc:ISO_639_2B AS ?n
), so I am not sure if there is any value in it.
There could also be a function that looks for “fre” with any datatype,
On Apr 9, 2020, at 2:20 PM, Jan Voskuil <[email protected]
<mailto:[email protected]>> wrote:
Hi,
I had a long and complicated question, but in the process of writing
it up I have found the answer completely on my own.
Rather than throwing the text away, I thought why not share it. It is
about the behaviour of complex datatypes in SPARQL.
Sorry for the spam...
For a project, we intend to use a small subset of information
contained in the so-called Authority Tables of the Publication Office
of the EU.
In this context, we want to copy into a local graph some triples
concerning certain instances of skos:Concept.
For example, the triple that describes the concept that stands for
French and one of its notations, as in [1].
In the process, we want to get rid of the datatype URI, with the
result in [2].
The argumentation supporting this move is that we do not need the
information about the particular coding scheme. And if we need it in
the future, we are better of using the more verbose but less obscure
form in [3], from the same original source (AT).
To further strengthen the argumentation, one can say that querying
for concepts based on a string matching a notation is made impossibly
complicated using custom datatypes as in [1]. A "simple literal"
(i.e. a plain literal without language tag) does not match the typed
datatype string in [1]. Only one with the same datatype URI does.
Moreover, you can't cast a simple literal to a complex one, at least
not without extending the SPARQL-engine (see paragraph 17.1 in the
SPARQL 1.1 reference).
To back this up, I ran the three variants of the query in [4] against
the data in [1] (or rather the original AT-graph describing 7K+ of
languages).
The variant with binding #1 results in exactly one match, as expected.
The variant with binding #2 results in zero matches, again as expected.
The variant with binding #3 results in 17K matches, one for each
pairing of a concept and an associated notation.
The latter result was mildly surprising, as I would have expected no
results at all. But then it occurred to me that you could expect an
error to be thrown.
And indeed, when I looked into the Error Log-tab, I found the warning
in [5]. The warning apparently leaves the variable ?n unbound, which
explains the query result.
The only remaining question is why a warning is thrown and not an
error, but I guess that should be explainable from the spec.
Thanks for being there, -j
[1]
language:FRA skos:notation "fre"^^euvoc:ISO_639_2B .
[2]
language:FRA skos:notation "fre" .
[3]
language:FRA euvoc:xlNotation [
rdf:type euvoc:XlNotation ;
dct:type
<http://publications.europa.eu/resource/authority/notation-type/ISO_639_2B>
;
rdf:value "fre" ;
] .
[4]
SELECT *
WHERE {
#1 BIND ( "fre"^^euvoc:ISO_639_2B AS ?n )
#2 BIND ( "fre" AS ?n )
#3 BIND ( euvoc:ISO_639_2B("fre") AS ?n )
?c a skos:Concept .
?c skos:notation ?n .
}
[5]
WARN [Thread-63] (E_Function.java:105) - URI
<http://publications.europa.eu/ontology/euvoc#ISO_639_2B> has no
registered function factory
--
You received this message because you are subscribed to the Google
Groups "TopBraid Suite Users" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to [email protected]
<mailto:[email protected]>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/topbraid-users/cbacd974-020d-4720-9585-806c1e320143%40googlegroups.com
<https://groups.google.com/d/msgid/topbraid-users/cbacd974-020d-4720-9585-806c1e320143%40googlegroups.com?utm_medium=email&utm_source=footer>.
--
You received this message because you are subscribed to the Google
Groups "TopBraid Suite Users" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to [email protected]
<mailto:[email protected]>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/topbraid-users/01282D53-71C5-406E-B71F-B0A56F1ABDBB%40topquadrant.com
<https://groups.google.com/d/msgid/topbraid-users/01282D53-71C5-406E-B71F-B0A56F1ABDBB%40topquadrant.com?utm_medium=email&utm_source=footer>.
--
You received this message because you are subscribed to the Google Groups "TopBraid
Suite Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/topbraid-users/5d80dbbd-1390-6260-88f8-8f74382707a6%40topquadrant.com.
