The dynamic nature of web data brings forward the need for maintaining data versions as well as identifying semantically rich changes between them. In this paper, we advocate the need for supporting complex changes in evolving RDF(S) knowledge bases. We outline the basic challenges and provide solution insights through a real-world example from the field of biology. * Supported by the EU-funded ICT project "DIACHRON" (agreement no 601043). + Supported by the European Union (European Social Fund - ESF) and Greek national funds through the Operational Program "Education and Lifelong Learning" of the National Strategic Reference Framework (NSRF) - Research Funding Program: Thales. Investing in knowledge society through the European Social Fund.
The increasing amount of information published on the web poses new challenges for data management. A central issue concerns evolution management, as the dynamic nature of data brings forward the need for maintaining data versions as well as identifying changes between them. For example, biologists often use ontologies in order to curate their data from multiple domains of interest like anatomy, diseases, biomedical investigations, etc. These ontologies are frequently updated as errors may need to be fixed or new knowledge about the state of the art may need to be incorporated. As a result, curators of depending ontologies are interested in understanding the evolution history in order to learn more about the changes that have taken place on the respective domain of interest.
In this paper, we argue that understanding data evolution should involve highlevel, semantically rich, user-defined changes that we call complex changes. Formalizing complex changes involves facing the challenges of modeling, defining, detecting and querying changes. Although the concept of complex changes is not bound to any specific data model, in this paper we focus on RDF(S) knowledge bases, as RDF is a de-facto standard for representing data on the web. The goal of this paper is to highlight the main challenges as well as possible solution insights towards a framework that makes changes first class citizens.
The paper outline is as follows. In section 2 we discuss in detail the challenges for supporting complex changes. In section 3 we provide an end-to-end real world example that demonstrates important aspects of our approach to the aforementioned problems. Finally, in section 4 we conclude the paper. 2
Modeling changes. An approach for modeling changes in RDF(S) knowledge bases would be determining the added and deleted triples between versions. However, this is not sufficient for understanding data evolution. Human-readable, high-level changes should be employed. In this case, two basic issues must be taken into consideration. ─ Granularity of changes. Fine-grained or coarse-grained changes? Fine-grained changes have the advantage of describing primitive changes, while coarse-grained changes provide more semantics and conciseness by grouping primitive changes in logical units. ─ Semantics of changes. Model-specific or data- and application- specific changes? Model-specific changes describe modifications that may appear in a specific representation model. They constitute a fixed set of generic changes. On the other hand, data- or application- specific changes represent user-defined changes that suit on specific use-case scenarios. Supporting user-defined changes has the advantage of allowing different interpretations of evolution.
In order to tackle the above issues, we distinguish between simple and complex changes. Simple changes constitute a fixed set of fine-grained, model-specific changes. Complex changes are coarse-grained, user-defined, application-specific changes.
In previous works [
Defining changes. A declarative language for defining changes is needed for supporting user-defined complex changes. The language expressiveness should be investigated. A complex change definition should consist of a finite, non-empty list of simple or (already defined) complex changes, and a set of constraints over these changes. The supported constraints may filter parameter values, express pre- or post- conditions, relate change parameters, pose cardinality constraints (e.g. there must be at least one change of a specific type) and allow or not overlaps among changes.
In [
Detecting changes. As new dataset versions are periodically released, simple and
complex changes can be detected among versions. In [
Querying changes. In our view, querying data evolution should be based on data as much as on changes. Changes, like data, can appear in the query body to express complex conditions, like the fact that an entity has been modified in a specific manner, or can be returned by the query in order to retrieve explicit change instances. Some interesting query types that should be supported are the following: ─ Retrieve changes among versions, or restrict selected changes by the type of change or the elements that they have affected or the versions between which they are detected. ─ Retrieve elements, given that changes of specific type have affected them at specific versions. 3
The Experimental Factor Ontology (EFO) [
Consider that a new class is added into the ontology. This class is also assigned with a class label, a textual definition and synonyms of the class label. The class label corresponds to rdfs:label annotation property, the textual definition corresponds to the efo:definition property and the synonym to the efo:alternative-term property. Note that for simplicity and space limitations we consider only these operations.
Modeling changes. These changes are fine-grained and can be described by
model-specific operations. The addition of a new class can be modeled as
Add_Type_Class(c), where c is the new class. The addition of a new label can be
modeled as Add_Label(c, l), where c is the respective class holding the new label l.
The addition of a new definition or synonym corresponds to an addition of a new
property and can be modeled as Add_Property_Instance(s, p, o), where p is the new
property which is assigned to class s with value o. In our approach, these are simple
changes. We can rely on [
Notice that Add_Property_Instance suits all possible properties, while in this scenario the assigned properties are of two specific types: efo:definition and 1 http://www.ebi.ac.uk/ efo:synonym. It is more suitable to have intuitive changes regarding the specific properties involved, like Add_Definition and Add_Synonym. Also, the discussed modifications are likely to appear jointly. As a result, it may be useful to demonstrate these changes as a unit. Therefore, they can be grouped into one change named Add_Annotated_Class. In our approach, these are examples of complex changes.
Defining changes. The complex changes Add_Definition, Add_Synonym and Add_Annotated_Class can be defined as follows: CREATE COMPLEX CHANGE Add_Definition(class, definition) { CHANGE LIST Add_Property_Instance(class, prop, definition); SELECTION FILTER prop='efo:definition'; }; CREATE COMPLEX CHANGE Add_Synonym(class, synonym) {
CHANGE LIST Add_Property_Instance(class, prop, synonym); SELECTION FILTER prop='efo:alternative_term'; }; CREATE COMPLEX CHANGE Add_Annotated_Class(class, label, definition, synonym) {
CHANGE LIST Add_Type_Class(class), Add_Label(class, label), Add_Definition(class, definition), Add_Synonym(class, synonym) *; }; The name and parameters of each defined complex change are declared right after the CREATE COMPLEX CHANGE clause. In the CHANGE LIST clause the contained simple or complex changes are declared. Note that the asterisk (*) beside Add_Synonym in Add_Annotated_Class definition indicates that there might be zero, one, or more such changes, one for each added synonym, posing a cardinality constraint. Defining Add_Definition and Add_Synonym includes a constraint, declared in the SELECTION FILTER clause, filtering the property type. In Add_Annotated_Term, the parameter name class is used among the contained changes, indicating that they refer to the same actual class.
Detecting changes. As ontology versions are periodically released, we can identify the changes that have occurred among versions. Simple changes have to be detected first. Notice that Add_Definition and Add_Synonym are defined in terms of simple changes, while Add_Annotated_Class includes complex changes too. Therefore, Add_Definition and Add_Synonym should be detected first by evaluating their definitions over the detected simple change instances, while Add_Annotated_Class next as it depends on complex change instances too. Alternatively, Add_Annotated_Class can be expressed in terms of simple changes, by substituting Add_Definition and Add_Synonym changes with their definitions. In this way, all complex change definitions can be evaluated over the detected simple change instances. The detected simple and complex change instances constitute a hierarchy of changes, where the user can see the changes themselves as well as how they are interconnected.
Querying changes. For querying changes, SPARQL can be extended with suitable
keywords. The following query gives an example of querying changes. It returns all
classes that have been added and annotated between versions 2.45 and 2.46. For this
example, we assume that defined changes and detected instances are represented in an
ontology of changes as in [
SELECT ?class FROM CHANGES ON DATASET <D> WHERE { ?c rdf:type co:Add_Annotated_Class; co:aac_p1 ?class.
FILTER change_span(?c BETWEEN VERSION 2.45 AND 2.46). } 4
In this paper we advocated the need for formalizing complex changes over RDF(S) knowledge bases and outlined the basic challenges that have to be faced to realize our vision. An example inspired from the biological domain is used to motivate the need for complex changes and present the basic concepts of a possible solution. Nevertheless, supporting complex changes may be useful in any evolving domain. 5