Open World Validation in OWL

Clark & Parsia proposed that ontologies be separated into open-world assumptions and closed-world integrity constraints. The integrity constraints are simply an OWL ontology that is interpreted as validations rather than inferences. For example, an OWL ontology used as an integrity constraint may have a restriction stating that only managers can supervise employees. Under normal open-world semantics, anyone who supervises an employee is inferred to be a manager. Under closed-world semantics, someone who supervises an employee must be asserted to be a manager, otherwise there is a data consistency error.

The C&P recommendation is simple -- a new annotation property og:imports allows an ontology to import another ontology as integrity constraints. C&P have implemented integrity-constraint validation in Pellet. Other inference engines ignore the annotation property and never import the integrity constraints.

It really is a mindset issue.  If you approach ontologies with the mindset of databases (closed-world semantics), then you want to validate that any property that has been defined with a domain is only used on an object that is a member of the domain.  You interpret the domain statement as a usage or integrity rule. 

If you approach ontologies with the (correct) mindset of inferencing and open-world semantics, then you interpret a domain statement as an inference:  anything that has the property is inferred to be a member of the domain.  There is very little validation that can be done in open-world semantics -- if you want to use domain and range statements as kinds of usage constraints, then you have to go to the trouble of defining a lot of disjoint classes so that you can detect an inconsistency. 

For example, if the domain of the property "hasBarkTexture" is the class Tree, and there is an assertion that my dog Fido hasBarkTexture of "Ruff", then the only way to detect an inconsistency is if Dog and Tree are defined to be disjoint.

The main problem is that people who are building ontologies aren't in general trained ontologists, and aren't thinking in terms of open-world semantics.  They are approaching ontologies as if it were an exercise in object-oriented or database design, and they are making mistakes when defining properties and classes.  They are using domain statements as if they were defining class properties, and using range statements as if they were defining property value or type constraints.  That isn't correct, as far as the OWL theory and inferencing goes.

As long as people don't use inferencers, the incorrect semantics doesn't matter much.  But since all the inference engines are designed according to the OWL open-world semantics, as soon as a poorly designed ontology is used with inferencing, all kinds of problems will arise.

We (the ontology team) are planning to investigate this thoroughly with respect to the mapping ontology.  My intuition is that the general idea is very good, though I'm not sure about the details of what they propose.  One issue is that there is no standard definition of how to interpret OWL constructs for closed-world reasoning, as there is for open-world reasoning, so we would either have to define our own (and build our own OWL-based validator) or depend on the Clark and Parsia guys (and use Pellet).  I suppose this is another area where we could help push toward a de facto standard. I don't really like the idea, but it's still early, I may come around to it.

I would say the ideal way for this to work (in my imagination) is that all our validation rules could be expressed as SPARQL queries. This would allow the ontologists to build the validator themselves, simply by creating dashboards that are driven by the SPARQL queries.  We wouldn't actually have to code a custom GUI and tool for validation, it would just be another instance of building a page by laying out SPARQL-driven widgets.  I think this is possible, but I'm not sure.

In any case, we'll let everyone know what (if anything) we figure out in the next couple weeks.