Add consistency check optimisations from Ontotext

[benjamingeer]

This adds optimisations implemented by Ontotext for our consistency checking rules.

• Use custom inference rules to make tables (i.e. named graphs) of pre-calculated information about the cardinalities on properties of resource instances, and use those tables to simplify the consistency rules.
• Use [Cut] to avoid generating redundant compiled rules.

Without these optimisations, incunabula-data.ttl was taking 10 hours to load. With these optimisations, it loads for me in about 30 seconds.

If a class has a cardinality on a property whose objects can't be marked as deleted (i.e. they aren't instances of knora-base:Resource or knora-base:Value), currently you have to make that property a subproperty of knora-base:objectCannotBeMarkedAsDeleted. This is ugly, but there doesn't seem to be a better way. In any case, I think it's only needed for classes in knora-base. Project-specific ontologies shouldn't need to use it.

I also added missing cardinalities for hasStandoffLinkTo and hasStandoffLinkToValue to knora-base:Resource, and adjusted the test data accordingly. The GUI will need some code to ensure that users cannot add or modify objects of hasStandoffLinkTo, but can still use that property in the extended search (#162).

These consistency rules require GraphDB 7.1 or later.

Documentation is in consistency-checking.rst.

Closes #33: Check the triplestore for inconsistencies.

Closes #190: Check cardinalities of Values using Consistency Checking.

[benjamingeer]

This is now ready to be reviewed after #186 is merged.

[tobiasschweizer]

• There are warnings when building the docs with make html:

  docs/rst/knora-api-server/design-documentation/consistency-checking.rst:284: WARNING: Literal block expected; none found.
  docs/rst/knora-api-server/design-documentation/consistency-checking.rst:286: WARNING: Title underline too short.
  
  i p r [Context <onto:_cardinality_1_table>]
  ------------------------------------
  docs/rst/knora-api-server/design-documentation/consistency-checking.rst:286: SEVERE: Unexpected section title.
  
  i p r [Context <onto:_cardinality_1_table>]
  ------------------------------------
  

• You wrote:

A property definition should specify the types that are allowed as subjects and objects of the property, using knora-base:subjectClassConstraint and (if it is an object property) knora-base:objectClassConstraint.

However, this is only effective if we really apply these constraints permanently. Should we always use common super classes in case a property applies to more than one type of subject/object? In other words: Should we always require these constraints?

• What does that mean?

  An object property has an object that does not exist. This can be treated as if the object is of the wrong type.

  Does it mean that for example a resource has a property pointing to a value object IRI but this IRI is not subject of further statements?

[benjamingeer]

There are warnings when building the docs

Fixed, thanks.

Should we always require these constraints?

The Knora API server requires objectClassConstraint for each property of a resource; I've clarified this in the RST doc and in the knora-base doc.

For subjectClassConstraint, Marion and Loïc found that it's awkward to require a common base class in some cases. It would be better to support multiple objects for subjectClassConstraint (#243), but I'll try to do that (if possible) in a separate pull request.

Does it mean that for example a resource has a property pointing to a value object IRI but this IRI is not subject of further statements?

Yes. I've clarified this in the RST doc.

[tobiasschweizer]

echo "I am awkard" | awk '{ print $1" "$2" not "$3}'

[benjamingeer]

awk 2> >(awk '{print "My bird says: Squ" $2 "! Squ" $2 "!"}')

[tobiasschweizer]

I think the section about consistency checking in the documentation explains the task well. However, for more clarity, could you add some infos about:

• the use of the keywords Id and Consistency and the difference between them (Id is used to be build the tables, Consistency to actually check)
• the function of ----------------------:
  As far as I understood, in a consistency rule the statement below the ----------- is expected to be there in the data and if it is not, the rule is violated (like for min_cardinality_1_any_object). But there are also rules without further statements below the ---------------- where additional conditions are written in square brackets and if they apply, the rule is violated (max_cardinality_1_without_deletion_flag).

[tobiasschweizer]

I have a question regarding the Id rules:

Id: maxCardinality_1_table
i rdf:type r
r owl:maxCardinality "1"^^xsd:nonNegativeInteger
r owl:onProperty p
------------------------------------
i p r [Context onto:_maxCardinality_1_table]

Let's take the example of a book. A book is subclass of a kb:resource and also subclass of a bunch of blank nodes that are themselves of type restriction, defining cardinalities on properties this very resource class may have.

:book rdf:type owl:Class ;

      rdfs:subClassOf knora-base:Resource ,
                      [
                         rdf:type owl:Restriction ;
                         owl:onProperty :title ;
                         owl:minCardinality "1"^^xsd:nonNegativeInteger                      ] ,
                      [
                         rdf:type owl:Restriction ;
                         owl:onProperty :hasAuthor ;
                         owl:minCardinality "0"^^xsd:nonNegativeInteger                      ] ,
                      [
                         rdf:type owl:Restriction ;
                         owl:onProperty :publisher ;
                         owl:minCardinality "0"^^xsd:nonNegativeInteger                      ] ,
                      [
                         rdf:type owl:Restriction ;
                         owl:onProperty :publoc ;
                         owl:maxCardinality "1"^^xsd:nonNegativeInteger                      ];

Because rdfs:subClassOf is used, the resource book is also of type blank node (its Iri) i <rdf:type> r? r must be an blank node Iri, otherwise the following statements would not work:

 r <owl:maxCardinality> "1"^^xsd:nonNegativeInteger
    r <owl:onProperty> p

I find it confusing that a resource class is both subclass of a another resource class (kb:Resource) and actual instances that are of type owl:Restriction.

[benjamingeer]

The blank nodes are class definitions, not instances of classes. The OWL 2 spec says:

owl:Restriction rdf:type rdfs:Class .
owl:Restriction rdfs:subClassOf owl:Class .

[benjamingeer]

Better now?