Syntax for Terms

[RieksJ]

We have recently specified the following model as a generic way to deal with terms:

It is characteristic of a Term to represent (identify) a single Concept (or other Knowledge Artifact, such as a mental model, use-case etc.). Most often, a name (TermName) suffices for that purpose. However, there are also examples where the same name is used to represent different kinds of knowledge artifacts (within a single scope), e.g. guardianship can represent a set of rights and duties that enables a guardian to care for a 'dependent', but guardianship can also refer to a mental model that deals with how to define such rights and duties, how to instantiate them, how they may be used, etc. Thus, there are cases where the class/type (TermType) of the knowledge artifact must be taken into account as well.

In theory, there is even more. For example a relation named 'Owns' can have different forms, e.g. 'Owns(Party,Idea)' would be quite different from 'Owns(Party,LegallyOwnedProperty)'. Distinguishing between such terms requires the ability to include attributes (TermAttrs) in the Term.

Under the assumption that the model shown in the figure makes sense, I would like to see a syntax for a Term that

• would not require authors to specify TermType or TermAttrs, unless that would be necessary to actually identify the knowledge concept it is intended to represent.
• allows authors to specify TermType or TermAttrs if they like to (e.g. for completeness reasons), or if it is necessary to actually identify the knowledge concept it is intended to represent.
• can be used in conjunction with the current specification of term refs, as a substitute for the id field (the TRRT-tool should be able to distinguish between the occurrence of an id that identifies a curated text (i.e. is the id field in a curated text), and the occurrence of the Term-syntax that we are devising.
• can be used to easily create a YAML-list of terms, so that we can do synonyms.
• is disregarded by standard markdown renderers when it is used as a part of the term-ref syntax (as is currently the case; this means that it doesn't produce rendered texts that distract the reader from the text by showing (parts of) the term-ref syntax.)

[sih]

My understanding of the above:

Terms are equal (i.e. the same term) if and only if:

• The TermName is the same (I think it's best to take the same as meaning case-insensitive)
• The TermType is the same
• Each of the TermAttrs are identical (although they can appear in a different order)

Out of all of those, only the TermName is mandatory. So for two terms where there is only a name, then that is the comparison made.

Given that I wonder whether we remove the termid in the curated terms, but create one for the MRG. It will be a useful shorthand for the above, and may in turn be useful down the line in TRRT territory.

It can be human-readable, e.g. TermName-<index> where index represents each occurrence of that name. Or it can be a hash of the key attributes (e.g. name, type, and attrs)

[RieksJ]

For our intended purposes, (strict) equality is not needed. Rather, we need to specify the procedure whose inputs are (a) a term, and (b) a terminology (i.e. a set of MRG-entries), and produces a subset of MRG-entries that match the provided term. This would mean that if a term were provided that only has a TermName, the resulting set would select all entries whose termname field has the same value as TermName (regardless of whether or not the MRG-entry would has a value in the termtype field). Then, if also a TermType is specified (and/or TermParams), the selected set is weeded out more and more. In the end, the subset is either empty (error: term not found in this scope), it has multiple entries (error: term is ambiguous in this scope), or it has exactly one element (hooray! term found!).

I've done a preliminary writeup of this matching process in the TRRT specs

[sih]

That certainly works for selecting terms from other scopes. However, if we have curated terms where the term name is the same (as per your examples above) won't we need strict equality in order to generate an MRG?

[RieksJ]

Ah. You are perhaps referring to the construction of a terminology, where we say that if a term that is 'imported' already exists in the terminology-under-construction, the existing term will be discarded (overwritten, superseded, ...). I hadn't thought about that.

Pondering the idea, and reviewing the terminology construction text, it seems that there is some unfinished business here, which I'll take back to #3 .

[RieksJ]

@dhh1128 do you have suggestions for a syntax for terms that satisfies the requirements of the first (edited) post?

[dhh1128]

I think you might be combining some ideas in a way that's not standard in terminology theory.

A term is a label for a concept. The end. There is no "type" in a term. There are no "attributes" in a term. A term has an associated type and attributes, but there is nothing inside the term except the characters that constitute its content. Thus, the diagram you would use, if you wanted to follow terminology theory, might be something like this:

By "syntax for terms", I assume you mean a URL syntax that disambiguates "foo" in sense 1 from "foo" in sense 2. If so, then I suggest you add a concept id to the URL as an optional component. You don't need to reference the attrs or the type -- just which concept is the term's referent.

[RieksJ]

@dhh1128 Thanks for pointing out some terminology-theory terminology. I'll consider that when the issue is closed.

What I am looking for is a syntax that is similar to the one we devised for references (to terminology) in markdown, which is of the form [showtext](id#trait@scope:vsn), but replaces id with term (per your figure), and optionally also type and/or attrs.

It occurs to me that I could perhaps also phrase it as: I would like the part id to be extended with two optional arguments. What characters (similar to #, @, :) are available such that markdown renderers would mess up the rendered texts (e.g. when such links are used within tables or other markdown curiosities)?

[dhh1128]

You could maybe use + or ;. But I don't think references that include term type or term attrs are conceptually correct. References that include the identifier of the related concept would make more sense, IMO. So instead of:

[showtext](id+type+attrs#trait@scope:vsn)

...I recommend:

[showtext](id+concept_id#trait@scope:vsn)

[RieksJ]

Ah. I was thinking (wrongly) only about 'special' characters, not + or ;. But they would serve the purpose.
And so perhaps also ,, $, &, *, !, and ?. Correct?

[RieksJ]

I'd like to discuss the conceptual (in)correctness of references that include a term type. The current (formalized) terminology model states that a (scoped) term represents, AND identifies a specific knowledge artifact, which are not only (the intangible) concepts, but also (intangible) mental models, relations between concepts, and more.

I would like to be able to have the word terminology refer to a mental model type of knowledge artifact, as well as to a concept type of knowledge artifact, because that's how such words are used in practice, within a single terms-community/scope. In the glossary of that terms-community, terminology would then appear with a meaning as a concept, and with a meaning as a mental model.

Essentially, this boils down to wanting the ability to semantically overload a single term within the scope of one terms-community, yet retaining the ability to precisely identify the associated knowledge artifacts.

[dhh1128]

The current (formalized) terminology model states that a (scoped) term represents, AND identifies a specific knowledge artifact, which are not only (the intangible) concepts, but also (intangible) mental models, relations between concepts, and more... with a meaning as a mental model... semantically overload a single term...

Terms are not supposed to be semantically overloaded; that kind of defeats the purpose of them.

Isn't a mental model just a specialized type of concept that has certain special properties? (I know, it may not have been modeled as a subclass of "concept" as it's been conceived thus far; I'm asking about whether mental models are concepts as "concept" is generally understood outside our context...

[RieksJ]

While I wouldn't know what the "general understanding outside of our context" of the term "concept" is, I have currently no objections to have it represent what I've come to call "knowledge artifact".

I agree that a (scoped) term must not be semantically overloaded. It's precisely why I considered having it consist of multiple parts, the only required one of which is a 'name' (which you call 'term', but that's not the issue). It would mean that a (scoped) term is a text that typically only consists of its name, but can have added characters/words when necessary.

Isn't that what happens often in practice? I can imagine a person (Alice) referring to "the door", and Bob goes: "which door", and Alice responds "the kitchen-door" or "the door ..." (and adds some attributes that supposedly enable Bob to identify the door that Alice means.

It seems as if we're dealing with some issues I've tried to grasp in the eSSIF-Lab term "Identifier" and the pattern on "Identification" (which may need some additional work). The gist is that identifiers, while used for identification purposes, do not always actually identify stuff; to actually identify an entity (i.e.: single it out from a set of entities) requires the construction of a non-empty set of attributes (names, values, ...) that only pertain to one element of the set of entities within which you want to identify (single out) an entity. Note that the identification-property of a set of attributes (i.e. the property that it actually singles out one entity) is a pervasive one. Adding entities to the set can make the property go away (e.g. you have one boy named Pete in the class, and another one is added that happens to have the same name).

I would like to be able to construct attribute sets that pertain to knowledge artifacts that do not exclusively depend on a name/term attribute (e.g. Pete). Does that make sense?

[RieksJ]

closed - see essif-lab/framework#127.