Synchronisation de Jena OntModels avec bnodes

Question

Cette question concerne la question de rcreswick sur Serializing Jena OntModel Changes. J'ai des modèles Iéna sur deux machines (ou plus) qui doivent rester synchronisées sur les sockets. Le problème principal que je dois résoudre est que les modèles peuvent contenir des nœuds anonymes (bnodes), qui peuvent provenir de n'importe lequel des modèles.

Question: Suis-je sur la bonne voie ici, ou y a-t-il une approche meilleure et plus robuste que je ne prends pas en compte?

je peux penser à 3 approches de ce problème:

1. sérialisation le modèle complet: Ce coût est prohibitif pour la synchronisation de petites mises à jour. En outre, comme les modifications peuvent se produire sur les deux machines, je ne peux pas simplement remplacer le modèle de la machine B par le modèle sérialisé de la machine A. Je dois les fusionner.
2. Sérialiser un modèle partiel: Utilisez un modèle dédié à la sérialisation qui contient uniquement les modifications à envoyer sur le socket. Cette approche nécessite un vocabulaire spécial pour représenter les instructions supprimées du modèle. Vraisemblablement, quand je sérialise le modèle de la machine A à la machine B, les identifiants de nœuds anonymes seront uniques à la machine A mais peuvent chevaucher les ID des nœuds anonymes créés sur la machine B. Par conséquent, je vais devoir renommer les nœuds anonymes de l'identifiant de la machine A à l'identifiant de la machine B afin de gérer correctement les futurs changements.
3. Sérialiser des instructions individuelles: Cette approche ne nécessite aucun vocabulaire particulier, mais peut ne pas être aussi robuste. Y a-t-il d'autres problèmes que les nœuds anonymes que je n'ai pas encore rencontrés?
4. Générer des ID de noeud uniques au niveau mondial (NOUVEAU): Nous pouvons générer des ID uniques globaux pour des noeuds anonymes en préfixant l'ID avec un ID de machine unique. Malheureusement, je n'ai pas compris how to tell Jena to use my ID generator au lieu de la sienne. Cela nous permettrait de sérialiser les instructions individuelles sans remapper les identifiants de bnode.

Voici un exemple pour étayer un peu plus cette discussion. Supposons que j'ai une liste sur la machine A représentée comme:

    _:a rdf:first myns:tom 
    _:a rdf:rest rdf:nil 

Je sérialiser ce modèle de la machine A à la machine B. Maintenant, parce que la machine B peut déjà avoir un (indépendant), nœud anonyme avec id « a », je remapper id 'a' à un nouveau id 'b':

    _:b rdf:first myns:tom 
    _:b rdf:rest rdf:nil 

maintenant, la liste change sur la machine a:

    _:a rdf:first myns:tom 
    _:a rdf:rest _:b 
    _:b rdf:first myns:dick 
    _:b rdf:rest rdf:nil 

Depuis la machine b n'a jamais la machine a rencontré un id de 'b' avant, il ajoute un nouveau mappage à partir de la machine A id 'b' à un nouvel identifiant 'c':

    _:b rdf:first myns:tom 
    _:b rdf:rest _:c 
    _:c rdf:first myns:dick 
    _:c rdf:rest rdf:nil 

Le problème est encore compliqué avec plus de deux machines. S'il y a une troisième machine C, par exemple, elle peut avoir son propre noeud anonyme 'a' qui est différent du noeud anonyme 'a' de la machine A. Ainsi, la machine B a vraiment besoin de conserver une carte des identifiants de nœud anonymes des autres machines à ses ID locaux, et pas seulement des ID distants en général aux ID locaux. Lors du traitement des modifications entrantes, il faut tenir compte de l'origine des modifications pour mapper correctement les identifiants.

Answer 1

Etes-vous autorisé à ajouter vos propres triplets au modèle? Si c'est le cas, j'introduirais une déclaration pour chaque nœud, en donnant à chacun un identifiant public alternatif sous la forme d'un URN. Vous pouvez maintenant commencer à faire correspondre des bnodes entre les deux modèles.

Les nœuds vierges ou non, cependant, la synchronisation bidirectionnelle vous mènera seulement si loin. Si vous essayez de détecter des changements simultanés équivalents sur les deux modèles, des stratégies comme celle-ci ne vous mèneront pas loin.

Voici un exemple. Disons que vous démarrez une nouvelle entreprise d'entretien des pelouses. Afin de créer quelques affaires, vous et votre partenaire allez à un événement en plein air local, et essayez de réserver des rendez-vous d'essai à prix réduit. Les deux d'entre vous, chacun armé d'un ordinateur portable, se mêlent et enregistrent toute personne intéressée. L'enregistrement est a:

address and zip 
phone number 
appointment dateTime 

Supposons que chaque enregistrement soit stocké en tant que ressource dans votre modèle. Il est possible pour vous de rencontrer le mari, et votre partenaire pour rencontrer la femme du même ménage. Que vous coïncidiez la même date de rendez-vous ou non, le système aurait du mal à dédupliquer l'entrée. Que vous utilisiez un noeud binaire pour chaque enregistrement ou un URI basé sur UUID, il ne serait pas dé-dupé. Le seul espoir est si vous utilisez dites le numéro de téléphone sous une forme canonique pour synthétiser un URI déterministe pour l'enregistrement.