2009-04-07 5 views
1

Diese Frage auf Serializing Jena OntModel Changes-rcreswick ‚s Frage bezieht. Ich habe Jena-Modelle auf zwei (oder mehr) Maschinen, die über Sockets synchronisiert bleiben müssen. Das Hauptproblem, das ich angehen muss, ist, dass die Modelle anonyme Knoten (bnodes) enthalten können, die in jedem der Modelle entstehen können.Synchronisiergerät Jena OntModels mit bnodes

Frage: Bin ich hier auf dem richtigen Weg oder gibt es einen besseren, robusteren Ansatz, den ich nicht in Betracht ziehe?

Ich kann für dieses Problem von 3 Ansätze denken:

  1. Serialize das komplette Modell: Dieses für die Synchronisierung kleine Updates unerschwinglich teuer ist. Da Änderungen an beiden Maschinen auftreten können, kann ich das Modell von Maschine B nicht einfach durch das serialisierte Modell von Maschine A ersetzen. Ich muss sie zusammenführen.
  2. Serialisieren ein Teilmodell: ein spezielles Modell für die Serialisierung verwenden, die nur die Änderungen enthält, die über die Socket gesendet werden müssen. Dieser Ansatz erfordert spezielle Vokabular Aussagen darzustellen, die aus dem Modell entfernt waren. Vermutlich, wenn ich das Modell von Maschine A Maschine B, anonymes Knoten-IDs zu Maschine A wird einzigartig serialisiert aber deshalb mit IDs für die anonymen Knoten erstellt auf Rechner B überlappen kann, werde ich auf anonyme Knoten umbenennen und eine Zuordnung halten von Maschinen A's anon ids, um B's IDs zu bearbeiten, um zukünftige Änderungen korrekt zu handhaben.
  3. Serialize einzelne Aussagen: Dieser Ansatz erfordert keine spezielle Vokabular, aber vielleicht nicht so robust sein. Gibt es andere Probleme als anonyme Knoten, die ich noch nicht kennengelernt habe?
  4. Erzeuge global eindeutige bnode-IDs (NEU): Wir können global eindeutige IDs für anonyme Knoten generieren, indem wir der ID eine eindeutige Rechner-ID voranstellen. Leider habe ich how to tell Jena to use my ID generator statt seiner eigenen nicht herausgefunden. Dies würde es uns ermöglichen, einzelne Anweisungen zu serialisieren, ohne Bnode-IDs neu zuordnen zu müssen.

Hier ist ein Beispiel, um diese Diskussion ein wenig mehr zu ergründen. Angenommen, ich habe eine Liste auf Maschine A wie folgt dargestellt:


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

ich dieses Modell von Maschine A serialisiert Nun zu Maschine B., weil Maschine B bereits eine (nicht verwandten) anonymen Knoten mit der ID ‚a‘ haben kann, ich zu id 'a' auf eine neue id 'b':


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

Nun ist die Liste Änderungen an der Maschine A:


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

Da Maschine B nie Maschine A von id 'b' zuvor begegnet ist, es Fügt eine neue Zuordnung von Maschine A hinzu id 'b' zu einem neuen id 'c':


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

Das Problem wird noch komplizierter, mit mehr als zwei Maschinen. Wenn es beispielsweise eine dritte Maschine C gibt, kann sie ihren eigenen anonymen Knoten 'a' haben, der sich von dem anonymen Knoten 'a' der Maschine A unterscheidet. Daher muss Maschine B wirklich eine Zuordnung von jeder der anonymen Knoten-IDs der anderen Maschinen zu ihren lokalen IDs halten, nicht nur von Remote-IDs im Allgemeinen zu lokalen IDs. Wenn eingehende Änderungen verarbeitet werden, muss berücksichtigt werden, woher die Änderungen stammen, um die IDs korrekt zuzuordnen.

Antwort

1

Darf man seine eigenen Tripel zum Modell hinzufügen? Wenn das der Fall ist, würde ich für jeden Knoten eine Anweisung eingeben, die jeder eine alternative öffentliche ID in Form einer URN gibt. Sie können nun mit dem Anpassen von Bnodes zwischen den beiden Modellen beginnen.

Leere Knoten oder nicht, obwohl die Zwei-Wege-Synchronisierung nur Sie so weit bringen wird. Wenn Sie versuchen, gleichwertige gleichzeitige Änderungen an beiden Modellen zu erkennen, werden Strategien wie diese Sie nur so weit bringen.

Hier ist ein Beispiel. Nehmen wir an, Sie gründen ein neues Unternehmen für Rasenpflege. Um ein Geschäft aufzubauen, gehen Sie und Ihr Partner zu einer lokalen Outdoor-Veranstaltung und versuchen, einige vergünstigte Probetermine zu buchen. Die zwei von euch, jeder mit einem Laptop bewaffnet, vermischen sich und nehmen jeden auf, der interessiert ist. Der Datensatz lautet:

Angenommen, jeder Datensatz wird als Ressource in Ihrem Modell gespeichert. Es ist möglich, dass Sie den Ehemann und Ihren Partner treffen, um die Ehefrau desselben Haushalts zu treffen. Ob Sie zufälligerweise denselben Termin dateTime buchen oder nicht, das System würde es schwer haben, den Eintrag zu duplizieren. Egal, ob Sie für jeden Datensatz einen Bnode oder einen UUID-basierten URI verwenden, er würde nicht deduplizieren. Die einzige Hoffnung ist, wenn Sie die Telefonnummer in einer kanonischen Form verwenden, um einen deterministischen URI für den Datensatz zu erstellen.

+0

Vielen Dank für Ihre Antwort! Wir haben es mit diesem Isomorphieproblem zu tun, indem wir jede Maschine auf einen bestimmten Teil der Ontologie beschränken. In Bezug auf Ihr Beispiel könnte Person A in der Kundenliste arbeiten, während Person B für die Verwaltung des Inventars verantwortlich ist. Unsere Domain verfügt außerdem über eindeutige eindeutige IDs für die relevanten Entitäten. Das Problem ist, dass Person A der Kundenliste einen Listenknoten hinzufügen könnte, der sich zufällig mit einer Bnode-ID in der Liste der Düngemittellieferanten überschneidet. –