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

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.