Object Properties and Data Type
Protégé has various tabs for creating object properties and data type properties. If the property should be related to individuals, then it should be an object property, and if it connects individuals with literals, then this should be a data type property.
If you have a hasEdition property whose domain is Book , then the question becomes what the range should be. If you expect triples, for example:
Book72 hasEdition "1"^^xsd:int Book16 hasEdition "3"^^xsd:int
where value is a literal, then hasEdition must be a data type property. If, on the other hand, you have an Edition class with some specific individuals, for example,
Edition a owl:Class . first a Edition . second a Edition . third a Edition . …
so you can
Book72 hasEdition first . Book16 hasEdition third .
then hasEdition should be a property of the object.
If you need to look at the serialization of RDF and determine which types are properties, you should request the owl:ObjectProperty and owl:DatatypeProperty classes (and, for the sake of completeness, owl:AnnotationProperty ). That is, depending on whether the hasEdition property of an object or a property of a data type, which you will see:
hasEdition a owl:ObjectProperty .
or
hasEdition a owl:DatatypeProperty .
Deciding what to use
Whether you want the hasEdition property to be a datatype property or an object property really depends on what data you are going to store, and it depends on your application. If you simply present simple information like "first" , "second" , etc., then you probably want to use a data type property that links the book to its publication. This is probably a good route if you present books in an abstract way, that is, not individual copies of books (as opposed to an inventory system for booksellers that will deal with individual copies of books).
If, on the other hand, what you actually represent are copies of books. For example, if you are a seller of books and have 25 copies of the Semantic Web available for a working ontologist and 27 copies of Programming the semantic Web ), then it may really be interesting for you to submit separate editions of books on which the title, ISBN, etc. will be kept by the publisher, not a separate book.
This is just an opinion, and you really have a lot of flexibility in choosing your data model. Getting good data models usually requires some experience, and experience takes time. However, you have good tools for manipulating and transforming data, so you can experiment with different views and map them to each other.
An example of the consequences of choosing one or the other
I suggest you take a look at the RDF Primer . Resources and literals are different types of things. Resources are anonymous or identified by the IRI and may be subject to claims (and thus be members of classes, by virtue of the statement
@prefix lib: <http://example.org/library/> . lib:HermanMelville rdf:type lib:Author .
Literals, such as the string "Herman Melville ", cannot be subjects of sentences and therefore cannot be members of classes. With authors as resources (individuals) you can do
lib:MobyDick lib:hasAuthor lib:HermanMelville . lib:HermanMelville lib:hasName "HermanMelville"@en .
In this case, hasAuthor is a property of the object, and hasName is a property of the data type.
Alternatively, you can make the hasAuthor a datatype property and instead do
lib:MobyDick lib:hasAuthor "Herman Melville"@en .
If you do this, then you do not have a convenient way to add additional information about the author, since the literal "Herman Melville"@en cannot be the subject of a triple, therefore you cannot, for example, say
"Herman Melville"@en places:livedAt places:Arrowhead .
whereas in the first case you could say
lib:HermanMelville places:livedAt places:Arrowhead .
It really is a question of how you want to be able to request your data. In the case where hasAuthor is a property of an object, I can write such a query to find books written by authors who lived in Arrowhead:
PREFIX lib: <http://...> PREFIX places: <http//...> SELECT ?book WHERE { ?book lib:hasAuthor ?author . ?author places:livedAt places:Arrowhead . }
or even more succinctly (but equivalently):
PREFIX lib: <http://...> PREFIX places: <http//...> SELECT ?book WHERE { ?book lib:hasAuthor [ places:livedAt places:Arrowhead ] . }
On the other hand, if hasAuthor is a data type property that associates a book with its author’s name, we can still have an Author class whose instances are associated with their names with the hasName property, but it makes querying the data more complicated because the hasAuthor property forces the layer indirectness (get the name of the author of the book, then find the author who has this name), so we have such requests as:
PREFIX lib: <http://...> PREFIX places: <http//...> SELECT ?book WHERE { ?book lib:hasAuthor ?authorName . ?author lib:hasName ?authorName . ?author places:livedAt places:Arrowhead . }
This query cannot be simplified so nicely. It really comes down to how you want to be able to request your data and what is convenient for you. Please note that some of the queries that you can write in SPARQL are much more difficult to write as OWL DL expressions. When hasAuthor is a property of an object, the class of books whose authors live in Arrowhead with is defined by the expression:
lib:hasAuthor (places:livedAt value places:Arrowhead)
which is simply a class of things that have an author who lived at Arrowhead. If hasAuthor is a data type property, it is much harder, if not impossible, to write such an expression because you need to find two things (a book and an author) that have the same literal value (a string that is the name of the author).