Ontology Design Principles

Michel Dumontier edited this page Feb 8, 2018 · 2 revisions

In order to generate high quality ontologies, we advocate the following ontology design principles:

Agile Design

Ontology design should be simple, sustainable and highly effective. While some ontologies are being designed to comprehensively capture knowledge in a particular domain, others are far simpler and significantly more pragmatic. In all cases, ontology design should be clearly motivated by use cases thereby enabling rapid and focused development, continual evaluation, and regular milestone releases.

We encourage both a collaborative and competitive ontology design practice. Ontologies may be designed by individuals or small groups, and published as working drafts with open calls for participation towards improvement and consensus. Where ontologies may not or cannot satisfy certain use cases, or artistic differences preclude effective collaboration, designers should feel free to make derivative or alternative works to address these deficiencies and demonstrate their utility. Good ideas should inform existing ontologies or the ontologies risk losing their relevance.

Basic Design Principles

The following set of basic principles must be followed by any Semantic Science ontology.

  1. The ontology must be represented and correctly adhere to the strict semantics of the Web Ontology Language (OWL)
  2. All ontologies must be licensed with Creative Commons 0 or [Creative Commons by Attribution][(https://creativecommons.org/licenses/by/4.0/). This ensures that people are free to share and create derivative works with or without the sole condition that derivative works must acknowledge sources.
  3. Resources, whether ontologies or entities described within them, must be uniquely and persistently identified by International Resource Identifiers (IRI). These should be dereferenceable such that putting them in your browser will return information about those entities. OWL documents must also be versioned.
  4. Resources should be described with brief English labels (rdfs:label) and human readable definitions (dcterms:description) that are as accurate as possible, such that they focus on essential/differentiating featues, avoid circularity and figurative or obscure language and do not add superfluous information or impose unnecessary constraints. For consistency, labels should be lower case (unless a formal name) and words separated by whitespace.
  5. Resources should be (to the extent possible) described through logical axioms that match their human readable descriptions.

Advanced Design Principles

OntoClean is a methodology for analyzing ontologies based on formal, domain-independent properties of classes. These include:

  1. Identity: Identity criteria provides us with the information necessary to understand what attributes are necessary (and sufficient) for class membership such that we can compare two classes and determine whether they are the same or different. Identity criteria are inherited down the class hierarchy, whereas attributes that are non-identity are not.
  2. Rigidity: A property is rigid if it is essential to all their instances. For example, the property of being a person, usually represented by the class Person, is essential for the lifetime of that person. In contrast, the property of being a student is non-rigid because an individual can become or stop being a member of that class, and hence this is not essential for all its individuals. If we treat time as a line, then there are ray and segment-like behaviours:
  3. Semi-temporal rigidity: A property is semi-temporally rigid when it takes hold at some time forward. Consider the property of dead people: one is dead forever, but all dead people were once not dead.
  4. Ephemeral rigidity: A property is ephemeral rigid if instances have this property for one finite and continuous period of time. For instance, the property of living people is that they come into existence for some finite period of time and go out of existence for the remainder of time.
  5. Existential rigidity: A property is existentially rigid if in any possible world where an instance of that property exists, it instantiates the property. This is useful for characterizing properties exemplified by abstract entities that are arguably outside of time or that consider only single states of affairs and treat time, space, possibility as modalities.
  6. Actuality: A property is actually rigid if the property only holds for actually existing entities (those located in space-time in this universe).
  7. Unity: A property has unity if all individuals are wholes under the same relation. For example, Sand has unity, in that any arbitrary subsection are also of the same type. The same cannot be said of a Person.
  8. Dependence: A property is dependent if each instance of it implies the existence of another entity. The property Student, for example, is dependent, since to be a student there must be a teacher; for every instance of student there is at least one instance of teacher.

##Linked Knowledge Integrating diverse knowledge is an ambitious endeavor with several outstanding challenges. Even representing the same kind of knowledge from different data providers is hard. Yet linked data is not sufficient for mining our collective knowledge and answering questions across the set of related resources due to irregular representation of data. We must strive towards compatible/convertable representations, with data models that can check semantic consistency. For SIO, we aim to document ontology-based design patterns that we and others can reuse. We encourage you to contribute to this conversation on the mailing list. This will facilitate the publication of structured knowledge on the emerging semantic web that is both accurate in the details and precise in the representation.

You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.
Press h to open a hovercard with more details.