Reasoning and datatypes of Literals

Question

In Turtle-RDF it is convenient to omit the datatype extension ^^xsd:string for string literals. But when i try to do reasoning with StarDog, http://www.stardog.com/, only the individual :YYY with the extension "green"^^xsd:string is found to be a :GreenButton

@prefix :      <http://stackoverflow.com/q/29075078/1281433#> .
@prefix rdfs:  <http://www.w3.org/2000/01/rdf-schema#> .
@prefix owl:   <http://www.w3.org/2002/07/owl#> .
@prefix xsd:   <http://www.w3.org/2001/XMLSchema#> .
@prefix rdf:   <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .


:color   a            owl:DatatypeProperty ;
         rdfs:range   xsd:string ;
         rdfs:domain  :Button .


:XXX     :color       "green"             .
:YYY     :color       "green"^^xsd:string .


:Button         a     rdfs:Class .

:GreenButton    a     rdfs:Class ;
                owl:equivalentClass [ a owl:Restriction;
                                      owl:onProperty :color ;
                                      owl:hasValue "green"
                                    ] .

:TestButton     a     :GreenButton .

Reasoning result:

+-------------+----------+----------------------------------------------------+
|      s      |    p     |         o                                          |
+-------------+----------+----------------------------------------------------+
| :XXX        | rdf:type | :Button                                            |
| :YYY        | rdf:type | :Button                                            |
| :YYY        | rdf:type | :GreenButton                                       |

| :TestButton | rdf:type | :GreenButton                                       |
| :TestButton | :color   | "green"^^<http://www.w3.org/2001/XMLSchema#string> |
  ...

What is the best way to deal with it?

**"In Turtle-RDF it is convenient to omit the datatype extension ^^xsd:string for string literals."** Note that in the original RDF, there are plain literals (with no datatype or language tag) as well as datatyped literals. The plain literal "green" is different from the datatyped literal "green"^^xsd:string. In RDF 1.1, however, all literals have a datatype and "green" is just shorthand for "green"^^xsd:string. I'm not sure whether that's the issue here or not, but it may be relevant. "green" isn't necessarily the same as "green"^^xsd:string. — Joshua Taylor, Jun 09 '15 at 11:59
@Jushua: Yes, i noticed that. But, on the other hand, the plain literal "green" in the definition of the class :GreenButton is actually translated into "green"^^ by the reasoner or the data import or whatever..? — rmv, Jun 09 '15 at 12:15

score 4 · Answer 1 · answered Jun 09 '15 at 14:14

According to OWL semantics "green" and "green"^^xsd:string are actually equivalent. They are also equivalent in RDF 1.1. Stardog does not support RDF 1.1 yet and there is a bug wrt string literal reasoning as you noticed. Your observation is correct: plain literals in OWL axioms are automatically converted to xsd:string but literals in instance assertions are not. There is an open ticket (#2340) for this and you can check release notes in the future to see when this is fixed. Until then the workaround is to always use xsd:string for instances.

chris · Accepted Answer · 2015-06-09T12:35:09.453

3

According to the docs:

RDF parsing in Stardog is strict: it requires typed RDF literals to match their explicit datatypes, URIs to be well-formed, etc. In some cases, strict parsing isn’t ideal—it may be disabled using the --strict-parsing=FALSE.

However, even with strict parsing disabled, Stardog’s RDF parser may encounter parse errors from which it cannot recover. And loading data in lax mode may lead to unexpected SPARQL query results. For example, malformed literals ("2.5"^^xsd:int) used in filter evaluation may lead to undesired results.

Have you tried disabling strict-parsing and see what the effects are?

p.s. see Joshua's comment in the question. I am not advising to switch off strict parsing, but it may be the only option if dealing with arbitrary/external data that is sparsely typed (assuming it does resolve the issue).

edited Jun 09 '15 at 12:35

answered Jun 09 '15 at 10:05

chris

1,787
1
13
13

Thank you for googling ;-) I also tried to disable strict parsing by "bin/stardog-admin db create -n myDatabase -o strict.parsing=FALSE -- /tmp/test.ttl" but it does not seem to have any effect..? – rmv Jun 09 '15 at 11:50
@rmv So did this actually work for your or not? It seems like a pretty good answer, and you marked it as accepted, but your comment makes it seem like it might not have worked... – Joshua Taylor Jun 09 '15 at 11:56
@Jushua: The question was "What is the best way to deal with it?" The answer as far as i understood is: use typed RDF literals like "green"^^xsd:string in my example above. I accepted this answer. My comment only concerns the (non-recommend) workaround which switches off strict parsing. – rmv Jun 09 '15 at 12:05
It's ok to unmark the answer if there is a better/more ellaborate solution. Joshua is certainly right in his original comment. There are indeed [differences in handling literals](http://www.w3.org/TR/rdf11-new/#literals) between rdf and rdf 1.1, so that may be a factor. I have updated slightly my answer. – chris Jun 09 '15 at 12:34
@chris: For me it's fine that "green" is different from "green"^^xsd:string. No problem with that. But i am a little bit confused that the statement owl:hasValue "green" in the class definition becomes automatically translated into "green"^^xsd:string as can be seen in the reasoning result table. – rmv Jun 09 '15 at 12:46
So it seems it does not convert literals consistently across TBox/ABox (based on your example), but we can't be sure. How complete is the data sample you provided? Do you get the proper entailments when strings are properly typed? I feel you should unmark my answer and keep the question open for more responses. In any case though, my advice is to be consistent and type all your literals, especially if you are unsure whether the parser supports rdf 1.1. – chris Jun 09 '15 at 16:55

Reasoning and datatypes of Literals

2 Answers2