VocBench Logo

Home Documentation Downloads Support About us

Custom Forms Management

The need to go beyond ontology-driven modeling

The editing capabilities of ontology editors are usually...ontology-driven. That is, data-entry forms are painted on the screen, and options for filling them are provided, by analyzing the axioms defined in the ontology vocabularies loaded in the dataset being managed, including both the W3C basic modeling vocabularies (RDF, RDFS, OWL, SKOS, SKOS-XL) and domain-specific ones. However, a purely ontology-driven approach has some limitations.

One typical limitation is the lack of axioms on annotation properties. The range of some properties is known "de facto", such as the use of language literals for RDFS and SKOS labeling properties, or rdfs:Resource in the case of rdfs:seeAlso, but no axiom is stating this information. We have solved this in previous versions of Semantic Turkey by introducing some hard-wired ranges in the system, taking precedence over the analysis of available axioms.

Yet, in many scenarios, users would benefit from a greater level of customization when valueing properties, as some objects only make sense when built according to well-known templates. For instance, a general-purpose RDF editor, would prompt the user with the possibility to select an existing skosxl:Label when valuing the skosxl:preLabel property, or to create a new one. However, a skosxl:Label instance only makes sense if a skosxl:literalForm is provided for it. Hence, a pattern with the mandatory skosxl:prefLabel --> skosxl:literalForm should be specified somehow. This is not limited to creation, but also to viewing: indeed, such kind of objects only makes sense if, in a view of the resource described by them, the skosxl:literalform linked to the skosxl:Label is explicitly shown, and not the URI/bnode describing it. Again, we have solved such typical cases with built-in solutions tailored over notable vocabularies (such is the case of SKOS-XL). However, we felt the need for giving users the possibility to tailor the UI of Semantic Turkey to their specific needs.

User-Customizable Forms

Custom Forms are a flexible data-driven form definition mechanism that we devised for VocBench, allowing users to perform a declarative specification of the key elements that concur to the creation of a complex RDF resource. In particular, custom forms rely on the combination of the following four key elements:

Custom Ranges have been implemented in VocBench through a (rather unhortodox :-) ) use of CODA, the UIMA-based framework for Unstructured Information Acquisition, Management and RDF-Triplification. In UIMA, information acquired from unstructured content is processed and stored inside feature structures that can be later retrieved and stored into a target repository according to different technologies and models. CODA extends UIMA by focusing on the triplification of UIMA feature structures. CODA provides a highly-expressive transformation language, PEARL, thought specifically for transforming feature-structures into RDF graphs.

The implementation of Custom Ranges in VocBench exploits all the power of PEARL, to build forms by means of UIMA feature structures. User-defined feature structures are parsed by VB and used to create a form for filling their content. The rest of the PEARL rule describes how the user prompted content is converted into RDF nodes and then composed into an RDF graph

The construction of new resources in VB through Custom Forms is managed through two solutions:

Data Architecture

In this section we describe the components realizing the data architecture of Custom Ranges in ST.

The PEARL rule defining the templates for these structured objects is embedded into an XML file called Custom Range Entry (see figure below). The binding between an entry and each specific property is defined in another XML file, called Custom Range. In the next section, we will see how to create these files in Semantic Turkey.

Custom Range concept

Usage: the Custom Form Management Page

To configure Custom Forms, a management page is accessible through the VocBench Tools menu.

Custom Forms Page

The panel is composed of three main sections:

The Custom Form section lists available custom forms. The greyed ones are factory-provided custom forms that cannot be altered, yet their content can be inspected (in order to use them as examples), or they can be adopted as-is.

The following action buttons are available for interacting with the listed forms and for cresating new ones:

Created custom forms are project-local. If users want to reuse a custom form across different projects, they can export them from a project and reimport them into a new project.

A click on the create button produces the following form for describing a Custom Form:

Custom Forms Page

Here follows a description of the fields in the form:

Editing Custom Forms

As anticipated earlier, Custom Forms are defined by specifying a PEARL document, declaring a set of RDF nodes that are created from a set feature structures. In fact, the node section of the CODA rule determines the fields that will compose the form. The graph section will then specify how these nodes are arranged into an RDF graph.

Custom Forms Editing

Let's explain how it works with an example, by considering the nodes and graph sections of the Form in the previous picture:

		...
nodes = {
    reifNoteId uri(coda:randIdGen["note", {}]) .
    noteLit literal userPrompt/note .
    source literal userPrompt/source .
    related uri userPrompt/related .
    modified literal^^xsd:datetime userPrompt/modified .
    created literal(coda:datetime["yyyy-MM-dd"]) .
}
graph = {
    $reifNoteId rdf:value $noteLit .
    OPTIONAL { $reifNoteId dc:related $related . }
    OPTIONAL { $reifNoteId dc:source $source . }
    OPTIONAL { $reifNoteId dc:modified $modified . }
    $reifNoteId dc:created $created.
}
...		
	

The nodes section is composed of various lines, each with three elements:

In the graph section, the placeholders for the created ndoes are then used to assemble the description of the resource created through the form. The CODA placeholders that appears in OPTIONAL block in this section will be optional in the input form too. So, in this case, there will be five fields: note, source, related, modified and created and only the first will be mandatory.

Note that the refiedNoteId and the created nodes are not created by transforming some user input, as the userPrompt element is missing from their rows. This means that these elements will be generated from scratch, as some converters are actually generators able to create new RDF nodes on the sole basis of some configuration (e.g. the coda:dateTiem converter generates the representation for the current date and time when not dateTime expression is passed as the third argument of the node declaration).

The Form Editor supports syntax highlighting, though it does not currently provide syntax completion. A syntax helper for the converters has however been provided, in the form of a converter picker, that lists all the available converters already loaded into the system, their possible invocation signatures (converters supports invocation overloading) and copying their syntaxes on the editing textarea, as shown in figure below:

Custom Forms Page

For each converter, it is possible to select the proper signatureby clicking on the pencil symbol besides the signature textfield, showing a chooser window like in figure below

Custom Forms Page

Overlaying Default Forms

Skos concepts, schemes, collections, etc.. all these kind of resources share default forms that expose advanced editing characteristics that cannot be (currently) represented through custom forms and that, in any case, should not be overridden by them. For instance, the concept creation form shows a list of schemes that will be associated to the new concept: this list. though editable, is defaulted to all schemes inherited from its parent concept (the one on which the "create child concept" action has been performed). Clearly this particular behavior *should* always be part of the concept creation form. In order to keep the peculiar characteristic of each resource's form, and yet to allow for a certain degree of customization, custom form adopt an overlaying mechanism in which the basic structure of known-resources' forms is kept, and the additional specification of a custom constructor is added to it.

In such overlaid custom forms, some of the information that is produced by the default part of the form could be necessary for computing some aspects of the custom part. E.g. the localname of a concept could be reused in the node section of the custom form, in order to create another resource connected to the concept whose URI is similar to the one of the concept. In order to support this possibility, all default forms fields are also mapped as

In the following figure, an editor opened on a new form cloned from the basic factory-based template for extending default forms

Custom Forms Page