Синхронизация Jena OntModels с bnodes

Question

Этот вопрос относится к вопросу rcreswick на Serializing Jena OntModel Changes. У меня есть модели Jena на двух (или более) машинах, которые должны оставаться синхронизированными по сокетам. Основная проблема, которую мне нужно решить, состоит в том, что модели могут содержать анонимные узлы (bnodes), которые могут возникнуть в любой из моделей.

Вопрос: Я нахожусь на правильном пути здесь, или есть лучший, более надежный подход, который я не считаю?

я могу думать о 3-х подходах к этой проблеме:

1. Serialize полная модель: Это слишком дорого для синхронизации небольших обновлений. Кроме того, поскольку изменения могут произойти на любой машине, я не могу просто заменить модель машины B сериализованной моделью на машине A. Мне нужно объединить их.
2. Сериализация частичной модели: Используйте специальную модель для сериализации, которая содержит только те изменения, которые необходимо отправить по сокету. Этот подход требует, чтобы специальный словарь представлял заявления, которые были удалены . Предположительно, когда я сериализую модель с машины A на машину B, анонимные идентификаторы узлов будут уникальными для машины A, но могут перекрываться с идентификаторами для анонимных узлов, созданных на машине B. Поэтому мне придется переименовать анонимные узлы и сохранить сопоставление от идентификаторов anon машины A до идентификаторов машины B, чтобы корректно обрабатывать будущие изменения.
3. Сериализация отдельных заявлений: Этот подход не требует специального словаря, но может быть не таким надежным. Есть ли проблемы, кроме анонимных узлов, которые я еще не встречал?
4. Генерировать глобально уникальные идентификаторы bnode (NEW): Мы можем генерировать глобально уникальные идентификаторы для анонимных узлов, префикс ID с уникальным идентификатором машины. К сожалению, я не понял how to tell Jena to use my ID generator вместо своего. Это позволило бы сериализовать отдельные заявления без переназначения идентификаторов bnode.

Вот пример, чтобы обсудить это обсуждение немного подробнее. Предположим, у меня есть список на машине представляемого как:

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

сериализовать эту модель из машины А в машине В. Теперь, потому что машина B может уже иметь (несвязанного) анонимный узел с идентификатором «а», я переназначить идентификатор 'а' на новый идентификатор 'Ъ':

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

Теперь список меняется на машине A:

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

Поскольку машина B никогда не сталкивался идентификатор машины А в 'б' прежде, добавляет новое отображение из машины A id 'b' на новый идентификатор 'c':

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

Проблема осложняется более чем двумя машинами. Например, если есть третий компьютер C, он может иметь собственный анонимный узел «a», который отличается от анонимного узла «a» машины A. Таким образом, машине B действительно необходимо сохранить карту от каждого из анонимных идентификаторов узлов других компьютеров до ее локальных идентификаторов, а не только от удаленных идентификаторов в целом до локальных идентификаторов. При обработке входящих изменений он должен учитывать, где были внесены изменения, чтобы правильно отображать идентификаторы.

Answer 1

Вы можете добавить свои трои в модель? Если это так, я бы представил инструкцию для каждого bnode, предоставляя каждому альтернативный общедоступный идентификатор в форме URN. Теперь вы можете начинать сопоставление bnodes между двумя моделями.

Пустые узлы или нет, хотя двухсторонняя синхронизация приведет вас к вам. Если вы пытаетесь обнаружить эквивалентные одновременные изменения на обеих моделях, стратегии, подобные этому, будут только доходить до вас.

Вот пример. Предположим, вы начинаете новую компанию по уходу за газонами. Чтобы развернуть бизнес, вы и ваш партнер заходите на местное мероприятие на открытом воздухе и пытаетесь заказать несколько дисконтированных пробных встреч. Двое из вас, каждый из которых вооружен ноутбуком, смешиваются и записывают всех, кого это интересует. Запись имеет:

address and zip 
phone number 
appointment dateTime 

Предположим, что каждая запись хранится как ресурс в вашей модели. Вы можете встретиться с мужем и вашим партнером, чтобы встретиться с женой того же самого дома. Если вы случайно заказываете ту же дату dateTime или нет, системе будет сложно снять дубликат записи. Если вы используете bnode для каждой записи или URI UUID, это не будет отменено. Единственная надежда состоит в том, что вы используете номер телефона в какой-то канонической форме для синтеза детерминированного URI для записи.