${taskforce.name} Avatar
  1. OMG Task Force

Commons Ontology Library (Commons) 1.0 FTF — Closed Issues

Open Closed All
Issues resolved by a task force and approved by Board

Issues Summary

Key Issue Reported Fixed Disposition Status
COMMONS-12 The properties in the collections ontology are confusing to users Commons 1.0b1 COMMONS 1.0 Resolved closed
COMMONS-11 Need to be able to indicate whether or not something can only be classified by a single classifier from a specific scheme Commons 1.0a1 COMMONS 1.0 Resolved closed
COMMONS-3 The format of the tables throughout the specification needs improvement Commons 1.0a1 COMMONS 1.0 Closed; No Change closed
COMMONS-18 There needs to be an additional usage note on Text in the TextDatatype ontology with a stronger warning Commons 1.0b1 COMMONS 1.0 Resolved closed
COMMONS-16 Revise the abbreviation for the AboutCommons "make file Commons 1.0b1 COMMONS 1.0 Resolved closed
COMMONS-19 CodeSet should be a subclass of arrangement Commons 1.0b1 COMMONS 1.0 Resolved closed
COMMONS-14 Revise the version IRI for all of the Commons ontologies to agree for finalization purposes Commons 1.0a1 COMMONS 1.0 Closed; No Change closed
COMMONS-9 The constraint on a classifier that says it must classify something is too restrictive Commons 1.0a1 COMMONS 1.0 Resolved closed
COMMONS-2 The terms and definitions section of the Commons Ontology Library is incomplete Commons 1.0a1 COMMONS 1.0 Resolved closed
COMMONS-1 The use of rdfs:isDefinedBy is inconsistent in the annotation vocabulary Commons 1.0a1 COMMONS 1.0 Resolved closed
COMMONS-26 Revise the definition of designation to better align with the latest version of ISO 1087 Commons 1.0b1 COMMONS 1.0 Resolved closed
COMMONS-4 Some of the diagrams in Clause 8 are difficult to read Commons 1.0a1 COMMONS 1.0 Resolved closed
COMMONS-6 Some of the commons ontologies include double spaces in annotations Commons 1.0a1 COMMONS 1.0 Resolved closed
COMMONS-5 Examples are needed to help explain to Commons users how to use the ontologies Commons 1.0a1 COMMONS 1.0 Resolved closed

Issues Descriptions

The properties in the collections ontology are confusing to users

  • Key: COMMONS-12
  • Status: closed  
  • Source: Thematix Partners LLC ( Mrs. Elisa F. Kendall)
  • Summary:

    Users are confused as to whether they need comprises or hasConstituent or hasMember or hasPart.

    In order to address this, we need to augment some of the properties with disjointness, such as between comprises and hasPart. Then we need to make clear that membership involves discrete elements and constituency may or may not involve discrete elements. hasConstituent can be used with cardinality constraints whereas hasPart cannot be due to OWL reasoning constraints.

  • Reported: Commons 1.0b1 — Fri, 12 Aug 2022 19:13 GMT
  • Disposition: Resolved — COMMONS 1.0
  • Disposition Summary:

    Clarify the use of several properties in the Collections ontology

    Clarify the definition of properties related to inclusion, including when to use comprises vs. hasPart (which is transitive), and hasConstituent vs. hasMember (whose elements are discrete and countable), making hasConstituent and hasMember disjoint in the Collections ontology

  • Updated: Tue, 28 Mar 2023 17:31 GMT
  • Attachments:

Need to be able to indicate whether or not something can only be classified by a single classifier from a specific scheme

  • Key: COMMONS-11
  • Status: closed  
  • Source: Thematix Partners LLC ( Mrs. Elisa F. Kendall)
  • Summary:

    This is not expressible in OWL, easily. One option would be to create a boolean that indicates this is the case, which perhaps a rule engine for data quality, or sparql, or a SHACL shape could then test. What you really want to be able to say is that 'is classified by' can only have one value from a given classification scheme when applied to something.

    This is a change to the Classfiers ontology, which may impact that section of the specification.

  • Reported: Commons 1.0a1 — Fri, 5 Aug 2022 18:37 GMT
  • Disposition: Resolved — COMMONS 1.0
  • Disposition Summary:

    Supporting this feature should be done in a user ontology, but we provide a flag for those that might need it

    The simplest way to say that only one member of a specific classification scheme can be used to classify something is to add a restriction to the concept in question. Something like

    ClassifiedItem isClassifiedBy max 1 SpecificClassifier

    where the classified item is the concept in a user ontology being classified, and specific classifier is the one from the scheme that applies. For example, suppose that the classification scheme / controlled vocabulary includes the individual paint colors that are available to customize a vehicle for purchase for some model/model year and manufacturer. A vehicle manufactured by that manufacturer that is of that model and model year can only have one color from that scheme, i.e.,

    Vehicle isClassifiedBy exactly 1 VehicleColor

    where the VehicleColor is a member of that specific scheme.

    We could complicate the classifiers ontology to add several new classes, such as ClassifiedThing, UniquelyClassifiedThing, SpecificClassificationScheme (or ExclusiveClassificationScheme) and SpecificClassifer, where the SpecificClassifier is a member of the ExclusiveClassificationScheme, where all members of the scheme are disjoint/different from one another, and where a UniquelyClassifiedThing can be classified by max 1 SpecificClassifier. The FTF agreed that this would overly complicate the ontology, though, and that commons users can add the restriction on the thing that they are classifying as needed without requiring the "clutter".

    We will provide a boolean flag, called isExclusive to allow users that need it to add such a flag to their classification scheme.

  • Updated: Tue, 28 Mar 2023 17:31 GMT
  • Attachments:

The format of the tables throughout the specification needs improvement

  • Key: COMMONS-3
  • Status: closed  
  • Source: Thematix Partners LLC ( Mrs. Elisa F. Kendall)
  • Summary:

    (1) Different fonts: I can understand why you are using a fixed-width font in the metadata tables to identify the right-hand columns as the actual values of the terms listed in the left column.
    In the Properties tables I suggest to use a sans-serif font (e.g. Ariel) for the Axioms column to clearly distinguish the Axioms from the Annotations
    (2) The Properties tables are too cramped. It is not clear what the purpose of the name repetitions in parentheses in the Name column is. However, these repetitions take up unnecessarily much horizontal space. This could be solved by always moving them in a line under the bold camel-case name. The recovered horizontal space should be then allocated to the Axioms column, which is way too narrow. Many axioms are mutilated by inappropriate line breaks.
    (3) Since you are not using vertical separators (which is ok), you should extend the gutter whitespace between columns to improve readability, in particular between Annotation and Axiom columns.
    (4) Clause 6 should contain good explanations regarding the fonts and the table layouts [and the parenthesis names].

  • Reported: Commons 1.0a1 — Fri, 1 Jul 2022 18:45 GMT
  • Disposition: Closed; No Change — COMMONS 1.0
  • Disposition Summary:

    Most formatting issues raised in AB review were addressed via errata

    We added gutter space and separators to make the tables easier to read in a revision via errata prior to AB approval and final voting at the June meeting. Moving labels (which are the human-readable rather than camel case names) to the middle column is something that we can do once we agree on a format for ontology generation in LaTeX in a future version of this specification. The format we used for the Commons is the same as recent FIBO, LCC, and other ontology specifications until such time as we are able to automate generation of the material.

  • Updated: Tue, 28 Mar 2023 17:31 GMT

There needs to be an additional usage note on Text in the TextDatatype ontology with a stronger warning

  • Key: COMMONS-18
  • Status: closed  
  • Source: Thematix Partners LLC ( Mrs. Elisa F. Kendall)
  • Summary:

    This datatype is quite useful but most free and some commercial OWL tools don't support (1) custom datatypes in OWL, and (2) rdf:langString. We need to provide a stronger warning to users who might want to extend Text with the inherent risk in doing so depending on their application and tool infrastructure.

  • Reported: Commons 1.0b1 — Sat, 20 Aug 2022 22:51 GMT
  • Disposition: Resolved — COMMONS 1.0
  • Disposition Summary:

    Add a note to Text that warns people not to use it under certain circumstances

    The current scope note doesn't go far enough to warn potential users of some of the issues with this datatype. A stronger usage note should be added in addition to the current scope note.

  • Updated: Tue, 28 Mar 2023 17:31 GMT
  • Attachments:

Revise the abbreviation for the AboutCommons "make file

  • Key: COMMONS-16
  • Status: closed  
  • Source: Thematix Partners LLC ( Mrs. Elisa F. Kendall)
  • Summary:

    The AboutCommons.rdf file is a convenience file that can be used to load all of the ontologies into ontology editors such as Protege, triple stores, and other applications. The namespace prefix for this ontology does not conform to the others in terms of its structure, however. It is currently "abt-cmns" and should be "cmns-abt".

  • Reported: Commons 1.0b1 — Sat, 20 Aug 2022 02:25 GMT
  • Disposition: Resolved — COMMONS 1.0
  • Disposition Summary:

    Revise the namespace prefix for AboutCommons to be "cmns-abt"

    The namespace prefix in the beta 1 specification for this ontology is "abt-cmns", which is different in structure from all the others, which are of the form "cmns-"<ontology prefix>.

    Fixing this requires a 1 line change to the specification and a revision to the AboutCommons ontology, attached.

  • Updated: Tue, 28 Mar 2023 17:31 GMT
  • Attachments:

CodeSet should be a subclass of arrangement

  • Key: COMMONS-19
  • Status: closed  
  • Source: Thematix Partners LLC ( Mrs. Elisa F. Kendall)
  • Summary:

    This is a gap, as classification scheme and identification scheme are both already subclasses of arrangement.

  • Reported: Commons 1.0b1 — Sat, 20 Aug 2022 23:10 GMT
  • Disposition: Resolved — COMMONS 1.0
  • Disposition Summary:

    Make CodeSet a kind of Arrangement

    CodeSets are essentially controlled vocabularies that conform to some scheme and that are collections. Every code set is both an arrangement and a collection in other words. Thus, code set should be a subclass of arrangement.

  • Updated: Tue, 28 Mar 2023 17:31 GMT
  • Attachments:

Revise the version IRI for all of the Commons ontologies to agree for finalization purposes

  • Key: COMMONS-14
  • Status: closed  
  • Source: Thematix Partners LLC ( Mrs. Elisa F. Kendall)
  • Summary:

    This issue involves updating the version IRIs for all of the ontologies to be 20220801 for finalization

  • Reported: Commons 1.0a1 — Sat, 20 Aug 2022 00:19 GMT
  • Disposition: Closed; No Change — COMMONS 1.0
  • Disposition Summary:

    The IRI changes can be made editorially thus no vote is required.

    After discussion within members of the FTF we determined that we can make the changes to the version IRIs editorially and a vote on this issue is not required.

  • Updated: Tue, 28 Mar 2023 17:31 GMT

The constraint on a classifier that says it must classify something is too restrictive

  • Key: COMMONS-9
  • Status: closed  
  • Source: Thematix Partners LLC ( Mrs. Elisa F. Kendall)
  • Summary:

    Classification schemes should be able to be defined without necessarily referring to all of the things that they classify. For example, one should be able to encode industry classifiers without having to know exactly what those classifiers apply to. Thus, the constraint that a classifier classifies some thing should be loosened to be min 0, meaning 'may'.

    This issue affects the Classifiers ontology, only

  • Reported: Commons 1.0a1 — Thu, 14 Jul 2022 21:44 GMT
  • Disposition: Resolved — COMMONS 1.0
  • Disposition Summary:

    Loosen the restriction on Classifier from at least one to min 0

    The original restriction on the property classifies on Classifier was too restrictive, i.e., it required all classifiers to reference at least one thing that they classify. For ontologies that represent things like industry classifiers such as NAICS, the "schema", or t-box, that represents those classifiers should not be required to include them. Typically such reference data would be in a separate controlled vocabulary, or a-box, i.e. a separate ontology that is only imported when in use.

    The solution is to change a someValuesFrom owl:Thing restriction to a minCardinality 0 restriction on the property classifies on the class, Classifier.

  • Updated: Tue, 28 Mar 2023 17:31 GMT
  • Attachments:

The terms and definitions section of the Commons Ontology Library is incomplete

  • Key: COMMONS-2
  • Status: closed  
  • Source: Thematix Partners LLC ( Mrs. Elisa F. Kendall)
  • Summary:

    This section defines ontology, but none of the other key terms that are present in any of the ontologies. It should be revised to incorporate at least some of the basic definitions that are present in the ontology files.

  • Reported: Commons 1.0a1 — Fri, 1 Jul 2022 18:40 GMT
  • Disposition: Resolved — COMMONS 1.0
  • Disposition Summary:

    Augment the terms and definitions clause with a few additional high-level definitions

    Add definitions for several top-level terms used in the ontologies that may be useful for specification users.

  • Updated: Tue, 28 Mar 2023 17:31 GMT

The use of rdfs:isDefinedBy is inconsistent in the annotation vocabulary

  • Key: COMMONS-1
  • Status: closed  
  • Source: Thematix Partners LLC ( Mrs. Elisa F. Kendall)
  • Summary:

    In the annotation vocabulary machine-readable file, the use of rdfs:isDefinedBy is inconsistent. For reified elements for Dublin Core annotations, we use the Qname / abbreviated IRI to link to the source. For reified elements for the Simple Knowledge Organization System (SKOS), we use the full IRI. And, we have not included rdfs:isDefinedBy for any of our local annotation declarations.

    The latter is probably ok, but we should normalize the references for Dublin Core and SKOS to all use the same approach.

    This issue was raised by Richard Beatch in his AB review.

  • Reported: Commons 1.0a1 — Fri, 1 Jul 2022 18:25 GMT
  • Disposition: Resolved — COMMONS 1.0
  • Disposition Summary:

    Normalize the use of rdfs:isDefinedBy for Dublin Core and SKOS declarations

    In the case of Dublin Core annotations in the annotation vocabulary, we used rdfs:isDefinedBy to refer to the same property in the Dublin Core namespace using an abbreviated IRI followed by the local name. In the case of SKOS annotations we used rdfs:isDefinedBy to reference the entire ontology IRI for SKOS.

    The fix to this issue is to revise all of the rdfs:isDefinedBy annotations for the Dublin Core annotations to use the same approach as we did for SKOS, i.e., to refer to the ontology using the IRI for Dublin Core.

    This revision affects the machine-readable AnnotationVocabulary ontology only, and has no impact on the specification document.

  • Updated: Tue, 28 Mar 2023 17:31 GMT
  • Attachments:

Revise the definition of designation to better align with the latest version of ISO 1087

  • Key: COMMONS-26
  • Status: closed  
  • Source: Thematix Partners LLC ( Mrs. Elisa F. Kendall)
  • Summary:

    The definitions of designation and name need some additional work and don't align with the ISO definitions as well as they should. The definition of designation needs clarification and the definition of name should state that it is not linguistically neutral per its usage in the standard. Also, even if we clarify name, we probably don't want it to be disjoint with identifier as it is now (needs further discussion).

  • Reported: Commons 1.0b1 — Thu, 1 Sep 2022 16:34 GMT
  • Disposition: Resolved — COMMONS 1.0
  • Disposition Summary:

    Clarification of the distinctions between kinds of designators

    1. Clarified the definition of designation, denotes, and name, and better aligned them with ISO 704 / ISO 1087 in the Designations ontology
    2. Augmented the definition of a contextual name to require a context in the Contextual Designations ontology
    3. Further clarified the distinction between an identifier, contextual identifer and code / code set by adding notes, making identfies a functional property, and adding the notion of a contextual identification scheme in the Identifiers, Contextual Identifiers, and Codes and Code Sets ontologies

  • Updated: Tue, 28 Mar 2023 17:31 GMT
  • Attachments:

Some of the diagrams in Clause 8 are difficult to read


Some of the commons ontologies include double spaces in annotations

  • Key: COMMONS-6
  • Status: closed  
  • Source: Thematix Partners LLC ( Mrs. Elisa F. Kendall)
  • Summary:

    These double 'blanks' cause minor hygiene issues when using the EDM Council's test harness and should be addressed.

  • Reported: Commons 1.0a1 — Sun, 10 Jul 2022 00:16 GMT
  • Disposition: Resolved — COMMONS 1.0
  • Disposition Summary:

    Eliminate double 'spaces' in several commons ontologies

    This is a trivial update but cleans up an issue identified through the EDM Council's hygiene test environment.

    Revisions impact the machine-readable files only, and include:

    1. Elimination of a double space in the scope note on CombinedDateTime in the Dates and Times ontology
    2. Elimination of double spaces in the abstract and a note on Designation in the Designators ontology
    3. Elimination of a double space in a note on ClassificationScheme in the Classifiers ontology
    4. Elimination of a double space in a note on ContextualName in the ContextualDesignators ontology

  • Updated: Tue, 28 Mar 2023 17:31 GMT
  • Attachments:

Examples are needed to help explain to Commons users how to use the ontologies

  • Key: COMMONS-5
  • Status: closed  
  • Source: Thematix Partners LLC ( Mrs. Elisa F. Kendall)
  • Summary:

    There are no examples in the specification itself, which are needed to assist both library implementers and users of the ontologies.

  • Reported: Commons 1.0a1 — Fri, 1 Jul 2022 19:03 GMT
  • Disposition: Resolved — COMMONS 1.0
  • Disposition Summary:

    Add examples

    The attached document includes an informative annex representing examples that we hope will be helpful to implementers of the Commons library.

  • Updated: Tue, 28 Mar 2023 17:31 GMT
  • Attachments:
    • Annex B.odt 25 kB (application/vnd.oasis.opendocument.text)