Ontology-Driven Forms

In TopBraid we have multiple implementations of input forms that can be used to edit (and search for) instances of a given class. A common question in open systems such as RDF is: given a class (rdf:type), which properties should be listed on an edit form. In theory, any RDF instance can have any property but obviously it would be unhelpful to simply list all.

Our algorithm to determine "relevant properties" for a given class looks at

• properties with matching rdfs:domain (incl. owl:unionOf domains)
• properties that have owl:Restrictions on the type (or its superclasses)
• "inferred" properties based on rdfs:subPropertyOf
• predicates mentioned in SPIN constraints where ?this is the subject (this includes spl:Argument and spl:Attribute, as well as future shapes)

For our use cases, these conditions have turned out to be suitable heuristics. In TopBraid Composer (which is aimed at advanced users), we allow users to manually add other properties. In our web user interfaces (such as TopBraid EVN) we assume a closed world, but power users can override the default form layouts.

An example screenshot of such a form in TBC is here:

    http://knublauch.com/oslc/TBC-EditForm-InvalidSquare.png

You can see how this form is highlighting SPIN constraint violations (the square must have equal width and height) - it highlights the properties delivered by the CONSTRUCTed spin:ConstraintViolations. Each constraint violation also has a human-readable error message, again constructed by the constraint. This showcases the importance of a structured vocabulary to report constraint violations back (as Dimitris suggested earlier).

The object-oriented structure of SPIN and its inheritance model also allows the constraint checker to determine which constraints it needs to evaluate for a given instance. As a heuristic, it will only execute those constraints that are attached to the types or its superclasses. When executing those, it will pre-bind ?this with the currently selected instance.

The next question is how to determine the allowed values for a property, used to pick a suitable input widget. Our algorithm looks at the obvious candidates:

• rdfs:ranges
• owl:allValuesFrom restrictions
• default range of owl:Datatype/Object properties (xsd:string, owl:Thing)
• spl:valueType defined by spl:Argument or spl:Attribute
• future versions would check for whatever Shapes vocabulary gets created

Similarly, for cardinalities (number of allowed values), we look at

• owl:cardinality restrictions
• owl:FunctionalProperty (= max 1)
• spl:Argument (= max 1)
• future versions would look at Shapes cardinalities

In the following screenshot of one of our web products, the cardinality of "area" has been restricted using a SPIN constraint, so there is no + button.

    http://knublauch.com/oslc/EVN-EditForm-Chad.png

You can also see different input widgets depending on the value type.

I hope this illustrates how we are already using OWL with closed world semantics, and that OWL ontologies can be mixed and enriched with SPIN constraints. At the same time, a completely functional system to enter instances could also be built without any knowledge of OWL, just using SPIN and its (Shape) templates.