как я могу распознать свойства объекта и свойства типа данных?

О свойствах объекта и типа данных

В Protégé есть разные вкладки для создания свойств объекта и свойств типа данных. Если свойство должно связывать индивидов с индивидами, тогда оно должно быть свойством объекта, а если оно связывает индивидов с литералами, тогда оно должно быть свойством типа данных.

Если у вас есть свойство hasEdition, домен которого Book, тогда возникает вопрос, каким должен быть диапазон. Если вы ожидаете троек вроде:

Book72 hasEdition "1"^^xsd:int
Book16 hasEdition "3"^^xsd:int

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

Edition a owl:Class .
first a Edition .
second a Edition .
third a Edition .
…

так что вы можете иметь

Book72 hasEdition first .
Book16 hasEdition third .

тогда hasEdition должно быть свойством объекта.

Если вам нужно взглянуть на сериализацию RDF и определить, к каким типам относятся свойства, вы должны запросить классы owl:ObjectProperty и owl:DatatypeProperty (и, для полноты, owl:AnnotationProperty). То есть, в зависимости от того, является ли hasEdition свойством объекта или свойством типа данных, вы увидите:

hasEdition a owl:ObjectProperty .

or

hasEdition a owl:DatatypeProperty .

Решаем, что использовать

То, хотите ли вы, чтобы свойство hasEdition было свойством типа данных или свойством объекта, на самом деле зависит от того, какие данные вы собираетесь хранить, а это зависит от вашего приложения. Если вы просто представляете простую информацию, такую ​​как "first", "second" и т. Д., Тогда вы, вероятно, захотите использовать свойство типа данных, которое связывает книгу с ее изданием. Это, вероятно, хороший вариант, если вы представляете книги в абстрактном виде, т. Е. Не отдельные экземпляры книг (в отличие от системы инвентаря продавца книг, которая будет иметь дело с отдельными экземплярами книг) .

С другой стороны, если вы на самом деле представляете экземпляры книг. Например, если вы продавец книг и имеете в наличии 25 копий Semantic Web для рабочего онтолога и 27 копий Programming the Semantic Web), то вас может заинтересовать представление отдельных изданий книг на название, ISBN и т. д., вероятно, будут храниться в издании, а не в отдельной книге.

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

Пример последствий выбора того или другого

Предлагаю вам ознакомиться с RDF Primer. Ресурсы и литералы - разные типы вещей. Ресурсы анонимны или идентифицируются IRI и могут быть объектами утверждений (и, таким образом, входить в классы в силу утверждения

@prefix lib: <http://example.org/library/> .

lib:HermanMelville rdf:type lib:Author .

Литералы, такие как строка "Herman Melville ", не могут быть субъектами предложений и, следовательно, не могут быть членами классов. С авторами в качестве ресурсов (отдельных лиц) вы можете делать

lib:MobyDick lib:hasAuthor lib:HermanMelville .
lib:HermanMelville  lib:hasName "HermanMelville"@en .

В этом случае hasAuthor - это свойство объекта, а hasName - свойство типа данных.

С другой стороны, вы можете сделать hasAuthor свойством типа данных и вместо этого сделать

lib:MobyDick lib:hasAuthor "Herman Melville"@en .

Однако если вы это сделаете, у вас не будет удобного способа добавить дополнительную информацию об авторе, поскольку литерал "Herman Melville"@en не может быть предметом тройки, поэтому вы не можете, например, сказать

"Herman Melville"@en places:livedAt places:Arrowhead .

тогда как в первом случае вы могли бы сказать

lib:HermanMelville places:livedAt places:Arrowhead .

На самом деле это просто вопрос того, как вы хотите иметь возможность запрашивать свои данные. В случае, если hasAuthor является свойством объекта, я могу написать такой запрос, чтобы найти книги, написанные авторами, жившими в Arrowhead:

PREFIX lib: <http://...>
PREFIX places: <http//...>

SELECT ?book WHERE { 
  ?book lib:hasAuthor ?author .
  ?author places:livedAt places:Arrowhead .
}

или даже более кратко (но эквивалентно):

PREFIX lib: <http://...>
PREFIX places: <http//...>

SELECT ?book WHERE { 
  ?book lib:hasAuthor [ places:livedAt places:Arrowhead ] .
}

С другой стороны, если hasAuthor является свойством типа данных, которое связывает книгу с именем ее автора, у нас все еще может быть класс Author, экземпляры которого связаны с их именами с помощью свойства hasName, но это немного усложняет запрос данных. , так как свойство hasAuthor заставляет слой косвенного обращения (получить имя автора книги, а затем найти автора, у которого есть это имя), поэтому у нас есть такие запросы, как:

PREFIX lib: <http://...>
PREFIX places: <http//...>

SELECT ?book WHERE { 
  ?book lib:hasAuthor ?authorName .
  ?author lib:hasName ?authorName .
  ?author places:livedAt places:Arrowhead .
}

Этот запрос нельзя так упростить. На самом деле все сводится к тому, как вы хотите иметь возможность запрашивать данные и что вам удобно. Обратите внимание, что некоторые запросы, которые вы можете написать на SPARQL, намного сложнее написать как выражения OWL DL. Когда hasAuthor является свойством объекта, класс книг, авторы которых жили в Arrowhead, задается выражением:

lib:hasAuthor (places:livedAt value places:Arrowhead)

который просто является классом вещей, автор которого жил в Arrowhead. Если hasAuthor является свойством типа данных, написать такое выражение гораздо сложнее, если не невозможно, потому что вам нужно найти две вещи (книгу и автора), которые имеют одинаковое буквальное значение (строка, которая является именем автора ).