SysML v2 defines scalar quantities in terms of tensor and vector quantities, but these are missing in the Commons quantities and units ontology. They are needed to generate the library corresponding to the SysML quantities and units library

Currently, a geopolitical entity is a subclass of geographic region. But, a geopolitical entity can span regions, and in a handful of cases may not be associated with well-defined borders. A geopolitical entity would be better defined as a political entity associated with a geographic region, and loosen the relationship between the two concepts.

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

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

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

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.

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.

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

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.