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

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

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

Спасибо.

источник

2016-11-30 Greg Cox

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

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

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

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

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

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

источник

2016-12-01 06:19:52

ОК, я могу перейти к реализации своих ограничений в конструкторах. Я делал это в прошлом. Конструкторы вызываются, когда ассоциированный класс утверждается, и когда конструкторы срабатывают, их утверждения делают его видимым трехмерным хранилищем - видимым для последующих запросов. Недостатком является то, что серьезные ошибки не блокируют утверждение класса, как для спина: Fatal или spin: ошибка с ограничениями. Мне нужно будет тщательно подумать о том, как защитить последующие правила от неудобства при плохих данных (например, отрицательный CRO2: SignalRate). DELETE может быть ядром решения. –

@GregCox Я упомянул об этом раньше, чем я думаю, но не стесняйтесь регистрировать запрос функции с помощью RDF4J. Учредитель SPIN официально все еще находится в стадии бета-тестирования, и мы должны упускать из виду варианты использования при выборе дизайна. –

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

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

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

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

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

Вот снимок экрана примера правило, реализованные в виде Подствойства спина: конструктор:

источник

2016-12-02 13:00:13

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

ответ

Смежные вопросы