Web portal software is relatively easy to set up and populate from the perspective of the end-user, but it leaves the back-end database devoid of subject domain semantics due to the requirement for a generic implementation. This approach seriously hampers e ective search capabilities to retrieve relevant information. Ontology-based data access (OBDA) could, in theory, solve this problem through adding a semantic `layer' over such web portal implementations. To this end, we provide and demonstrate the proof-of-concept methodology by enhancing the operational National Accessibility Portal of South Africa. We developed the adolena ontology, which is based on both the semantics in the database and augmented with notions from foundational and related domain ontologies. adolena was then made compliant with the OWL2 pro le DL-LiteA and mapped to the relational database using the OBDA Plugin for Protege. Experimentation with OBDA queries unequivocally demonstrates its advantages compared to the portal's keyword-based search.
The vast majority of extant operational databases are not Semantic Web enabled databases, and fall into two major categories: the well-designed tailor-made databases with a rich database schema and the convenience databases that are generated with a default schema irrespective of the subject domain semantics, such as a database that runs at the back-end of a Joomla-powered website. The main advantage of the second type lies with the user-cum-content-creator, for s/he is not dependent on system administrators to keep the implementation upto-date. This was also a requirement deemed crucial by the stakeholders of the South African National Accessibility Portal (NAP) that provides information about disabilities, assistive devices, such as wheelchairs and talking thermometers, and so forth, which has been aligned with the goal of the African Decade of Persons with Disabilities (1999 to 2009) to empower persons with disabilities. While this freedom may be liberating for the content-creator, it seriously hampers e ective search and retrieval of the data, which for a small website might still be browseable but this does not work anymore for web portals. Hence, the need for enrichment of the implementation arises so as to enable advanced query capabilities (without disrupting the content additions by users), which, invariably, can only be done by adding subject domain information that then has to be connected to the database content.
Over recent years, theory of linking ontologies to data and an overall
framework of Ontology-Based Data Access (OBDA) has been maturing [
The remainder of the paper is structured as follows. We outline the materials and methods in section 2. The newly developed domain ontology, OBDA mappings, and experimental data with the test results of the OBDA-enhanced portal compared to the plain NAP is presented and discussed in section 3. We close with conclusions and current work in section 4. 2
To realise the proof-of-concept examination of semantically enriching an existing web portal with OBDA, we devised the following methodology: 1. Develop experimental domain ontology, which comprises: (a) consulting top-level categories from foundational ontologies as top-down development approach; (b) reverse engineering the contents of the `groups' and `subgroups' tables from the portal database (alternatively called, e.g., `Section' and `Category' in Joomla-like CMSs) as bottom-up approach; (c) sourcing related domain ontologies, taxonomies, and the like for potential of reusing them in whole or in part; and (d) verifying the resultant ontology with the domain experts; 2. Ensure that the ontology is `simple' enough to be expressible in DL-LiteA, including conversion or removing of violating axioms, if necessary, and verify that this new ontology still conforms to the understanding of the subject domain and represents reality faithfully; 3. Enrich the database with knowledge from the ontology by either adding tables or instances, if necessary; 4. De ne OBDA mappings between the ontology and SQL queries over the portal database through the Protege OBDA plugin; 5. Test SPARQL queries with the Protege OBDA plugin and compare the query answers with those of the near-analogue in the web portal; 6. Provide web interface to the OBDA Plugin to allow users to use the enhanced search capabilities.
The materials used for this procedure are as follows. The extant ontologies
consulted with the aim of potential reuse are: DOLCE [
In this section we report on the outcomes of ontology development, conversion from the comprehensive version to one that is better suited for use in OBDA, the ontology-to-database mappings, and the striking di erences in query answers be4 http://www.ifomis.org/bfo 5 WHO's disabilities classi cation: http://www.who.int/classi cations/icf/site/index.cfm 6 Downloadable from http://www.inf.unibz.it/ rodriguez/OBDA/ les/obdaplugin/current/. The stable release will be available on the TONES website. tween the standard web portal and OBDA-enhanced querying. All data les are available online at http://ksg.meraka.org.za/wiki/SNAP OBDA experiment. 3.1
The experimental domain ontology adolena|the Abilities and Disabilities OntoLogy for ENhancing Accessibility|was developed through a combination of top-down and bottom-up activities. The basic structuring principle in the current, openly available, experimental adolena|which contains 141 classes, 16 object properties, and has a DL expressivity SHIQ|deals with 4 principal concepts: Ability, Disability, Device, and Functionality. A device assistsWith some ability, ameliorates some disability, and hasFunction some functionality, a disability affects abilities (with inverse isAffectedBy). In addition, there is initial additional knowledge about ServiceProviders, such as a device Vendor, that certain devices requiresAbility an ability, and Person with BodyParts (e.g., to say that a prothese replaces some body part).
This ontology was build in Protege with the built-in FaCT++ reasoner by,
rst, creating a preliminary seed ontology based on the current structure of
NAP by manually examining the \services", \groups", and \topics" tables of
the database. Clearly, an automated extraction from table content to taxonomy
is preferable, which could be integrated with an overall approach of logic-based
reverse engineering (e.g., [
Transformation to DL-LiteA. As mentioned, the full adolena is
represented in a language with DL expressivity SHIQ. We could either make the
OBDA mappings with adolena, or simplify the ontology|be it manually or
automatically|to the OWL 2 pro le7 for DL-LiteA and make the OBDA
mappings with that one. For experimental purposes, we have carried out two manual
simpli cations from adolena.owl to the AdolenaSlim.owl and to
AdolenaSmall.owl8. The former was created by using a previous created comparison
between ontology languages [
The automated transformation includes also rewritings and approximations, e.g., it has rewritten several axioms by introducing new placeholder concepts and roles; hence, 4. the automated transformation into AdolenaDLLite is a closer approximation to adolena than either AdolenaSlim or AdolenaSmall is.
8 We have chosen not to make the mappings with adolena, because an OBDAmapping for a Protege object property in a non-DL-LiteA ontology might be lost in the automatic transformation to DL-LiteA-compliance by the DIG-QuOnto reasoner, be it that it was an unsupported axiom in the expressive ontology|hence, discarded|or an approximated one through newly introduced roles and concepts. In such an occasion, executing SPARQL query to retrieve data, which rst approximates the ontology on-the- y, would be empty.
Advanced transformations and remodelling as indicated in item 3v were not
done manually because it is non-trivial to do and demotivating whilst knowing
that there is a tool that can do it automatically (the DIG-QuOnto) whereas the
modeller would have to re-invent all the transformation and approximation
algorithms. Eventually, it was decided to use AdolenSlim and AdolenaSmall in this
experiment instead of AdolenaDLlite, because, rst, the automated rewritings
and approximations appeared to hamper domain expert understanding of the
represented knowledge because it was unclear how the rewriting and
approximations had happened to each concept, role, and axiom (e.g. to trace the function
of each new Aux Class1, N ewRole 1 and so forth and what it replaced).
Second, as a knock-on e ect, it was perceived to complicate declaring the OBDA
mappings. From an ontology developer perspective, it thus would be better if
the on-the- y approximation were a separate, explicit, OBDA development step.
A straight-forward nice GUI rendering hiding such transformation details could
solve it (the successful precedent has been set with the ICOM ontology editor
[
AdolenaSlim as well as AdolenaSmall were used for OBDA after observing that the ontology had to be saved in the RDF/XML format instead of the OWL/XML format so as to maintain backward compatibility between Protege alpha 4.0 and its earlier version 3.3.1 for which the OBDA Plugin has been developed (the OBDA plugin for Protege alpha 4.0 is currently under development). 3.2
Linking the ontology to the NAP database. Declaring OBDA mappings
in the light of a semantics-poor database requires considerable knowledge about
the database, SQL, and the theory behind the mappings. As with the previous
steps, the linking has been carried out manually, though noting that preliminary
results to automate this procedure [
description_contentelement.description_ce_id where HEAD has the class from the ontology and the combination of the name and description values in the database that will be turned into objects in the ontology, i.e., assuming that devices are identi ed by their name and description, and the BODY contains the actual SQL query to the database. While the above is a sensible query to retrieve human-readable information about motorised wheelchairs in a standard database environment, what we actually have in the database is that the devices, including motorised wheelchairs, are identied (in database terms, primary key) by their content id, hence, the following OBDA mapping is in this case the correct one.
HEAD: NAP:Motorised_Wheelchair(getObj($content_id)) BODY: select distinct content_id from content, i18ncontent, rainbowcontent where rainbowcontent.grouping_grouping_id = 9280 and rainbowcontent.rainbowcontent_id =
i18ncontent.rainbowcontent_rainbowcontent_id and i18ncontent.i18ncontent_id =
content.i18ncontent_i18ncontent_id and content.language = 0" The mapping queries for the other classes and properties in the ontology are similar; see Fig.1 for an example, among many, in the OBDA Plugin's interface. More mappings are available on the experiment's webpage.
Sophisticated queries. While obviously we can query for instances of concepts and roles just like in SQL, we shall focus on the more interesting queries that are di cult, or even impossible to do with standard database technology; put di erently, we focus on novel query features.
First, let us combine reasoning over the ontology with database queries. Given the OBDA mappings, we want to retrieve \all devices that assist with upper limb mobility ", where we have in the ontology the taxonomy of devices under Device, which is related to Ability through the assistsWith role, and UpperLimbMobility v Ability. The database itself does not contain any speci c data about relating devices to abilities and not even about abilities themselves. With OBDA, however, the query answer is not empty; in fact, it returns all motorised wheelchairs, as depicted in Fig. 2. This answer is returned thanks to OBDA's query evaluation: by availing of the knowledge represented in the ontology, it nds that it is MotorisedWheelchair (a type of Device) that has an assistsWith relation to UpperLimbMobility; hence, the nal query to the database is only the one to retrieve motorised wheelchairs.
A di erent type of query is one over the ontology itself with, e.g.,\show me all abilities that are a ected by quadriplegia", taking into account that we have, in addition to a taxonomy of types of Ability, the affectedBy/affects roles and Quadriplegia as a type of Disability. Given the current state of the ontology, it returns UpperLimbMobility and LowerLimbMobility.
The third example that illustrates a typical query pattern as identi ed by the domain experts is, e.g., \retrieve all devices for paraplegia", where in the ontology we have Paraplegia v Disability and, in the full adolena, at the top of the two sub-taxonomies the ameliorates role between Device and Disability. This is, in fact, analogous to devices that assist with an ability, and the appropriate query is, in Datalog syntax, q(x) :- Device(x), ameliorates(x,y), Paraplegia(y) If, on the other hand, we would not have this particular ameliorates in the ontology, then the query to circumvent this gap would have been q0(x) :- Device(x),assistsWith(x,y),Ability(y),affects(z,y),Paraplegia(z) which causes not only a considerably slower performance in query answering but also complicates the mappings because there as no instances of Ability and Disability in the database. How to identify the best strategy for successful and satisfactory completion of a query scenario|in this case solving it by having (or adding) a mere relation in the ontology versus changing the mappings and queries|is fertile ground to devise guidelines as to where to start looking for a solution and what to do in which occasion.
Comparison of OBDA versus keywords. Given the mappings, and the immediate user requirements, we now would like to retrieve data from the NAP database. To this end, we rst want to retrieve data about Wheelchairs. The SPARQL query that returns only and all wheelchairs is
SELECT ?x WHERE f?x rdf:type 'NAP:Wheelchair'g The keyword search in NAP can have two approximations: (i) simple keyword search and (ii) `advanced' keyword search. Obtaining information about wheelchairs, one retrieves well over 150 results ranging from wheelchair as assistive device, news about wheelchairs, recreation, and classi eds (see Fig.3). In the advanced search, \wheelchair" + Category returns 0 results, and \wheelchair" + Category + all checkboxes in Provinces, Interest Groups and all Disabilities returns 22 hits, all of them within the assistive devices. Clearly, with the OBDA enhancement we obtain immediately the targeted results speci cally about wheelchairs, neither being distracted by the many irrelevant hits nor having to do guesswork in the `advanced keyword' search. We obtain analogous results with similar queries, which are available on the webpage as well.
Let us have a look at the more sophisticated queries from the previous section. Take the phrase \devices that assist with upper limb mobility" in the simple search and in the advanced search where the following check boxes were checked: Category and Speci c Information, Physical (in Disabilities), all Provinces, and all Interest Groups. The portal's returned hits (screenshots available online) di er most likely due to the combination of categorisation of the content items by the content providers, the limited set of check boxes one can select, and that only system administrators can change it. Compare this with OBDA and the query answer in Fig. 2. Here we have obtained all MotorisedWheelchairs, but not the Protheses that the NAP answer contains as rst query answers in addition to the wheelchairs later on in the keyword search result. The reason for the di erence in query answers is that adolena and its slimmed versions do have an assistsWith relation between MotorisedWheelchair and UpperLimbMobility, but not yet between Prothese and UpperLimbMobility. There is no technical limitation for not having this relation in the ontology. It simply had not been added because the ontology is still under development and the focus was to test the proof-ofconcept of linking an ontology to an operational database and combine reasoning over the ontology itself with querying the database that does not have any table with instance data about abilities. This has been demonstrated successfully; thus, simply adding \Prothese v 9assistsWith.UpperLimbMobility" to adolena and the corresponding mappings in the OBDA plugin fully solves the observed di erence.
The last example of the comparison is a very nice illustration between suboptimal meaning-unaware string-based searches and semantics-rich querying. Take, for instance, \devices for the blind" (q(x):-Device(x), ameliorates(x,y), Blind(y) or analogous to q0 in the the previous paragraph). The NAP's results (screenshots available online) has the rst device on page 2: a video magni er, which is, however, not relevant to blindness but rather to low-vision. The rst relevant device is a talking alarm clock, on page 3 (i.e., in the range of hit numbers 10-15). On the other hand, when we examine the OBDA results depicted in Figure 4, 7 devices|both Braille and talking devices|were returned. As before, this query answer is more appropriate to the original query than the NAP keyword search results.
The last step in the methodology|providing web interface to the OBDA
Plugin to allow users to use the enhanced search capabilities|is currently under
investigation with respect to the user requirements and tool availability. The
two main paradigms to let end users formulate queries without resorting to a
standard query language such SPARQL, are through a version of Query By
Diagram or a near-natural language interface. Such tools for OWL do exist, e.g.
[
In addition to showing the realistic option to semantically enhance web
portals, the demonstration of OBDA-enhancements in a HealthCare & Life Sciences
setting may help to scope the planning of activities on KnowledgeBase
improvements during the new lease of the W3C HCLS IG9, noting that the same
technology can be used also for ontology-based database integration [
We have successfully demonstrated enhancing an existing web portal, the NAP, with OBDA by developing an experimental domain ontology, adolena, converting it to an OBDA-compliant one, declaring ontology-to-database SQL query mappings, and performing SPARQL queries to retrieve answers that were signi cantly better than the standard keyword-based searches. In addition, the methodology proposed is generalisable to other web portals that are based on generic software. The procedure both to conduct the steps as well as to link the outputs of each step to the input of the next one, however, has been carried out manually, which will bene t from more automation. Indeed, ongoing research and tool development are moving in the direction of automation of these steps.
Current and future work includes adding more knowledge to the ontology, nalising the last step of web-based OBDA querying, and providing a more detailed methodology and automated work ow environment for OBDA-focussed systems development.
Acknowledgements. We would like to thank Diego Calvanese, Giuseppe De Giacomo, Mariano Rodr guez, and Fabio Savo for their feedback and suggestions on the manual and automated transformations to DL-LiteA-compliant ontologies and OBDA mappings and software usage support.