Skip to content

Revision of Best Practices for CCO

John Beverley edited this page Aug 8, 2024 · 3 revisions

Overview

This document outlines the proposed revisions to the existing Best Practices document for the Common Core Ontologies (CCO). The purpose is to keep the practices current and effective for ontology development and application.

Revision History

Date Author Change Summary Link to Detailed Changes
YYYY-MM-DD Author Name Summary of the change or addition. View Changes

Current Best Practices Document

Document Title: Best Practices for Common Core Ontologies
Version: X.X
Date: YYYY-MM-DD

Link to Current Document

Proposed Change

Original Text

"This principle does not prohibit the use of subclass or equivalent class axioms whereby a class is defined to be a subclass or equivalent class of an anonymous class. The OWL language provides the means to express facts about entities using relations to other entities. For example, a fact such as “Automobile has_part some Engine” uses the has_part relation to relate each automobile to at least one engine. The semantics of this fact is that Automobile has been made a subclass of the anonymous class “thing having at least one engine as part”. The class is anonymous because it is not part of the asserted taxonomy. The set of subclass and equivalent class axioms forms the inferred taxonomy of an ontology. In this inferred taxonomy classes previously anonymous become explicit and the principle of single inheritance is no longer in force. For further details see: (Smith & Ceusters, 2010)"

User and Documentation

Chris Mungall Issue 24

Discussion

This is a little confusing as it confuses assertion with namedClass v classExpression distinction.

If I assert "car SubClassOf has_part some engine" it's still an assertion, not inferred.

I think what you want to say is:

  1. Ontology editors should only assert one named superclass
  2. The inferred/released edition of the ontology may have multiple direct inferred superclasses. This will be especially common with compositional classes which form a lattice/polyhierarchy on reasoning

Note that I think 1 is a good engineering rule of thumb but would not elevate to a principle.

Approval Process

  1. Review: The proposed revisions are reviewed by the relevant stakeholders.
  2. Feedback: Incorporate feedback and make necessary adjustments.
  3. Approval: Final approval by designated authority or committee.
  4. Implementation: Update the Best Practices document with approved changes.

Final Document

Updated Document Title: Best Practices for Common Core Ontologies
Version: X.X
Date: YYYY-MM-DD

Link to Updated Document