The Linked Data initiative [2] promotes the publication of previously isolated databases as interlinked RDF triple sets, thereby creating a global scale dataspace, known as the Web of Data. However, the full potential of linked data depends on how easy it is to publish data stored in relational databases (RDBs) in RDF format. This process is often called RDB-to-RDF.
A general and flexible way to publish relational data in RDF format is to create RDF views of the underlying relational data. The contents of views can be materialized to improve query performance and data availability. However, to be useful, a materialized view must be continuously maintained to reflect dynamic source updates. Basically, there are two strategies for materialized view maintenance. Re-materialization re-computes view data at pre-established times, whereas incremental maintenance periodically modifies part of the view data to reflect updates to the database. It has been shown that incremental maintenance generally outperforms full view recomputation [1].

IVMF is a framework, based on rules, for incremental maintenance of external RDF views defined on top of relational data.

Figure 1. Suggested Framework

Figure 1 depicts the main components of the framework. Briefly, the administrator of a relational database, using the Rubya (Rules by assertion), should define a set of rules, which are responsible for: (i) computing the view maintenance statements necessary to maintain a materialized view V with respect to base updates; and (ii) sending the view maintenance statements to the view controller of V. The rules can be implemented using triggers. Hence, no middleware system is required.
The view controller for the RDF view has the following functionality: (i) receives the view maintenance updates from the RDB server and (ii) applies the updates to the view accordingly.
Our approach is very effective for an externally maintained view because: the view maintenance rules are defined at view definition time; no access to the materialized view is required to compute the view maintenance statements propagated by the rules; and the application of the view maintenance statements by the view controller does not require any additional queries over the data source to maintain the view. This is important when the view is maintained externally [2], because accessing a remote data source may be too slow.

The demo video is available at http://tiny.cc/rubya. First, the video shows, with the help of a real-word application, the process of defining the RDF view and generating the maintenance rules with Rubya. Then, it shows some practical examples of using the rules for incremental maintenance of a materialized RDF view. To the best of our knowledge, no tool is available for the incremental maintenance of RDF view.

Generating Rules with Rubya

The use of rules is therefore an effective solution for the incremental maintenance of external views. However, creating rules that correctly maintain an RDF view can be a complex process, which calls for tools that automate the rule generation process. In following we further detail the Rubya tool that, based on the mapping between the relational schema and a target ontology, automatically generates the RDF view exported from the relational data source and the set of rules required for the incremental maintenance of the RDF view.

Figure 2. Rubya components

Figure 2 highlights the main components of Rubya. The process of defining the RDF view and generating the maintenance rules with Rubya, consists of three steps:
STEP 1: The mapping generation step results in a specification of how to represent RDB schema concepts in terms of RDF classes and properties in a target vocabulary of the designer’s choice. Using the correspondence assertion editor of Rubya, the user loads the source and target schema, and then, he can draw correspondence assertions (CAs) to specify the mapping between the target RDF schema and the source relational schema. The CAs induce schema mappings defined by the class of projection-selection-equijoin queries, which supports most types of data restructuring that are common in data publishing. We make a compromise in constraining the expressiveness of mappings to obtain an algorithm that is very efficient.
A CA can be: (i) a class correspondence assertion (CCA), which matches a class and a relation schema; (ii) an object property correspondence assertion (OCA), which matches an object property with paths (list of foreign keys) of a relation schema; or (iii) a datatype property correspondence assertion (DCA), which matches a datatype property with attributes or paths of a relation schema. CAs have a simple syntax and semantics, and yet suffice to capture most of the subtleties of mapping relational schemas into RDF schemas.
Consider the relational schema ISWC_REL and the ontology CONF_OWL shown in Figure 3. Table 1 shows some examples of correspondence assertions between CONF_OWL and ISWC_REL, and the transformation rule induced by each assertion. For example, the transformation rules induced by CCA1, DCA1 and OCA2 are (the translations from attribute values to RDF literals are omitted for simplicity):
CCA1: specifies that each tuple t in Persons relation produces an RDF triple, such as: 

<http://example.com/person/t.authorID>rdf:type foaf:Person . 

DCA1: specifies that each tuple t in Persons produces an RDF triple, such as: 

<http://example.com/person/t.authorID> foaf:mbox"t.email" .

OCA1: specifies that, for each pair <p, t>, where pis a tuple in Papers and tis a tuple in Persons such that t is referenced by p through path j =[ Fk_Publication, Fk_Author], produces a triple such as: 

<http://example.com/document/p.paperID> 

         dc:creator <http://example.com/person/t’.personID>.

OCA1 is a little more complex, but it can be graphically defined. The user just navigates through the path by clicking over the FK nodes in the source schema and the CA Editor builds the assertions.

Figure 3. CONF_OWL and ISWC_REL schemas

Table 1. Examples of CA between CONF_OWL and ISWC_REL

	Correspondence Assertion	Transformation Rule
CCA1	foaf:Person ≡Persons[perID]	foaf:Person(s) ← Persons(t), HasURI[CCA1](t,s)
CCA2	foaf:Document ≡Papers[paperID]	foaf:Document(s) ← Papers(t), HasURI[CCA2](t,s)
CCA3	skos:Concept ≡Topics[TopicID]	skos:Concept(s) ← Topics(t), HasURI[CCA3](t,s)
DCA1	foaf:mbox ≡ Persons / email	foaf:mbox(s,v) ← Persons(p), HasURI[CCA1](p,s), nonNull(p.email), RDFLiteral(p.email, “email”, “Persons”,v)
OCA1	dc:creator ≡ Papers / φ, where: φ = [FK_Publications, FK_Authors]	dc:creator(s,o) ← Papers(p), HasURI[CCA2](p,s), HasReferencedTuple[φ](p,t), Persons(t), HasURI[CCA1](t,o)
OCA2	conf:researchInterests ≡ Persons / φ, where: φ = [FK_Authors, FK_Publications, FK_Papers, FK_Topics]	conf:researchInterests(s,o) ← Persons(p), HasURI[CCA1](p,s), HasReferencedTuple[φ](p,t), Topics(t), HasURI[CCA3](t,o)

STEP 2: The GRVS module automatically generates the RDF view schema, which is induced by the correspondence assertions defined in Step 1. The vocabulary of the RDF view schema contains all the elements of the target RDF schema that match an element of the source relational schema.
STEP 3: The GVMR module automatically generates the set of rules required to maintain the RDF view defined in Step 2. The process of generating the rules for a view V consists of the following steps:

(a) Obtain, based on the CAs of V, the set of all relations in the relational schema that are relevant to V.

(b) For each relation R that is relevant to V, three rules are generated (see Figure 4). An update is treated as a deletion followed by an insertion.

When   INSERT 0N R    Then       U:= GVU_INSERTonR (rnew);     ApplyUpdates( V, U);   (a)

When   DELETE 0N R    Then       U:=GVU_DELETEonR (rold);     ApplyUpdates( V, U);   (b)

When   UPDATE 0N R    Then        U:=GVU_DELETEonR (rold);      ApplyUpdates( V, U);      U:= GVU_INSERTonR (rnew);      ApplyUpdates( V, U); (c)

Figure 4. Rules for maintenance of View V with respect to updates on relevant relation R

In Figure 4, the procedures GVU_INSERT[R] and GVU_DELETE[R] are automatically generated, at view definition time, based on the CAs of V that are relevant to R. The procedure GVU_INSERT[R] takes as input a tuple rnew inserted in R and returns the updates necessary to maintain the view V. The procedure GVU_DELETE[R] takes as input a tuple rold deleted from R, and returns the updates necessary to maintain the view V. In [4] we present the algorithms that compile the procedure “GVU_ INSERT[R]” and“GVU_ DELETE[R]” based on the CAs of V that are relevant to R. Our formalism allows us to formally justify that the rules generated by our approach maintain correctly the view.
Table 2 shows the procedure GVU_DELETE[Rel_Person_Paper], which returns the updates necessary to maintain the RDF view exported from ISWC_REL with respect to deletions on relation Rel_Person_Paper. Assertions OCA1 and OCA2 are relevant to relation Rel_Person_Paper, because its foreign key Fk_Publication occurs in the path of both OCA1 and OCA2. The updates required by OCA1 reduce to (lines 02-10): For each tuple p in Papers that is referenced by rold through path [Fk_Publication], recompute the property dc:creator for p according to transformation rule of OCA1 (see Table1).  Note that the property dc:creator of other tuples in Papers is not affected by insertions on relation Rel_Paper_Topic. The updates required by OCA2 are computed in lines 12-20.

Table 2. Procedure GVU_DELETE[Rel_Person_Paper]

01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22

U :=  Ø;  /* Updates required by OCA1  Q1 = ObtainReferencedTuple[Fk_Publication](rold );   For each t1  in Q1 do {    s = GenerateURI[CCA2](t1);    U := U ∪ { “DeleteTriple(s, "dc:creator", ?o);”}; Q2 = ObtainReferencedTuple[Fk_Publications, Fk_Author ](t1)};   For each t2 in Q2 do {    o = GenerateURI[CCA1](t2);    U := U ∪ { “If person(o) then InsertTriple(s, "dc:creator", o);”}}; /* Updates required by OCA2 Q1 = ObtainReferencedTuple[Fk_author](rold );   For each t1  in Q1 do {     s  = GenerateURI[CCA1](t1);     U := U ∪ { “DeleteTriple(s, " conf:researchInterests ", ?o);”};     Q2 = ObtainReferencedTuple[Fk_Publications, Fk_Papers, Fk_Topics](t1);     For each t2 in Q2 do {         o = GenerateURI[CCA3](t2);         U := U ∪ { “If skos:concept(o) then InsertTriple(s, "conf:researchInterests",  o);”}}} Return(U).}

 

We create a virtual machine in Azure with environment configured.
To connect to the virtual machine download the file rubya.rdp and execute it (user name: rubya password: Rubya1234).

 

Welcome to the Rubya Tool installation guide which provides instructions on how to manually install and configure Rubya environment and Fuseki server.
Follow these steps to configure Rubya environment:
Step one:
Install jdk 8 is available at jdk 8.

Figure 5. Install jdk 8

 

 

Step two:
Install oracle 11g is available at oracle 11g.

Figure 6. Install oracle 11g

 

 

Step tree:
Download fuseki server and viewController available at Maintenance.rar.
Step four:
Download rubya tool available at rubya.rar.
Step five:
Unpack file mestrado.rar and acess path /mestrado/Fuseki-0.2.0.
To start fuseki server execute a command in prompt windows or terminal linux:
java -jar fuseki-sys.jar --update --loc=DIR2 /test

Figure 7. Start fuseki serve

 

 

Test fuseki service: Acess http://localhost:3030

Figure 8. Fuseki - control page

 

 

Click "Select" botton

Figure 9. Fuseki - Select dataset

 

 

Show a Fuseki service page

Figure 10. Fuseki server page

 

 

Step six:
Acess path /mestrado and execute a command in prompt windows or terminal linux:
java -jar setPropertiesBD.jar [URL_DATABASE] [USER] [PASSWORD]

Figure 11. Start setPropertiesBD

 

 

Open other terminal and execute a command in prompt windows or terminal linux:
java -jar viewControllerCompleto.jar [URL_DATABASE] [USER] [PASSWORD]

Figure 12. Start viewController

 

 

Step final:
Execute file rubyaTool.jar

. Start Rubya

 

 

Description:

Figure 13 depicts the relational schema ISWC_REL. Each table has a distinct primary key, whose name ends with ‘ID’. Persons and Papers represent the main concepts. The attribute conference of Papers is a foreign key to Conferences. Rel_Person_Paper represents an N:M relationship between Persons and Papers. The labels of the arcs, such as Fk_Publications, are the names of the foreign keys.

Figure 13. ISWC_REL database schema

Figure 14 depicts the ontology CONF_OWL, which reuses terms from four well-known vocabularies: FOAF (Friend of a Friend), SKOS (Knowledge Organization System), VCARD and DC (Dublin Core). We use the prefix “conf” for the new terms defined in the CONF_OWL ontology.

Figure 14.  CONF_OWL target ontology

 

Download schema and ontology .owl is available at Case_Study.rar.

 

 

Mapping Editor

Figure 15 shows Mapping Editor to create all Mappings between Ontology and Relational Data Base.
Figure 15.  Rubya - Mapping Editor

 

 

 

Mapping:

Table 3 shows a set of CAs that specify a mapping between CONF_OWL and ISWC_REL, obtained with the help of the tool described in Rubya tool. Table 3 also shows the transformation rules induced by each CA.

Table 3. Correspondence Assertions between CONF_OWL and ISWC_REL

	Correspondence Assertion	Transformation Rule
CCA1	foaf:Person ≡Persons[perID]	foaf:Person(s) ← Persons(t), HasURI[CCA1](t,s)
CCA2	foaf:Document ≡Papers[paperID]	foaf:Document(s) ← Papers(t), HasURI[CCA2](t,s)
CCA3	skos:Concept ≡Topics[TopicID]	skos:Concept(s) ← Topics(t), HasURI[CCA3](t,s)
CCA4	conf:Organization ≡ Organizations[orgID]	conf:Organization(s) ← Organizations(t), HasURI[CCA4](t,s)
CCA5	conf:Conference ≡ Conferences[confID]	conf:Conference(s) ← Conferences(t), HasURI[CCA5](t,s)
CCA6	conf:PostalAddress ≡ Organizations[address, location, postcode, country]	conf:PostalAddress(s) ← Organizations(t), HasURI[CCA6](t,s)
OCA1	dc:creator ≡ Papers / φ, where: φ = [FK_Publications, FK_Authors]	dc:creator(s,o) ← Papers(p), HasURI[CCA2](p,s), HasReferencedTuple[φ](p,t), Persons(t), HasURI[CCA1](t,o)
OCA2	conf:researchInterests ≡ Persons / φ, where: φ = [FK_Authors, FK_Publications, FK_Papers, FK_Topics]	conf:researchInterests(s,o) ← Persons(p), HasURI[CCA1](p,s), HasReferencedTuple[φ](p,t), Topics(t), HasURI[CCA3](t,o)
OCA3	conf:hasAffiliation ≡ Persons / φ, where: φ = [FK_Persons, FK_Organizations]	conf:hasAffiliation(s,o) ← Persons(p), HasURI[CCA1](p,s), HasReferencedTuple[φ](p,t), Organizations(t), HasURI[CCA6](t,o)
OCA4	vcard:ADR ≡ Organizations	vcard:ADR(s,o) ← Organizations(t), HasURI[CCA4](t,s), Organizations(t), HasURI[CCA6](t,o)
OCA5	skos:subject ≡ Papers / φ, where: φ = [FK_Papers, FK_Topics]	skos:subject(s,o) ← Papers(p), HasURI[CCA2](p,s), HasReferencedTuple[φ](p,t), Topics(t), HasURI[CCA3](t,o)
OCA6	conf:conference ≡ Papers / φ, where: φ = FK_Conferences	conf:conference(s,o) ← Papers(p), HasURI[CCA2](p,s), HasReferencedTuple[φ](p,t), Conferences(t), HasURI[CCA5](t,o)
OCA7	skos:broader ≡ Topics / φ, where: φ = FK_Parent	skos:broader(s,o) ← Topics(t), HasURI[CCA3](t,s), HasReferencedTuple[φ](t,u), Topics(u), HasURI[CCA3](u,o)
DCA1	foaf:mbox ≡ Persons / email	foaf:mbox(s,v) ← Persons(p), HasURI[CCA1](p,s), nonNull(p.email), RDFLiteral(p.email, “email”, “Persons”,v)
DCA2	foaf:name ≡ Persons / {firstName, lastName}	foaf:name(s,v) ← Persons(p), HasURI[CCA1](p,s), nonNull(p.firstName), nonNull(p.lastName), RDFLiteral(p.firstName, “firstName”, “Persons”,v1), RDFLiteral(p.lastName, “lastName”, “Persons”,v2), concat([v1,v2],v)
DCA3	rdfs:label ≡ Organizations / name	rdfs:label(s,v) ← Organizations(o), HasURI[CCA4](o,s), nonNull(o.name), RDFLiteral(o.name, “name”, “Organizations”,v)
DCA4	foaf:homepage ≡ Organizations / homepage	foaf:homepage(s,v) ← Organizations(o), HasURI[CCA4](o,s), nonNull(o.homepage), RDFLiteral(o.homepage, “homepage”, “Organizations”,v)
DCA5	vcard:street ≡ Organizations / address	vcard:street(s,v) ← Organizations(o), HasURI[CCA6](o,s), nonNull(o.address), RDFLiteral(o.address, “address”, “Organizations”,v)
DCA6	vcard:locality ≡ Organizations / location	vcard:locality(s,v) ← Organizations(o), HasURI[CCA6](o,s), nonNull(o.location), RDFLiteral(o.location, “location”, “Organizations”,v)
DCA7	vcard:pcode ≡ Organizations / postcode	vcard:pcode(s,v) ← Organizations(o), HasURI[CCA6](o,s), nonNull(o.postcode), RDFLiteral(o.postcode, “postcode”, “Organizations”,v)
DCA8	vcard:country ≡ Organizations / country	vcard:country(s,v) ← Organizations(o), HasURI[CCA6](o,s), nonNull(o. country), RDFLiteral(o.country, “country”, “Organizations”,v)
DCA9	dc:title ≡ Papers / title	dc:title(s,v) ← Papers(p), HasURI[CCA2](p,s), nonNull(p.title), RDFLiteral(p.title, “title”, “Papers”,v)
DCA10	dcterms:abstract ≡ Papers / abstract	dcterms:abstract(s,v) ← Papers(p), HasURI[CCA2](p,s), nonNull(p.abstract), RDFLiteral(p.abstract, “abstract”, “Papers”,v)
DCA11	dc:date ≡ Papers / year	dc:date(s,v) ← Papers(p), HasURI[CCA2](p,s), nonNull(p.year), RDFLiteral(p.year, “year”, “Papers”,v)
DCA12	skos:prefLabel ≡ Topics / topicName	skos:prefLabel(s,v) ← Topics(t), HasURI[CCA3](t,s), nonNull(t.topicName), RDFLiteral(t.topicName, “topicName”, “Topics”,v)
DCA13	rdfs:label ≡ Conferences / name	rdfs:label(s,v) ← Conferences(c), HasURI[CCA5](c,s), nonNull(c.name), RDFLiteral(c.name, “name”, “Conferences”,v)

 

RDF View Schema:

Figure 16 shows the exported RDF view schema ISWC RDF induced by the CAs in Table 3. The vocabulary of ISWC RDF contains all the elements of the CONF OWL ontology that match an element of ISWC REL.

Figure 16. ISWC_RDF exported view schema

 

 

Figure 17.  Rubya - exported view schema

 

 

The current state of the data source ISWC REL is that shown in Figure 18

Figure 18. ISWC REL Database State

 

Download ISWC REL Database State is available at Database_State.

View Maintenance rules:

Table 4 e 5 shows the Store Procedures and Triggers generated from tables TOPICS and Rel_Paper_Topics Table 4. Rules - table TOPICS
Table 5. Rules - table REL_PAPER_TOPICS
Relevant trigger and store procedures is available at triggers and store procedures.

Figure 19. Procedures JAVA generated

 

Using generated rules for maintenance of RDF View:

Figure 20 shows the state of view CONF_RDF which is induced by the CAs in Table 3. In Figure 20, consider the URI “http://example.com/”. The triples of the view CONF_RDF are generated by applying the transformations rules in Table 3 to the database state in Figure 18.

Figure 20. State of the view induced by the CAs in Table 3

 

 

Example 1.

Consider, for example, the insertion of the tuple into Organizations: