DIG 2.0 Extension for handling bulk data (Outdated)

Together with the definition of these classes, the new implementation of the framework must provide the documentation necessary to clearly define the semantics of all the newly defined classes.

Extensions to the Tell and Retrieve and management elements

To allow for the management of ontologies with linking axioms we extend the Request and Response classes.

Concerning data sources management:

CreateDataSourceAllocateURI.- Tells the server that it should create a new data source and allocate an unique URI for it. Useful for creating anonymous or one time use data sources. The user can then use the given URI to add access parameters or relate linking axioms to it. The server should respond with a confirmation containing the URI of the data source on a successful execution.

CreateDataSource.- Tells the server to create a new data source identified by the given URI.  The server should answer with an error if there exists another data source with the same URI.

ReleaseDataSource.- Tells the reasoner to delete the data source identified by the given URI. All linking axioms related to the data source must be removed by the user first. If there are still linking axioms related to this data source before issuing a release command, the reasoner shouldn't remove the data source and should reply with an Error explaining the situation. On successful execution of the command the server should delete any reference to data source parameters or annotations related to the given data source.

SetDataSourceParameters.- Tells the reasoner to assign a list of parameters to the given data source. If an URI of one of the given parameters is the same as one of the data source's already associated parameters, the old value of the parameter should be replaced with the new value and a warning should be issued.

GetDataSourceAnnotations.- Tells the reasoner to retrieve all the annotations associated to the given data source. The server should return a a (possibly empty) SetOfAnnotations containing all the annotations related to the data source.

GetDataSourceParameters- Tells the reasoner to retrieve all the parameters associated to the given data source. The server should return a (possibly empty) SetOfParameters containing all the parameters related to the data source.

Concerning linking axiom management:

TellLinkingAxioms.- Tells the reasoner to associate a set of linking axioms to the given ontology.

GetAllLinkingAxiom.- Tells the reasoner to return a (possibly empty) SetofLinkingAxioms containing all the linking axioms associated to the given ontology.

RetractAllLinkingAxioms.-  Tells the reasoner to remove all the linking axioms associated to the given ontology. A warning should be issued if there are no associated axioms.

Considerations:

Confirmations: If a command has been executed successfully, a confirmation should be issued.

Undefined URIs: If a command defining/retreiving a DataSource/LinkingAxiom/Ontology identified by an unknown URI, an error should be thrown indicating the issue.

Typing of Sources, Parameters and Axioms: The user needs to pass parameters which are properly typed. That is, if the user is defining parameters for a DataSource of type X which accepts parameters of type paramX, the parameters given must be of type paramX. An error should be returned as a result of any command with badly typed parameters. The same situation is for Linking Axioms and Data Sources.

4.1 Implementation of the framework for RDBMS Data Sources

A TypingAxiom is a statement of relationship between an attribute of a relation and an OWL data type. In a typing axiom, the source query is an instance of the SQLProjection class, which stands for the projection of the attribute attributeName over the relation relationName (see figure 3). The target query is represented by an OWL 1.1 data type. Typing axioms allow the user to validate the data in the data source against the ontology's data types.

The next is an example of a typing axiom indicating that the data of the attribute name  in the relation P of the data source identified by the URI rdbms://dbms.unibz.it belongs to the xsd:String data type. Datatypes allowed are those defined in the OWL 1.1 definition.

4.1.1 Semantics for the RDBMS implementation

In this section we recall the work presented in [DL-LiteA], [Poggi et al. 07], which defines the semantics for the linking axioms presented in section 4.1. This work is focused on the problem of linking data stored in a relational database to the instances of the concepts and roles in an ontology with the objective of effectively manage an ABox via a Relational Database Management System (RDBMS).

 

An important issue to be taken into account in this context is the notorious problem of impedance mismatch between values (data) and objects, which is due to the fact that relational sources store values, whereas instances of concepts are objects denoted by ad hoc identifiers, which are different from data items.  To address this problem, [Poggi et al. 07] proposes to keep data value constants separate from object identifiers, and to consider a domain of object identifiers that are built from data values by applying function symbols. More formally, the alphabet Γ_O of object identifiers is constituted by value constants from a set Γ_v, and by object terms, i.e., expressions of the form f(d_1,...,d_n), where f is a function symbol of arity n, and d_1,...,d_n are again value constants.

Given Γ_O, we can define an ABox in the standard way as a finite set of membership assertions, in which we may use not only value constants but object terms.

To define the semantics of such an ABox, we simply define an interpretation I in the standard way, and just note that the interpretation function  ^I assigns a different element of the interpretation domain to every object identifier in Γ_O (i.e., we enforce the unique name assumption on object identifiers).

We consider now the problem of linking objects in the ontology to the data in a relational database DB.  We do so by relying on mapping techniques studied extensively in data integration [Lenzerini et al. 02].  Specifically, we consider a set M of linking axioms, partitioned into two sets, M_t and M_a, where:

•  M_a is a set of assertions, called mapping axioms, each one of the form

  Φ Ψ

    where Φ is a first-order logic query of arity n over DB, and Ψ is a conjunctive query of arity n over the elements of the TBox T, without non-distinguished variables, that possibly includes terms in Γ_O.
• M_t is a set of assertions, called typing axioms, each one of the form

  Φ T_i

    where Φ is a query over DB denoting the projection of one relation over one of its attributes, and T_i is one of the data types provided by the DL;

We recall from [Poggi et al. 07] that typing axioms are used to assign appropriate types to constant values appearing in the relations of DB. Basically, these assertions are used for interpreting the values stored in the database in terms of the types used in the ontology. Mapping axioms, on the other hand, are used to map data in the database to concepts, roles, and attributes in the ontology.

It is worth noting that now that we have object terms, the data layer underlying an ontology contains only data, whereas object identifiers are virtually built on top of this data.  Thus, autonomous data sources can effectively provide their portion of data and contribute to the ontology instance-level, without being required to agree on any particular object identification scheme.

 

An ontology with linking axioms in a Description Logic DL is then constituted by a triple O_m = <T, M, DB>, where:

• T is a TBox expressed in DL,
• M is a set of linking axioms, and
• DB is a relational database.

In order to define the semantics of an ontology with linking axioms, we define when an interpretation I satisfies a set of linking axioms M w.r.t. a  database DB.  Specifically, we say that I satisfies M: Φ Ψ w.r.t. DB if for each tuple t of value constants in Γ_v, if t ϵ ans(Φ, DB)^*, then we have that t^I ϵ Ψ^I. An interpretation I = (Δ^I, ^I) is a model of O_m = <T, M, DB> if and only if I is a model of T and satisfies M w.r.t. DB.

With the notion of model in place, we can define all reasoning services over ontologies with linking axioms in the usual way.

* We use ans(φ, DB) to  denote the set of tuples (of the arity of φ) of value constants returned  as the result of the evaluation of the query φ over the database DB.

Example:

Consider the following:

a) an ontology O consisting of  the axioms:  Student ISA ƎName ,  Student ISA ƎLastname , CumLaudeStudent ISA Student, where Name and Lastname are concrete domain roles (i.e., attributes);   b) database DB and a relation R ϵ DB that stores   information about students; c) attributes n, l, gpa$  of R, which store the name, lastname, and gpa of students respectively;  d) n, l is a binary key for R; e) n, l are  strings. Now we present mapping m₁, which is a mapping axiom, stating how  tuples in R are related to CumLaudeStudent individuals, and typing axioms m₂ m₃ which type the attributes n and l of  R w.r.t. the value domains of O:

 

m1:	qdb(n, l) R(n, l, gpa), gpa > 7.5		qO(n, l ) CumLaudeStudent( stud(n, l )), Name( stud(n, l ), n ), Lastname( stud( n, l ), l )
m2:	qdb(n) R(n, l, gpa)		name
m3:	qdb(l) R(n, l, gpa)		lastname

where each q_db is a First-Order (i.e., SQL) query expressed over R,  q_O is a conjunctive query over O, stud( n, l ) is a function from name-lastname pairs to Γ_O, and name and lastname are concrete value domains for strings representing names and lastnames,  respectively.

The following is the instantiation of the MappingAxiom class for mapping axiom m₁. The axiom is presented in the XML based representation of MappingAxiom. Notice the use of a the <QueryFunction .. /></QueryFunction> element in query atoms within the ABox Query.

<MappingAxiom dataSource="rdbms://dbms.unibz.it">   <SQLQuery query="SELECT name, lastname FROM R WHERE gpa >= 7.5" arity="2" />   <Retrieve>    <QueryHead>       <ConcreteDomainQueryVariable URI="#name"/>             <ConcreteDomainQueryVariable URI="#lastname"/>     </QueryHead>     <QueryBody>       <QueryObjectIntersectionOf>         <ConceptQueryAtom>           <QueryFunction URI="#stud">             <QueryVariable URI="#name"/>             <QueryVariable URI="#lastname"/>           </QueryFunction>           <owl:OWLClass owl:URI="#CumLaudeStudent"/>         </ConceptQueryAtom>             <ConcreteDomainQueryAtom>           <QueryFunction URI="#stud">             <QueryVariable URI="#name"/>             <QueryVariable URI="#lastname"/>           </QueryFunction>           <ConcreteDomainQueryVariable URI="#name"/>           <owl:DataProperty owl:URI="#Name"/>         </ConcreteDomainQueryAtom>         <ConcreteDomainQueryAtom>           <QueryFunction URI="#stud">             <QueryVariable URI="#name"/>             <QueryVariable URI="#lastname"/>           </QueryFunction>           <ConcreteDomainQueryVariable URI="#lastname"/>           <owl:DataProperty owl:URI="#Lastname"/>         </ConcreteDomainQueryAtom>       </QueryObjectIntersectionOf>     </QueryBody>   </Retrieve> </MappingAxiom>

5 Examples

This section provides 2 examples to illustrate a possible use of the framework. The examples are given in terms of the implementation for RDBMS data sources instantiated in the XML form of the protocol.

5.1 A case in which the user wants to populate several atomic concepts in the ontology with instances build from values retrieved from a single relation in a database.

1. a RDBMDataSource DB identified with the URI = "rdbms://movies.org" with a relation movie which stores information about movies.
2. attributes name, director, year and country of movie,  where the first three form a primary key for movie.
3. an ontology with atomic concepts Movie, Country and atomic role ProducedIn and the following axioms:

Denoting that a every Movie has attributes Name, Director and Year, that every Movie participates in a relation ProducedIn whose range is a Country, and last, that a Country has an attribute Name.

Where countryObj and movieObj are the functions that create the object identifiers from the values given to them.

The designer could use the following linking axiom, in addition to the previous one, to populate this concept with the appropriate objects:

References

[Lenzerini et al. 02]

Lenzerini, M.: Data integration: A theoretical perspective. In: Proc. of the 21st ACM SIGACT SIGMOD SIGART Symp. on Principles of Database Systems (PODS 2002). (2002) 233 246
 

[Heflin and Hendler, 01]

Heflin, J., Hendler, J.: A portrait of the Semantic Web in action. IEEE Intelligent Systems 16(2) (2001) 54 59
 

[DL-LiteA]

Calvanese, D., De Giacomo, G., Lembo, D., Lenzerini, M., Poggi, A., Rosati, R.: Linking data to ontologies: The description logic dl-litea. In: Proc. of the 2nd Workshop on OWL: Experiences and Directions (OWLED 2006). (2006)
 

[Poggi et al. 07]

Poggi, A., Lembo, D., Calvanese, D., De Giacomo, G., Lenzerini, M., Rosati, R.: Linking data to ontologies. J. on Data Semantics (2007) To appear.
 

[Calvanese et al. 06]

Calvanese, D., De Giacomo, G., Lembo, D., Lenzerini, M., Rosati, R.: Data complexity of query answering in description logics. In: Proc. of the 10th Int. Conf. on the Principles of Knowledge Representation and Reasoning (KR 2006). (2006) 260 270.
 

[DIG1.0]

Bechhofer, S.: The DIG Description Logic interface: DIG/1.0. Technical report, University of Manchester (2002)
 

[DIG2.0]

Bechhofer, S., Motik, B.: DIG 2.0 Specification. Editor s Draft of 02 January 2007. Available at: http://www.cs.man.ac.uk/ bmotik/dig/dig specification.html
 

[DIG ABox Query]

Kaplunova, A., Moller, R.: ABox Query Interface proposal. Editor s Draft of 18 January 2007. Available at: http://www.sts.tu-harburg.de/ al.kaplunova/dig-query-interface.html
 

[QuOnto]

Acciarri, A., Calvanese, D., De Giacomo, G., Lembo, D., Lenzerini, M., Palmieri, M., Rosati, R.: QUONTO: QUerying ONTOlogies. In: Proc. of the 20th Nat. Conf. on Artificial Intelligence (AAAI 2005). (2005) 1670 1671