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.

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

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.

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.

(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].

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.

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.

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.

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".

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.

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

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.

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

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.

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

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.

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.

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.

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.

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.

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).

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

All these diagrams, with the exception of Figure 9, have too small symbols and text. It would be very easy to reduce the width of those diagrams by reorganizing the content a little, this would allow larger magnification of the images.

Replace a number of the diagrams in the Commons specification

A number of diagrams changed over the course of the FTF work, and several have been made a bit more readable per the AB request. This resolution is aimed at replacing those diagrams in the specification document.

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

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

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

Add examples

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