hasDescription, describes, and isDescribedBy:

• are very vaguely defined
• have unclear usage
• are little to do with the declared scope of Designators (about naming)
• duplicate the more broadly used dct:description
• are only used in two other places (cls:classifies is subPropertyOf describes - which is not semantically valid since a classifier does not "describes the nature of" the thing it classifies) and (qtu;describesActualExpression subPropertyOf hasDescription - would be better as subPropertyOf cmns-doc;specifies)

Relationships between elements of a taxonomy are difficult to represent without adding properties for concepts such as broader / narrower classifiers.

For generated ontologies such as BACM, and applications that need access to the blank nodes in an ontology, it is useful to have a UUID for every node, particularly blank nodes, which could be handled as an annotation. For alignment with XMI metamodels it may be quite useful.

This request came from BMI. We could add it to either (1) the annotation vocabulary, or (2) one of the identifier ontologies in Commons

See https://www.w3.org/2003/01/geo/. This tiny ontology with representation of lat/long is widely supported by graph databases and allows use of GeoSPARQL. It makes little sense for OMG to define its own properties such as &cmns-loc;hasLongitude..
Example:
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:geo="http://www.w3.org/2003/01/geo/wgs84_pos#">
<geo:Point>
<geo:lat>55.701</geo:lat>
<geo:long>12.552</geo:long>
</geo:Point>
</rdf:RDF>

The notion of a language is needed for DOL, API4KP, and MVF and LCC - which means that we should move it from LCC to Commons. The team agreed that it should be added to the codes and code sets ontology, including a language identifier and related properties.

For visibility outside OMG I think we should be registering all our ontologies which I think may require a few extra items of metadata as here https://lov.linkeddata.es/Recommendations_Vocabulary_Design.pdf such as Dublin Core terms title and description (we have label and abstract), (date) issued and modified, and for elements, rdfs:comment (we have the more specific skos:definition). I think most of these could be added via automated script (e.g. Each skos:definition also becomes a rdfs:comment).

The current definition of capability isn't sufficiently clear about skills and qualifications that an individual might have in addition to an organization (both are needed), and should better describe the concept of having the skills, expertise, and other qualifications in order to, for example, achieve business goals and objectives.

Capacity on the other hand is about having the resources to execute. These two terms are used somewhat interchangeably in FIBO, for example, but in order to use them properly for other use cases they should be differentiated and disjoint.

This ontology defines "County" and "FederalState", which bias the ontology toward the administrative geography of the United States. Cantons and provinces are defined as synonyms or FederalState, but other countries have subdivisions that go by other names. The term "GeopoliticalEntity" could apply in that case (e.g., to a French "région" or "département", except that GeopoliticalEntity is defined as a subclass of GeographicRegion, which is "an area of land that has common features" which seems to be mostly about physical characteristic (a mountain, a plain, etc.) not a geopolitical entity.
It would seem that more generic terms than "County" or "FederalState" should be used to better address the geopolitical subdivision of countries other than the U.S.

expressesTheMagnitudeOf
Definition: indicates the subject or topic of something, such as
a document
Range: ScalarQuantity

I'm pretty sure the definition is wrong.
And the range seems wrong too.

1. The first term is shown as "cmns-col;Constituent" – what does the prefix mean???

2. The annotation starts with "An element is an object..." instead of "A constituent is an object..."

The term LogarithmicScale (near top left of page 91) should be bold.

The annotation for the DateTime row states "The time zone is implicitly GMT." This time zone is now known as UTC, and this should be used rather than GMT because UTC is the legal reference, and UTC is measured from midnight while GMT was measured from midday. There are other distinctions, see https://www.timeanddate.com/time/gmt-utc-time.html.

The specificaton of DatePeriod states: "A date period is unknown if either the start date or the end date has no value. If a date period
is unknown, then the duration should either be omitted or unknown (have no value)."
What about the situation in which the period is known but the dates are not yet known? For example, as I write this we know that OMG's Q2 meeting will be over 5 calendar days, but it may be June 12-16 or June 19-23. There could be a date period associated to such an entity (meeting) that don't have a start date or end date, but have a known duration, which should be recorded. "Duration" is not necessariiy a good substitute because it is not limited to a date range.

The sentence "Oversight for curation of the library will be managed by the Commons task force (RTF) via the normal
OMG process" seems to be mssing the word "revision" before "task force".

The definition in Commons Annotation Vocabulary is not a mere copy of what's in DCT with the documented addition of making it a owl:AnnotationProperty, but adds the triple :
<rdfs:subPropertyOf rdf:resource="&skos;note"/>
That may or may not be a good idea but it adds a dependency and it's a significant change that should be flagged.
In fact, given that SKOS itself makes use of DCT, that makes for a somewhat undesirable circular dependency though not formally stated.

If an aim is some sort of unification then maybe skos:definition should be made a subProperty of dct:description.

Wrong property used for collection members in restrictions on List and ChronologicallyOrderedCollection.
These make use of hasConstituent but this is disjoint with hasMember and it says "This property is disjoint with hasMember, and should be used in cases where the constituents of something are not considered discrete elements of whatever they are included in, such as a substance or composite."

We've said that hasMember is distinct from hasConstituent, but the actual definitions are not necessarily obviously different to users. The definition of hasConstituent changed after the original ontology was submitted, and the notion of Constituent as a class could be used to support either members or constituents, even though the properties in question are disjoint.

It is likely that we need to find a different "word" or "phrase" to describe elements of a composite that are not necessarily distinguishable from one another, and revise the ontology accordingly.

The definition of List includes "set of related items"

Little best practice or guidance is given in either the spec or the ontology. By the fact that they're included it seems that skos:prefLabel and skos:altLabel are recommended. However they're not actually used in this or any of the other Commons ontologies.
Commons itself provides an alternative with its Designations ontology. And OMG provides a strong capability in MVF.

Users of Commons should be warned about the anti-pattern use of rdfs:label as the primary in conjunction with skos:altLabel which makes it impossible, with reasoning enabled, to return only the primary (since skos:altLabel; is a subProperty of rdfs:label)

The definitions taken from SKOS seem altered and incomplete.
For example here is the official definition from SKOS RDF file for altLabel. The Commons version changes the label (using "tag" instead of "label") and omits the comments, one of which is the important (informal) disjointness constraint, and example.

<rdf:Description rdf:about="#altLabel">
<rdfs:label xml:lang="en">alternative label</rdfs:label>
<rdfs:isDefinedBy rdf:resource="http://www.w3.org/2004/02/skos/core"/>
<skos:definition xml:lang="en">An alternative lexical label for a resource.</skos:definition>
<skos:example xml:lang="en">Acronyms, abbreviations, spelling variants, and irregular plural/singular forms may be included among the alternative labels for a concept. Mis-spelled terms are normally included as hidden labels (see skos:hiddenLabel).</skos:example>
<!-- S10 -->
<rdf:type rdf:resource="http://www.w3.org/2002/07/owl#AnnotationProperty"/>
<!-- S11 -->
<rdfs:subPropertyOf rdf:resource="http://www.w3.org/2000/01/rdf-schema#label"/>
<!-- S12 (not formally stated) -->
<rdfs:comment xml:lang="en">The range of skos:altLabel is the class of RDF plain literals.</rdfs:comment>
<!-- S13 (not formally stated) -->
<rdfs:comment xml:lang="en">skos:prefLabel, skos:altLabel and skos:hiddenLabel are pairwise disjoint properties.</rdfs:comment>
<!-- For non-OWL aware applications -->
<rdf:type rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#Property"/>
</rdf:Description>

SBRM and other OMG processes need to be able to connect documents to the components therein. RTF members have requested that we add these terms to the documents ontology to facilitate mapping to other document ontologies as well as for extension purposes.

Several OMG members have requested a general ontology that includes sites and facilities, which are currently modeled in FIBO, primarily for lending and asset management purposes, but they are also needed for retail and manufacturing. The relationship between a site and a facility is many to many, and modeling them for manufacturing as well as retail, energy, military, and other domain areas can be tricky. Having the general pattern that can be extended by any domain area would be very useful for extension purposes.

Ontology StructuredCollections adds properties to Constituent which tend to add confusion rather than value. Specifically it adds a synonym "element" with explanation "an element is part of a set..." yet a set is by definition unstructured - the opposite the whole purpose of the ontology which is structured collections

The class ChronologicallyOrderedCollection is unclear when it says "structured collection whose elements are ordered by time", since the elements are more than simple (time) values but individuals with potentially many properties which are time-related. Even for the example given of bank transactions there's often a difference between the time the transaction happened and when it was recorded: my credit card statement has both "Post Date" and "Trans Date" - with the statement ordered by Post Date. And in some cases the time-related property might be on a separate linked individual. For some cases it could get a lot more complex e.g. employment for a person - there might be period overlaps.
Even ChronologicallyOrderedConstituent does not help - it seems to select only hasObservedDateTime which is both over-specific (how does it help with Employment?) and still under-specified (since hasObservedDateTime is itself pretty vague "indicates a date and time associated with an event, measurement, record, or observation" which does not discriminate the above examples or help with Employment).

It's counterintuitive that the class StructuredCollection is not in the ontology StructuredCollections. It breaks the naming pattern that an ontology is named after its principle class.

Commons is missing a class representing a simple ordered list of items. The class StructuredCollections:List is far too heavyweight for general use:
Each member must be an IndexedConstituent which in turn must have a value for comprises which is an IndexValue defined in an IndexingScheme and only that actually refersTo a nonNegativeInteger.
      myList a :List ;
      :hasMember [
            a :IndexedConstituent ;
:comprises [
a :IndexValue ;
:characterizes <member1> ;
:isDefinedIn :myScheme ;
:refersTo ??;
:hasNumericValue 1
]
           ] ,    
           a :ListMember ;
            :refersTo <member3> ;   
            :hasSequence 3 ;
           ] ,    
           a :ListMember ;
            :refersTo <member2> ;   
            :hasSequence 2 ;
           ]    
.
That might represent a StructuredElementList but for a basic list one would only need one class and two properties - something like:
      myList a :List ;
      :hasMember [
            a :ListMember ;
            :refersTo <member1> ;   
            :hasSequence 1 ;
           ] ,    
           a :ListMember ;
            :refersTo <member3> ;   
            :hasSequence 3 ;
           ] ,    
           a :ListMember ;
            :refersTo <member2> ;   
            :hasSequence 2 ;
           ]    
.

There is a gap in the quantities and units ontology whereby we cannot represent counts of things, which do not necessarily have units, nor can we properly represent ratio values, which may involve scalar quantity values that do not have units. There is also a challenge in representing ratio values more generally, since there is no numeric value representing the ratio on the class.

This is needed for representation of tensor and vector quantities for the quantities and units ontology, and for representation of certain machine learning algorithms, among other requirements.