Terminology and definitions in the core vocabularies

[aidig]

In general, it would be helpful if more attention could be paid to composing structured and application neutral definitions in order to ensure wide reuse of the core vocabularies.

Adopting a common methodology for composing definitions across the core vocabularies, will strengthen the semantics and improve the quality of definitions, which will in turn help ensure that users interpret the vocabularies in a uniform and interoperable way.

Definitions of elements should be structured in a standardized way. Definitions should be formulated as
intensional definitions, stating the genus (the nearest superordinate concept) and differentia (properties
that differentiate the concept from other members of the genus). This approach is widely adopted in terminology and standardization work.

By composing intensional definitions, it is easier to achieve concise and precise definitions that unambiguously and in a robust manner convey the meaning of a concept, and, equally important, a number of inappropriate characteristics of other definition types are avoided.

The definition should not contain elements that express an inappropriate limitation of the concept by, for example, describing technological, organizational or political dependencies. Additional context-related comments or examples should not be included in the definition as this information may not be relevant to the definition and may prevent broad reuse of the concept, yet this information can be included as separately annotated information. Things that are only typically or usually true should not be part of the definition, but may be added in a separate comment or usage note if desired.

Inspiration could in several cases be had from IATE (https://iate.europa.eu/home) where many terms and concepts have been defined and also translated into the various MS languages, which should ease adoption in individual MS. If IATE uses a term that is different from what is well-established in the core vocabularies, the IATE term could perhaps be added as a skos:altLabel in order to ease translation tasks.

Comment provided by:
https://github.com/aidig
https://github.com/mayaborges

[aidig]

Examples

These example are to illustrate the request for a greater focus on terminology and definitions in the Core Vocabularies (#12)

Example from Core Business Vocabulary:

Legal Entity (from v.1):

This is the key class for the Business Core Vocabulary and represents a business that is legally registered. In many countries there is a single registry although in others, such as Spain and Germany, multiple registries exist. A Legal Entity is able to trade, is legally liable for its actions, accounts, tax affairs etc. It is a sub class of org:FormalOrganization which covers a wider range of entities, such as charities

Observations:

• does not follow the recommended structure for definitions: [superordinate concept] +[differentiating characteristics]. Perform the substitution test: it should be possible to substitute the term with the definition.
• begin the definition with the superordinate concept and omit phrases such as "This class/concept/element is/represents/covers"...
• definition contains supplementary information which should be added separately as comments, examples or usage notes

Legal Entity : (from v.2)

A Legal Entity able to transact business, typically registered with a body able to confer legal status such as a national business register.
Usage: A Legal Entity is able to trade, is legally liable for its actions, accounts, tax affairs etc. This makes Legal Entities distinct from the concept of organisations, groups or sole traders. Many organisations exist that are not Legal Entities, yet to the outside world they have staff, hierarchies, locations etc. Other organisations exist that are an umbrella for several Legal Entities (universities are often good examples of this). This vocabulary is concerned solely with registered Legal Entities and does not attempt to cover all possible trading bodies.

Observations:
In v.2, the information has been separated and a usage note has been introduced which is great.
The structure appears to follow the recommended structure [superordinate concept] +[differentiating characteristics]
However, the first concept mentioned in the definition should be the superordinate concept. In the above it appears to be self-referring? (Legal entity = legal entity able to transact business?).
In the UML-model the LegalEntity is a specialization of FormalOrganization...

Also, markers such as 'typically', 'often' or 'usually' signal that the following part does not always hold true - here that it is “typically registered with a body able to confer legal status" - yet, the usage note below states that the vocabulary is "concerned solely with registered Legal Entities".
What are the synonyms/alternative labels?

Also, might https://iate.europa.eu/entry/result/755144/all provide input/translations, here the focus seems to be on "having legal rights and obligations"

The definition can leave a reader with questions of which entities are covered by it. In many contexts a legal entity is viewed as something along the lines of something/someone who can enter into a legally binding contract, and ‘able to transact business’ could potentially mean something along those lines. However, most natural persons are able to enter into contracts, as is any organisation who can hire staff or make agreements with vendors, some of which are explicitly excluded in the usage note, so maybe ‘transact business’ is supposed to mean something along the lines of ‘sell things commercially’. This would of course also exclude public organisations, which may be intended, however in a Danish context where certain public organisations are legally defined as legal entities to be registered in our Business Registry the intent is not as clear as one could wish

Example from the Core Person Vocabulary

residency

Residency typically provides an individual with a subset of the rights of a citizen.

Observations:

• The definition is not concerned with what residency is, but with what the effect of having one is. If you don’t know beforehand, it would not give any idea that it has to do with living somewhere.
• The definition only mentions something that is typically true. A definition should only contain what is always true.
• A definition should not contain the term it defines

Example from CPOV

Foundation Event

Public Organizations are formed and changed in response to events. This may be the result of new legislation, new policies, taking on new obligations etc. The CPOV captures this in its Change Event class but recognises the specific case of an Organization's foundation as being sufficiently distinct to require a subclass of Change Event.

Observation:
Not a definition, but the rationale for including the class in the vocabulary.
In cases where an element that is being reused has a poor definition it is of course not possible to simply change the definition, but it could be advantageous to add defining information in a usage note.

Regarding reuse of existing elements and usage/application notes:

In cases where an element that is being reused has a poor definition it is of course not possible to simply change the definition, but it could be advantageous to add defining information in a usage note.

gender (Core Person)

• defined as “Gender of the Person”, a “definition” that gives absolutely no information not already available from label and domain. And in fact, the meaning of gender is not clear.

Contact Point (CPOV)

• defined as “A class representing a point of contact.”, which again gives no information about what a contact point is.

Comments provided by:
https://github.com/aidig
https://github.com/mayaborges

[makxdekkers]

Many thanks for your comments, @aidig! You are right that some of the definitions could definitely be improved. We'll take your suggestions into account in the further work on the Core Vocabularies in the next months.

[barthelemyf]

Based on your comments @aidig and on best practices from standards such as ISO (ISO 704:2000(E) and ISO 11179-4:2004(E)), we have proposed a set of rules for defining concepts. We have also detailed an approach to apply these rules as strictly as possible while ensuring that we don't break semantic interoperability of existing definitions. Comments on these rules are welcome!

[fititnt]

We have also detailed an approach to apply these rules as strictly as possible while ensuring that we don't break semantic interoperability of existing definitions. Comments on these rules are welcome!

@barthelemyf very serious public question here: for head terms an/or definitions that already are part of the Core Vocabularies and are considered by outside organizations as nomina periculosa, the editors of SEMICeu will prioritize:

a. Will SEMICeu prioritize protect human lives based on new evidence
b. Keep "strict conformance" or "keep software backward compatibility" whatever it takes

Note that while the set of rules you mentioned did not cite "don't break semantic interoperability of existing definitions" (so, by your quote, there are unwritten rules, which already are problematic, as it seems to override the written ones) the written rules only mention ISOs, where the ISO (organization) already is relatively new on nomenclature and typically not found fit for scientific names (which, by the way, is more what SEMICeu is doing). The written rules, for example, did not have any mention for existing Scientific Nomenclature which go back as far as Carl Linnaeus 1758. The SEMICeu/Core-Person-Vocabulary already do have serious, life threatening harmful, nomenclature issues which clash with existing conventions, like the ones used by World Health Organizations, when translated to other languages.

[EmidioStani]

The updated definitions can be found here: https://github.com/SEMICeu/CPOV/blob/master/releases/2.00/Changelog_definitions.md