how can I recognize object properties vs datatype properties?
Asked Answered
L

1

11

My ontology is book classification library. I have problems in this. I want to build a book classification ontology by protégé 4.1, this classification has 14 categories, beside the sibling classes Author, book, Isbn. Individuals in book class are book’s subject(about 600 subjects) , and individuals in author class are name’s author and also isbn class. then I'm confused in object properties and datatype properties. if hasEdition is in properties in my ontology then i say that every book in class book have relation with edition class. so i use object properties but individual in this class(edition class) is integer<9. then how can tell it? is it datatype or object? and can use object properties vs datatype properties? (a same name)

Lanta answered 18/7, 2013 at 13:35 Comment(0)
T
40

On Object and Datatype Properties

In Protégé there are are different tabs for creating Object Properties and Datatype Properties. If a property should relate individuals to individuals, then it needs to be an object property, and if it relates individuals to literals, then it needs to be a datatype property.

If you have a property hasEdition whose domain is Book, then the question becomes what the range should be. If you expect triples like:

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

where the value are literals, then hasEdition should be a datatype property. If, on the other hand, you have a class Edition with some particular individuals, e.g.,

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

so that you can have

Book72 hasEdition first .
Book16 hasEdition third .

then hasEdition should be an object property.

If you need to look at the RDF serialization and determine which types the properties are, you should query for the classes owl:ObjectProperty and owl:DatatypeProperty (and, for the sake of completeness, owl:AnnotationProperty). That is, depending on whether hasEdition is an object property or a datatype property you would see:

hasEdition a owl:ObjectProperty .

or

hasEdition a owl:DatatypeProperty .

Deciding which to use

Whether you want a hasEdition property to be a datatype property or an object property really depends on what kind of data you're going to be storing, and that depends on your application. If you're just representing simple information like "first", "second", etc., then you probably want to use a datatype property that relates a book to its edition. This is probably a good route if you're representing books in the abstract, i.e, not individual instances of books (as opposed to a bookseller's inventory system, which would be be concerned with individual instances of books).

If, on the other hand, what you're actually representing are instances of books. E.g., if you're a bookseller and have in stock 25 copies of Semantic Web for the Working Ontologist and 27 copies of Programming the Semantic Web), then you might actually be interested in representing individual editions of books, on which the title, ISBN, and the like would probably be stored on the edition, not the book individual.

This is just an opinion, and you really do have a lot of flexibility in choosing your data model. It typically takes some experience to get nice data models, and experience takes time. Even so, you've got good tools for manipulating and transforming the data, so you can experiment with different representations, and map from one to the 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 distinct types of things. Resources are anonymous or identified by an IRI, and can be the subjects of statements (and thus be member 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 the subjects of sentences, and so 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 an object property and hasName is a datatype property.

On the other hand, you can make hasAuthor a datatype property and instead do

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

If you do this, though, then you don't have a convenient way to add any additional information about the author, since the literal "Herman Melville"@en cannot be the subject of a triple, so you can't for instance, say

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

whereas in the first case, you could say

lib:HermanMelville places:livedAt places:Arrowhead .

It's really just a matter of how you want to be able to query your data. In the case that hasAuthor is an object property, I can write a query like this to find books written by authors who lived at Arrowhead:

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

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

or even more concisely (but equivalently):

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

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

On the otherhand, if hasAuthor is a datatype property that relates a book to the name of its author, we can still have an Author class whose instances are related to their names by the hasName property, but it makes querying the data a bit more complicated, since the hasAuthor property is forcing a layer of indirection (get the name of the author of the book, then find the author who has that name), so we have queries like:

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

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

This query can't be simplified so nicely. It really comes down to how you want to be able to query your data, and what's convenient for you. Note that some queries that you can write in SPARQL are much harder to write as OWL DL expressions. When hasAuthor is an object property, the class of books whose authors lived at Arrowhead with is given by the expression:

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

which simply is the class of things that have an author that lived at Arrowhead. If hasAuthor is a datatype property, it is much more difficult, 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 (the string that is the author's name).

Tramway answered 18/7, 2013 at 17:7 Comment(7)
thank you joshua. What do you think? i use hasEdition data properties or object propertes? if I suppose that a class Edition with some particular individuals then how do it work? I mean that how related book' individual with Edition's individual? i so sorry I have another question . if I want to say that individual's Author that Participate Relation "hasAuthor" properties are type of string, then how tell it? (As regards hasAuthor is object properties)Lanta
@Lanta I"ve updated my answer with some thoughts on when you might make hasEdition a datatype or object property. For something like hasAuthor, you can either make authors be individuals, which then have, e.g., names (provided by the hasName data property), or you can make hasAuthor be a datatype property, in which case it relates the book the name of its author.Tramway
ok. so if hasAuthor as object propeties and i make another properties that Included author's name (same hasName). Do I understand correctly? but what is relation betwean hasAuthor and hasName?mean : how i tell that There is a relation betwean hasAuthor and hasName? sorry joshua and thank youLanta
@Lanta hasAuthor relates a book to an individual that is a member of the class Author. hasName relates the author individual to the author's name. The graph would look sort of like [book] --hasAuthor--> [author] --hasName--> "Herman Melville".Tramway
I have a question. if individuals author class are name’s author then do I need to make hasName properties? because individuals in author are Author'name. i can relate member of book class(Moby-Dick) with member of author class(herman meville) by hasAuthor properties(object properties).without making hasName prpoerties?Lanta
@Lanta I've updated with an example of what will happen if you make hasAuthor an object property as compared to a datatype property. In general, while it's good for human readers that IRIs have meaningful names (e.g., <http://example.org/books/MobyDick> is better than <http://example.org/class23489/member20943>), the identifiers are opaque, and any information that needs to be understood should be added as triples, not just encoded in the IRIs.Tramway
mmmm. yes thank you very much Joshua Talor.I feel that the world of ontology is much greater than I thought.thank youLanta

© 2022 - 2024 — McMap. All rights reserved.