Unexpected behaviour of OWL-RL reasoner (Literals in the position of Subjects)

[arrascue]

This problem has been reported in #50, but there it has been reported as a problem on PROV-O.

The problem seems to be more generic than that. The following is a minimal example:

@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .

<https:example.org/A> dcterms:issued "2018-06-21T12:00:00"^^xsd:dateTime .

The augmented graph contains the following (offensive) inferred triple:

"2018-06-21T12:00:00"^^xsd:dateTime a xsd:dateTime ;
    owl:sameAs "2018-06-21T12:00:00"^^xsd:dateTime .

This type of inferred facts would cause the graph to be unparseable in some triplestores. In GraphDB, for instance, one gets a parsing error.

Other OWL-RL reasoners, like the one from GraphDB, do not generate statements with literals as the first component of a triple.

The version used was owlrl==6.0.2

The ticket #13 seems to aim to solve this, but is it open since 2018.
Are there any plans to fix it?

[ashleysommer]

Hi @arrascue
Please take another look at the conversation in #13 and #18.
You'll see issue #13 was fixed by #18 in November 2018.
The major change in #18 was to introduce the ability to have Literals in the Subject position, not remove it.

This is intentional behaviour. Whether it is correct or not is a different question.

When that change was made in 2018, the view by @iherman and @wrobell was that Literals in the Subject position are allowed by RDFlib, so the OWL-RL tool should use take advantage of the feature.

[nicholascar]

From the RDF 1.2 Concepts Specification:

• Section 3.1 Triples
  • An RDF triple is a 3-tuple (s, p, o) where:
    • s is an IRI or a blank node
    • p is an IRI, and
    • o is an IRI, a blank node, a literal or a triple term.

So no literals in the s or p positions.

and:

The set of nodes of an RDF graph is the set of subjects and objects of the triples in the graph. It is possible for a predicate IRI to also occur as a node in the same graph.

so subjects cannot.

However, according to Section 7. Generalized RDF Triples, Graphs, and Datasets:

A generalized RDF triple is a triple having a subject, a predicate, and an object, where each can be an IRI, a blank node, a triple term, or a literal.

and this is "convenient" since:

the completeness of the RDFS entailment rules is easier to show with a generalization of RDF triples.

So OWL-RL implements generalised triples and this is ok but ansl in the Spec:

NOTE: Any user of generalized RDF triples, graphs, or datasets needs to be aware that these notions are non-standard extensions of RDF, and their use may cause interoperability problems. There is no requirement for any RDF tool to accept, process, or produce anything beyond standard normative RDF triples, graphs, and datasets.

So we have a nice-to-have already implemented but sometimes it can be problematic.

Suggestion:
Perhaps implementing optional removal logic is sensible as per Issue #50, but it should be opt-in:

DeductiveClosure(RDFS_Semantics).expand(g, generalised_triples=True)

There are several options to include/exclude axiomatic triples etc., in the result, so setting generalised_triples=True seems sensible. Would love to see a PR for this, HINT HINT.

I already also do this sort of cleanup a bit:

# remove boring RDF & RDFS bits
for t in g.triples((None, None, None)):
    if str(t[0]).startswith((str(RDF), str(RDFS))):
        g.remove(t)

So there's lots to improve in the output presentation...