I would like to know if there are any good practices for modeling Roles in ontologies. I am particularly interested by modeling roles that changes over time (CEO Role during a period of time). Also it is very common to model roles as properties and roles as classes. What are the best practices to pick one or the other approach ? How can we relate both ?

Thanks in advance


asked 13 Dec '12, 13:59

fellahst's gravatar image

accept rate: 12%

edited 14 Dec '12, 18:30

The pattern Time indexed person role from the Ontology Design Patterns might help you. Similar pattern is used in the Organization Ontology to express changes of roles through time, see this example.

permanent link

answered 16 Dec '12, 13:17

jindrichm's gravatar image

accept rate: 31%

You may be interested in the participation schema http://vocab.org/participation/schema

permanent link

answered 16 Dec '12, 12:17

brinxmat's gravatar image

accept rate: 15%

I made some research on this topic the last couple of days and I realized that my question was a pretty tough one to answer. I wanted to share with you my findings, in the hope that the readers will produce better ontologies in the future.

The best papers I have found on the subject of properly modeling roles in ontologies are:

OntoClean is a methodology for validating the ontological adequacy of taxonomic relationships. It is based on highly general ontological notions drawn from philosophy, like essence, identity, and unity, which are used to characterize relevant aspects of the intended meaning of the properties, classes, and relations that make up an ontology. These aspects are represented by formal metaproperties, which impose several constraints on the taxonomic structure of an ontology. The analysis of these constraints helps in evaluating and validating the choices made.

These last two papers were the best I could find on this topic and the model presented seems to be very solid and has been used for building the ontology editor Hozo.

Existing ontology tools such as Topbraid, Protege do not have any formal model built-in to properly model roles in ontologies and techniques like Ontoclean to validate the quality of the ontologies. Addition of such techniques would be a great improvement, that would lead to the production of better and more reusable ontologies. Too many ontologies produced today are poor qualities because the tools do not implement best practices in ontology modeling.

permanent link

answered 16 Dec '12, 16:29

fellahst's gravatar image

accept rate: 12%

edited 16 Dec '12, 16:33

Good pointers (esp OntoClean which presents a useful set of guidelines), though I somewhat disagree with your last paragraph. While additional tool support is of course always useful and can make things easier, ultimately, proper modeling of an ontology is the ontology egineer's job, and conversely, if it's not done right, the engineer's fault, not the tool's.

(16 Dec '12, 19:46) Jeen Broekstra ♦ Jeen%20Broekstra's gravatar image

The question of whether to model some characteristic as a class or a property is a very common one. It does not only apply to roles, but to any sort of characteristic of an individual you can think of. In general, I'd say that a good rule of thumb is to think about whether the characteristic you're modeling is intrinsic to the individual: if the characteristic were to change, would we still consider the individual the same individual? If the answer to that question is yes, it is not intrinsic, and this makes it a good candidate for modeling it as a property. If the answer is no, it makes it a good candidate for modeling as a class.

This may sound straightforward but it often is not clear cut. Example: in a domain about cars, we may want to say things about red cars and blue cars. Should the color be a (sub)class (:RedCar and :BlueCar), or a property (:Car :hasColor :Color)? The answer IMO depends on whether you consider colors intrinsic to the item being modeled. If, in your domain, you wanted to cater for the fact that cars can be spray-painted a different color, then modeling as a property makes more sense. If, however, in your domain you consider the color a uniquely defining characteristic, then modeling as a class may make more sense (as an aside, another reason to choose properties over classes is that you may not always know the color of each individual, and dealing with that kind of missing information is often easier when it's expressed as a property).

In the case of roles, I'd say that modeling as a property generally makes more sense, especially if, as in your case, you anticipate them changing over time.

permanent link

answered 16 Dec '12, 15:12

Jeen%20Broekstra's gravatar image

Jeen Broekstra ♦
accept rate: 37%

Not sure how your comment relates to my question.

(19 Dec '12, 23:09) fellahst fellahst's gravatar image
Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here



Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text](http://url.com/ "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:


question asked: 13 Dec '12, 13:59

question was seen: 2,023 times

last updated: 19 Dec '12, 23:09