metanorma / metanorma-plugin-glossarist

Glossarist plugin for Metanorma
BSD 2-Clause "Simplified" License
1 stars 0 forks source link

Preferred designation of a concept also set as preferred in another concept #37

Closed opoudjis closed 3 weeks ago

opoudjis commented 2 months ago

https://github.com/metanorma/metanorma/issues/75

This is not necessarily a bug, but I need it to be investigated.

In isotc204-glossary/concepts, we have several instances where the term name given in one reappears as a designation in another term:

[[urn_iso_std_iso_14812_3.3.1.12]]
=== lane
preferred:[generic lane]

...

[[urn_iso_std_iso_14812_3.3.1.13]]
=== traffic lane
preferred:[lane]

Metanorma complains that "lane" occurs in both 3.3.1.12 and 3.3.1.13, and it should. "Preferred" means that "lane" is an equally applicable name of both terms, and that makes it ambiguous.

My suspicion is that you shouldn't be using preferred:[] here, but admitted:[], the indication of an alternative (but not preferred) designation of a term. That is actually the default for ISO terms; preferred, saying that the two designations are fully equivalent, is an exception; and in fact it's an exception that is not supported in ISO; it was introduced for glossarist.

In https://github.com/metanorma/metanorma-standoc/issues/797, we differentiate their rendering:


term; preferred-name

admitted-name


If these second names were given on the next line in the source document, please change their markup accordingly, from preferred to admitted. This is likely not just a glossarist rendering issue, but a source representation issue.

opoudjis commented 2 months ago

I do see that admitted:[] is used elsewhere in the export. Still want to query this. Using "lane" as the first preferred designator in 3.3.1.12 (generic lanes), and the second, but equally preferred designator in 3.3.1.13 (traffic lanes), may be intentional, but it is still a bad idea. The point of termbases is to make technical vocabulary less ambiguous, not merely to document ambiguity.

ronaldtse commented 3 weeks ago

The source is in officially published standard, in STS XML:

<term-sec id="sec_3.3.1.12"><label>3.3.1.12</label>
<tbx:termEntry id="term_3.3.1.12">
<tbx:langSet xml:lang="en">
<tbx:definition>&lt;generic&gt; portion of <tbx:entailedTerm target="term_3.3.1.2">road reservation (3.3.1.2)</tbx:entailedTerm> intended to accommodate a single line of moving <tbx:entailedTerm target="term_3.1.1.3">material entities (3.1.1.3)</tbx:entailedTerm> along its length</tbx:definition>
<tbx:example><tbx:entailedTerm target="term_3.3.1.13">Traffic lane (3.3.1.13)</tbx:entailedTerm>, <tbx:entailedTerm target="term_3.3.3.1">cycle lane (3.3.3.1)</tbx:entailedTerm>, <tbx:entailedTerm target="term_3.3.3.4">sidewalk (3.3.3.4)</tbx:entailedTerm>.</tbx:example>
<tbx:note><tbx:entailedTerm target="term_3.3.1.12">Lanes (3.3.1.12)</tbx:entailedTerm> are often bounded by lane markings.</tbx:note>
<tbx:note>Lanes may be significantly wider than the normal vehicle width to allow variance in lane position of the vehicle as well as for various vehicle dimensions.</tbx:note>
<tbx:note>The "lane" nomenclature typically refers to <tbx:entailedTerm target="term_3.7.6.3">motor vehicle (3.7.6.3)</tbx:entailedTerm> usage, but can also refer to other purposes, such as <tbx:entailedTerm target="term_3.3.3.4">sidewalks (3.3.3.4)</tbx:entailedTerm>.</tbx:note>
<tbx:tig id="term_3.3.1.12-1">
<tbx:term>lane</tbx:term>
<tbx:partOfSpeech value="noun"/>
</tbx:tig>
<tbx:tig id="term_3.3.1.12-2">
<tbx:term>generic lane</tbx:term>
<tbx:partOfSpeech value="noun"/>
</tbx:tig></tbx:langSet>
</tbx:termEntry>
</term-sec>
<term-sec id="sec_3.3.1.13"><label>3.3.1.13</label>
<tbx:termEntry id="term_3.3.1.13">
<tbx:langSet xml:lang="en">
<tbx:definition>portion of <tbx:entailedTerm target="term_3.3.1.5">carriageway (3.3.1.5)</tbx:entailedTerm> designed to accommodate a single line of moving <tbx:entailedTerm target="term_3.7.6.1">road vehicles (3.7.6.1)</tbx:entailedTerm></tbx:definition>
<tbx:note>The term "lane" is often used to refer to a "traffic lane" when the context is known to be "traffic".</tbx:note>
<tbx:note>A traffic lane can be bi-directional, such as a single lane <tbx:entailedTerm target="term_3.3.5.1">road (3.3.5.1)</tbx:entailedTerm>, a two-way turn/overtaking lane, or a reversible flow lane.</tbx:note>
<tbx:note>Some jurisdictions allow supplemental uses of a traffic lane, such as multiple motorcycles sharing the width of a traffic lane or allowing a bicycle to use the edge of a lane.</tbx:note>
<tbx:tig id="term_3.3.1.13-1">
<tbx:term>traffic lane</tbx:term>
<tbx:partOfSpeech value="noun"/>
</tbx:tig>
<tbx:tig id="term_3.3.1.13-2">
<tbx:term>lane</tbx:term>
<tbx:partOfSpeech value="noun"/>
</tbx:tig></tbx:langSet>
</tbx:termEntry>
</term-sec>

The encoding in the OP is correct as it stands, and this is indeed a problem to be resolved.

[[urn_iso_std_iso_14812_3.3.1.12]]
=== lane
preferred:[generic lane]

...

[[urn_iso_std_iso_14812_3.3.1.13]]
=== traffic lane
preferred:[lane]
opoudjis commented 3 weeks ago

My objections stand, but if the client wants the ambiguity in an official terminology, that's on them. Closing.

ronaldtse commented 3 weeks ago

Thanks @opoudjis , it's fine to raise warnings against this because the situation does present an ambiguity.