Linked data schemata: Fixing unsound foundations

2.1. Challenge 1: Heterogeneous use of RDF, RDFS, OWL and others

OWL DL ontologies describe a formal domain model based on description logic. It is a difficult task to produce a logical model which accurately and correctly encapsulates any non-trivial domain [7]. This has probably influenced the relative popularity of RDFS terms in linked data [28]. In the wild, RDF and OWL are mixed very freely [16,28]. Polleres et al. phrase this as their challenge 2 for reasoning over linked data i.e. linked data is not pure “OWL”. In fact some common linked data vocabularies make reference to other ontologies which are not compatible with OWL at all, but specified in raw RDF collection types, or worse DAML or even other esoteric languages (see Section 6 for the evidence we have collected). Since these ontologies reference each other’s terms, full validation cannot proceed without determining whether the referenced ontologies are themselves consistent and complete.

If linked data was limited to the use of RDFS or OWL DL, or perhaps even some extension of OWL DL which could encompass elements of OWL Full (such as predication over classes and properties) then consistent model checking would be possible. However the problematic historical unification of RDF and OWL as OWL Full has led to an interpretative fissure between it and OWL DL [18]. OWL DL provides a clear model theoretic semantics which allows one to decidably determine whether a given OWL ontology, potentially coupled with instance data, is consistent. By contrast, OWL Full attempts to mix in the very loose syntactic rules of RDF to arrive at a compromise between OWL and RDF and is not decidable due to mixing logical and metalogical symbols. In fact the full unification of RDF and OWL was dropped as a requirement for OWL Full in OWL2 [6].

Two very problematic deficiencies that are encountered when interpreting RDF/RDFS ontologies as OWL for the purpose of model unification are the use of primitive RDF collection types and predication. The primitive RDF properties rdf:first, and rdf:next are seen in the wild but these are used as internal syntactic symbols of OWL. This means that they cannot be used by properties and classes without leading to inconsistency.

The second problem which arises in the wild is the question of predication. In OWL DL, one may not refer to classes of classes, or properties whose domains are themselves classes or properties. This was done in order both to ensure decidability and to avoid well known “Russell-type” paradoxes such as this one derived from [27].

This particular OWL description is satisfied only when it is not, and vice versa. The difficulty arises from the ability to quantify naively over the rdf:type property itself. This is very similar to Russell’s use of the set of all sets. There are methods, well known to logicians [22], of allowing predication over classes and predicates by introducing some sort of stratification to the quantification, but no syntax to do so is present in OWL.

In summary the heterogeneity of linked data schemata means that OWL Full is insufficient for validation and the incompatibilities between RDF and OWL DL mean that even if a single model could be constructed, OWL Full would be undecidable and/or incomplete.

2.2. Challenge 2: Linked data import and referencing semantics

In linked data schemata there are two ways that other ontologies/vocabularies are referenced, either by explicitly including them using owl:imports, or implicitly by making reference to URIs of properties and classes in an external namespace. The meaning of the first is given a precise semantics under OWL DL (which is not unproblematic in its own right as we will see later) and the entire imported ontology is unioned with the current one during reasoning. The second is a widely used convention that URIs are referred to without importation, for example see [5]. This leads to the question of how to validate over such opaque references. This is a serious problem as one could potentially be referring to an instance as a class, or a class as an instance, one could have references to a class which refers to a third ontology which is shared and does not allow sound subsumption, or any number of other such problematic mixing of meanings without any way of checking for correctness.

2.3. Challenge 3: The impact of distributed authoring and publication

Developing ontologies that can be easily reused in contexts that were not anticipated by the ontology developer is analogous to the software engineering challenge of developing libraries for reuse in situations where they must coexist with a wide variety of other libraries – many of the same principles apply. For example, a basic principle of software engineering is that libraries which use other libraries should not change their behavior for other libraries. Similarly, ontologies which alter other ontologies are dangerous. Gruber expressed one aspect of this as being “able to define new terms for special uses based on the existing vocabulary, in a way that does not require the revision of the existing definitions” [12]. This sensitivity to ontological hijacking is particularly relevant as OWL’s support for modularity is extremely primitive – the import statement unifies models into a common model that has a global scope.

To understand why ontology hijacking is a problem, consider the following example. Vocabulary A imports vocabulary B and changes the definition of class X within it with the owl:equivalentClass predicate. Vocabulary C also imports ontology B and uses class X, then imports vocabulary A to use an unrelated term within it. Unless the author of C carefully checks the definition of A, they will find themselves unknowingly using a modified version of class X which may render vocabulary C as invalid. This is closely analogous to the situation where a software library modifies the behavior of other libraries – a situation which has been widely recognized as breaking good software engineering practices since the 1970s: software libraries should not have external side effects.

Of course if A, B and C are subsequently unified into a single model, then logical inconsistencies can become apparent. Due to the complexity of OWL, these inconsistencies may only be detectable by reasoner and despite the prevalence of OWL terms in linked data vocabularies it is evident from our findings that many creators of these vocabularies do not perform reasoner-based checks.

Linked data’s focus on the reuse of independently developed and maintained ontologies introduces other significant practical problems. Ontologies that reuse other ontologies are vulnerable to these referenced ontologies becoming unavailable over time, or changing in ways that render them incompatible [28]. This highlights the weaknesses in OWL and especially RDFS’s ontology or vocabulary lifecycle support and the variety of practices observed makes automated approaches untenable for the open Web of Data where many core vocabularies predate even OWL2’s limited versioning metadata. Given the wide diversity of contexts in which they have been developed – and the cost and difficulty in maintaining them – there is a significant risk of ontologies degenerating over time due to changes in the availability or structure of their dependent ontologies.

The OWL API [17] is one approach to addressing this problem – it supports locality of information allowing one to only treat assertions made in a specified or local context. However, this depends upon all concerned ontologies using this mechanism correctly and ontologies being well structured.

2.4. Challenge 4: Permissivity of OWL and RDFS

OWL and RDFS are an extremely permissive languages – reasoners will create a valid model wherever possible, inferring many elements automatically [25]. Thus a number of OWL and RDFS descriptions which are formally correct contain human errors not intended by the ontology designer, and yet will produce valid models. For example, the following assertions:

These will create Peter as an instance of a “ManBearPig” due to OWL and RDFS allowing inference of class axioms that would produce a valid model. This is counter-intuitive to software engineers who assume a class structure that must be declared in advance. Thus, such specification errors are common in practice yet they are not detected by standard reasoners.

3.1. Frameworks and approaches for assessing linked data quality

The underlying framework for current linked data quality assessment has been defined by Zalveri et al. [36]. In terms of their quality framework our current work addresses mainly intrinsic dimensions of the schema – syntactic validity, semantic accuracy (in terms of misuse of properties) and consistency. However we also address the contextual dimension of understandability by checking for human-readable labelling of properties and classes.

Our current work builds upon the previous version of our Dacura data curation platform [10] by extending the simple rule-based data validation implemented in Apache Jena/Java described in our Workshop on Linked Data Quality 2014 publication [23] with a custom reasoner and ACID (Atomic, Consistent, Isolated, Durable) triple-store for validation and data integrity enforcement. This new component, the Dacura Quality Service, is built in SWI-Prolog on ClioPatria [35] and is described in the next section. An earlier version of the Dacura Quality Service which covered a much smaller set of OWL features was described in a paper at the 2nd Workshop on Linked Data Quality [23]. That paper has been extended here to also include a discussion of the new Dacura Schema Management service, our experimental validation of linked data schemata in the wild and new recommendations for best practice when constructing new linked data vocabularies.

The RDFUnit methodology for test-driven quality assessment by Kontokostas et al. [21] is a SPARQL-based approach to validating linked data schemata and datasets. RDFUnit is very close to being a union of SPIN and the Stardog2

Since 2014, the W3C’s Data Shapes Working Group has been working on SHACL (Shapes Constraint Language) to describe structural constraints and validate RDF instance data against those. Instance data validation, (except where the data is part of the schema for example when using owl:oneOf to define a class), is outside the scope of this paper. However it is possible that suitable SHACL constraints could be used to validate RDF graphs describing schemata. As with the basic SHACL-based approach to data validation it is unclear why re-stating a specification in another formalism (SHACL) is a good approach to validation – see also [26] for further remarks on the applicability of description logics to constraints.

Luzzu [8] is a stream-oriented linked data quality assessment framework that focuses on data instance centric measurement of user-defined baskets of quality metrics. Although the metrics are expressed in a domain specific language that is described as extensible it would be necessary for the user to write java code to implement the necessary checks. This is not feasible for most users, even knowledge engineers: the user would have to write an OWL reasoner to detect the logical errors in the unified dependency tree of a linked data schema which Dacura identifies. The framework is potentially of great practical use to users of linked data datasets that wish to assess their quality based on a custom basket of measures, but provides very little assistance when assessing the logical soundness of the schema. One innovation of Luzzu is the specification of a Quality Report Ontology to provide machine-readable quality assessment results. Dacura has a similar ontology defined for reporting reasoning errors, the Reasoning Violations Ontology.3

Much closer to our Dacura schema validation service is Suárez-Figueroa et al.’s OntOlogy Pitfall Scanner, OOPS! [29]. This is a web-based tool for ontology evaluation. It is aimed at detecting ontology anomalies or “worst practices” as a form of automated ontology evaluation. It is based on evaluation of an input ontology against a catalogue of common errors or pitfalls seen in ontologies. There is very little overlap between the 41 pitfalls currently detected by OOPS! and the set of errors detected by Dacura due to the lack of OWL reasoning or model combination in OOPS. There are some easy to detect “best practice” pitfalls such as “P08 Missing annotations” which Dacura does not currently detect but which are simple extensions of our current best practice rules and will be added in future work. It is interesting to note that in their extensive analysis of current ontologies and the ontology engineering community, OOPS decided, like us, to define class cycles as a potential source of errors in linked data schemata, despite being legal in many cases in OWL 2. The implementation of OOPS! as a restful web service is very attractive and useful for integration into both a basic public webpage for checking and as a service called by other ontology engineering tools.

The challenges for reasoning caused by the unification of RDF and OWL has been extensively discussed in the literature, for example see Patel-Schneider and Fensel [27] where, even before OWL was standardized, these incompatibilities were summarized as “defining the model theory of OWL as an extension of the model theory of RDF and representing OWL constructs syntactically in RDF leads to paradoxical situations, i.e., ill-defined model theories for OWL”. The authors’ five approaches to layering OWL over RDF, including identifying the presence of Russell-type paradox if OWL is directly layered over RDFS as a same-syntax solution. Nonetheless this was the approach adopted in OWL-Full. The ramifications of these decisions live on today in our challenge 1 for validating linked data schemata.

Later, when the OWL standard was agreed, the principal authors of the OWL Semantics documented the “difficult trade-offs” that they made during the design of OWL version 1 [18]. Horrocks et al. identify four broad classes of problems: syntactic, semantic, expressive power and computational problems. While the latter two categories seem less relevant for our current work it was in fact the computational overheads introduced by allowing the use of classes as instances that led to the exclusion of this feature from OWL-DL and as will be seen in our experimental work, under the title of impredicativity, this causes many observed issues in linked data. In Section 6.2 of that paper the solution proposed for dealing with malformed OWL syntax expressed in RDF leads to the creation of additional anonymous classes despite them being “almost certainly not what was intended by the user”. This is an example of our challenge 4 (permissivity of OWL) that leads to standard reasoners being unable to detect these issues in linked data schemata without human inspection of the resultant reasoned ontology. In contrast our approach highlights these potential errors and presents them to the user or validator for verification. Finally in the discussion on future extensions despite the admission that the import of ontologies by other is likely to be the norm in the Semantic Web (as we now see in linked data) the OWL import facility is described as “very trivial” and this underpins our challenges 2 and 3 for linked data schemata validation. Both the closed world and unique name assumptions are identified as being desirable in some situations despite being outside the scope of the general OWL model. Our approach to schemata validation and the experimental evidence we have collected demonstrate the practical applicability of these assumptions for validation, even on the open web.

When the OWL standard was revised as OWL2 in 2008, the process was again documented by some of the principal authors [6]. Grau et al. identified additional issues with OWL1 ontology specifications, including an additional complication in the import semantics whereby two (or more) ontologies written in the same OWL species can interact in unpredictable and unintuitive ways when one ontology imports the other, leading to a new ontology that is contained in a different species. OWL 2 introduces the idea of declaration consistency which means all types must be declared, although not syntactically necessary, this forms the basis for additional validation checks to catch mistyping of entity terms. However this approach is not applicable to linked data that is not written in OWL 2. The validation checks performed by our approach can detect such trivial typing errors in general linked data schemata e.g. misspelt names of classes. OWL 2 also improves support for imports by tightening the specification of ontology name URIs as both name and published location of the ontology on the web. However, as our experimental results show (Section 6) not all commonly imported ontologies in the current Web of Data are at their stated locations. Ontology versioning management support is also added, but this is still primitive and the species or profile impacts of imports is still unintuitive and unpredictable (challenge 2).

Most recently, as the success of the open linked data movement has become apparent, with billions of triples published, the question of data quality and hence validation has come to the fore [2,24]. Patel-Schneider [26] discusses the issues and approaches to applying description logic to validation, attacking the claim that closed world or unique name interpretations have no place in the description logic world (and hence within OWL/RDFS) and can be applied to linked data for validation. Although Patel-Schneider focuses on RDFS and a SPARQL-based approach to validation of linked data, our approach adopts some of the same assumptions about closed worlds and unique names in our custom reasoner.

OPEN IN VIEWER

Fig. 1.

Screenshot of the Dacura Schema Manager.

The original Semantic Web vision included the goal of applying reasoning at a web scale [1]. Linked data provides the basis of the current Web of Data and so reasoning over it has naturally been tackled by several researchers, see for example [9,20] and [28]. Given the divergence of linked data from the Semantic Web ideal, a wide variety of non-standard reasoning approaches have been applied from probabilistic techniques [9] to rule-based approaches [20]. Given our interest in RDFS and OWL-based schemata validation we focus here on approaches that support the RDFS and OWL standards. The challenges for applying reasoning to linked data as laid out by Polleres et al. may be summarized as data scale, data heterogeneity (mixing of OWL DL, OWL Full and RDFS), data inconsistency, data dynamics and extending inference beyond RDFS and OWL. Data scale is less of an issue for our work since we focus on schemata and thus primarily TBox assertions, although some linked data schemata (e.g. OpenCyc – see Section 6) include instance data which render them very large. Nonetheless the focus of open web reasoning work on operating on billions of triples largely addresses challenges which are out of scope for our validator. Tackling heterogeneity is also a focus of our work (challenge 1) but whereas we aim to identify inconsistent or incomplete schemata in order to fix them and improve their quality, the approach of the reasoning over linked data community is to try and do the best possible with the triples available. While appropriate for their use case, it often leads to strategies that weaken consistency or soundness constraints to make the problem tractable, silently discard problematic triples or conservatively reduce the materialisation of inferred triples compared to completely applying the OWL Direct Semantics [28]. Although there are points of similarity, in general these approaches would produce weaker validation results than our approach since they are not sound and less complete.

As discussed in the background section, the free mixing of RDF, RDFS and OWL triples gives rise to different interpretations. Our approach is to deliberately misinterpret as OWL the RDF/RDFS classes and properties that are normally outside the scope of OWL-DL when there is no immediate conflict in doing so, e.g. a rdfs:class is treated as equivalent to an owl:class. This doesn’t present an insurmountable difficulty for reasoning. Similarly rdf:Property is treated at an equivalent level to owl:DatatypeProperty and owl:ObjectProperty and no overlap is allowed between them. All domains and ranges that are asserted are checked to ensure they support subsumption. Misuse of language features and low level RDF syntax with reserved meaning in OWL such as rdf:List is detected as an error.

This approach is applicable in situations where the data is going to be published only for the combined ontology, or used only internally to a system which interprets the instance data as OWL. This is in line with common practice for linked data but presents potential problems for interoperability of the produced linked data since OWL reasoners might deem it inconsistent due to the fact that we still allow a mix RDFS and OWL and hence are not a proper subset of OWL DL. However, as our experimental results will show, this is necessary for dealing with the commonly used vocabularies on the Web of Data today.

4.2. Overcoming challenge 2 (imports)

Since there are a range of ways that linked data schemata reference or import each other, it was necessary to define a mechanism to construct the composite ontology defined by a linked data schemata to enable validation under a closed world assumption. For this reason, we have treated all dependencies to external namespaces as implicit owl:imports.

Dependencies between ontologies were defined as either property dependence or structural dependence:

Property dependence: if an ontology A uses a property from another ontology B, then A is considered to have a dependence on B.

Structural dependence: if an ontology A contains a statement which defines its classes or properties in terms of entities in ontology B, then A is considered to have a structural dependence on B. Table 2 shows the specific OWL terms which we consider create structural links between ontologies.

Other references to external URIs in a schema were ignored.

Having defined what we considered to amount to the class of dependencies between ontologies, the Dacura Schema Manager tool implements these rules to analyse any given ontology and recursively create its dependency tree, fetch the constituent ontologies or vocabularies and create a union between them for checking by the DQS.

4.3. Overcoming challenge 3 (distributed authoring)

The Dacura Schema Manager detects all dependencies between ontologies as described in the last section. This forms the basis for detecting references to missing or unavailable ontologies. Similarly it can detect namespace violations such as ontology hijacking when they occur in input ontologies. The logical consequences of building unified models from many ontologies are detected by the DQS, especially when local work-arounds have been made that render the unified model inconsistent.

4.4. Overcoming challenge 4 (OWL permissivity)

By applying the closed world assumption to the full graph imported from the Web of Data that specifies a linked data schema it is possible to detect orphan classes. These are rejected as incompletely specified (similar to the use of declarations in OWL 2 but without the need to augment existing ontologies with these new declarations). In addition, the detection of subsumption failures and cycles in class or property declarations allows us to detect potential misuse of OWL features.

We applied the Dacura Schema Manager dependencies tool to all of the top 50 ontologies identified. The output of this tool (Fig. 1) was used to identify the set of ontologies and vocabularies that each ontology depends on directly, then we included these ontologies, identifying the set of ontologies needed by these included ontologies, including them and continuing until all of the dependencies were included or were deemed to be impossible to include. This produced a breadth-first dependency tree for each ontology. This increased the number of ontologies in our analysis set to 91 – shown in Table 6. We then analyzed all these ontologies with the DQS tool to identify to what extent they exhibited problems in terms of creating a unified knowledge model that incorporated them. It should be noted that the ontologies that were included through this dependency analysis are almost all due to the inclusion of the most two most common vocabularies (dc and foaf) and thus most of the dependency tree shown here is common to virtually all linked data vocabularies.

Figure 2 gives an example of the dependency tree for one ontology: Open Annotation [30]. This dependency tree covers 22 of the top 25 vocabularies rated as most popular by LOV in terms of vocabulary reuse (incoming links) as seen in Table 3. This ontology was selected as an example for both practical and theoretical reasons. Practically, we wished to implement a system for the Seshat: Global History Databank in which users could annotate content at a variety of scopes and we wanted to be able to validate instance data which was expressed according to the ontology. Theoretically, it represented a good example of a linked data schema in the wild, as is shown by the analysis above, – it has been constructed by a W3C community group according to the linked data principles, using well known third party vocabularies and ontologies and it is in use in practice. It is ranked by LOV as the 32nd most popular linked data vocabulary overall (from 542 vocabularies) and its dependency tree, as discovered by Dacura, includes 25 of the 31 vocabularies rated as more popular than it by LOV.

OPEN IN VIEWER

Fig. 2.

Open Annotation dependency tree of linked data vocabularies and ontologies.

Our dependency analysis terminated whenever we came to an ontology that we could not retrieve, either because we discovered that the ontology no longer existed (e.g. WordNet), or because we proved unable to locate a machine-readable version of the ontology on the Internet, after approximately 8 hours of effort in searching. In one case our dependency tree brought us to an ontology that was simply too big for our tools to handle – OpenCyc (rdf/xml file: 246 MB) due to insufficient memory on our test computer. There was only two structural links to this ontology from the rest, so the omission can be considered to be relatively minor. In two cases dependent ontologies were written in DAML, a predecessor of OWL and these ontologies were not automatically analyzed as our tools were not capable of interpreting them. Manual analysis of both revealed that they had no further dependencies.

Once the dependency tree of ontologies for each ontology had been established, the composite schema so defined (consisting of the union of all of the imported ontologies) was analyzed by the DQS reasoner and the OOPS! tool for validation errors for each ontology in Table 6. See the next section for the results.

As is to be expected in the evolving Web of Data a number of the referenced ontologies were no longer available (at least they are not currently available at the advertised URL and we were unable to find them elsewhere) – Table 7. The linked data community should be aware of the implication of this for linked data quality – if schema specifications are going to be rendered incomplete due to changes in the availability of imported ontologies or terms then it places a limit on the degree of validation that can be performed – terms from such vocabularies become simple untyped variable names with zero semantics associated with them.

6.2. Ontology hijacking

A widespread pattern observed in the ontologies under analysis was the presence of assertions designed to support interoperability of ontologies (Table 8). For example, a very common pattern was to specify that certain properties from imported ontologies were defined to be of type owl:AnnotationProperty – to allow them to be processed by standard OWL tools which do not know how to deal with properties defined as rdf:Property. The basic problem with this pattern is that this amounts to non-coordinated interoperability on a library scope – each ontology attempts to handle interoperability for its own scope, but when these ontologies are combined together, each piecemeal attempt at interoperability is combined into a common model and the union of these piecemeal attempts at library level interoperability without any facilities for modularity leads to inconsistency.

The second major category of ontology hijacking observed in the data are illegal assertions that serve to silently kill error reporting in tools. For example the assertion: rdfs:Class a owl:Class is used in two separate ontologies – it declares that an RDFS class is an instance of an OWL class – an interpretation that is not true under OWL DL or Full but it manages to successfully silence error checking in a number of tools. These type of assertions are particularly unwise because they make the knowledge model inconsistent. They also break the robustness principle by deliberately producing malformed specifications rather than compensating for real-world variation and noise at input.

Finally, in a certain number of cases, ontologies knowingly and explicitly change other ontologies for convenience in utilizing external class definitions. This type of usage is most pointedly described in the bibo ontology:

An editorial note in the ontology states: “BIBO assert that a dcterms:Agent is an equivalent class to foaf:Agent. This means that all the individuals belonging to the foaf:Agent class also belongs to the dcterms:Agent class. This way, dcterms:contributor can be used on foaf:Person, foaf:Organization, foaf:Agent and foaf:Group. Even if this link is not done in neither the FOAF nor the DCTERMS ontologies this is a wide spread fact that is asserted by BIBO.” In such cases it would be more appropriate to use local sub-classing to achieve the equivalent effect without over-writing the definitions in external namespaces.

Three ontology were found to contain basic errors which were interpreted as typos – the predicate rdfs:ramge appears twice in contact (rather than rdfs:range). In dcat, the property name foaf:Page is used, whereas foaf:page (without capitalization) is the correct property name, while in nrl, 3 incorrect URLs are used to refer to classes and properties in rdfg (the correct URLs use ‘/’ rather than ‘#’ as an element prefix). The presence of such errors in long established and public ontologies highlights the lack of tool support for ontology validation – they are simple and obvious errors but they will not be identified by standard OWL reasoners (Table 9).

6.4. Impredicativity/misuse of language constructs

Since OWL DL is a first order theory, it is not possible to quantify over classes and predicates. Yet no such restriction exists in RDF. This leads to a number of problems when using OWL ontologies which reference RDF ontologies which make use of higher-order and impredicative features. In the very widely used dc ontology, the rdf:type relation is given a range of rdfs:Class. This is immediately problematic as rdfs:Class is the class of all classes and such impredicative statements cannot be made in OWL DL but are dangerous regardless, due to the very real threat of paradox. Similarly the rdf:subClassOf relation is used to derive a subclass of the class of classes. This again is higher order reasoning, without any guarantee of predicativity (Table 10).

In skos we see the use rdf:List as a range, but rdf:List is an internal syntactic element of OWL. Free mixing of rdf:first and rdf:next would leave reasoners unable to distinguish what is intended as a property and what is intended to be syntax of the language itself. While this problem has been described thoroughly [18], it also has not been stamped out in the wild, and skos is a very widely used ontology purporting to be OWL.

In gn, log, void, qb, wdrs, atom, voaf we see the very common use of higher order logic, with subclassing of class, properties, and assignation of ranges over properties and classes. In most of these cases the statements were probably unnecessary. However higher order reasoning may sometimes be useful and we will discuss later how such things can be achieved without stepping into undecidability.

In atom there is an even more unusual metalogical statement, making a statement about statements themselves! Without some sort of stratification such logic is dubious at best. Atom additionally makes use of inference facilities that are not themselves part of OWL. Utilizing ontologies of this form requires a tool chain which is capable of making these inferences, which is something which is not widely available.

6.5. Property/class cycles

Table 11 presents the class or property cycles detected in the crm ontology. The first example, asserts that a legal body is equivalent to a group, which seems highly questionable, though it would require the crm authors to confirm. The second looks more likely, but still questionable, where they establishing an equivalence between “bearing a feature” and “being composed of”.

We have also noticed that many statements of equivalence were between classes in different ontologies, establishing a link between an element in one place, and that in another. However, these equivalences were often coupled with additional qualifications. Such behavior completely negates the capacity to use linked data in an interoperable fashion, as the original publisher of the ontologies data may very well have instance data which is deemed invalid when read, by the second publisher, and vice versa. This “ontology hijacking” [15] should be highly discouraged.

The 50 most commonly used vocabularies were also analysed with OOPS! (OntOlogy Pitfall Scanner) [29] for comparison (although four failed to load). A this tool analyzes ontologies in isolation without loading any dependencies, the dependent ontologies analyzed by Dacura were not included. There is very little intersection between the classes of violations/pitfalls identified between the two systems because OOPS! is primarily a syntax scanner and it does not attempt to incorporate dependent ontologies and combine them into a unified model, nor does it apply any significant reasoning. However, OOPS! does check for several additional types of best-practice violations that are not considered to be violations from Dacura’s point of view. For example, the P08 missing annotations code produced by OOPS! reports cases where classes or properties are missing labels – while this is a useful check, there is nothing illegal about such missing elements and they thus do not cause Dacura to reject the ontology. The only areas where Dacura and OOPS! overlap is in the identification of absent domain/range assertions for properties and secondly in the identification of untyped classes and properties. Dacura also checks for such violations, however, in Dacura they are considered to be strictly informational messages as in many cases, such missing assertions are consistent with best practice, e.g. when the domain or range is specified in a super-property. In such cases, OOPS! violations will in fact be incorrect because it does not attempt to load super-properties and respecifying the domain or range in a sub-property duplicates information which complicates schema change management. Table 12 shows the results of testing the covered ontologies and vocabularies with OOPS!

7.1. Metareasoning with rdf:List

Ontologies in OWL cannot use the underlying syntactic elements of rdf:List within the logic of the ontology, as is done in SKOS. The appropriate way to deal with this problem is to have a drop in replacement for RDF collections written in OWL such that there is no syntactic/logical mixing. There have been some list ontologies constructed such as the Ordered List Ontology,6

The impredicative and higher order features of RDF are used by 15 of the top 50 ontologies (including their dependencies) and hence it can be considered a common problem. Supporting such behavior does not require abandoning soundness or allowing paradox. Type theory, going back to Russell, developed techniques to avoid impredicative paradoxes through the use of some form of stratification, which could be used to extend OWL DL. The complexity or indeed decidability of such an extension remains to be explored.

A lot of the uses of predication over types (e.g. in dc) are useful and have known solutions, e.g. [4,22] so it is strange to reject it as outside OWL DL. This is the reason naïve set theory is inconsistent. Punning provides some useful ways of providing information about classes and properties. However, this does not enable the same logical power, which is available through stratified predication where reasoning can be extended to the metalogical level.

7.3. Equivalence and hijacking

From the ontologies surveyed, it appears that equivalence within a given ontology is rarely needed. If a class is the same as another class, it seems unlikely to be the case that the ontology designer does not know it. If two classes are indeed the same, it is best to combine the definitions of the classes into a single class, which improves referential transparency and simplifies ontology management. If two names are needed, simply assigning more than one rdfs:label is recommended as a better solution.

However, there is the further use of identification of one class with that of another ontology. Such identification of classes with other ontologies leads to the question of why one would simply not use the class name from the alternative ontology unless one wants to actually hijack the class for extension? And if it is the later, then it seems unfair that the contract be entirely one sided, as any published linked data which comes from the ontology will no longer have the same meaning as that given in the original ontology.

One potential answer to this problem is that ontologies which intend to coordinate, and actually mean to be equivalent, utilise subclassing in either direction. So for instance, instead of saying:

One could say, in the ex and library ontologies respectively:

In this scenario, collaboration between ontology designers would be required, such that hijacking was less of a concern.

Where it is necessary to make ontologies backward compatible with existing tools, a custom ontology should be constructed and all interoperability assertions should be placed within it and then imported. Beyond such cases, Ontology hijacking should be avoided in all cases – just like when using external libraries in software engineering, importing ontologies should not have side effects on other ontologies. We propose a general design principle that importing ontologies should have no side effects.