The definitions in Collections are terse or drawn from diverse sources, and the notes focus on technical aspects (such as transitivity) that don't help a modeler decide which to use.
hasMember definition is overly terse, whereas hasPart is almost absurdly long and littered with disjunctions making it all-inclusive of anything.

in FIBO for example hasPart is used to link from a PooledFund to its FundUnits, and a BondPool to its Bonds. And from a Judiciary to its Courts.
But on the other hand hasMember is used to link a Program to its Projects and an InstrumentPool to its FinancialIstruments.

Clearly there is some understanding of the distinction being deployed in FIBO, especially related to Pools, that is not clear in the Commons definitions. Especially because BondPool subclasses DebtPool which subclasses InstrumentPool which has a hasMember restriction, yet hasPart is used.
Also it's unclear why hasPart has no relation to comprises.
Generally I think there's too much in authors' heads and not enough written - which is essential for successful and consistent usage in ontologies, data and queries.

Definitions follow:
hasMember: includes, as a discrete element. Note that the domain of hasMember should be some sort of collection, aggregate, or group. In the Financial Industry Business Ontology (FIBO), hasMember is used in the case of parties (people and organizations), whereas comprises can have anything in its range.

hasPart: indicates any portion of something, regardless of whether the portion itself is attached to the remainder or detached; cognitively salient or arbitrarily demarcated; self-connected or disconnected; homogeneous or gerrymandered; material or immaterial; extended or unextended; spatial or temporal

It has hasCountry and hasCounty but not hasState. The examples use hasSubdivision which is the super property, but trying to get back the state via hasSubdivision will also return the County and the Country.

The phrase "is employed in the process of accomplishing something for" is poor English: specifically the final word "for".
I'm not even sure why it's even in ContextualDesignators since it's not referenced anywhere.

It's certainly not formally defined enough to be used to represent the notion of a restricted legal currency for a country.as in
<owl:Class rdf:about="&fibo-fnd-acc-cur;Currency">
...
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="&cmns-cxtdsg;isUsedBy"/>
<owl:someValuesFrom rdf:resource="&cmns-loc;GeopoliticalEntity"/>
</owl:Restriction>
</rdfs:subClassOf>
And this is nothing to do with the notion of context.

There is also inconsistent usage - the above is use by a geopolitical entity; there is also fibo-fnd-acc-cur:CalculatedPrice uses PricingModel which is not an entity and has quite different semantics.

There are several places with restrictions such as the following. It would be preferable to just use Registrar, separating the concerns. In those cases where a RA also does registration then it could be multiply classified as a Registrar too. <owl:someValuesFrom> <owl:Class> <owl:unionOf rdf:parseType="Collection"> <rdf:Description rdf:about="&cmns-ra;RegistrationAuthority"> </rdf:Description> <rdf:Description rdf:about="&cmns-ra;Registrar"> </rdf:Description> </owl:unionOf> </owl:Class> </owl:someValuesFrom>

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.

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.

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.

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.