Notre éditeur RDF

Dans ce qui suit, nous démontrons que les deux requêtes Sparql-update InsertData et DeleteData pour la suppression ou l’insertion d’un seul triplet t à partir d’un graphe G sont exclusivement commutatives. À cette fin, la commutativité de toutes les requêtes Sparql-update précédemment décrites est étudiée par paires de requêtes comme suit :

Proposition 6.1

Les couples des requêtes (DeleteInsert, DeleteData), (DeleteInsert, InsertData) et (Dele- teInsert, DeleteInsert) ne sont pas commutatifs.

Démonstration. Les contre-exemples suivants sont suffisants pour démontrer cette non commu- tativité :

DeleteInsert et DeleteData. Étant donné deux mobiles, Mobile 1 et Mobile 2, commençant une édition collaborative et concurrente à partir d’un état commun d’un graphe RDF qui contient l’ensemble des triplets : (”A”, < uri1 >, ”C”), (”A”, < uri2 >, ”B”).

Mobile 1 Mobile 2

A

Q1=Delete {?s, ?p, 'B'} Insert {"A", <uri2>, "D"} Where {"A", <uri2>, "B"}

Q2=Delete Data{"A",<uri2>,"B"} uri1 uri2 Q2=Delete Data{"A",<uri2>,"B"} C B A C B A C A C A C D A C D uri1 uri2 uri1 uri2

uri1 uri2 uri1

uri1

Q1=Delete {?s, ?p, 'B'} Insert {"A", <uri2>, "D"} Where {"A", <uri2>, "B"}

Figure 6.6 – Un contre exemple pour la commutativité des requêtes DeleteInsert et DeleteData. Comme le montre la figure 6.6, en appliquant et échangeant les deux requêtes : Q1=Dele- teInsert(Delete(?s,?p,"B") ; Insert("A",<uri2>,"D") ; Where("A",<uri2>,"B")) et Q2 =Delete- Data(("A",<uri2>,"B")), les deux mobiles finissent avec deux états conflictuels. Pourquoi cette divergence ?. Après que le Mobile 2 avait supprimé le triplet ("A", <uri2>, "B"), il reçoit la requête Q2 pour changer ce même triplet supprimé !. En effet, cette requête consiste à rem- placer le triplet concerné avec un autre (suppression suivie d’une insertion). Mais lors de la sélection de l’ensemble des triplets justifiant la condition exprimée dans la clause Where("A", <uri2>,"B") (c-à-d, s="A",p=<uri2> et o="B"), il aura un ensemble vide comme résultat de cette sélection conditionnée. C’est pour cette raison que le triplet ("A",<uri2>,"D") n’a pas pu être inséré par Mobile 2 ; les deux requêtes élémentaires DeleteData et InsertData issues de la requête DeleteInsert seront équivalentes à NO-OP.

DeleteInsert et InsertData. La figure 6.7 montre un contre-exemple pour la commutativité des requêtes DeleteInsert et InsertData. L’incohérence est due aux opérations concurrentes d’insertion et de suppression du même triplet ("A", <uri4> "D"). Le Mobile 1 commence par la suppression de tous les triplets justifiant la condition de s= "A" et reçoit ensuite une requête distante pour insérer le triplet t1= ("A", <uri4>, "D") . De son côté, le Mobile 2 commence avec

l’insertion de t1 et après, il reçoit une requête DeleteInsert ayant comme effet de supprimer tous les triplets justifiant la condition s = "A". Du fait que le Mobile 1 insère et supprime le même triplet qui n’a pas été vu par le Mobile 2 lors de l’exécution de la requête DeleteInsert, les deux mobiles vont se retrouver avec deux états conflictuels.

Mobile 1 Mobile 2 A Q1=Delete {"A",?p,?o} Insert {"A",<uri5>,"N"} Where {"A",?p,?o} Q2=Insert Data{"A",<uri4>,"D"} uri1 uri2 Q2=Insert Data{"A",<uri4>,"D"} B C A B C A D A N A N A D N uri1 uri2 uri5

uri4 uri5 uri5

uri4 B uri1 C uri2 Q1=Delete {"A",?p,?o} Insert {"A",<uri5>,"N"} Where {"A",?p,?o}

Figure 6.7 – Un contre exemple pour la commutativité des requêtes DeleteInsert et InsertData. DeleteInsert et DeleteInsert. Comme le montre la figure 6.8, les deux mobiles appliquent et échangent deux requêtes DeleteInsert pour la mise-à-jour d’un graphe partagé et finissent par deux vues incohérentes. Initialement, le Mobile 1 remplace le triplet ("A",<uri2> "B") par le triplet ("A", <uri3> "K"). Quant au Mobile 2, il remplace le même triplet avec ("A", <uri4> "M"). Après échange des deux requêtes, l’évaluation de la clause Where("A",?p,"B") donne un ensemble vide au niveau des deux mobiles. Par conséquent les requêtes Q1 et Q2 seront équivalentes à No − Op.

Proposition 6.2

Les différentes paires des requêtes Sparql-update InsertData et DeleteData, appliquées sur un graphe RDF, pour insérer ou supprimer un seul triplet sont commutatives.

Démonstration. Dans ce qui suit, nous donnons une démonstration de la commutativité de ces deux requêtes, selon les différentes paires possibles :

InsertData et InsertData. Il est à démontrer que :

Mobile 1 Mobile 2 A Q1=Delete {"A",?p,?o} Insert {"A",<uri4>,"M"} Where {"A",?p,"B"} uri1 uri2 Q2=Delete {?s,?p,?o} Insert {"A",<uri3>,"K"} Where {"A",?p,"B"} B C A B C A C M uri1 uri2 uri2 uri4 Q1=Delete {"A",?p,?o} Insert {"A",<uri4>,"M"} Where {"A",?p,"B"} Q2=Delete {?s,?p,?o} Insert {"A",<uri3>,"K"} Where {"A",?p,"B"} A K _C uri3 uri2 A K C uri3 uri2 A C M uri2 uri4

Figure 6.8 – Un contre exemple pour la commutativité d’un couple de requêtes DeleteInsert.

Pour démontrer l’équivalence de ces deux séquences, nous commençons d’un côté afin d’ob- tenir l’autre :

[InsertData(G, t1); InsertData(G, t2)] ≡ InsertData(InsertData(G, t1), t2) = InsertData(G ∪ t1, t2)

= ((G ∪ t1) ∪ t2) ∗ ∗ commutativit ´e de l0union ∗ ∗

= ((G ∪ t2) ∪ t1)

= InsertData(G ∪ t2, t1)

= InsertData(InsertData(G, t2), t1) ≡ [InsertData(G, t2); InsertData(G, t1)] InsertData et DeleteData.

Nous considérons deux cas : (i) t1 , t2 : il est à démontrer que :

[InsertData(G, t1); DeleteData(G, t2)] ≡ [DeleteData(G, t2); InsertData(G, t1)]. Démonstration :

[InsertData(G, t1); DeleteData(G, t2)] ≡ DeleteData(G ∪ {t1}, t2) ≡ {G ∪ {t1}}\{t2}

∗ ∗ A\B= A ∩ ¯B ∗ ∗ = {G ∪ {t1}} ∩ ¯{t2} ∗ ∗ distributivi´e de ∩ sur ∪ ∗∗ = {G ∩ ¯{t2}} ∪ {{t1} ∩ ¯{t2}} ∗ ∗ t1 , t2 ⇒ {t1} ∩ {t2} = ∅ ∗ ∗ = {{G ∩ ¯{t2}} ∪ {{{t1} ∩ ¯{t2}} ∪ {{t1} ∩ {t2}}}

∗ ∗ distributivit ´e de ∩ sur ∪ ∗∗

= {G ∩ ¯{t2}} ∪ {{t1} ∩ { ¯{t2} ∪ {t2}}} = {G ∩ ¯{t2}} ∪ {{t1} ∩ U}

= {G ∩ ¯{t2}} ∪ {t1} = {G\{t2}} ∪ {t1}

≡ [DeleteData(G, t2); InsertData(G, t1)] (ii) t1= t2 : Nous pouvons considérer deux autres cas élémentaires :

cas1 : t ∈ G ⇒ InsertData(G, t)= NoOp

[InsertData(G, t); DeleteData(G, t)] ≡ [NoOp; DeleteData(G, t)] ≡ [DeleteData(G, t); NoOp]

≡ [DeleteData(G, t); InsertData(G, t)] cas2 : t < G ⇒ DeleteData(G, t) = NoOp

[InsertData(G, t); DeleteData(G, t)] ≡ [InsertData(G, t); NoOp] ≡ [NoOp; InsertData(G, t)]

≡ [DeleteData(G, t); InsertData(G, t)] DeleteData et DeleteData :

Il est à démontrer que :

[DeleteData(G, t1); DeleteData(G, t2)] ≡ [DeleteData(G, t2); DeleteData(G, t1)]. Démonstration :

[DeleteData(G, t1); DeleteData(G, t2)] ≡ DeleteData(G\{t1}, t2) ≡ {G\{t1}}\{t2} ∗ ∗ A\B= A ∩ ¯B ∗ ∗ = {G\{t1}} ∩ ¯{t2} = {G ∩ ¯{t1}} ∩ {t2}¯ = G ∩ { ¯{t1} ∩ {t2}}¯ = G ∩ { ¯{t2} ∩ {t1}}¯

= {G ∩ ¯{t2}} ∩ {t1}¯ = {G\{t2}}\{t1}

≡ [DeleteData(G, t2); DeleteData(G, t1)].

La table 6.1 récapitule les résultats des démonstrations précédentes pour la commutativité des différentes paires de requêtes Sparql-update.

DeleteInsert InsertData DeleteData DeleteInsert

InsertData _{X X}

DeleteData _{X X}

Table 6.1 – Commutativité des paires de requêtes Sparql-update.

En se basant sur les démonstrations des propositions 6.1 et 6.2, nous pouvons énoncer le théorème suivant :

Theorem 6.1

Les requêtes Sparql-update InsertData(t) et DeleteData(t) sont commutatives sur un graphe RDF.

7

Synchronisation des copies RDF

Le protocole de synchronisation MobiRdf, entièrement exécuté côté clone, vise à mainte- nir la cohérence des graphes RDF partagés. Il est basé sur l’éditeur commutatif précédemment déduit et utilise un schéma de réplication optimiste afin de permettre un accès concurrent aux différents répliques des graphes RDF partagés sur les mobiles et leurs clones. Cependant, cette synchronisation conduite par un éditeur Sparql-update commutatif, qui est exclusivement basée sur les deux requêtes commutatives InsertData(t) et DeleteData(t), n’empêche pas les utilisa- teurs d’exécuter toutes les autres requêtes. En effet, chaque requête appliquée côté mobile sera décomposée (par le clone correspondant) en un ensemble de requêtes commutatives qui vont être appliquées et diffusées vers les autres clones.

La commutativité assure la cohérence syntaxique d’une manière simple. Toutefois, le clone fait appel à des moteurs de raisonnement afin de maintenir la cohérence des relations séman- tiques des données RDF. Ainsi cet appel permet de :

(i) Déduire les relations de dépendance entre les requêtes.

(ii) Optimiser les requêtes utilisateurs. Par exemple, si un mobile génère deux requêtes In- sertData(t)et DeleteData(t) pour insérer et supprimer le même triplet, ces deux requêtes seront ignorées par le clone.

(iii) Déduire les effets secondaires des requêtes appliquées, c-à-d, inférer de nouveaux tri- plets suite à une insertion d’un triplet ou supprimer des triplets dépendants d’un autre triplet suite à sa suppression.

Notre mécanisme de synchronisation favorise une gestion optimale même en matière de consommation des ressources cloud. En effet, après diffusion des requêtes par un clone, les autres clones procèderont à leur intégration sans application des processus de raisonnement.