Functional Dependencies in OWL ABoxes Jean-Paul Calbimonte, Fabio Poto, C. Maia Keet 3 École Polytechnique Fédéale de Lausanne (EPFL) Database Laboatoy - Switzeland jean-paul.calbimonte@epfl.ch National Laboatoy of Scientific Computation (LNCC) Compute Science Coodination Petopolis, Bazil fpoto@lncc.b 3 Faculty of Compute Science, Fee Univesity of Bozen-Bolzano, Italy keet@inf.unibz.it Abstact. Functional Dependency has been extensively studied in database theoy. Most ecently, thee have been some woks investigating the implications of extending Desciption Logics with functional dependencies. As it tuns out, moe complex functional dependencies at the type-level can lead to undecidability, which thus esticts its usage in the TBox. This pape theefoe focuses on enhancing its applicability to instances in the ABox. We specify FD as a new constucto, ealized as an OWL concept. FD instances ae mapped to Hon clauses and evaluated against the ABox accoding to use s desied behavio. The latte allows uses to detemine whethe FDs should be intepeted as constaints, assetions o views in the knowledge base. Ou appoach theeby gives ontology uses data guaantees and featues usually found only in databases.. Intoduction Data dependencies have been intoduced as a geneal fomalism fo a lage class of database constaints that augments the expessivity of database schemas []. Functional dependencies (FD) ae a paticulaly inteesting type of data dependency [] that elegantly captue elationships between attibutes of a elation leading to the identification of pimay keys and is used fo the nomalization pocedue of a conceptual o logical data model in ode to avoid edundancy in epesentation of the data. Othe impotant applications of FD in database include quey ewiting [3] and quey evaluation [4]. The semantics expessed though functional dependencies ae equally elevant when specifying a conceptual model by means of an application ontology fo ontology-diven infomation systems. It has been obseved [5] that in data-centic applications, uses expect ontologies to offe mechanisms simila to those found in the database aea that guaantee the coectness of enteed data. In paticula, FDs allow uses to explicitly state high-level constaints that, once enfoced, can validate the cuent state of a Desciption Logics ABox that contains assetions about individuals of the vocabulay in the TBox.
Indeed, in ecent yeas, a bulk of pio eseach has investigated the implications of adding functional dependencies to ontology languages (e.g. [6,9,,,9,0]). These initiatives took one of two paths: extending a DL language with a new FD concept constucto o adding FD (and key) as numbe estictions ove concepts and elationships. It tuns out that extending DL with a new FD concept constuct equies e-evaluating the logical implication algoithms, which in the geneal case has been shown to lead to undecidability [6]. Thus, in this scenaio, adding database-like constaints to ontologies (TBox) and emaining in the decidable fagment of fist ode logic equies limiting the expessiveness of a DL language in vaious ways. Fo many data-centic ontology-diven applications, howeve, coectness of enteed data in the ABox may be moe elevant than the expessiveness at the type-level. This wok takes the latte assumption and poposes an extension of DL ontologies with database-like expessive FD assetions. Indeed, FDs ae specified as instances of a newly defined TBox concept named FD. The hee poposed solution fo FD assetions in an OWLontology setting to meet use equiements, adhee to W3C standads, and cicumvent cetain theoetical limitations allows fomulating complex FD ules, including multiple paths in both the antecedent and consequent of the ule. Thee types of FDs will be consideed: classical, keys, and explicit dependencies. The fist two coespond to typical database functional dependency wheeas the last one is a paticula case of tuple geneating dependency [7]. We ealize ABox FDs by mapping FD instances to Hon clauses [7,8] using the SWRL ule language [8]. The effect of unning the FD ules ove the ABox may achieve diffeent esults depending on the desied behavio. Thee of such behavios have been identified leading to the extension of taditional DL knowledge base: FDs intepeted as constains, as assetions and as views. Fistly, the constaint behavio indicates instances that do not comply with the FD ules. The second appoach efines the unique name assumption in DL by identifying sameas instances epesented by diffeent nominals and adding the coesponding axioms to the ABox. Finally, a view behavio etuns quey esults matching the FD specification. The emainde of this pape is stuctued as follows. Section contains the peliminaies with elated woks and poblem motivation using examples. Section 3 pesents a fomal famewok fo the FD constuct and discusses enfocement intepetation. Section 4 intoduces the FD constuct in OWL and section 5 pesents a fist pototype implementation. Finally, we conclude in section 6.. Motivating examples and elated wok We fist sketch FD functionality desied by modeles and discuss elevant theoetical contibutions and limitations aftewads.. Motivating examples In database theoy, FDs have been seen as one of the most impotant concepts of elational modeling. It allows specifying dependencies between attibutes of elations and povides the basis fo nomalization theoy and elational keys. A FD is denoted as X Y, with X and Y being sets of attibutes of a elation R. Such FD states that the values of the attibutes in Y ae uniquely defined by the (values of the) attibutes in X. When tansposing simila ules to the ontology wold we discove that FDs could indeed be vey useful to enich the epesentation of subject domain infomation. Take,
fo instance, an ontology about flights. We can patially model the Flight, Aipot and Gate concepts and thei linking oles, as shown in Figue. Fig.. The FD depatsthough fo Flight and Gate, indicated with a thick aow. In this epesentation, the depatsfom and aivesat oles functionally detemine the depatsthough ole, which leads to the gate. In this example, two flights having the same aival and depatue aipots should also agee on the depatue gate. Anothe inteesting use of functional dependencies is elated to the notion of keys. Conside as an example a Passpot concept in the Flight ontology. Let us assume that an expet in the domain states that the County and PassNumbe compose the keys of the Passpot concept, i.e., Passpot is a weak entity type. Similaly to what one would expess in a database schema we could specify that the oles issuedincounty and PassNumbe compose the key fo a Passpot. In an ontology, we can think of County, Passpot and Peson as concepts with the oles displayed in Figue establishing a elationship between them. The oles epesented by dotted lines ae the ones maked as pat of the key. In this case the key would ensue that two passpots issued fo the same county and having the same pass numbe ae the same. If they ae the same, it is obvious that all the othe oles must also agee on thei values. Fig.. The key fo the weak entity type Passpot in an ontology; paticipating oles ae dawn with dashed lines. Moe complex and inteesting FDs can be defined ove paths of oles. Conside the example of flight tickets whee the pice of the flight ticket depends on the aival and depatue aipots, depicted in Figue 3. Fig. 3. FD with paths fo a flight ticket. In Figue 3, the FD is defined not only based on the oles having Ticket as domain, but also on paths of oles stating fom Ticket. Moeove, we can be inteested in explicitly stating how exactly the pice is detemined based on the aipots. Fo instance, we could
define a function that calculates the pice based on the distance between the two aipots: fpice(depatueaipot,aivalaipot) = distance(depatueaipot,aivalaipot) In that case we explicitly specify the function and that is why we will efe to this case as Explicit Dependency thoughout this pape (Figue 4). Fig. 4. FD fo the flight ticket with explicit function Up to now we have seen seveal examples of FD enfocement ules that would add expessivity to ontologies. We can classify them as classical FDs like in the ticket pice example in Figue 3; key FDs like in the passpot example in Figue ; and FDs with explicit function like in Figue 4. Theefoe, we see the need of defining all these flavous of FDs in DL. In the Web Ontology Language OWL-DL [4], as well as its poposed successo OWL DL (based on SROIQ [4]), only basic FDs ove a binay elationship ae expessible using FunctionalPopety and InveseFunctionalPopety.. Related woks Functional dependencies have been extensively studied in databases as a fomalism to extend database schema semantics [,7]. In the field of Desciption Logics (DL), FDs have also been the subject of ecent investigations. In [9], Bogida and Weddell expessed the necessity of adding uniqueness constaints to semantic data models, specifically DL. They used CLASSIC [0] as taget knowledge epesentation system fo intoducing a new FD constucto, simila in syntax to object-oiented database keys and slightly modified to epesent classic FDs. As expected, this simple FD declaation does not affect the tactability of the sub-sumption algoithm. A moe geneal FD concept constucto fo DL was late intoduced by Khizde, Toman and Weddell []. Thei appoach mainly focused on uniqueness constaints with the extension of paths to expess ole composition in FD declaation elements. The esulting DL is named DLFD and a tanslation fom DL-Class to DLFD is poposed. The authos exploed the complexity of logical implication poblems in DLFD, by poving equivalence with quey answeing in Datalog ns with some estictions, leading to a polynomial time quey evaluation. Calvanese, De Giacomo and Lenzeini, inteested in modeling conceptual data models such as ER and UML, as DL knowledge basesoposed identification and FD assetions fo the DLRifd language [] in addition to othe common modeling chaacteistics of conceptual data models, such as n-ay elationships. FDs and uniqueness constaints ae mapped to DLRifd numbe estictions and showed that easoning with these (non-unay) fd assetions is EXPTIME complete. Anothe inteesting featue of DLRifd is its ability fo epesenting Object-Oiented class opeations (methods) using the fd constuct [5]. An opeation has the fom f(p,,ph):r, whee f is the name of the opeation, h paametes, each one belonging to classes P,, Ph, and the
esult of f belongs to class R. Fomally, such an opeation coesponds to a (h+)-ay pedicate; let R be an (h+)-ay pedicate, and i,, h, j denote components of R, then an intepetation I satisfies the assetion (fd R i, i h j) if fo all t, s R I, we have that t[i ] = s[i ],, t[i h ] = s[i h ] implies t[j] = s[j]. Howeve, DLRifd with such FDs has not been implemented in any modeling tool o easone. Lutz et al. [9] fist consideed the case of adding keys to moe expessive DLs. The esult is the addition of a set of key definition statements in a so-called key box. Lutz et al. poved that these key constaints have an impotant impact on decidability. Fo instance, satisfiability of concepts becomes undecidable in the geneal case. Decidability is NEXPTIME-complete if key boxes ae esticted to a paticula kind called Boolean key boxes. Lutz and Milicic also exploed the possibility of adding not only keys but also FDs to DLs with concete domains [0]. Although it would initially seem that FDs ae weake than uniqueness keys, thei wok showed that the impact on decidability and complexity of easoning is equally poblematic (fom the pespective of scalable implementations) in the language they defined, ALC(D) FD. In [3], Toman and Weddell extend thei pevious effots [6] by adding the possibility of using the FD concept constucto not only in top level and in the ight hand side of inclusion dependencies ( ). Howeve, this extension in the geneal case is shown to lead to undecidability. Decidability is egained by focusing on a educed DL whee Path FDs occu only at top level o in monotone concept constuctos. Thus, one can obseve a clea compomise between expessivity of FDs and the decidability of the esulting DL language. Put diffeently, the ontology develope s desied FD behaviou as descibed in section., (i) is not met in pesent ontology development softwae and (ii) might be implemented only patially at the type-level (TBox) (iii) but, despite the theoetical and softwae limitations, developes still would like to see such functionality soon. To addess these poblems, we necessaily depat fom the above-discussed appoaches by intoducing FD as an application level constuct in the ontology, i.e. without changing the ontology language, and defe pat of the pocessing to outside of the ontology, whee the obtained deived esults can be poted back into the ontology. This solution is in pat inspied by [5] that elegantly discuss the ole of constaints in ontologies as compaed to those in databases and the notion of distinguishable witness pedicate fo holding instances not confoming to specified constaints []. We descibe a fomal famewok that accommodates classic FDs, keys, and explicit dependencies in the next section. 3. Fomalization Famewok 3. Abstact Syntax A FD definition fd, used fo FD easoning at the instance level, is composed of the following elements: the antecedent A, consequent C, a oot concept R and eventually a skolem function f (see fomulae and 5): fd = ( A, C, R, f ) () which can be expessed as an implication, in the same vein as taditional FDs: f ( fd R : A!!" C) () As illustated in fomula 3 below, the antecedent A is a set of paths. A path u i is in tun composed of a list of oles, each one being i. The consequent is defined by a single path u, which is composed of l oles u i. The oot concept R is the stating point of all
paths in the antecedent and consequent, so that a FD expesses elationships among oles of a single instance of the R concept. Notice that all paths consideed ae single valued and simple concatenations of oles, such that moe complex composition constucts ae not allowed. A = { u, u,..., u } i u = { i, C = { u}, i, n,..., i, mi } u = { s, s,..., sl} In case of having the deteministic function f defined, it takes as paametes individuals of the anges of the last oles of the antecedent paths. And the esult of f must be an individual in the ange of the last ole of the path in the consequent. 3. FD Semantics Concening the semantics of the fd definition, we fist define path evaluation unde an intepetation X. Given an intepetation X, we say it is composed by a domain Δ X and an intepetation function. As we have seen the intepetation function maps a ole i,j to a subset i,j X Δ X!Δ X. Fo paths we apply the same pinciple using composition of these intepetation functions. Given a path u i, a concept R and an individual x, with x R X, then u i X (x) is defined as: i,m X ( ( i, X ( i, X (x))) ) Now an intepetation X satisfies a FD fd = (A, C, R, f), with A and C defined as in (), if fo all a, b R X it is veified that: if u X (a)= u X (b) and u i X (a)= u i X (b) and u n X (a)= u n X (b), then u X (a)= u X (b) 3.3 Classic FDs In the simple example of the flight gate that depends on the aival and depatue aipots (see Figue ), the fd definition would be composed of the following antecedent, consequent and oot concept: A = {u,u } C = {u} R = Flight u = {depatsfom} u = {aivesat} u = {depatsthoughgate} We can expess FDs as Hon clause ules so that late an engine can enfoce the FDs fo the instances of an ontology (i.e. its ABox). In the case of classic FD the abstact fd definition in () can be tanslated to the following Hon ule:... "... "... ", n,, n, ( a, p ( a, p ( b, q ( b, q n, s ( a, p ) " s s ( b, q ) " s n,,,,,, q,, n,, q n,, q,, ) "... " s ) "... " s l l,m,m n,mn l! l! n,mn ) ", q ), m!, m! l n, mn! n, mn! l, g ) ", g, g ) ", g n n ) "! sameas ) " ( l p l, q ) whee the a, b i,j,q ij and g i elements ae fee vaiables. The vaiables a and b ae the common oot nodes linking all the paths in the antecedent and consequent of the FD. (3)
The i,j ae oles of an antecedent path and the si ae oles of the consequent, just as shown in () (3). These mappings suffe slight vaiations when applied to the case of key and explicit functions. 3.4 Keys If the FD epesents a key, FD fdk, then the consequent is the instance of the oot concept itself (Id) and thee is no need to specify C. It is not necessay to specify f eithe: fdk = (A, R) (fdk R : A Id) (4) Given the intepetation X, it satisfies the key fdk if fo all a, b R X : if u X (a)= u X (b) and u X i (a ) = u X i (b) and u X n (a)= u X n (b), then a= b Notice that the only diffeence at the intepetation level is that instead of ensuing the equality between u X (a)= u X (b), we need to ensue the equality of the instances a and b themselves. In the simple example of the passpot with a key FD, the fdk definition would be composed of the following antecedent and oot concept: A = { u, u } C = { u} R = Passpot u = { issuedincounty} u = { passnumbe} The fdk needs to ensue that the instances ae themselves equal if the antecedent holds. In the case of key FD the abstact fdk definition in (4) can be tanslated to the following Hon ule:...... "... ", n,, n, ( a, p ( a, p ( b, q ( b, q, n,, n,,,,, n,, q n,,, q,,m,m n,mn n,mn, m!, m! n, mn! n, mn!, g ) ", g, g ) ", g n n ) ) "! whee a, b i,j,q ij and g i ae vaiables in the ule language. sameas( a, b) 3.5 Explicit Function In defining explicit function FDs, fde, the deteministic function f is specified along with the antecedent and consequent: fde = (A, R, C, f) f ( fde R : A!!" C) (5) Given the intepetation X, it satisfies the explicit FD fde if fo all a R X, and t,, t n Δ X if t = u X (a) and t i = u X i (a) and t n =u X n (a), then u X (a)=f(t,,t i,,t n ) In the moe complex case of the ticket pice we would have: A = {u,u } C = {u} R = Ticket f = f ticket u = {belongstoflight,depatsfom} u = {belongstoflight,aivesat} u = {haspice}
Notice that in this example we have two paths u and u each one having two components. The function f ticket takes aipots as paametes and etuns a pice instance. The abstact fde syntax in (5) can be tanslated to the following Hon ule:,...... " ( a, p ( a, p i, n, i, ( a, p n, s ( a, p ) " s i, n, i, ) "... " s,,,,,m, m! i, l! i,mi n,mn l! i, mi! l!, g ) ", g ) " n, mn! ) i, g n ) " " s l l!, f ( g,..., gi,..., g n whee a i,j, and g i ae fee vaiables. Having pesented the syntax and semantics fo the thee FD modes discussed in this wok, we tun now to discussing enfocement policies with espect to a knowledge base, which we name FD intepetations. 3.6 FD Intepetations An inteesting aspect about FDs in ontologies is that depending on the kind of enfocement, they can be applied quite diffeently. We have identified thee FD intepetations: constaints, new assetions and views. In the fist enfocement mode (i.e., constaints) FD expesses invalid states of the ABox. Instances confoming to an FD constaint ae identified and exposed to use analysis. The second intepetation ceates new ABox assetions with instances matching the FD definitions. Finally, view intepetation coesponds to etieving instances matching FD specifications. To bette undestand this diffeence of usage of FD assetions, conside the following example, again in the context of the Flight ontology: The tax on a ticket pice functionally depends on the passenge age-goup, the depatue aipot and the aival aipot. We identify the paths fo the antecedent and consequent; and the function f tax that computes the tax based on the depatue, aival and age goup: tax = f tax(depatueaipot,aivalaipot,agegoup). The FD is defined as: fd tax : (A,C,Ticket, f tax ) " {belongstoflight,depatsfom}, & $ $ A = # { belongstoflight,aivesat}, ' $ %{ haspassenge,belongstogoup $ }( C = {{ haspice,hastax} } Conside, in addition, the following ABox: belongstoflight(t,f) depatsfom(f,geneva) aivesat(f,heathrow) haspassenge(t,carl) belongstogoup(carl,junior) The FD assetion intepetation would poduce the following ABox statement hastax(p, f tax(geneva,heathrow,junior)) fo a pice P of ticket T. Symmetically, in case of adapting the FD constaint enfocement intepetation, the ole hastax would appea in the consequent of a FD specification in its negative fom to check fo huting instances, such as: not hastax(p,f tax(geneva,heathrow,junior)). Finally, view intepetation is )) (6)
syntactically equivalent to FD assetion but with intepetation leading to instances being etuned to the use. 3.7 Extended Knowledge Base In ode to accommodate the afoementioned intepetations we extend the conceptual model poposed in [5] accoding to the following extended DL-FD knowledge base, epesented as a sextuple: K=(T, A, FD,C,C A,V) Such that: T is a finite set of standad TBox axioms, A is a finite set of standad ABox assetions, FD is a finite set of functional dependency definition instances, whee each FD definition can be classified as: FD a is a finite set of assetion FDs fda i FD c is a finite set of constaint FDs fdc i FD v is a finite set of view FDs fdv i C is a finite set of constaint witness classes w fdci, with fdc i FD c C A is a finite set of assetion huting some FD c constaint and expessed as witness facts, i.e. instances of w fdci. V is a finite set of view definitions V={v fdv,, v n fdv n }, whee fdv i FDv The set C A of witness classes models instances huting FD constaints. They allow uses to analyze the huting instances without diectly affecting the ABox. The view intepetation specifies queies whose answes ae computed by the explicit dependency function ove detemining popety values. The view chaacteization defes fom simple assetions in that the FD ule definition specifies necessay and sufficient conditions fo ABox assetions to match with pedicates in FD.V compehends view labels mapped to coesponding FD v instances. Having defined FDs fomally and integated them within an extended knowledge base, we discuss in the next section how functional dependency is specified in OWL. 4. Specifying FD in OWL-DL In this section, the fomalism intoduced in section 3 is ealized into an appoach fo integating FD into OWL-DL. 4. OWL FD Package In ode to model the abstact FD definition pesented in () and (), an OWL Class called FD has been specified. This class, its subclasses and popeties, have been defined in an OWL FD package with a sepaate namespace owlfd. In this way, we can euse these FD definitions in any owl ontology, by impoting the owlfd namespace: <owl:impots df:esouce="http://lbd.epfl.ch/fdowl.owl"/> 4. OWL FD Class The owlfd:fd class, just like in the definition intoduced in (), has the following popeties: antecedent, consequent, ootclass and hasfunction. The antecedent popety links FD instances to one o moe Path instances. Similaly, the
consequent popety links a FD instance to at most one Path. The ootclass popety has a df:class as ange associating a FD instance to a class name in the OWL ontology. The ootclass eflects the oot concept of the abstact FD. Finally, the hasfunction popety indicates the esouce id of the function coesponding to f as in the abstact definition. FD! owl:thing! antecedent only Path! antecedent min! consequent only Path! consequent max = ootclass exactly! hasfunction max Fo the case of keys, a sub-popety of ootclass called keyrootclass has been defined. Any FD definition featuing this subpopety instead of ootclass should be intepeted as a FD key definition. The Path class, efeenced by the antecedent and consequent contains a list of popety efeences called owlfd:patlist. The PatList class is an extension of the geneic df:list, specializing the df:fist and df:last popeties. In ode to make the PatList an odeed list of efeences to popeties, the fist popety of this list can only accept df:popety instances. The PatList definition is specified as: PatList! df:list! df:fist only df:popety = df:fist exactly! df:est only df:list = df:est exactly A Path is linked to a PatList though the pats popety. A path must have one PatList. We give now the definition of a Path: Path! owl:thing! pats some PatList = pats exactly 4.3 Subclasses of FD In addition thee subclasses of FD have been defined: FD a,fd c and FD v. These subclasses coespond to the abovementioned intepetation types: assetions, constaints and views espectively: FD a! FD FD c! FD FD v! FD As we have seen in the pevious section, these intepetation diffeences don t have much impact on the abstact definition. In fact it is sufficient to use one of the thee afoementioned subclasses (FD a, FD c o FD v ) to get the expected esults in tems of intepetations.
5. Implementation Having descibed ou appoach fo adding functional dependencies to OWL, we poceed now to descibe a pototype implementation demonstating the applicability of ou ideas. 5. Implementation design The stating point fo implementation of functional dependencies fo ontologies is definitely the FD constucts definition. We have descibed how FDs can be descibed in abstact tems and how this abstaction can be expessed using ou OWL FD classes and popeties (see Figue 5). It is impotant to notice that the FD definitions ae independent fom any actual implementation of the enfocement of the dependencies. The mechanisms to guaantee that the definitions hold could follow vaious diffeent appoaches. In this wok we have focused on mapping the FD definitions to Hon clause ules. In the specific case of OWL, the SWRL language constitutes a concete example of an effot unifying OWL DL and Hon clauses. We have aleady shown how to map the OWL FD definitions to ules. This mapping mechanism has been implemented fo the thee discussed intepetations. FD definitions and deived ules ae based on pedicates whose teminology is pat of a known knowledge base. Fig. 5. FD Class in the ontology development tool Potégé. Instances of FD ae functional dependency definitions fo the ontology; Figue 6 illustates a Potégé OWL FD instance specification. Then, each path, such as FD_PilotAssigment with thei PathLists in the Flight ontology, is also easily editable with Potégé. In this example, the Path is given by the PatList composed of popeties scheduledasflight and managedbyailine (see Figue 7). Fig. 6. FD antecedent and consequent.
5. Mapping fom OWL FD to SWRL Fig. 7. Path with PatList. We have developed a Java application that takes OWL FD definitions of an ontology and geneates the coesponding set of SWRL ules. This pocedue follows the mapping descibed in section 3. In the next subsections, we will econside the tax example of section 3.6, with the thee vaiants of intepetation. Figue 8 shows a geneated SWRL ule in the SWRL tab of Potégé []. Fig. 8. SWRL ule fo tax FD. Fo the sake of simplicity in this example, the f tax function has been eplaced by a simple multiplication function called multiply, which is available out of the box as a SWRL Built-In function and is suppoted in the basic package of the SWRL ule engine we used. Altenatively, we could have specified a moe complex function and have implemented the intended behaviou using a Java class. In the following sections we pesent the vaiations accoding to the intended intepetation. 5.. Assetion SWRL ules To diffeentiate this kind of FD definitions, we use the FD a subclass of ou FD class. In this fist case the head of the ule, o the deduction of the ule evaluation, is a pedicate that is added to the ABox of the knowledge base. This pedicate is a popety assetion of the kind popetyname(?vaiable,?vaiable). In the example, the popetyname is hastax, the vaiable?ticket epesents a ticket individual matching the conditions in the ule s body, and the?i vaiable holds the esult of the evaluation of the swlb:multiply function ove the vaiables?age and?deptax. These last two ae the age of the passenge of the ticket and the tax of the depatue aipot. To add the esults of the ule evaluation
to the ABox, the use has to expot the esulting pedicate back to OWL though the Potégé inteface. 5.. Constaint SWRL Rules These FDs ae individuals of the subclass FD c. Contay to FD a ules, these do not add any new assetions to the ABox as a esult of FD evaluation. Instead, thei enfocement checks whethe existing ABox assetions ae consistent with the FD c definitions. In case of huting instances ae detected, they ae classified to the coesponding witness class, which holds the infomation about the individual who is violating the FD c constaint. A witness popety in its most basic fom indicates which individual violates the constaint and the expected instance value. In the tax example, if fo some eason someone has asseted that hastax(ticket,300), this contadicts the expected pedicate hastax(ticket,00). The following witness is poduced: witness tax(ticket,00). We can see the complete SWRL ule in the Potégé inteface in Figue 9. Notice that the witness can gow in complexity, and the infomation it could eventually hold depends on how the witness popety is modeled. This is simila to custom exceptions in a pogamming language. The witness popeties ae defined in thei own constaint teminology set C, as descibed in section 3.7. The witness assetions ae in tun stoed in the C A set. Fig. 9. Constaint SWRL ule. 5..3 Views with SWRL Rules As we have aleady mentioned, the case of views is quite simila to that of newassetions. The chief diffeence is that the pedicates of the head of the ules, the esults of the ule evaluation, ae not added to the ABox. They ae computed at un-time duing quey pocessing. Fo example in the model of tax, equation (6), the ticket tax is computed and etieved in a quey, but neve stoed anywhee. Fo views the esults ae displayed in the context of quey execution. 6. Conclusions The extension of DL knowledge base with functional dependencies has been acknowledged as elevant in poducing moe expessive ontologies. In this wok we investigate the extension of knowledge bases with thee kinds of functional dependencies: classic, keys and featuing explicit functions. In fact, to the best of ou knowledge, this is the fist wok in ontologies that exploes functional dependencies with an explicit function elating dependent to detemining popeties. We popose a
fomal famewok to extend ontologies with these thee functional dependencies and study the diffeent behavios that can be consideed when unning FD as Hon clause ules. We identified thee main types of intepetations fo FDs: constaints, newassetions and views; and show how to integate them within a common stuctue. The conceptual epesentation is implemented in OWL by a new OWL FD concept that can be added to any OWL ontology. This concept holds all the attibutes of an FD as popeties and its instances ae called functional dependency definitions. Moeove, a mapping function tanslates FD assetions into SWRL ules, allowing infeences to poduce the desied FD behavio. The famewok has been implemented in an initial pototype unde Potégé and using Jess as the ule execution engine. Ou appoach to extend the knowledge base with a new FD class has both advantages and disadvantages. An advantage is that it can be easily adopted without equiing any extension to the ontology language. Futhemoe, as the FD evaluation is done though SWRL on instances in the ABox, it does not affect subsumption easoning in the TBOX. It tuns out that this same aspect can be seen as a disadvantage as subsumption cannot be expessed ove constained concepts with FD. One of the main poblems with functional dependencies and especially keys, is to evaluate equality. A pagmatic option is to define equality based on datatype popeties of individuals, but this is a whole subject on its own and may deseve a deepe analysis. Anothe inteesting issue that we leave fo futue investigation is the case of key FD with multi-valued non-key attibutes, in addition to the paths and FDs that we have modeled ove single valued popeties in this pape. In this scenaio, deciding on equality of sets seems not evident. Similaly, if popeties in the head of a FD ae allowed to be multi-valued, then existential quantification ove the set is equied. 7. Refeences [] S. Abiteboul, R. Hull and V. Vianu. Foundations of Databases, Addison Wesley, 995. [] R. Fagin. Functional dependencies in a elational data base and popositional logic. IBM Jounal of Reseach and Development (6)ages 543-544. 977. [3] J. Hong, W. Liu, D.A. Bell, Q. Bai. Answeing Queies Using Views in the Pesence of Functional Dependencies. In: Poceeding of BNCOD 005ages 70-8. 005. [4] S. Abiteboul and O. Duschka, Complexity of answeing queies using mateialized views. In Poc. Of the ACM SIGACT-SIGMOD-SIGART Symposium on Pinciples of Database Systems (PODS), Seattle, WA, 998 [5] B. Motik, I. Hoocks, U. Sattle. Bidging the Gap Between OWL and Relational Databases. In Poceedings of the 6 th intenational confeence on Wold Wide Web, pages 807-86, 007. [6] D. Toman, G. E. Weddell, On Keys and Functional Dependencies as Fist-Class Citizens in Desciption Logics. In: Poceedings of IJCAR 006: 647-66, 006 [7] C.Beei, and M. Y.Vadi. Fomal system fo tuple and equality geneating dependencies. SIAM J Comput 3 (984), 76--98. [8] I. Hoocks, P. F. Patel-Schneide, H. Boley, S. Tabet, B. Gosof, M. Dean. SWRL: A Semantic Web Rule Language Combining OWL and RuleML, http://www.w3.og/submission/swrl/ W3C Membe Submission May 004.
[9] A. Bogida and G. E. Weddell. Adding uniqueness constaints to desciption logics (peliminay epot). In Poceedings of the Fifth Intenational Confeence on Deductive and Object Oiented Databasesages 85--0, 997. [0] A. Bogida, R. Bachman, D. McGuinness, L. Alpein Resnick. CLASSIC: A Stuctual Data Model fo Objects. In Poceedings of the 989 ACM SIGMOD Intenational Confeence on Management of Dataages 59-67. June 989. [] V. L. Khizde, D. Toman, and Gant E. Weddell. On Decidability and Complexity of Desciption Logics with Uniqueness Constaints. In Intenational Confeence on Database Theoy ICDT'0ages 54-67, 00. [] D. Calvanese, G. De Giacomo, and M. Lenzeini. Identification constaints and functional dependencies in Desciption Logics. In Poc. of IJCAI 00, 55-60. [3] F. Baade, D. Calvanese, D. McGuinness, D. Nadi, P. F. Patel-Schneide, Eds. The Desciption Logic Handbook: Theoy, Implementation and Applications. Cambidge Univesity Pess, 003. [4] S. Bechhofe, F. van Hamelen, J. Hendle, I. Hoocks, D. L. McGuinness, P. F. Patel-Schneide, L. A. Stein. OWL Web Ontology Language Refeence, http://www.w3.og/tr/owl-ef/, W3C Recommendation 0-0-004. [5] D. Beadi, D. Calvanese, and G. De Giacomo. Reasoning on UML class diagams. In Atificial Intelligence Volume 68, Issues -. Octobe 005ages 70-8. [6] H. Boley, S. Tabet, and G. Wagne. Design Rationale of RuleML: A Makup Language fo Semantic Web Rules. In Poceedings of SWWS 0, Stanfod. 00. [7] R. Fagin. Hon Clauses and Database Dependencies. In Jounal of the Association fo Computing Machiney, Vol 9, no 4ages 95-985, 98. [8] R. Fagin. Nomal Foms and Relational Database Opeatos. ACM SIGMOD Intenational Confeence on Management of Data, May 3-June, 979, Boston, Mass. Also IBM Reseach Repot RJ47, Feb. 979. [9] C. Lutz, C. Aeces, I. Hoocks, and U. Sattle. Keys, Nominals and Concete Domains. In Poceedings of the Eighteenth Intenational Joint Confeence on Atificial Intelligence (IJCAI 03)ages 349-354. Mogan Kaufmann. 003. [0] C. Lutz and M. Milicic, Desciption Logics with Concete Domains and Functional Dependencies. In Poceedings of the 6th Euopean Confeence on Atificial Intelligence (ECAI-004), 004. [] B. Ludäsche, A. Gupta, and M.E. Matone, Model-Based Mediation with Domain Maps, 7th Int l Confeence on Data Engineeing, Heidelbeg, Gemany, 00. [] Potégé Community, SWRLQueyBuiltIns. Potégé Wiki http://potege.cim3.net/cgi-bin/wiki.pl?swrlqueybuiltins, July 007. [3] D. Toman and G. E. Weddell. On Path-functional Dependencies as Fist-Class citizens. In the 005 Intenational Wokshop on Desciption Logics (DL005), Edinbugh, Scotland, UK, July 6-8, 005. [4] I. Hoocks, O. Kutz, and U. Sattle. The Even Moe Iesistible SROIQ. In: Poceedings of KR-006, Lake Distict, UK, 006.