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

Question

Я использую 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 в каком-то другом контексте / графе? Я просто использую default/graph для всего.

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

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

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

Это поведение согласуется между утверждением в TopBraid Composer FE и RDF4J Workbench.

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

Благодарю.

Answer 1

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

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

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

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

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

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

Answer 2

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

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

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

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

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

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