Синхронизация Jena OntModels с bnodes - PullRequest
Новая
       14

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

1 голос
/ 08 апреля 2009

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

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

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

  1. Сериализация полной модели : Это слишком дорого для синхронизации небольших обновлений. Кроме того, поскольку изменения могут происходить на любой машине, я не могу просто заменить модель машины B на сериализованную модель из машины A. Мне нужно объединить их.
  2. Сериализация частичной модели : Используйте выделенную модель для сериализации, которая содержит только те изменения, которые необходимо отправить через сокет. Этот подход требует специального словаря для представления операторов, которые были удалены из модели. Предположительно, когда я сериализую модель с машины A на машину B, идентификаторы анонимных узлов будут уникальными для машины A, но могут совпадать с идентификаторами для анонимных узлов, созданных на машине B. Поэтому мне придется переименовывать анонимные узлы и сохранять сопоставление от идентификаторов машины А к идентификаторам машины В для правильной обработки будущих изменений.
  3. Сериализация отдельных высказываний : Этот подход не требует специального словарного запаса, но может быть и не таким надежным. Есть ли другие проблемы, кроме анонимных узлов, с которыми я еще не сталкивался?
  4. Создание глобально уникальных идентификаторов bnode (NEW) : Мы можем генерировать глобально уникальные идентификаторы для анонимных узлов, добавляя префикс 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». Таким образом, машина B действительно должна хранить карту от идентификаторов анонимных узлов каждого другого компьютера с его локальными идентификаторами, а не только от удаленных идентификаторов в целом с локальными идентификаторами. При обработке входящих изменений необходимо учитывать, откуда произошли изменения, для правильного сопоставления идентификаторов.

1 Ответ

1 голос
/ 11 апреля 2009

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

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

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

address and zip
phone number
appointment dateTime

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

...