SNIK Technical Blog

Situation

There are three immediate subclasses of meta:Top ("subtops"): Function, Role and Entity Type.

Problem

As they are disjoint, any subclass of more than one of them would be empty, which we assume to be an error and thus show here.

Solution

Automatically generate offending classes below and manually remove all but one of the subtop statements for each of them.

Situation

In addition to direct subclass relations, we model the transitively implied subclass relation to a subtop using the meta:subtop relation. Other knowledge bases may handle this differently, for example DBpedia always explicitly defines all superclasses.

Problem

If A is subclass of B and A and B have different disjoint superclasses C and D, this implies that A is empty, similar to the multiple subtops problem.

Solution

Manually unify the subtops of the subclass-superclass pairs below.

Situation

In addition to the subclass relation, we also have the similar but different component relations.

Problem

If A is subclass of B and A is also a component of B (or vice versa in the other direction), this seems syntactically wrong.

Solution

Manually decide for one of the relations. If a component relation is chosen and the supercount is only 1, a new superclass needs to be specified.

Situation

The subClassOf relation is transitive.

Problem

If A is subClassOf B and B is subClassOf C then any explicit triple of A subClassOf C is redundant.

Solution

Delete the explicit triple A subClassOf C.

Situation

The different SNIK subontologies are linked mostly using skos:closeMatch, skos:narrowMatch and skos:broadMatch, which which imply owl:equivalentClass, rdfs:subClassOf and the inverse of rdfs:subClassOf.

Problem

For the same reasons mentioned for multiple subtops and inconsistent subtop, we assume an error if the ends of a link have a different subtop.

Solution

Remove all interlinks between classes with different subtops.

Situation

Classes are sets of individuals and can be subclasses (subsets) of other classes.

Problem

Subclass cycles (A subclass of B ... subclass of A) collapse all members of the cycle to the same set, which is assumed to be unintentional.

Solution

Find subclass cycles below and and manually remove at least one of them. Because of the limitiations of SPARQL 1.1 property paths, we cannot select the full cycle but only give all pairs of classes on a cycle.

Situation

All classes should have a label.

Problem

Some classes don't have a specified label.

Solution

Show classes with missing label and manually add labels.

Situation

For easier exploration, visualization and understanding, we want to group all our classes in a more or less balanced tree based on the subclass/superclass relation.

Problem

Some classes don't have a specified superclass and thus are not connected to the rest of the hierarchy.

Solution

Because nearly all have a subtop statement, we use this automatically to add a superclass statement to the graph http://www.snik.eu/ontology/virtual for classes that don't have one already. As this creates a very unbalanced tree, you can display those classes below and try to find a more specific superclass for them.

Situation

If a concept is used as the object in some triple, then it should have its own attributes (occur as a subject).

Problem

Sometimes concepts occur as only as an object but not as a subject.

Solution

The responsible extractors for the respective subontologies need to add statements for the objects listed below.

Situation

Each SNIK property has a domain that defines allowed subjects.

Problem

Some classes are used as a subject for a triple without being a direct or transitive subclass of the defined domain of the property.

Solution

The offending triples should be removed or remodelled to conform to the domain.

Situation

Each SNIK property has a range that defines allowed objects.

Problem

Some classes are used as an object for a triple without being a direct or transitive subclass of the defined range of the property.

Solution

The offending triples should be removed or remodelled to conform to the range.

Situation

Class URLs should conform to UpperCamelCase.

Problem

Naming conventions weren't clearly set from the beginning and some pecularities are not widely known, for example abbreviations such as IbmMachine, not IBMMachine.

Solution

Manually correct offending class URLs.

Situation

Property URLs should conform to lowerCamelCase.

Problem

Naming conventions weren't clearly set from the beginning and some pecularities are not widely known, for example abbreviations such as updatesAtm, not updatesATM.

Solution

Manually correct offending property URLs.

Situation

Every class should have a definition from the book.

Problem

Some don't.

Solution

Try to find a definition in the source.

Situation

We use semicolons for multiple properties in our extraction tables to hold multiple values.

Problem

Semicolons are rarely used in the textbooks, especially for short strings and outside of definitions. Thus they hint at semicolons being used at the wrong place or at errors in the conversion script.

Solution

Generate all literals containing semicolons except those from definitions of more than 100 characters.

Situation

The subclass hierarchy should ideally be a more or less balanced tree.

Problem

In practice, the hierarchy is too flat.

Solution

List all classes with more than 20 subclasses.

Situation

Classes are connected to other classes mostly by the subclass hierarchy and by restrictions.

Problem

Some classes are isolated from all others, limiting their use and preventing them from being connected to the vizualization graph.

Solution

List all classes that are not connected to other classes by restrictions. Because we already covered the hierarchy, we are not taking it into account here. Because there are over 1000 of those cases, we only list the first 100. They are not necessarily faulty but it may be worthy to investigate if they can be connected in some way.

Situation

Our URIs begin with http://...

Problem

Tools like the OntoWiki sometimes fail to expand a prefix and thus create URIs that have an incorrect prefix.

Solution

List all triples with URIs that are neither HTTP URIs nor blanknodes.

Situation

Some URIs are used in the property position of a triple but are neither declared as owl:ObjectProperty, nor as owl:DataTypeProperty.

Problem

This violates the typing constraints of OWL 2 DL.

Solution

List all URIs are used in the property position of a triple but are neither declared as owl:ObjectProperty, nor as owl:DataTypeProperty. Exclude those defined in vocabularies like RDF, RDFS, OWL and so on.

Situation

Some URIs may be defined as more than one of owl:ObjectProperty, owl:DatatypeProperty and owl:AnnotationProperty.

Problem

This violates the typing constraints of OWL 2 DL.

Solution

List all URIs that are defined as more than one of owl:ObjectProperty, owl:DatatypeProperty and owl:AnnotationProperty.

Situation

Some URIs may be used in axioms without being defined as an owl:Class.

Problem

This violates the typing constraints of OWL 2 DL.

Solution

List all URIs that occur in axioms but that aren't defined as an owl:Class.