Хорст (pD*) по сравнению с OWL2-RL

Брилл, внутри GraphDB есть единый механизм правил, который поддерживает разные профили рассуждений, в зависимости от выбранного набора правил. Предопределенные наборы правил являются частью дистрибутива — посмотрите файлы PIE в папке configs/rules. Также можно взять один из существующих профилей и адаптировать его под свои нужды (например, удалить правило, которое не нужно).

Фундаментальное различие между OWL2 RL и тем, что мы называем OWL-Horst (pD*), заключается в том, что OWL2RL раздвигает границы того, какие конструкции OWL могут поддерживаться с использованием этого типа правил следования. OWL Horst ограничен RDFS (subClassOf, subSpropertyOf, домен и диапазон) плюс то, что было популярно в прошлом как OWL Lite: sameAs, эквивалентный класс, эквивалентное свойство, симметричное свойство, переходное свойство, обратное значение, функциональное свойство, обратное функциональное свойство. Также есть частичная поддержка: crossoverOf, someValuesFrom, hasValue, allValuesFrom.

В дополнение к этому OWL 2 RL добавляет поддержку AsymmetricProperty, IrreflexiveProperty, propertyChainAxiom, AllDisjointProperties, hasKey, unionOf, AdditionalOf, oneOf, DifferentFrom, AllDisjointClasses и всех примитивов кардинальности свойств. Он также добавляет более полную поддержку для пересеченияOf, someValuesFrom, hasValue, allValuesFrom. Имейте в виду, что существуют ограничения на вывод, поддерживаемый OWL 2 RL для некоторых из этих свойств, например. какие типы выводов следует или не следует делать для определенных выражений класса (ограничения OWL). Если вы выбрали OWL 2 RL, проверьте Таблицы 5-8 в спецификации, https://www.w3.org/TR/owl2-profiles/#OWL_2_RL. Набор данных GraphDB owl-2-rl полностью ему соответствует. GraphDB — единственный крупный тройной магазин с полным соответствием OWL 2 RL — см. эту таблицу (https://www.w3.org/2001/sw/wiki/OWL/Implementations) он появляется под своим прежним названием OWLIM.

Мое предложение состояло бы в том, чтобы использовать OWL Horst для большого набора данных, так как рассуждение с OWL 2 RL может быть намного медленнее. Это зависит от вашей онтологии и шаблонов данных, но, как правило, вы можете ожидать, что загрузка/обновления будут в 2 раза медленнее с OWL 2 RL, даже если вы не используете широко его дорогостоящие примитивы (например, цепочки свойств). Посмотрите разницу между скоростями загрузки при тестировании RDFS+ и OWL 2 RL здесь: http://graphdb.ontotext.com/documentation/standard/benchmark.html

Наконец, я бы порекомендовал вам использовать оптимизированные версии предварительно определенных наборов правил. Эти версии исключают некоторые правила рассуждений RDFS, которые бесполезны для большинства приложений, но добавляют существенные накладные расходы на рассуждения, например. тот, который делает вывод, что субъект, предикат и объект утверждения являются экземплярами rdfs:Resource

Id: rdf1_rdfs4a_4b 
     x  a  y
    -------------------------------
     x  <rdf:type>  <rdfs:Resource>
     a  <rdf:type>  <rdfs:Resource>
     y  <rdf:type>  <rdfs:Resource>

Если вы хотите оставаться на 100% совместимым со спецификацией W3C, вам следует использовать неоптимизированные версии.

Если вам нужна дополнительная помощь, напишите на [email protected]

В дополнение к тому, что написал Атанас (наш генеральный директор) и вашему прекрасному примеру, http://graphdb.ontotext.com/documentation/enterprise/rules-optimisations.html приведены некоторые идеи о том, как оптимизировать наборы правил, чтобы сделать их быстрее.

Две идеи:

• ptop:transitiveOver быстрее, чем owl:TransitiveProperty: квадратичная и кубическая сложность по длине транзитивных цепочек
• ptop:PropChain (цепочка из 2-х мест) быстрее, чем обычная owl:propertyChainAxiom (цепочка из n-мест), потому что не нужно разворачивать rdf:List, лежащий в основе представления owl:propertyChainAxiom.

При некоторых условиях вы можете преобразовать стандартные конструкции OWL в эти пользовательские конструкции, чтобы обеспечить оба соответствие стандартам и более высокую скорость:

• использовать правило TransitiveUsingStep; если каждое TransitiveProperty p (например, skos:broaderTransitive) определено в свойстве шага s (например, skos:broader) и вы не вставляете p напрямую
• если вы используете только двухэтапные owl:propertyChainAxiom, то преобразуйте их в пользовательские, используя следующее правило, и сделайте вывод, используя правило ptop_PropChain:

Id: ptop_PropChain_from_propertyChainAxiom
  q <owl:propertyChainAxiom> l1
  l1 <rdf:first> p1
  l1 <rdf:rest> l2
  l2 <rdf:first> p2
  l2 <rdf:rest> <rdf:nil>
  ----------------------
  t <ptop:premise1>   p1
  t <ptop:premise2>   p2
  t <ptop:conclusion> q
  t <rdf:type> <ptop:PropChain>

http://rawgit2.com/VladimirAlexiev/my/master/pubs/extending-owl2/index.html описывает дополнительные идеи для конструкций расширенных свойств и содержит иллюстрации.

Дайте нам знать, если мы можем помочь дальше.

Немного подумав, я придумал конкретный пример. Онтология здоровья полости рта и заболеваний (http://purl.obolibrary.org/obo/ohd.owl) содержит три взаимосвязанных объекта:

• восстановленный зуб
• восстановленная поверхность зуба, являющаяся частью восстановленного зуба
• процедура восстановления зуба, которая создает восстановленную поверхность зуба (например, когда в зуб помещается пломба)

Аксиомы, которые определяют эти объекты (с использованием псевдоманчестерского синтаксиса):

restored tooth equivalent to Tooth and has part some dental restoration material
restored tooth surface subclass of part of restored tooth
filling procedure has specified output some restored tooth surface

Отношение has specified output является подсвойством отношения has participant, а отношение has participant содержит цепочку свойств:

has_specified_input o 'is part of'

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

В качестве конкретного примера давайте определим некоторых людей (используя псевдо rdf):

:patient#1 a :patient .
:tooth#1 a :tooth; :part-of :patient#1
:restored-occlusal#1 a :restored-occlusal-surface; :part-of tooth#1 .
:procedure#1 :has-specified-output :restored-occlusal#1 .

Предположим, вы хотите запросить все восстановленные зубы:

select ?tooth where {?tooth a :restored-tooth}

Рассуждения RDFS-Plus не найдут восстановленных зубов, потому что они не обрабатывают эквивалентные классы. Но OWL-Horst и OWL2-RL найдут такие зубы.

Теперь предположим, что вы хотите найти всех пациентов, которые подверглись (т.е. участвовали) в процедуре восстановления зубов:

select ?patient where {
    ?patient a patient: .
    ?proc a tooth_restoration_procedure:; has_participant: ?patient .
}

Опять же, RDFS-Plus не найдет пациентов, как и OWL-Horst, потому что этот вывод требует рассуждений о цепочке свойств has participant. OWL2-RL необходим, чтобы сделать этот вывод.

Я надеюсь, что этот пример будет полезен заинтересованному читателю :).

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