ИЛИ является законным в правилах SWRL, если выражено с использованием OWL ObjectUnionOf
.
Мне кажется, проблема в инструментальной поддержке поверхностного синтаксиса SWRL, как это показано в ваших примерах кода. Protege 3.x не поддерживает эту синтаксическую конструкцию OR (по крайней мере, в прошлый раз, когда я проверял), и хотя Protege 4.1 может ее отрендерить, он не может ее повторно обработать (только что проверил с помощью rc5). Но если вы используете недавний OWL-API (v3.2.x) и используете синтаксисы, такие как XML или синтаксис функционального стиля, все должно работать. (Обратите внимание, что Protege 3.x и 4.x используют совершенно разные OWL API, я рекомендую вам работать только с Protege 4.x и OWL-API 3.x.)
Если вы не можете заставить ИЛИ работать в SWRL, то вы можете использовать именованный класс, эквивалентный ObjectUnionOf
, например,
EquivalentClasses(my-processes, ObjectUnionOf(end-milling, drilling))
machine-tool(?mt) ^ has-process(?mt, ?p) ^ my-processes(?p)
-> my-machine-tool(?mt)
Обратите внимание, что ваш обходной путь (2-й пример кода) не дает семантически эквивалентного утверждения, потому что вы только заявляете:
SubClassOf(end-milling, my-processes)
SubClassOf(drilling, my-processes)
, что соответствует заявлению:
SubClassOf(ObjectUnionOf(end-milling, drilling), my-processes)
т.е. чтобы сформулировать эквивалентность, вам понадобится и другой вывод:
SubClassOf(my-processes, ObjectUnionOf(end-milling, drilling))
Обратите внимание, что ваше правило может быть легко выражено в OWL, т. Е. Вам не нужен SWRL для этого правила:
SubClassOf(
ObjectIntersectionOf(
:machine-tool
ObjectSomeValuesFrom(
:has-process
ObjectUnionOf(
:end-milling
:drilling
)
)
)
:my-machine-tool
)
Указание всего в OWL (если возможно) имеет некоторые преимущества, например, Вы получаете лучшую поддержку инструментов (имеется больше аргументов OWL, чем аргументов SWRL), и вы получаете более мощные аргументы (рассуждатели SWRL применяют правило только к известным людям).