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

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.

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

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.

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.

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.

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)

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.

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.

Concepts including authorization (as a situation), roles of authorizing party and authorized party, and related properties are needed by a number of task forces for describing the legal authority some party may have with respect to some organization or process, including delegated authority.

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)

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.

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

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.

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

1. County and FederalCapitalArea should be subclasses of CountrySubdivision

2. FederalState should have synonyms rather than this in the note "variously referred to as a state, province or canton".

3. Several annotations on geographic region identifier and a few other concepts need clarification

Cleaned up a few issues identified in the locations ontology during review

These include adjusting the class hierarchy for consistent representation of country subdivisions as well as minor adjustments to definitions

Rather than classifying 'something' an aspect should classify a set or group of things - at a higher metalevel than 'quality' in BFO, for example. This impacts the Classifiers ontology, in which Aspect is defined.

Clarified the definition of the Aspect class

Revised metadata to be current and revised the definition from

'characteristic or feature that can be used to dimensionalize, filter, or subset something'

to

'characteristic or feature that can be used to dimensionalize, filter, or a class, collection, or set of things'

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.

The issue of unitless measures should be addressed in the context of the work we are doing with tensors and vectors

There is ongoing good work on an ontology for tensors and vectors, with planned revisions for tensor and vector quantities planned for the Commons 1.3 RTF due to the amount of work involved. This issue should be resolved in conjunction with that one in case there are relevant related revisions.

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

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

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.

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.

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.

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