Fig 1. Prototypical OBDA-Enabled System architecture.
Authors:
Ontology Based Data Access (OBDA) is a novel field of research in which the objective is to provide access to data stored in heterogeneous data sources trough a semantic layer in the form of an ontology. The relationship between the data in the sources and the entities (concepts/roles) of the ontology is then stated through a set of semantic mappings. We refer to reasoners that support this kind of scenario as OBDA-Enabled reasoners.
The OBDA extension to the OWLLink Interface presented here allows OBDA-Enabled Systems to expose their functionality through the OWLLink Interface. This enables the reuse of currently available OWLLink infrastructure to facilitate interoperability between systems offering OBDA related functionality.
The current proposal is based on the experiences obtained from the OBDA extensions to OWLLink. It is aligned with the new OWLLink proposal and therefore with OWL 2.0.
This document is being published as one of a set of 2 documents:
The DIG 2 Working Group seeks public feedback on these Working Drafts. Please send your comments to public-dig2-comments@uni-ulm.de. If possible, please offer specific changes to the text that would address your concern.
This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
Contents |
With a quick review of publication in Data Integration, Sematic-Web or E-Science journals/conferences/workshops it is easy to see that the community whishes to be able to link their existing data repositories to semantic layers which allow them to extend the potenial of the stored information.
Many approaches have been explored, from adhoc software infrastructures to complex frameworks based on wrappers and semantic mappings. Recently, one of such approaches is gaining strength as it can realize a very flexible yet sound scenarios, Ontology Based Data Access or simply, OBDA.
OBDA is a novel field of research in which the objective is to provide access to data stored in heterogeneous data sources trough a semantic layer in the form of an ontology. The relationship between the data in the sources and the entities (concepts/roles) of the ontology is then stated trough a set of semantic mappings. We refer to reasoners that support this kind of scenario as a OBDA-Enabled reasoners. The general structure of a OBDA system is presented in the following figure.
Fig 1. Prototypical OBDA-Enabled System architecture.
Motivations for this kind of architecture are many, among them we have:
Even though the OBDA setting is being extensively studied and implemenations of OBDA-Enabled reasoners (i.e., QuOnto) or reasoners which provide OBDA-like functionality (i.e., KAON2, owl-gres) have already appeared, there are key components of the OBDA setting which have not been addressed and are required for taking OBDA technology closer to practical applications. One of these issues, the one that we address with this document, is OBDA-Reasoner-to-System interaction.
If OBDA technology is going to reach user applications, there is a need for a standard framework which i) OBDA-Enabled reasoners can use to offer their functionality ii) users can rely on to be able to develop modular applications which can interface which any OBDA-enabled reasoner, iii) developers can rely on to develop OBDA tools which can be used with any OBDA-Enabled reasoner.
The first key point to observe is, there are several key aspects of OBDA which characterize different instances of the OBDA setting. The key ones are the language in which ontology is described, the type and number of the data sources, the type of mappings connecting the sources and the ontology and the services which are made available to the user (e.g., subsumption checking, query answering, etc.).
As it can be seen with the previous developments in DL reasoner history, providing standard and open means of interaction with reasoners is necesary to take advantage of the functionality with in them. Additionally, open standards allow users/developers to create tools to maximize the potential of the original systems. The same is true in the context of OBDA technology.
More over, there is currently a lot of work and efford already devoted to Ontology related technology. Whatever mean of interaction for OBDA technology should be made in such a way that it would allow for the reuse of the technology already developed for traditional DL reasoners.
Motivated by the previous observations and with flexibility in mind, we formulated the following requirements for a OBDA interaction layer:
Data sources represent an external entity which stores data which is relevant to the domain of the ontology. They are identified uniquely by an URI. An OBDA enabled reasoner will access these sources to retrieve data that will populate the ontology. Associated to each data source there are a set of connection parameters which provide the reasoner with the required information to access the data source. Each parameter is identified by an URI and has a value.
Different types of data sources have different access methods, therefore require different access parameters. To cope with this situation and at the same time provide a structure that guarantees reusability, the OBDA extension provides a mechanism based on URIs’ to define which parameters are associated to which data sources
Associated to each data source there is a datasource-type-URI. Associated to the type URI there is a set of parameter-URI which are relevant to access the sources that type. Implementors of OBDA enabled reasoners which support a specific a datasource-type uri can assume that clients will define all the values for each of the parameter-uri. For details on how these URI’s are defined see the following section, modules.
A mapping specifies the relationship between the entities of the ontology and the data in a source. Based on [3], the OBDA extension for OWLLink defines a mapping as statement of relationship between a query over the source and a query over the ontology. We note that here query is used in the most general sense of the word, as it stands for any kind of computation. This modeling for the mappings can account for any type of mapping that has been used in previous approaches to map schemas in the related literature, therefor we believe that its well suited for OBDA purposes.
On the other hand, this modeling of mappings carries a considerable amount of variability that comes in the form of a) different semantics for the mappings b) and different languages (syntax and semantics) for the source/ontology queries.
To cope with this variance, the OBDA extension to OWLLink doesn’t fix any of these parameters. Instead, we fix a) the general structure that mappings will have, b) the operations that will be available over these mappings and c) we define a mechanism for implementors to fix the specific semantics and languages that they will use for the mappings they support. Reusability is guaranteed by the fact that once a mapping type, or query language is defined by an implementor other implementors can choose to use the components that he has defined.
For more details how to define specific types of mappings, see the following section, modules,
The OBDA extension also defines a set of API calls that OBDA-Enabled reasoners must implement to comply with the extension. The list and description of these calls is as follows:
Defines the set (0 or more) of data sources that will be used in mappings for a given ontology.
The data sources defined with this command are identified by unique URI’s specified by the client. Client’s are responsible for guaranteeing the uniqueness of such URI’s. Failure to do that can lead to inconsistent source parameters when two clients define two sources with the same URI but different parameters. The reasoner should response with an ok message after a successful execute or with and error otherwise, i.e., when the reasoner doesnt support the typeURI of one of the specified sources.
When a new data source is given, the reasoner should store the information about the source and its’ parameters. If one of the parameters defined by the source’s typeURI is not specified, the reasoner should set the parameters value to the empty string. If the data source already existed, all the value of the source’s parameters should be updated as if given for the first time.
Structure
The setDataSources command is composed by 0 or more DataSource elements. Note, the optional attribute typeURI becomes mandatory when using the setDataSources command. Each source will have 0 or more DataSourceParameter children.
Removes all information about the specified data sources together with all the mappings related to those sources.
Mappings are specified with the MappingAxiom element within a tells block. A mapping axiom’s dataSourceURI attribute, specifies the data source to which this mapping’s source query refers. It has exactly two children elements, the first is a query over the ontology, the second a query over the data source. The specific type of the elements which will be used for those children is defined by the type of data source associated with the mapping. This specification is provided by implementors at the time of declaring new datasource-typeURI (see section modules).
The OBDA-Enabled reasoner should ignore the mapping and response with a warning if a type of source/ontology query used in the mapping is not supported by the reasoner or is mistaken, e.g., type of the data source and the type of the queries in the mappings do not correspond to the specification of the data source.
Figure 1. Protocol Objects
The mechanism that allows implementors to define specific types of sources and mappings is the definition of modules based on the core OBDA extension to OWLLink. In the following we describe the procedure to define these modules.
OBDA-Enabled reasoner implementors can define new data source types following the next steps:
Defining query types
As said previously, the OBDA extension to DIG doesnt commit to a specific type of queries for the sources/ontology. In the general case, a query can be an arbitrary computation.
Instead, it provide a mechanism for the definition of specific types of queries.
When defining a new type of query implementors must: