Custom Ranges

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 ST 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 Ranges

Custom Ranges allow the user to customize the range of properties beyond what is axiomatically asserted in their definition. Furthermore, they allow to define complex patterns for creating new objects by providing customizable forms for filling the information they require to be consistent in the domain of interest.

Custom Ranges have been implemented in Semantic Turkey 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 Semantic Turkey exploits all the power of PEARL, to build forms by means of UIMA feature structures. User-defined feature structures are parsed by ST 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.

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.

Usage

Custom Range Graphic Editor

To configure the CustomRange mechanism, a configuration panel is accessible through the Firefox menu bar, by selecting the item Tools > Semantic Turkey > CustomRange (if the menu bar is not visible, press alt key).

The panel is composed of three main sections:

the top section allows to create relations between properties and Custom Ranges;
the middle section allows to create, edit and remove Custom Ranges;
the bottom one allows the same operations for the Custom Range Entries.

The top section manages the relations between properties and Custom Ranges, it allows to create and remove property-Custom Range associations. Clicking on New button, the dialog shown below will open. The property can be insert simply by typing the URI in the appropriate textbox or in alternative by exploring the property tree accessible by clicking on the blue button. Then the Custom Range can be selected between the one availables, which are listed in the same dialog.

If the desired Custom Range is not yet present, a new one can be created from the middle section of the configuration panel that allows also to edit or remove the available ones. In the Custom Range editor dialog (openable by clicking on the New or Edit buttons, depending on the operation to perform) is possible to define the Custom Range ID (not in edit mode) and to change (add and remove) the Entries that compose the Custom Range.

Finally, from the bottom section of the configuration panel, is possible to create new Custom Range Entry, edit and remove the available ones. The following attribute can be edit:

ID: a namespaced identifier;
Name: a short name which at the same time may suggest the nature of the range. This is also used in the UI to present the entry as a choice;
Description: a natural language understandable explanation of the range type. This is used as tooltip for when the mouse hovers over the choice;
Type: tells the nature of the range graph for reified resource or node for URI or literal;
Ref: the content of this property depends on the type of the entry. In case of graph Entry it must contains a CODA rule expressed in PEARL language;
Show Property: only available for graph entries, specifies the property whose value should be used to render the reified resource.

Custom Form

The definition of a Custom Range has as side effect the creation of custom form to enrich a property. In fact, the node section of the CODA rule determines the fields that will compose the form. Let's explain how it work by example considering the nodes and graph sections of the Entry in the previous figure.

		...
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.
}
...

In the nodes section there are defined the CODA placeholders. Here, the keyword userPrompt/ is used to indicate the values prompted to the user, furthermore what follows userPrompt/ is used to label the fields in the form. In the graph section, the placeholders are then used to define the reified resource. 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. The created node will not be prompted to the user but will be created by means a proper CODA converter.

Notice also that the datatype of a literal placeholder determines the accepted type of input in the field (see modified field).

In case of node Entry, where ref is simply a CODA converter and not a rule, the form will be composed by only one mandatory field with a default label value.

		 
literal^^http://www.w3.org/2001/XMLSchema#string

Custom Range files

The graphic editor is not the only way to edit Custom Ranges and Custom Range Entries, is possible to modify the files under the SemanticTurkeyData folder that contains a set of xml files which respect the following structure:

SemanticTurkeyData/

customRangeConfig.xml
it.uniroma2.art.semanticturkey.customrange.<cr_name1>.xml
it.uniroma2.art.semanticturkey.customrange.<cr_name2>.xml
...
it.uniroma2.art.semanticturkey.customrange.<cr_nameN>.xml
customRangeEntry/

it.uniroma2.art.semanticturkey.entry.<cre_name1>.xml
it.uniroma2.art.semanticturkey.entry.<cre_name2>.xml
...
it.uniroma2.art.semanticturkey.entry.<cre_nameM>.xml

Notice that as convention, every Custom Range file must be named with this syntax: it.uniroma2.art.semanticturkey.customrange.<cr_name>.xml
and this must be also the ID of the Custom Range. The same about the Custom Range Entry files which must be named it.uniroma2.art.semanticturkey.entry.<cre_name>.xml and this must be as well the ID of the Entry.

customRangeConfig.xml is a configuration file that links properties to Custom Ranges. This file contains a list of <configEntry> which have three attribute: property (the URI of a property), idCustomRange (the ID of the CustomRange to assign to the property) and replaceRanges, a boolean that indicates if the Custom Range should replace the classical range. For example, skosxl:prefLabel has range skosxl:Label, if a Custom Range is provided for this property, and the replaceRanges is true, skosxl:Label will be no more considered as range and it will be replaced by the Custom one.

		 
<customRangeConfig>
	<configEntry property="http://www.w3.org/2004/02/skos/core#note" 
		idCustomRange="it.uniroma2.art.semanticturkey.customrange.note" 
		replaceRanges="false" />
	<configEntry property="http://www.w3.org/2004/02/skos/core#definition" 
		idCustomRange="it.uniroma2.art.semanticturkey.customrange.note" 
		replaceRanges="false" />
	...
</customRangeConfig>

An example of Custom Range file is shown below. In this way the Custom Range identified as it.uniroma2.art.semanticturkey.customrange.note is an aggregate of the Custom Range Entries (<entry>) with the given IDs.

		 
<customRange id="it.uniroma2.art.semanticturkey.customrange.note">
	<entry id="it.uniroma2.art.semanticturkey.entry.reifiednote"/>
	<entry id="it.uniroma2.art.semanticturkey.entry.flatnote"/>
	<entry id="it.uniroma2.art.semanticturkey.entry.twolevelreifiednote"/>
</customRange>

Finally, here is an example of Custom Range Entry xml file that contains the attributes already explained previously.

		 
<customRangeEntry id="it.uniroma2.art.semanticturkey.entry.reifiednote" name="Reified note" type="graph">
  <description>
    A reified note, described by an RDF Resource linked through rdf:value to its lexical representation and to other metadata
  </description>
  <ref showProperty="rdf:value">
    <![CDATA[
        prefix	xsd: 	<http://www.w3.org/2001/XMLSchema#>
        prefix	rdf:	<http://www.w3.org/1999/02/22-rdf-syntax-ns#>
        prefix	dc:		<http://purl.org/dc/terms/>
        prefix	coda: 	<http://art.uniroma2.it/coda/contracts/>
    
        rule it.uniroma2.art.semanticturkey.reifiednote id:reifiednote {
            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.
            }
        }
    ]]>
  </ref>
</customRangeEntry>