Онтологии, OWL, Sparql: моделирование того, что "чего-то нет" и соображения производительности

мы хотим моделировать, что "чего-то нет" в отличие от отсутствующей информации, например, явное утверждение о том, что "пациент не получил химиотерапию" или что "у пациента нет одышки" отличается от отсутствующей информации о том, есть ли у пациента одышка.

мы подумали о нескольких подходах, например

• использование класса отрицания: "No_Dyspnea". Но это кажется семантически проблематичным, так как какой тип будет этим классом? Она не может быть потомком класса "одышка".
• использование свойств объекта "не существует", например" отрицает "или" does_not_have", а затем индивидуум корневого класса одышки в качестве объекта этой тройки.

• использование пустых узлов, которые описывают, что человек принадлежит к группе вещей, которые не имеют одышки. Например:

  dat:PatientW2 a [ rdf:type owl:Class;
                owl:complementOf [
                  rdf:type owl:Restriction ;
                      owl:onProperty roo:has_finding;
                      owl:someValuesFrom nci:Dyspnea;
                ]
              ] .
  

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

мы используем Сезам с магазином OWLIM-Lite и импортировали тезаурус NCI (280 МБ, около 80 000 концепций) и другую очень маленькую онтологию в магазин и добавили двух человек, один из которых имеет этот класс дополнения/ограничения.

следующий запрос занял вечность, чтобы выполнить, и я прекратил его через 15 минут:

select *
where {
  ?s a [ rdf:type owl:Class;
                      owl:complementOf [
                        rdf:type owl:Restriction ;
                        owl:onProperty roo:has_finding;
                        owl:someValuesFrom nci:Dyspnea;
                  ]
                ] .
} Limit 100

кто-нибудь знает почему? Я предположим, что этот подход создает много пустых узлов, и механизм запросов должен пройти через весь тезаурус NCI и сравнить все пустые узлы с этим?

если я помещаю эту тройку в отдельный график и только запрашиваю этот график, запрос возвращает результат мгновенно.

подводя итоги. Два основных вопроса:--13-->

• является ли третий подход действительно лучшим для моделирования "чего-то нет"
• Is это повлияет на производительность запросов?

правка 1

мы обсудили предложенные варианты. Это действительно помогло нам прояснить, чего мы действительно пытаемся достичь:

• мы хотим иметь возможность заявить ,что" у пациента есть одышка "или" у пациента нет одышки " в определенный момент времени.

• в будущем может/будет больше информации об этом пациенте, например, что теперь у него одышка.

• мы хотим иметь возможность писать запросы Sparql, которые запрашивают "всех пациентов, у которых есть одышка" и "всех пациентов, у которых нет одышки".

• мы хотим сохранить Sparql как можно более простым и интуитивно понятным. Например. используйте только одно свойство "has_finding", а не знать о двух свойствах (один для"has_exclusion"). Или знать о каком-то сложном пустом узле строить.

мы играли с вариантами:

• Отрицательные Утверждения О Свойствах: это звучало как лучшее решение этой проблемы, так как мы заявляем, что один человек не связан с другим человеком на этой собственности. Проблемы в том, что мы должны создать человека одышки ради того, чтобы иметь что-то как owl:targetIndividual. И мы не можем найти способ легко запросить отрицательное утверждение, а затем пойти через все owl:sourceIndividual и owl:targetIndividual цепи. Что делает Sparql довольно длинным и накладывает бремя на человека, пишущего запрос, чтобы узнать об этом.

• пустой узел с complementOf: мы хотели бы заявить что-то с этим, что мы не хотим заявлять. Это было бы утверждать, что "Patient1 не можете найти диспноэ". Если мы хотим, чтобы государство "Patient1 нет одышки найти сейчас (или на дату Х)". Поэтому мы не должны использовать это подход.

• использование типов исключения / включения (Вариант 1 и 2): после более близкого взгляда предложение Джина мы считаем, что с помощью general :Exclusion и :Inclusion классы вместе только с одним свойством has_finding и предоставление человеку с одышкой типа включения/исключения является самым простым для понимания, запроса и обеспечивает достаточные способности рассуждения. Пример:

  :Patient1 a :Patient . :Dyspnea1 a :Dyspnea . :Dyspnea1 a :Exclusion. :Patient1 ex:has_finding :Dyspnea1 .

таким образом, человек написание запроса Sparql должно только знать, что:

• есть одно свойство has_finding, который представляет намерения должным образом. Поскольку" нет одышки " технически также является находкой.
• но просто запрос с помощью has_finding не даст достаточной информации о том, действительно ли человек имеет его или нет. Запрос также должен содержать тройку о том, является ли человек с одышкой a :Exclusion (или включения в зависимости от цели запрашивать.)
• хотя это накладывает некоторую дополнительную нагрузку на средство записи запросов, это меньше, чем отрицательные утверждения свойств и легче понять.

мы были бы очень признательны за некоторые отзывы об этих выводах!