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 <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? > #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 <jan.vosk...@taxonic.com> 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 topbraid-users+unsubscr...@googlegroups.com > <mailto:topbraid-users+unsubscr...@googlegroups.com>. > 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 topbraid-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/01282D53-71C5-406E-B71F-B0A56F1ABDBB%40topquadrant.com.
