Terms, naming, and identification

[RieksJ]

This issue is raised for the purpose of collecting the changes that need to be made to the specification texts, and the tools (i.e. the MRGT and the TRRT), so that some problems with ambiguities in identifiers in the current spec can be nicely resolved. The following post details these problems so that this post can be used for collecting the changes (by editing this post).

Discussions have led to the following conclusions:

1. There should be 'primary keys' (proper, first class identifiers) for all kinds of entities we need to talk about. (@sih)
2. Every terms should represent one knowledge artifact, period (see Syntax for Terms #15) (@dhh1128)
3. This can be both done by have curated texts specify the term (and any synonyms) that represents the specific, single, knowledge artifact that it documents. (@RieksJ)
4. We no longer talk about id-fields, e.g. as used for Docusaurus, as that is considered to be outside the scope of our work. Due to the adoption of the 'transformation pattern', a rough description of which (that needs to be refined) is currently given here, we can see how each term can be automatically converted into an id if necessary. Current experience with the eSSIF-Lab TEv2 stuff does not produce any problems (so far).
5. The current TermRef syntax [showtext](id#trait@scopetag:versiontag) can remain if we replace id with term.

The terminology pattern has been adjusted to this:

[RieksJ]

Here is the reasons for this issue:

Chances are currently too high that users of TEv2 (curators, authors, others) get confused by that various ways in which stuff can(not) be identified (one of which is me). It must be crisply clear what identifiers are used for what purposes, and what it is they can identify.

One cause of this is that while identifiers are simply texts that are used for identification purposes (see its definition), that doesn't mean that when they are used, they actually (successfully) identify something. And it is well known that a single identifier may (successfully) identify different things in different contexts.

TEv2 is no exception, and terms may readily be ambiguous/overloaded. For example a text like 'guardianship' might identify a pattern that relates various concepts, thereby providing a mental model of what 'guardianship' entails, but it might equally well identify a concept, e.g. the specification of a set of rights and duties between parties in a jurisdiction, that enable them to care for and/or protect/guard/defend a vulnerable person.

[sih]

Will leave the bug label for implemented features that aren't working rather than changes to features

[RieksJ]

This thinking has changed the way Term and Scoped Term are thought of. While the definition of Term does not need to be changed - it remains a a word or phrase (i.e.: text) that is used in at least one scope/context to represent specific knowledge artifacts - the novelty is that it now consist of multiple parts (Name, Type and Attributes), of which only the Name part is required, and there can be at most one Type. This allows for having ambiguous names, that can be disambiguated by mentioning the type, and (in future) other attributes. Every Scoped Term, then can remain a Term that represents precisely one Knowledge Artifact. See also #15.

Continued work shows that knowledge artifacts, curated texts etc. are now much clearer to understand (for me, at least). It has also led to some modifications in the organization of frontmatter fields - more has been transferred to the generic header fields, and very little is left in the specific header fields. Also, some fields (for which the use case isn't clear) will be removed.

[RieksJ]

@sih: With PR #113, the documentation has become in line with te changes mentioned in the first post. One (easy) way to see changes is to look at at the list of common MRG-entry fields (and perhaps the very similar list of common CText header fields) and compare them with the MRGT code.

After that, you can close this issue.

[sih]

Just removed the in development label as haven't begun working on this yet, but I will add it again once I've started

[RieksJ]

@sih I am pondering on the idea to replace the basic syntax for termrefs (that uses the id that identifies a ctext) with the (still to be defined) syntax that will use a term (i.e.: some combination of termname, termtype and termparams, to be specified in #15 ). That would obviously impact the TRRT, but I don't see any impact on the MRGT. Do you agree?

[RieksJ]

closed - see essif-lab/framework#127.