Синхронизация Jena OntModels с бнодами

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

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

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

  1. Сериализировать всю модель: это непомерно дорого для синхронизации небольших обновлений. Кроме того, поскольку изменения могут происходить на любой машине, я не могу просто заменить модель машины B сериализованной моделью машины A. Мне нужно их объединить.
  2. Сериализация частичной модели. Используйте выделенную модель для сериализации, которая содержит только те изменения, которые необходимо отправить через сокет. Этот подход требует специальной лексики для представления утверждений, которые были удалены из модели. Предположительно, когда я сериализую модель с машины A на машину B, идентификаторы анонимных узлов будут уникальными для машины A, но могут перекрываться с идентификаторами анонимных узлов, созданных на машине B. Поэтому мне придется переименовать анонимные узлы и сохранить сопоставление. из анонимных идентификаторов машины А в идентификаторы машины Б, чтобы правильно обрабатывать будущие изменения.
  3. Сериализация отдельных операторов: этот подход не требует специальной лексики, но может быть не таким надежным. Есть ли проблемы, кроме анонимных узлов, с которыми я еще не сталкивался?
  4. Создание глобально уникальных идентификаторов bnode (НОВИНКА). Мы можем создавать глобально уникальные идентификаторы для анонимных узлов, добавляя к идентификатору префикс с уникальным идентификатором машины. К сожалению, я не понял, как сказать Jena использовать мой генератор ID вместо своего своя. Это позволило бы нам сериализовать отдельные операторы без переназначения идентификаторов bnode.

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


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

Я сериализую эту модель с машины A на машину B. Теперь, поскольку у машины B уже может быть (несвязанный) анонимный узел с идентификатором «a», я переназначаю идентификатор «a» на новый идентификатор «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 никогда раньше не сталкивалась с идентификатором «b» машины A, она добавляет новое сопоставление идентификатора «b» машины A с новым идентификатором «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 действительно необходимо сохранять сопоставление идентификаторов анонимных узлов каждой другой машины с ее локальными идентификаторами, а не только удаленных идентификаторов в целом с локальными идентификаторами. При обработке входящих изменений он должен учитывать, откуда пришли изменения, чтобы правильно сопоставить идентификаторы.


java serialization ontology jena
person Aaron Novstrup    schedule 07.04.2009    source источник

Ответы (1)


arrow_upward
1
arrow_downward

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

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

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

address and zip
phone number
appointment dateTime

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

person Dilum Ranatunga    schedule 11.04.2009
comment
Спасибо за ваш ответ! Мы решаем эту проблему изоморфизма, ограничивая каждую машину определенной частью онтологии. Возвращаясь к вашему примеру, человек А может работать со списком клиентов, а человек Б отвечает за управление запасами. Наш домен также имеет четко определенные уникальные идентификаторы для соответствующих объектов. Проблема в том, что человек А может добавить узел списка в список клиентов, который совпадает с идентификатором узла в списке поставщиков удобрений. - person Aaron Novstrup; 20.04.2009