We’re happy to release Pellet Integrity Constraint Validator version 0.3, a prototype system that uses OWL ontologies as integrity constraints for RDF data. ICV automatically translates OWL axioms into SPARQL queries (while still doing OWL inference, by the way!), so that an OWL ontology can be used to validate RDF data integrity automatically.

This offers the best of at least three worlds: the logical rigor and expressiveness of OWL; the “loose typing” of RDF and Linked Open Data; and the performance and scalability of SPARQL engines.

What’s new in Pellet ICV 0.3? Glad you asked:

1. explanations of violations
2. choice of validator implementation: Jena or Pellet will execute auto-generated SPARQL queries
3. option to check all IC violations
4. more efficient auto-generated SPARQL queries (using NOT EXISTS statement instead of LET in ARQ queries)

As always, comments, questions, and feedback are welcomed.

I’ve been working on an internal project lately, and while we were having a code review the other day, we decided that adding some validation via integrity constraints would be useful.  The catch was that I’m using Sesame, in particular, Sesame 1.2.7 since that offers the best query performance of their whole line of software (at least it did the last time I checked).  And since I am using the older Sesame API, I’m without SPARQL support.  This makes it difficult for me to repurpose our IC prototype since it’s based on Jena and SPARQL.

So I worked on an implementation of our IC interface that was based on the Sesame API and used SeRQL.  This turned out to be vastly easier than I expected.  One of the workaround’s we used for the SPARQL-based implementation was the OPTIONAL/FILTER/!BOUND pattern because SPARQL does not provide a NOT keyword for encoding Negation as Failure.  As it turned out, I didn’t need to implement a workaround like this using SERQL. I was able to get by using the NOT & IN keywords with a subquery to get the same behavior. The resulting queries are very clear.  So with some code to translate the constraints into SERQL queries, and a Sail implementation backed by a Pellet KnowledgeBase, we get the same IC joy in Sesame projects as we do with Jena and SPARQL.

This is good fodder for the new SPARQL working group that we’re participating in (nominally, so far); I believe subqueries and negation are both being considered.  They would make great additions to the revised SPARQL.

Simple Integrity Constraints & Reasoning

In this post I want to give a simple example to motivate the integration of OWL reasoning with integrity constraint checking. Consider the case encountered when instance data is expressed in terms of the most specific concepts in an ontology:

So, in this ontology there are three concepts: citizen, man, woman; and all citizens are men or women but not both. And, further, there is a property, Social Security Number.

The instance data is

So: there is a woman, Marge; and a man, Homer, who has a Social Security Number. In this example, how can we say that all citizens should have Social Security Numbers? Like this:

But without reasoner integration, this constraint won’t apply to either Marge or Homer, because the constraint refers to citizens, not to men or women. Which is as it should be since duplicating the constraint is not only inaccurate but error-prone (DRY, after all).

Since our integrity constraint checker uses OWL reasoning, however, it will infer that Marge and Homer are both citizens:

Thus, when it applies the integrity constraint (that citizens must have SSNs) it will produce a validation error: Marge is a citizen, which we know by reasoning, but the data does not contain Marge’s SSN.

Bad Workarounds

Integration with reasoning allows us to do better data modeling, since it prevents us from repeating the constraints for all of the most specific class types (men, women) when it’s simpler to put the constraint on a more general class (citizen). And this is more accurate data modeling, too, since the requirement for SSNs is not dependent on a person’s gender.

The obvious workaround, if you don’t have reasoning integrated with constraint checking, is to write integrity constraints in terms of the most specific concepts, which is almost always an unnecessary proliferation of constraints–violating DRY–and may be inaccurate modeling, too.

This workaround makes constraint authoring and maintenance much more difficult. By integrating with the reasoner, we support a more natural and scalable approach to integrity constraint specification, one that leverages the ontology by placing constraints appropriately high in the class hierarchy.

Preview Release

If you want to play with a preview release of our OWL-based Integrity Constraint validator, you can download it now. Note that it’s not licensed under open source terms. This version will likely be released open source in a future version of Pellet, but we’re not doing that today. Information about installation, use, and the forum for more information and bug reports (please!) are all included in the README.txt. Details of the evaluation license terms are in the LICENSE.txt.

Edited: 2009-06-18 to update version at download link.

Why Integrity Constraints?

Using OWL as an expressive schema language–i.e., giving OWL an integrity constraints semantics–addresses a general use case that neither OWL nor OWL2 can handle. In fact, people new to OWL often misunderstand this point, thinking that it’s an expressive constraint language that can be used to validate instance data as in relational databases or XML tools. People have a similar expectation for RDFS, too. After all, it sounds like RDF Schema should be to RDF what XML Schema is to XML. But it turns out that, due to the Open World Assumption (OWA) adopted by RDF and OWL, the axioms in an ontology are meant to infer new knowledge rather than trigger an inconsistency.

The simplest way to demonstrate this misconception in the context of RDFS is

   :isManufacturedBy rdfs:range :Manufacturer .
   :product1 :isManufacturedBy :ACME .

where the range restriction causes the inference that ACME is a Manufacturer, rather than causing a range violation–since ACME is not explicitly defined to be a Manufacturer instance. The same kind of unexpected inferences occur when using OWL constructs; for example, with cardinality constraints, missing values do not cause an inconsistency and extra values cause two individuals to be inferred owl:sameAs.

photo credit: House Of Sims

The key point is not that people don’t understand OWL, but that their expectations point to real use cases relevant to some kinds of applications. For example, you can use OWL axioms as integrity constraints in order to validate message structures exchanged in Supply Chain Management (SCM) systems. Similar use cases arise in an Enterprise Service Bus (ESB) when you exchange messages encoded in RDF/OWL rather than XML in order to perform “semantic validation.” Likewise, there are use cases for OWL as a kind of schema language for RDF instance data in Linked Data apps where the natural affinity between OWL and RDF–which the OWL2 working group has worked very hard to preserve, while evolving OWL2–has been difficult to achieve because of, in part, the lack of integrity constraint semantics for OWL.

Interpreting OWL axioms as constraints

Our approach to all of this is to give an alternative semantics for OWL axioms so that they are interpreted with CWA and a weak form of Unique Name Assumption (UNA). CWA interpretation means that we assume an assertion is false if we don’t know explicitly whether it is true or false. Weak UNA means that if two individuals are not inferred to be the same, then they will be assumed to be distinct. Then the user or application specifies that an ontology should be interpreted with standard OWL semantics and another should be interpreted with the alternative semantics. Or they specify that some ontology should be treated as a set of constraints for some RDF data.

The alternative semantics we use is based on the way integrity constraints are supported in classical Datalog systems where constraints are written in First Order Logic and then translated to Horn rules that use Negation as Failure (NAF). Since OWL is a subset of First Order Logic this approach works quite nicely for translating constraints written as OWL axioms.

In our case it turns out we can do this translation to SPARQL queries rather then Horn rules. So an OWL axiom is automatically translated to one or more queries; then if at least one query returns a result, that means the constraint is violated. I will explain the technical details of our approach in another post, but let me show the SPARQL query generated if we declare the range restriction above as a constraint:

   ASK WHERE {
      ?x  :isManufacturedBy  ?y .
      NOT { ?y  rdf:type :Manufacturer . }
   }

Of course the NOT keyword is not part of SPARQL, but you can fake it with the well-known OPTIONAL/FILTER/!BOUND pattern for encoding NAF in SPARQL.

This translation works for all OWL axioms and constructs, including everything in OWL2.

This means that users and developers don’t need to learn a different constraint language or learn to write complex SPARQL queries by hand, which is impractical since these queries get complicated for anything more complex than trivial examples. Instead they can just build OWL ontologies using their favorite OWL editor or reuse existing OWL ontologies and then just say that they want the axioms in these ontologies to be treated as integrity constraints.

So our new IC validator for Pellet means that you can now use Pellet and OWL to both create new knowledge and validate SemWeb instance data. That’s code and specification reuse for the win. That it’s also a very concrete bridge technology between RDF and OWL is icing on the cake.

What’s Next?

We are wrapping up the prototype and expect to release a version of it soon. In some future weblog posts, I’ll describe how constraint validation interacts with reasoning results and delve into the details of our technical approach.

Related articles

• Making Linked Data Reasonable using Description Logics, Part 1 (mkbergman.com)

Please take the OWL Integrity Constraints Survey to influence the future direction of Pellet. For background information about Integrity Constraints in OWL, see Opening, Closing Worlds—On Integrity Constraints.

This is neither a good nor bad thing; it just means there are at least two Big Use Cases people want to use OWL for: inferring new knowledge (CHECK) and abstract, expressive schema language (FAIL).

But giving a new — alternative or supplemental — semantics to OWL is non-trivial, which is why when NIST put out an SBIR solicitation for R&D related to using OWL in Supply Chain Management, we submitted an integrity constraints proposal. (Also, a sidenote for OWL Haters: you can’t, by definition, get more practical or “real world” than SCM. Not possible.)

Happily, we found out recently that we were awarded this funding (with very strong technical evaluations — yay!) and work is beginning soon:

1. We’re working on an OWLED EU paper, with Evan Wallace of NIST, that describes the design space; I’ll post links to the paper ASAP.
2. We’re actively soliciting use cases and requirements for OWL integrity constraints: please get in touch if you have feedback.
3. There will be some software released by early 2009 at the latest for experimentation.

SBIR Phase I funding will cover this work; but the follow-on, Phase II, is considerably larger and that’s where, if we can snag Phase II, we’ll push the prototype to production-grade, integrate it with the rest of Pellet and other OWL-based systems of ours (Owlgres comes to mind), and make a concerted “push to market”.

An industrial-quality Integrity Constraint subsystem for Pellet will open it up for use in new apps and, thus, in new markets. That’s exciting and, as always, we’ll be looking for commercial partners to work with us on those challenges.