Representation of Complex Changes 

Contexts in source publication

Context 1

... at the instance level, instantiating the corresponding classes. Specifically, at schema level, we introduce one class for each simple and complex change c ( p 1 , . . . , p n ) that is understood and considered by the language of changes ( L ), and at instance level, we introduce one individual for each detectable change c ( x 1 , . . . , x n ) in each pair of versions. For simple changes, the corresponding change definition is modelled as a subclass of the main class Simple _ Change , and is associated with adequate properties to represent its parameters (see Figure 2); each such property models the type of the parameter (e.g., whether it is a URI or a literal, via the classes rdfs:Resource, rdfs:Literal respectively) and its name (which is a descriptive name that allows a more intuitive interaction with the user, useful also during the construction of complex changes that consume said simple change). Also a descriptive name ( cname ) is captured for each type of change. Note that conditions do not need to be stored. For complex changes, similar ideas are used; however, note that the information related to complex changes is generated on the fly at change creation time (in contrast to simple changes, which are in- built in the ontology at design time). In addition, more detailed information related to the change should be available in the ontology for the change detection process, because, unlike simple changes, this information is not known at design time and cannot be embed- ded in the code. Each complex change is modelled as a subclass of the main class Complex _ Change , and is associated with adequate properties to represent its parameters (see Figure 3). Again, parameters have a type and a name, which are modelled in the same manner as in simple changes. In addition, each complex change is associated with the simple change(s) that it consumes, and includes also properties describing its (user-defined) descriptive name and its priority. Finally, for each complex change, the SPARQL query used for its detection, is automatically generated at change definition time; this is done for efficiency, to avoid having to generate this query in every run of the detection process. The SPARQL query encapsu- lates all the relevant information about the detection of the change, so further information on the complex change (namely conditions and associations) need not to be stored. The instance level is used to store the detectable simple and complex changes. Each detectable change between any two versions is represented using a different individual associated through adequate properties with all relevant information, namely, the versions between which the change was detected and the exact values of its parameters (of the change instantiation). For complex changes, we additionally need to include consumption information. Examples of such instantiations for simple and complex changes are shown in Figures 4 and 5, for the detectable changes Attach_Type_To_Measure( dm − measure : meas 7 v 8 t, dm − type : int ) and Mark_as_Obsolete ( ef o : EF O _ 0004151 ), respectively. Another useful feature of the ontology of changes is the storage of associations , which are necessary for the detection of complex changes. Associations are stored as instances classified under the class Association , and record the versions between which they are applicable, as well as the old and new values in the corresponding association. For example, Figure 6 shows the representation of the associations { x 1 } { x 2 } and { y 1 } { y 2 , y 3 } , which appear between versions v 1 , v 2 ...

Context 2

... change detection process is responsible for the detection of simple and complex changes between two dataset versions (and their corresponding associations, which are a necessary input for the detection of complex changes), as well as for the enrichment of the ontology of changes with information about the detectable changes. Thus, the process can be considered to comprise of two steps: the first is the identification of the detectable changes and the corresponding information (triples) to be inserted in the ontology of changes ( triple creation ), and the second is the actual ingestion of said information in the ontology of changes ( triple ingestion ). To detect simple and complex changes, we rely on plain SPARQL queries, which are generated from the information drawn from the definition of the corresponding changes (Definitions 3, 10). For simple changes, this information is known at design time, so the query is loaded from a configuration file, whereas for complex changes, the corresponding query is generated once at change-creation time (run-time) and is loaded from the ontology of changes (see Figure 3). The results of the generated queries determine the change instantiations that are detectable; this information is further pro- cessed to determine the actual triples to be inserted in the ontology of changes. Recall that this depends on the actual detected change and its type (see Section 4). More specifically, the SPARQL queries used for detecting a simple change are SELECT queries, whose returned values are the parameter values of the change; thus, for each parameter of the change definition, we put one variable in the SELECT clause. Then, the WHERE clause of the query includes the triple patterns that should (or should not) be found in each of the versions in order for a change instantiation to be detectable; more specifically, the triple patterns in δ + must be found in D new but not in D old , the triple patterns in δ − must be found in D old but not in D new , and the graph patterns in φ old , φ new should be applied in D old , D new , respectively. Let’s use this methodology to construct the SPARQL query for the simple change Attach_Type_To_Measure(m,t) in which: δ + = { ( m, rdfs : range , t ) } , δ − = ∅ , φ old = “ ”, φ new = “( m , rdf : type , qb : measureP roperty )”. The corresponding SPARQL query ...