Ограничение SPIN с использованием CONSTRUCT: куда идут тройки CONSTRUCT?

Я использую TopBraid Composer Free Edition (5.1.3) для создания онтологий, включая ограничения SPIN. Затем я загружаю полученные файлы RDF в RDF4J (2.0.1) и использую RDF4J Workbench для тестирования.

Я работаю над ограничениями SPIN. Вот пример проверки неотрицательных скоростей сигнала, который я добавил в класс CRO2:SignalRate:

CONSTRUCT {
  ?this soo:hasConstraintViolation _:b0 .
  _:b0 a spin:ConstraintViolation .
  _:b0 rdfs:label "Non-Positive SignalRate" .
  _:b0 spin:violationRoot ?this .
  _:b0 spin:violationPath Nuvio:hasDataValue .
  _:b0 spin:violationLevel spin:Warning .
}
WHERE {
    ?this Nuvio:hasDataValue ?signalRate .
    FILTER (?signalRate <= 0.0) .
}

Итак, я тестирую это ограничение в рабочей среде RDF4J, используя следующий запрос на обновление SPARQL:

PREFIX inst: <http://www.disa.mil/dso/a2i/ontologies/PBSM/Sharing/Instantiations#>
PREFIX Nuvio: <http://cogradio.org/ont/Nuvio.owl#>
PREFIX CRO2: <http://cogradio.org/ont/CRO2.owl#>

INSERT DATA {
  inst:aSignalRate_test a CRO2:SignalRate ;
    Nuvio:hasDataValue "-10"^^xsd:long .
}

Этот тестовый момент нарушает указанное выше ограничение. Если я опускаю тройку spin:violationLevel и разрешаю использовать по умолчанию spin:Error, то я получаю сообщение об ошибке из запроса, и тестовый экземпляр не утверждается, как ожидалось. При выполнении, как показано, нарушением ограничения является spin:Warning, поэтому создается индивидуум inst:aSignalRate_test со значением данных -10,0. Мой вопрос: куда идут утверждения в пункте CONSTRUCT ограничения? Я полагаю, что они утверждаются, поскольку изменение в spin:violationLevel влияет на поведение. Обратите внимание, что я пытался связать пустой узел со своим собственным свойством soo:hasConstraintViolation, но это не сработало. Утверждены ли тройки CONSTRUCT в каком-то другом контексте/графе? Я просто использую график по умолчанию для всего.

Я ищу ожидаемые тройки как с помощью RDF4J Workbench Explore, так и с использованием запросов SPARQL. Например, следующий запрос ничего не возвращает после подтверждения моего ошибочного CRO2:SignalRate:

PREFIX spin: <http://spinrdf.org/spin#>

SELECT DISTINCT *
WHERE {
    ?s spin:violationRoot ?o .
}

Это поведение соответствует утверждению в TopBraid Composer FE и RDF4J Workbench.

Моя цель — найти и использовать диагностические сообщения, выдаваемые в случае нарушения ограничений SPIN, желательно с помощью запросов SPARQL для поиска таких диагностических сообщений. Кажется разумным. Я что-то упускаю.

Спасибо.


sparql owl rdf4j topbraid-composer spin-rdf
person Greg Cox    schedule 30.11.2016    source источник

Ответы (2)


arrow_upward
2
arrow_downward

Короткий ответ: вы не можете.

Ограничения SPIN предназначены для обнаружения нарушений и сообщения о них. В RDF4J таким механизмом отчетности является журнал.

Соответствующая часть спецификации SPIN (http://spinrdf.org/spin.html#spin-constraints):

[...] если ограничение ASK оценивается как истинное для одного экземпляра, то этот экземпляр нарушает условие. Дополнительно запросы CONSTRUCT могут создавать экземпляры класса spin:ConstraintViolation, предоставляющие сведения о конкретном нарушении.

Обратите внимание, что от логического оператора не требуется что-либо делать с данными, создаваемыми ограничением на основе CONSTRUCT, — это просто необязательная «дополнительная информация».

Возможно, стоит посмотреть, можем ли мы добавить усовершенствование в средство рассуждений, чтобы сообщать о таких триплетах в той или иной форме, но в текущей системе только правила SPIN (использующие DELETE/INSERT и т. д.) изменяют базу данных. .

person Jeen Broekstra    schedule 01.12.2016
comment
Хорошо, я могу переключиться на реализацию своих ограничений в виде конструкторов. Я делал это в прошлом. Конструкторы вызываются, когда утверждается связанный класс, и когда конструкторы срабатывают, их утверждения попадают в видимое тройное хранилище, видимое для последующих запросов. Недостатком является то, что серьезные ошибки не блокируют утверждение класса, как это было бы в случае спина:фатальная или спина:ошибка с ограничениями. Мне нужно тщательно подумать о том, как защитить последующие правила от неверных данных (например, отрицательный CRO2:SignalRate). DELETE может быть ядром решения. - person Greg Cox; 01.12.2016
comment
@GregCox Я упомянул об этом, прежде чем подумать, но не стесняйтесь регистрировать запрос функции с помощью RDF4J. Резонер SPIN официально все еще находится в стадии бета-тестирования, и мы наверняка упустили из виду варианты использования при выборе дизайна. - person Jeen Broekstra; 01.12.2016

arrow_upward
1
arrow_downward

Итак, следуя комментариям @JeenBroekstra и моему ответному комментарию выше, я переключился на использование конструкторов, чтобы информация об ошибке оставалась в виде видимых артефактов. Я создал несколько собственных подсвойств spin:constructor, чтобы поддерживать порядок. Я также указал порядок выполнения этих конструкторов, чтобы эти проверки выполнялись раньше других правил, которые могут быть отключены (например, из-за отрицательной скорости сигнала).

Преимущества этого подхода:

  • Артефакты сведений об ошибках (например, spin:violationRoot) остаются видимыми в тройном хранилище. Это очень важно в моем приложении, которое включает межмашинное взаимодействие.
  • Все проверки соответствия выполнены, поэтому человек с несколькими проблемами перечисляет все проблемы как отдельные свойства hasConstraintViolation, а не только первое нарушение для блокировки создания экземпляра.

Недостатки этого подхода:

  • Заблудший индивидуум все еще создается.
  • Это нестандартное поведение, поэтому инструменты, предназначенные для поиска артефактов ограничений в журналах, вероятно, не найдут их.

Вот скриншот примера правила, реализованного как подсвойство spin:constructor:

введите здесь описание изображения

person Greg Cox    schedule 02.12.2016