Use Case: Instance Edit Forms

I would like to report on the requirement to automatically generate user 
interface elements based on shapes. This might be obvious to some on 
this list, but I still think there is value in writing it up for the 
requirements.

In TopBraid we have multiple implementations of input forms that can be 
used to edit 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.

HTH
Holger

Received on Thursday, 7 August 2014 05:59:06 UTC