Skip to content

Comments for INCITS SubGroup on MLO CCO

Jump to bottom
Alexander P. Cox edited this page Dec 18, 2020 · 2 revisions

High-Level Concerns

  1. FOL/CL/OWL: Does CCO want a FOL/CL version in addition to OWL, or will it remain canonically in OWL?

  2. For Barry: BFO2020 in OWL needs to be published and the version of the relations to be used must be agreed upon. Major issue: Is CCO going to use the temporized relations in BFO2020? If not, then it will need a version of the nontemporalized relations that are curated by the relations ontology group and aligned to BFO2020.

  3. Deprecation Policy: CCO needs a clearly stated deprecation policy that allows independently working developers to align data to a set of CCO URIs and know that the semantics of those URIs haven’t changed between versions.

  4. Scope: What defines the scope of a mid-level ontology? (e.g. APL thinks, minimally, all military-related terms are out of bounds, but more agent-related terms should be in: first name, last name, email address, postal address, etc...)

    4.1. Proposed Exercise: Review a collection of vocabularies that look like candidate mid-levels (e.g. dbpedia, schema.org... others?) and look at what terms are common across them. This is in line with CUBRC’s criteria that term frequency governs what is in and what is out of a mid-level.

    4.2. See here a list of Mid-Level Rules of Thumb extracted from https://www.nist.gov/system/files/documents/2019/05/30/nist-ai-rfi-cubrc_inc_002.pdf :

         *   The domain of a mid-level ontology should be expressible either as a single class or as a statement composed of classes and an object property within that ontology.

     *   Moreover, that class or those classes should be at the root level of the ontology. The remainder of the content of a mid-level ontology are those terms and relations that adequately characterize entities of that subject.

     *   One bound is to include only those entities that relate to the root type and not to other types as well.

     *   Include all subtypes of the classes of the top-level ontology that relate to only the root class or classes of the mid-level ontology and which are applicable to a significant percentage of its instances.

     *   On just how many subtypes to include we offer the rule of thumb that no more than three levels of subtypes should be included for any one of the general terms or relations.

  5. Consistent Difference: At every level of CCO's hierarchy, there should be a single principle for differentiation used so that it is always clear where to place a new class within the hierarchy. Presently, the artifact hierarchy runs afoul of this principle and it has made it difficult to extend (e.g. Is Medical Mask subclass of cco:ArtifactOfClothing or cco:MedicalArtifact?).

  6. Governance: What is the relationship between CUBRC, CCO, and various working groups that work with extensions of CCO? There is a need for a broader consortium to review changes and promote data exchange. Many concerns here to be discussed.

Low-Level Concerns

  1. Axioms: CCO classes appear under axiomatized. In the past, CUBRC has reasoned that not heavily axiomatizing CCO made it a more attractive representation for data fusion and downward refinement (e.g. The rule 'has four wheels' would get in the way of recognizing an instance of a car that lacks a wheel, and users could add subclasses of car that have these axioms if they wish). However, now there are tools for relaxing class axioms when they would get in the way of tasks like this.
  2. Language Support: CCO classes lack language support (i.e. labels in multiple languages with xsd language tags).
  3. Documentation: The documentation for CCO is both excellent and outdated. APL has been using a combination of SPARQL and LaTex to autogenerate much of its documentation from the ontologies directly. We’re happy to share this method if it would aid CUBRC or others.
  4. Required Property List: We need a list of required annotation properties and their formats for each CCO resource. Then, all resources in CCO should have these required annotation properties. Right now, many required annotations are missing. In general, more annotations see required within the OWL file (e.g. examples, axioms, alternative labels, bibliographic citations, elucidations)
  5. For Barry: Clearer guidelines are needed from NCOR/BFO regarding why it is appropriate to use BFO:site over BFO:spatial region for country, continent, etc... The medical examples that dominate the BFO documentation are not helpful (e.g. CCO's choice here should be clearly defensible for an IC/DOD/government audience familiar with BFO).
  6. Information: CCO has chosen to distinguish most information entity types by creating many subclasses of information bearing entities—the opposite of IAO’s choice, which distinguishes information entity types by creating subclasses of information content entity. The problem is that classes in CCO like ‘Document’ and ‘Video’ all refer to material entities, and hence cannot be about anything (here, one needs the cumbersome complication of saying the information that g-depends on these bearers is about something). I understand the issue (a complication caused by BFO) and I understand why CCO went this way rather than IAO’s direction, for which there are tradeoffs as well. However, given that any approach here is going to be problematic, this warrants some strategizing. One shouldn’t have to say ‘Find X that g-depends-on Y and is-about Z’ when one wants to say, more simply: ‘Find X that is-about Z’. The Common Annotation Standard takes the latter approach and defines its entities in terms of cco information bearing classes (e.g. Video Content rdf:type cco:RepresentationalInformationContentEntity and g_depends on some cco:Video).
  7. Roles and other Realizables: To create a role, one should be able to name the process that might realize it. Presently, some of the CCO roles satisfy this constraint, but more often they only specify the criteria for coming to bear the role. This begs the question: why not just create a defined class? (i.e. why say a citizen bears a citizen role “that inheres in a Person who is legally recognized as a member of a particular state…” rather than just drop all talk of roles and say a citizen is a person who has been legally recognized as a member of a particular state). To be clear, CCO is talking about actual roles in these cases, but we suggest their realization conditions should be specified. A good formulation is “A role that, if realized, is realized in a process of such and such a type…”. These same criteria may be used for evaluating the definitions of other realizable entities (including functions and dispositions).
  8. Is that a realizable? There are a handful of classes under BFO Quality or Information Content Entity that seem like realizable entities. Examples: Ethnicity, political orientation, disability, weight…
  9. Spatial and Temporal Relations: These should be reviewed to ensure they are complete and reflect their sources (Allen Interval and Region calculus).

--Neil Otte

Update 18 December 2020:

For a list of criteria for defining a mid-level ontology, see: https://github.com/CommonCoreOntology/CommonCoreOntologies/wiki/INCITS-MLO-WG:-Criteria-for-a-Mid-Level-Ontology For a list of desiderata for ontology design, see: https://github.com/CommonCoreOntology/CommonCoreOntologies/wiki/INCITS-MLO-WG:-Ontology-Best-Practices

Clone this wiki locally