We demonstrate how to develop Web-based user interfaces for Semantic Web applications using commonly available, off-the-shelf Web widget libraries. By formally defining the underlying data model that is assumed by these widgets, Semantic Web application developers can use familiar RDF constructs to map their own data to the model implemented by the Widgets. As an example, we briefly describe the interface model underlying our own framework, and provide concrete examples showing how it has been used to create Semantic Web applications in two different domains. We conclude by discussing the advantages and limitations of our approach.
Semantic Web data is typically rich in interconnections and highly heterogeneous. Designing user interfaces for applications that use this type of data is intrinsically hard. Designing interfaces for highly diverse data tends to lead to overly generic interfaces that do not communicate the richness of the data to the end user. On the other hand, interfaces that communicate this richness effectively tend to work well for only a set of fixed schemas and not for the entire dataset. Finding a sweet spot that balances these two forces is not trivial, especially if one takes into account that most Semantic Web developers are not UI specialists, and often have even little affinity with UI design. The problem is even deepened because many Semantic Web developers tend to build UIs from scratch, as the fixed data model that is assumed by many off-the-shelf UI toolkits seems to conflict with the heterogeneity of their data.
In this paper, we argue that for a wide range of applications, such a sweetspot can be identified and formally modeled in
RDFS or OWL. By building standard interface components on top of this model, building an initial interface can be as easy as mapping the application’s data model to this interface model.
This approach has the advantage that it leverages the significant amount of design, implementation and testing effort already invested in today’s Web UI toolkits, and we believe that reuse of these commonly available toolkits will, in general, lead to better interfaces than interfaces that are designed and implemented from scratch by a (small) Semantic Web research team.
In addition, it replaces the traditional configuration and tailoring that is needed to adapt a generic interface to a local dataset by a straight forward RDF data mapping task, a skill most Semantic Web developers will have. By providing default mappings, it is even possible to provide a noconfiguration, first crude version of a user interface, very early in the application development life cycle. This will give RDF data developers the “instant gratification” that has made many Web 1.0 and 2.0 applications so popular. It also encourages them to, during their data modeling and data development tasks, think about how their data will be used in the end-user applications, and how their modeling decisions may impact the interface.
Finally, while our approach provides pre-packaged solutions
for common tasks, it does not prohibit application
developers to go beyond those solutions in order to add more
advanced or more application specific interface components. It
is built to be extended or to build other layers on top of it.
This paper is structured as follows. In the next section, we
discuss related work and compare it to the approach
proposed in this paper. As an example user interface model
and its binding to a Web UI toolkit, we discuss the interface
model upon which the ClioPatria [
Modeling part of the user interface in RDF is in itself not
new. Fresnel [
Web interface widgets have become a standard in web
development. The choice among JavaScript libraries is numerous
and all provide a convenient abstraction of low-level issues,
such as cross-browser support. Interface widgets for
semantic content are also available. Eetu Ma¨kela¨ et. al. provide
several interface widgets that work on top of their ontology
service infrastructure ONKI [
The approach of semantic widgets is also used by the Semantic Web company Mondeca 1.
In many domains there is a central role for persons,
locations, times and artifacts. Sometimes these are modeled
together as an event. For example, in the cultural heritage
domain works of art are created by persons at a specific time
1http://www.mondeca.com/index.php/en/
intelligent topic manager/applications/
semantic portal semantic widgets
and location. In a figurative art it may also be important
to know which persons, times and locations are depicted.
News images are also made on a specific time and place by
a specific photographer and depict an event often involving
persons, times and locations. Persons, locations and times
are thus good candidates for a central model which is
sufficiently generic, while sufficiently specific to answer the
classic who, where and when questions to the end user.
Manmade artifacts also play a central role in many domains and
their specific properties can often be abstracted from by
using, for example, a general vocabulary such as Dublin Core.
In addition, different domains often deploy their own set of
specific thesaurus concepts that describe the properties of
events. We found that SKOS provides a sufficiently rich and
abstract model to describe these concepts and their relations.
Within the semantic search and annotation framework
ClioPatria [
Autocompletion is an interface feature that allows users to
type only a few characters instead of a full word or phrase.
After the user has entered the first characters, the system
responds by completing the word or phrase. If the characters
typed in so far can be completed in more than one way, most
interfaces present a list of multiple options. The user can
than either select one of the options from the list, or
continue typing to narrow down the number of options.
In context of the Semantic Web autocompletion is useful to
quickly find a resource by one of its labels2. In previous
work we argued that for different tasks and data sets
autocompletion widgets require a different configuration [
The two examples are built on top of the YUI autocompletion widget. The YUI widget contains several client side configuration parameters, it supports custom functions for result formatting, construction of remote data requests and it provides many event handlers. Although this is sufficient to configure the widget for an RDF data source, we experienced that it required extensive JavaScript programming to obtain the appropriate configurations. For example, visualizing different types of information requires the configuration of the server request as well as the client side JavaScript formatting functions.
An interface model for an autocompletion widget provides a single focal point for the configuration of a widget and only requires Semantic Web modeling skills. Note, we do not claim that this is a complete model for autocompletion, we merely want to illustrate that it is possible to define an interface model for an autocompletion widget in RDF. The model we present is for an extended version of the YUI autocompletion widget. We added support for clustered presentation of search results, a secondary display that is shown when the user hovers over a suggestion, a single configurable result formatting function and support for easy configuration :selection :organization :visualization :target rdfs:Class :match (rdf:Property) :sort (exact || inlink
|| rdf:Property) :group (rdf:Property) :smush true || false :max integer :primaryDisplay :preLabel (rdf:Property) :altLabel (rdf:Property) :subLabel (rdf:Property) :postLabel (rdf:Property) :secondaryDisplay of the server side search algorithm.
An interface model for the RDF concept autocompletion widget is shown in Fig. 3. The widget contains three main configuration properties that correspond with the three phases of the search process: selection, organization and visualization. For the selection of the appropriate resource it should be known what type of resources should be selected and which literals should be used to find these resource? The first is configured by providing an rdfs:Class for :target3. The second requires the definition of a collection of RDF label properties for :match. The order of the properties indicates which property has preferences in case the same resource is found by multiple labels. The selected resources can then be organized in a list or in groups of different lists. The grouping is performed on the values of the RDF properties provided for :group. The resources in the list can be ordered according to several criteria and are defined in a collection as a value of :sort. The built in constant, exact puts all resources with an exact matching label before resources with partial matching labels. Another built in constant is inlink that sorts the resources by the number of incoming links they have in the graph. Further sorting criteria are the display labels (explained in the next paragraph) or any rdf:Property. The number of results that are returned can be limited by defining :max. In a grouped organization the maximum applies to the number of items within a group. Finally, resources that are defined as equivalent (owl:sameAs or skos:exactMatch) are shown as a single suggestion when :smush is set to true.
The results are visualized in a primary and secondary display panel. The primary display contains all suggestions, while the secondary display is shown when the user hovers over one of these. The default display format of these panels, as shown in Fig. 4, is fixed. The primary display contains 3The properties and classes used in the interface models are contained in our own namespace http://e-culture. multimedian.nl/ns/interface/. In this paper we omit this namespace and simply write a colon. place markers for four labels besides the matching label itself. The developer defines which labels are shown by mapping domain specific properties to the properties of the interface model (e.g. mapping skos:broader to :subLabel). If the default display format is not sufficient a new formatting function can be created in the JavaScript widget, which might also require updates to the interface model.
Facet browser interfaces provide a convenient way to
navigate through a wide range of data collections. Originally
demonstrated in the Flamenco system [
Consider a faceted interface on a collection of documents. Each individual facet contains the values within one dimension. For example, one facet might display all the creators, whereas, another might display the subject categories. On an RDF data source this type of value selection corresponds to the values of a particular RDF property (e.g. dc:creator and dc:subject). Other selection criteria are also possible, such as all instances of a particular Class. In a similar fashion rdfs:Class
:target :target (rdfs:Class) :property rdf:Property :FacetNavigation :FacetView :facets :Facet :selection :organization
:visualization :sort (exact || rdf:Property) :group (rdf:Property) :smush true || false :max integer :hierarchy :relation rdf:Property :root (rdfs:Resource)
:FacetView :Facet
:Facet as the autocompletion suggestions, different types of facet values require different methods of organization. The creators might be best organized in an alphabetically ordered list, while the hierarchical structure is important for the subject categories. Also the visualization of facet values shows similarities with the autocompletion widget. Adding extra information in the display may help to disambiguate similar values. In addition, specific types of values (e.g. geographical locations and dates) are suited for alternative visualization (geographical map and timeline).
When the number of defined facets is too large to be shown in the interface, it has to be defined which facets are shown. In Longwell a facet view can be defined as a collection of facets for a particular target. The facets defined in this view are shown, while all other facets are collapsed and available on requested. An alternative method is to allow multiple views and allow the user to select the most appropriate view. For example, the creation view contains all facets that cover the creation of a document, whereas, the content view contains the facets about the topic. In either solution, a view defines which facets are selected for display.
As an example we describe a possible model for a faceted navigation widget. A screenshot of this widget, used for a collection of news items, is shown in Fig. 6. The widget displays multiple facets that are defined in a facet view and allows the selection of alternative views. The individual facets are built on top of the autocompletion widget, which allows re-use of its organization and visualization methods. In addition, it allows autocompletion within each facet. Again, we make the disclaimer that our purpose is not to provide a complete model for faceted navigation, but merely to illustrate that it is possible to define an interface model for a faceted navigation widget in RDF.
An interface model for a faceted navigation widget is shown in Fig. 5. The widget can contain multiple facet views, that each apply to the resources of a particular Class. Each facet view contains an RDF list of facets. A facet is configurable in the selection of facet values, the organization and visualization of these values. At the moment our widget only supports the selection of facet values from an rdf:Property. The configuration of the organization and visualization is similar to that of the autocompletion widget. In addition, the facet values can be organized hierarchically, meaning that initially only the root values of the hierarchy are shown and after selection of one of these its children become available.
Given an interface model the configuration of a Semantic Web application becomes a task of mapping the right properties and classes to this model. In practice, this often means first finding a suited intermediate model for the domain. For example, in terms of persons, locations and times. Second mapping this intermediate model to the widget’s interface model. We illustrate the mapping task with two use cases: configuring autocompletion components for a cultural heritage annotation application and configuring faceted navigation for a news application.
Within the MultimediaN E-Culture project [
The interface model for the autocompletion widget, as described in the previous section, is based on our findings at the Rijksmuseum. We acknowledge that a single study might not be sufficient to determine a complete interface model that applies to other domains. On the other hand, all three autocompletion fields required different features and configurations. Furthermore, the three fields cover generic types of resources (persons, thesaurus concepts and locations) that are very likely to be used in other domains as well. We first introduce the vocabularies used in the annotation interface, before describing the configuration of the person and concept autocompletion fields. We used three thesauri with persons: Getty’s United List of Artist Names4 (ULAN), DBPedia’s RDF version of person data5 from Wikipedia (WP) and the Rijkmuseum’s own people thesaurus. All three thesauri were mapped to the generic “Person” scheme of ULAN. For places we also used, Getty’s Thesaurus of Geographic Names6 (TGN) and aligned it with the Rijksmuseum’s place thesaurus. We used SKOS for the geographical containment relations in combination with location-specific properties from TGN. The concepts used in this domain were also modeled or mapped to SKOS. In addition to the Rijksmuseum’s events thesaurus we added the RKD IconClass7 thesaurus and, as a source for more general terms, W3C’s RDF version of Princeton’s WordNet8.
Listing 1 shows the configuration of the autocompletion widget in the Who field. The selection is restricted to resources of type ulan:Person. Note, the class of persons in the Rijkmuseum thesaurus and DBPedia people are subclasses of ulan:Person. We only consider literal values of skos:prefLabel and rdfs:label, where preference is given to the skos:prefLabel 4http://www.getty.edu/research/conducting research/thesauri/ulan/ 5http://dbpedia.org/ 6http://www.getty.edu/research/conducting research/thesauri/tgn/ 7http://www.iconclass.nl/ 8http://www.w3.org/2006/03/wn/wn20/ as this is first in the list. The results are organized alphabetically on the label and first showing all resources with an exactly matching label. The professionals at the Rijksmuseum explicitly indicated that they expect alphabetical ordering for a list of person names. As the autocompletion field gives access to the resources from different overlapping vocabularies it turned out essential to smush equivalent results to a single suggestion.
The primary display contains three labels in addition to the matching label. The :altLabel is only shown in case the match was not found an a skos:prefLabel. Thus, when a hit is found by a skos:altLabel it’s skos:prefLabel is also shown. The :endLabel contains the value of the skos:inScheme property. Thus indicating the thesaurus the term comes from. The professional annotators requested this information as terms are suggested from their own as well as other thesauri. The :subLabel shown beneath the main label is composed out of the values of four properties. Together these compose a short biography of the person. The annotators use this information to disambiguate similar persons from one another. The secondary display contains an image depicting the person and a longer biography. : P e r s o n A u t o c o m p l e t e a : A u t o c o m p l e t e ; : l a b e l ” s e a r c h p e r s o n ”@en ; : l a b e l ” zoek p e r s o o n ”@nl ; : s e l e c t i o n [ : t a r g e t u l a n : P e r s o n ; : match ( s k o s : p r e f L a b e l r d f s : l a b e l )
Listing 1. Person autocompletion allows autocompletion on instances of ulan:Person. The results are sorted first on exact matches and then alphabetically on the matching label. Results that are defined as equivalent (skos:exactMatch or owl:sameAs) are smushed. Each result is displayed with extra information. The primary display contains a short biography composed out of the values different properties and it contains the thesaurus source. The secondary display contains a full description and an artwork that depicts the person. : C o n c e p t A u t o c o m p l e t e a : A u t o c o m p l e t e ; : l a b e l ” s e a r c h c o n c e p t ”@en ; : l a b e l ” zoek c o n c e p t ”@nl ; : s e l e c t i o n [ : t a r g e t [ owl : u n i o n O f ( i c : C o n c e p t ; wn : S y n s e t ; rma : E v e n t ) ] ; : o r g a n i z a t i o n [ : s o r t ( ” e x a c t ” ” i n l i n k ” ) ; : g r o u p s k o s : inScheme ] ; : p r i m a r y D i s p l a y [
: s u b L a b e l s k o s : b r o a d e r ] ; : s e c o n d a r y D i s p l a y [ : d e s c r i p t i o n s k o s : n o t e ; : image v r a : s u b j e c t
] ; : m a t c h L a b e l ( s k o s : p r e f L a b e l r d f s : l a b e l ) ; Listing 2. Concept autocompletion allows autocompletion on instances of skos:Concept. The results are sorted first on exact matches and then on the number of inlinks. The suggestions from the same thesaurus are grouped together. In the secondary display a tree is shown with the all ancestors and direct children of the result.
Listing 2 shows the configuration of the autocompletion widget in the What field. We only describe the configurations that are different from the Who field. The target is defined as an owl:union of three classes, iconclass and wordnet terms and the events from the Rijksmuseum thesaurus. The resources from the three thesauri are each shown in a separate group. The Rijksmuseum wanted to give preference to terms from IconClass and only use WordNet as a backup. Organizing the results in different groups allowed the annotators to easily compare terms from the different thesauri to one and other. Within each group the results are ordered by the number of links that are pointing to the resource. Intuitively, this means that the popular resources are shown first.
ClioPatria is used to support search and browsing of news
items [
A screenshot of the faceted interface from ClioPatria is shown in Fig. 6. The top part contains four facets: document type, creation site, event and person. The result viewer, visible below the facets, contains news items related to the keyword “zidane”. The current query is shown in the header of the result viewer. The user can extend the query by selecting values from the facets. In this case the value “photo” is selected from the document type facet. The other facets only contain values that correspond with the current result set. Note, this prevents the user from constructing queries that lead to an empty result set. : C r e a t i o n S i t e a : F a c e t ; : l a b e l ” c r e a t i o n s i t e ”@en ; : t a r g e t ( newsml : newsItem ) ; : p r o p e r t y newsml : l o c C r e a t e d ; : h i e r a r c h y [ a : H i e r a r c h y ; : l a b e l ” Geonames l o c a t i o n h i e r a r c h y ”@en ; : r e l a t i o n geo : p a r e n t F e a t u r e ; : r o o t geo : World ] . : D e p i c t e d P e r s o n a : F a c e t ; . . . : Co nt e nt Vi ew a : F a c e t V i e w ; : l a b e l ” c o n t e n t ”@en ; : l a b e l ” c o n t e n t ”@nl ; : t a r g e t ( newsml : newsItem ; : f a c e t s ( : DocumentType : D e p i c t e d E v e n t : D e p i c t e d P e r s o n : C r e a t i o n S i t e
Listing 3. Excerpt of the facet and facet view configuration for a news demonstrator
web application generator
API RDF store
"static HTML"
JS widget 1 JS widget 2 JS widget n c o n t r o ll e r Listing 3 shows an excerpt of the facet and facet view configuration for a news demonstrator. The creationSite facet applies to instances of the class NewsItem, as indicated by the value of the :facetTarget property. This facet will display values from the property newsml property locCreated. As the values are part of a geographical containment hierarchy, this is used for the organization. In the screenshot of Fig. 6 the creationSite facet it is visible that initially only the children of the hierarchy root (e.g. World) are shown (e.g. Europe, Africa and Asia). When one of these values is selected, the children available through the hierarchyRelation, geo:parentFeature, become available. Four facets are grouped into a facet view that covers the content of news items. In a similar fashion other facets can be grouped into views on the production and document characteristics. The facet view menu shown in the screenshot on the top left allows the user to select one of these facet views.
The interface models have been implemented within the open
source semantic search and annotation ClioPatria framework 9.
The overall architecture of ClioPatria is described in [
We have shown how we can use RDF to model the interface widgets of a specific Web application, an abstract intermediate data model, and the mapping between these two models. We argue that this approach can provide developers with an interface early in the development cycle of a Semantic Web application. As long as the chosen widgets, associated interface model and intermediate model prove to be sufficiently rich, all the developer needs to do is to provide the mappings (in RDF) between his own data model and the intermediate model, using skills that Semantic Web developers can be safely assumed to possess. This approach also allows Semantic Web UIs to be built on top of existing Web tool kits, without sacrificing the heterogeneity and semantic richness of the underlying data.
A first drawback of our approach is that our interface models are typically specific for a given interface widget or toolkit. If the same RDF data needs to be displayed the same way in multiple interfaces, a vocabulary such as Fresnel, that abstracts from the interface technology used, might be a better alternative. In our applications, we have aimed to fully exploit the functionality of the interface widgets, and have traded the advantages of extra functionality against generality. Other developers might make a different trade off. A second drawback surfaces when a given set of widgets and the associated interface model provides insufficient functionality. Then, extensions will require traditional Web scripting skills to develop extensions to widget set, typically involving a mix of HTML, CSS and JavaScript. But it also requires skills to be able to model these extensions in RDF or OWL, and this combination of skills might be hard to find. For future work, we would improve upon our current interface model and its implementation. The current implementation is realized as an integral part of the ClioPatria server framework, and we are investing ways to be able to apply the same approach to create interfaces on top of arbitrary SPARQL endpoints.
The dataset used in the NewsML demonstrator has been kindly provided by AFP. We like to thank all members of the MultimediaN E-Culture Project for creating an environment that allows experimenting with Semantic Web technologies in a real life setting. In particular, we like to thank Jan Wielemaker for the cooperative development on ClioPatria and the inspiring feedback. We also like to thank our colleagues Raphae¨l Troncy and Michiel Kauw-A-Tjoe for the contributions to ClioPatria and setting up the news demonstrator. This research was supported by the MultimediaN project funded through the BSIK programme of the Dutch Government and by the European Commission under contract FP6027026, Knowledge Space of semantic inference for automatic annotation and retrieval of multimedia content — KSpace.