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.

Locations is missing a hasState property

Add a property called 'hasPrimarySubdivision' for use in querying in cases where RDF entailment or other reasoning is employed in order to reduce the results returned to only those that are considered primary.

This resolution depends on the results of Ballot #4, including the resolution to COMMONS13-28.

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.

Need the definition of capacity in organizations and to contrast it with capability

This resolution adds the concept of 'capacity' to the organizations ontology as requested.

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.

US-centric geopolitical terminology

This issue raises two questions: (1) whether certain concepts are overly US centric, which is addressed by use of LCC, and (2) the definition of geopolitical entity, which we have raised COMMONS13-49 to address.

With respect to US language, the concept of a county uses the same language used in other English speaking countries including the UK, Australia, etc. The concept of a federal state applies in a number of other countries including Mexico. LCC contains the names for all subdivisions world-wide that are reported to the UN in their native language(s), and so making these kinds of modifications to find more common terms, given that American English is the language of OMG specifications, is redundant.

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.

Poor definition of ctxtdsg:isUsedBy

This resolution simplifies and clarifies the definition of isUsedBy and makes minor adjustments to the definition of uses.

Note that any issues in consistency with respect to how these properties have been used by FIBO is outside the scope of Commons.

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

Additional taxonomic relations are needed in the classifiers ontology

Work to add some capabilities for taxonomic relationships is being done in the context of MVF. The MVF RTF could propose adding those concepts to the classifiers ontology, but there is no need to duplicate the work that they are doing, regardless of where these concepts land.

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.

The documents ontology is missing the notion of a document part

This resolution adds the requested concept of a document part to the documents ontology.

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.

StructuredCollections ontology misnamed

The issue states that there is a requirement that an ontology in Commons must include a class that has the same name as the ontology, and that as a consequence, this ontology is misnamed.

There are other cases where we have expanded on a concept and created a subordinate ontology that does not include the class of the same name, and we should be able to continue doing this without the constraint. If, for example, a particular community needs an expansion on some concept, we would add that new ontology expanding on the higher level, but not necessarily move the concept to the lower level. There are cases where people may need the notion of a structured collection but not the library of kinds of structured collections that might be useful for some use case.

Ontology renaming is quite disruptive, in fact, for people already using it, and should be avoided to the degree possible. The same is true for naming of concepts, although one can argue for doing that if it is appropriate for modularization or to create a higher-level concept on which multiple lower level concepts depend for interoperability. This is not that case, howevere.

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)

Annotation Vocabulary missing discussion of labeling policy

The RTF determined that adding notes to each of the subproperties of rdfs:labels to indicate the issue with queries that use entailment may return multiple labels was sufficient to address this issue.

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>

Address Awkward unions of RA and Registrar

This revision clarifies the distinction between a registrar and registration authority, enabling individuals playing both roles to be multiply classified as such and eliminating the unions that the issue raises.

Note that the diagram in Clause 8.16, Figure 17, will be revised via the resolution to issue COMMONS13-38.

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)

Unnecessary description properties in Designators

The properties in question come from the semiotic triangle (describes, defines, denotes), and were discussed at length when we first added them to the ontology. They are heavily used in IDMP, FIBO, API4KP, and elsewhere.

They are: describes, isDescribedBy, and hasDescription. With respect to dct:description, which was mentioned in the issue description, that's an rdf:Property commonly used as an annotation property in OWL. hasDescription in the Designators ontology is a data property. A data property is required for use in mapping attributes, where use of an annotation doesn't work. Revising the semantics of Dublin Core in our Commons ontologies would violate best practices in reuse / FAIR use of the vocabulary.

We agreed to add usage notes to the 3 properties in question, as provided in the body of this resolution.

Note too that Dublin Core is not an OWL ontology - it is an RDF vocabulary, and as such cannot be imported in any OWL ontology, only referenced. This is a nuance that many people don't understand, but is really important for consistency across uses. There are many folks out there that incorrectly import Dublin Core unfortunately, but that can cause inconsistency errors for reasoning, among other issues.

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.

Need the ability to describe the concept of authority

This revision adds a new business authorizations ontology, updates the relevant metadata files, and reuses the concept of an authorizing party in regulatory agencies and registration authorities.

This resolution depends on the resolution of the issues included in Ballots #1-#3 in terms of the metadata changes made therein to various files, as well as on the resolutions of COMMONS13-10 and COMMONS13-27 in order to update the AboutCommons metadata file to include the new ontologies. This file does not add semantics, however – it is provided for ease of use only.

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>

Locations ontology should reuse W3C WGS84 ontology

Added references to the WGS84 ontology using rdfs:seeAlso, given that the properties in this vocabulary are RDF properties and not directly usable in OWL. Also revised links to ESRI according to their new dictionary, and added hasAltitude for the sake of completeness.

Note that this revision depends on the resolution of Commons-1.3.20, which covers all changes made through Ballot #3.

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>

Annotation Vocabulary has incomplete definitions from SKOS

Modified the Annotation Vocabulary to revert to the precise annotations used in SKOS and Dublin Core rather than avoid circular definitions and comply with ISO 704, (which is required by ISO and thus for all OMG ontologies). Original explanatory notes remain in the ontology, though.

This change depends on the resolutions to issues in Commons 1.3, including revised metadata, through Ballot #3.

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.

Could a "date period" be defined even without knowing the exact dates?

Revised the comments on DatePeriod to indicate that a date period can be incomplete, i.e., one where the period is known but start and end dates are not, such as a 4-day work week or 5-day conference.

The resolution of this issue depends on the resolution of Commons-1.3-20.

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.

Need to augment the locations ontology to cover sites and facilities, or create a new ontology for these concepts

This resolution adds a new Sites and Facilities ontology, per the request from several OMG task forces and members as well as external Commons users. The proposed ontology has been tested extensively by FIBO and IDMP-O users, among others.

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.

Need to add the definition of language to the Codes and Code Sets ontology

This resolution adds a new Languages ontology for use in aligning and simplifying API4KP, DOL, LCC and MVF.

See the resolution to issue COMMONS13-32 for metadata and a revised overview diagram for the Designators ontology. This resolution adds a single property, hasTag, as covered in the attached revised Text, but the remainder of the details, including other changes needed to resolve COMMONS13-32 are covered under that issue resolution.

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

Constituent term has two issues

The first 'issue' was with respect to the namespace prefix, asking what it means. The prefix, 'cmns-col' is defined in clause 7.2, Table 7.2. That table includes all of the namespace prefixes for all ontologies included in the Commons library.

Secondly, the issue suggests a rephrasing of the explanatory note added to constituent in the structured collections ontology. The note comes from ISO 5127, which uses the term 'element' rather than 'constituent' in a synonymous way. We added the note and synonym in structured collections, with the thought that in the context of that note, the term 'element' was more appropriate (and was what the ISO standard used).

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.

Reference to GMT should be to UTC instead

Revise the annotation related to the DateTime definition in the ontology and specification to replace GMT with UTC.

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.

Refine annotation hierarchy for better alignment

The issue makes a good point regarding normalizing the hierarchy among external annotation properties, despite the fact that OWL reasoners ignore these kinds of axioms.

The RTF determined that we should not only improve that hierarchy in a few cases but make a statement about why we've done so in the ontology metadata.

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

Missing word "Revision"?

This issue was addressed editorially prior to publication of the Commons 1.2 specification, formal/25-02-03.

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

Typeface issue (LogarihmicScale should be bold)

This issue was addressed editorially in the formal Commons 1.2 specification prior to publication (formal/25-02-03)

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

Revised the structured collections ontology to use hasMember in place of hasConstituent

The definition of hasMember reflects the notion of a discrete member rather than one that may not be distinguishable, and thus this change revises the ontology such that the correct property is used in a couple of restrictions.

The definition of List includes "set of related items"

Revise the definition of list to eliminate the notion of 'set'

The original definition required the elements in a list to be part of as set, which is not correct. The definition should be revised to be clearer and more in line with how it is commonly used at OMG and elsewhere.

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.

Need an ontology representing multidimensional arrays

We agree that this is important, but have been waiting on adoption of SysML v2 and its new quantities and units library in order to complete the work. We plan to do so in Commons 1.4 now that SysML v2 has been adopted.

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

Need for simple ordered List

RDF provides the concept of an atomic list, similar to what is described in the request. This concept is rarely used in ontologies, where a richer notion such as the pattern provided in the structured collections ontology is often needed.

The concept of a simple list needs more discussion and specific use cases, and explanation for potential users as to when this should be used over the built in list structure available in RDF.

We are deferring this issue due to the need for use cases and more discussion.

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

Ill-defined notion of "ordered by time"

This needs much more discussion and use cases, as the concept included in the structured collections ontology is more about ordered records, not about richer concepts such as employment, for which FIBO, for example, uses the pattern expressed in the parties and situations model. That pattern is significantly richer with respect to the options for representation of a period of time for which the state of affairs holds.

We are deferring this to allow for use cases to be presented to the RTF and contrasted with suggesting that users leverage the parties and situations model for more complex states of affairs.

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 quantities and units ontology does not allow representation of unitless quantity values

We agree that this needs to be addressed. The RTF plans to work with the SysML v2 team to revise the quantities and units ontology to incorporate tensor and vector quantities, and review other related concepts in the course of doing so. SysML v2 has only recently become an adopted standard, however, and due to time constraints we need to defer this to Commons 1.4.

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

Confusing properties added to Constituent by StructuredCollections

Resolving this issue requires further discussion, and should be addressed in the context of other related issues, such as COMMONS13-36, which the RTF has deferred to Commons 1.4.

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

Add additional metadata for external ontology registration

Resolving this issue requires agreement on the list of additional annotations needed to support registration of our ontologies in external systems. The LOD community, for example, while widely used for a combination of ontology and vocabulary registration, suggests use of annotations that are in vocabularies that are no longer maintained or that include embedded, viral references to vocabularies that are either no longer maintained or that are not allowed for use on various government or commercial systems.

In other words, more research is needed, and agreement on the set of annotations and criteria for determining such a list, as well as which target repos we want to propose inclusion of OMG ontologies in, should be determined with consensus of, for example, the OMG AB.

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 constituent, and of the property hasConstituent needs additional refinement

This issue should be merged with COMMONS13-36 and the two addressed together, since they raise similar issues.

We deferred COMMONS13-36 due to the need to test a potential change with example data, thus this companion issue is being deferred as well.

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.

expressesTheMagnitudeOf seems wrong

The current definition of 'expressesTheMagnitudeOf is, in fact, 'specifies the quantity that some quantity value reflects', not 'indicates the subject or topic of something, such as a document', as described in the issue.

It may be the case that we need to refine this definition, and the RTF plans to review all of the definitions as we integrate additional quantities from SysML v2, but in this case, the person that filed the issue was looking at the wrong definition.

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

Unclear distinction between hasPart and hasMember

The RTF agrees that additional clarifying annotations would be helpful to users, but any inconsistency in FIBO in using these properties should be addressed there, not in Commons per se.

In order to confirm whether or not we can make hasDirectPart a subproperty of both comprises and of hasPart, though, we need some additional time to create test cases. The RTF plans to do so in Commons 1.4.

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

Certain ontologies would benefit from having a node id for ontology elements that supports searching

Resolving this issue requires a bit more research, and should take into account the changes that are coming in RDF 1.2, which simplifies reification among other things that may be relevant.

We are deferring this to allow for more discussion and to await finalization of the RDF 1.2 specification.

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 definition of geopolitical entity in the locations ontology needs refinement

The RTF agrees that this is important to address, but changing the definition of geopolitical entity, adding political entity, and then testing this with a revision of LCC that leverages this change will take time.

Thus we agreed to defer this to Commons 1.4.