Nested Terms
Hypertext-infused philosophy personal database software
Brought to you by:
jasonwinning
Menu
▾
▴
#19 Nested Terms
It would be nice if terms could be children of other terms. "Reason" is a term in my glossary. There are various kinds of reasons, like "Practical Reason" and "Epistemic Reason." It would be cleaner if these kinds of reasons could be nested under the "Reason" term, rather than having all of them at the same level on the tree.
Usually in this situation I would either add that term to multiple glossaries (again, a feature that has not been shown in a video yet but it is the current type of parent record showing in the Term tab) or, if that is not appropriate (might not be in this particular case, but for some terms I have a definition under the glossary Epistemology, and another under the glossary Moral Psychology. Internalism and Externalism are organized this way in my database), I would usually have a term for Reason, and then have its description embedded in the description for Epistemic Reason and Practical Reason. It is also possible to cause the Term record for Practical Reason to be sort of glued together with a Problem/Debate record for Practical Reason (yet another feature not shown in videos yet); this is what the "Link to Debate" hyperlink (in large font) in the middle of the tab is for. What that does is it causes the two records to stay synchronized so that when you edit the description for one, it change the description for the other one. Then you can have a Problem/Debate record for "Reason" be the parent of the other Problem/Debate records, and link the respective Term records to their Problem/Debate records. With these other existing mechanisms for establishing hierarchical relationships I feel like parent/child Term records may be somewhat redundant. But I'm open to being convinced otherwise.
Hmm... multiple glossaries doesn't help because the goal is to tie the two more narrow terms to the broader term, rather than spreading things out more. There aren't multiple glossaries they'd fit in to: they're all just in the "Reasons, Intentions, and Actions" glossary. Similarly, Problem/Debate Link possibility isn't relevant - right now there are no problems or debates for Reason, Epistemic Reason, or Practical Reason themselves. They're just terms that are relevant to lots of other stuff. And although I could embed the Reason term in the Epistemic Reason and Practical Reason terms, that doesn't solve the original issue, which is that the tree is cleaner and more logically organized if I can nest those latter two terms under the Reason term, since after all they are just more specific kinds of the general kind. (In fact since there are lots of sort of reasons, it's going to get pretty messy if they can't all just sit under "Reason.") It's not a big deal, because they can all be at the same level rather than having Reason be a parent to Epistemic Reason and Practical Reason, but I'm not sure I see the benefit of not allowing for nested terms.
Another example: I have two terms, "direct conation" and "indirect conation." It would be nice to nest those both under a larger term, "conation."
In a situation like this, what I have often done is had one Term record for "conation" and defined the terms "direct conation" and "indirect conation" in that description (without putting it in multiple Glossaries). And then I would make the search key something like "conati; direct conati; directly conati; indirect conati; indirectly conati" so it all links back to that one record. An advantage of this approach is that things are tied back to "conation" as you said. The disadvantage is that they won't show in the tree as separate terms.
I'm open to the idea of possibly having hierarchical relationships between term records but I need to think about it more. It seems like the hierarchical relationship will actually need to be between Concept records, not Term records (there is always one Concept record for every Term/Glossary combination; the Concept record is actually where any given definition for a Term record lives). Would a Concept record need to have more than one parent? If so, the Term tab UI is going to get kinda messy...
Okay after thinking about it I'm warming up to the idea but it seems to me that there will indeed need to be multiple parents and that concepts, not terms, will be hierarchically related. For example I would like to have "Mental State" under both "State" (in the Metaphysics glossary, not the Politics glossary) and "Mental Entity". Now the trick will be to figure out a UI for the Terms tab that won't be a mess. I'm open to any suggestions.
I think I just came up with an elegant solution for the UI. In the existing parent table (that currently just shows glossaries), I will add a new column on the right for parent terms. This makes sense because 1) any parent concept will always be in at least one of the glossaries for the current term--otherwise it doesn't make sense to call it a parent, and 2) there is no need to show parent table rows just for the glossary when there is a parent concept in that glossary. UI-wise, this will be a pretty small change. So the "Parent Term" column in the glossaries table (which will just be labeled as "Parent Records" as on other tabs) will just be blank in most cases but can be edited to select the parent concept. This is all making sense.
I just realized there is another issue to think about. In my database I have a debate record for "Intelligence" and another one for "Artificial Intelligence". And both are already united with Term/Concept records. Should the application automatically ensure there is a corresponding hierarchical relationship between the concepts as well? Or maybe show a warning message? It doesn't do any warning or anything if both Debates are united with Labels or Notes without there being a parent-child relation between the Labels/Notes. I've never really thought about this until now; with Labels or (especially) Notes, this doesn't seem like as big a deal. But it almost seems like having dangling Terms corresponding the Debates/Positions that are already in a hierarchical relationship (without the Terms being in that relationship) is a situation that should simply be prohibited.
Here is the question: Is there a scenario where you might want to have Debate1, Debate2, Concept1, and Concept2, where Debate1 is the parent of Debate2, Debate1 is united with Concept1, and Debate2 is united with Concept2, but also want there to be no hierarchical relation between Concept1 and Concept2? (or a situation where you would want Concept1 and Concept2 to have the hierarchical relationship but not Debate1 and Debate2)?
I generated a report and found that in my database (now almost 22,000 records accumulated over 9 years, although key works weren't implemented until 2017, after which I used Labels much less often) there are 17 instances of Debates/Position in hierarchical relationships that are united with Labels not in that hierarchical relationship. For many of those it's not obvious that putting the labels in a corresponding hierarchical relationship would be a good idea. I'm thinking automatic enforcement or warnings to the user maybe aren't the way to go.
I think the best solution to this is just to provide the ability to generate a report in the queries tab for the user to see where there is a parent/child relationship not reflected in corresponding records the parent/child records are united to, so the user can deal with those situations manually if desired. This is similar to how there is currently a report you can generate to see if there are authors with very similar names that are possible duplicates.
I now realize that the issue mentioned previously, that a concept record may be united with other records that are in hierarchical relationships that they concept is "out of sync" with, is a non-issue, because when the description for a concept record is in display mode, it already shows a listed of "Related concepts", which are exactly the ones that one might want to add as parents or children of the current concept.
Development for this feature is complete and testing is mostly done. It will be included in the next release, 1.24
Along with this enhancement will also be included the ability to specify multiple "senses" for a term. For example, the term "Reason" might have at least 3 senses: the activity of mentally carrying out inferences, the faculty by which one reasons, or something that can justify such inferences (the sense used in philosophy of action). You will be able to have one term record and add 3 senses in the "Parent records" section of the Terms tab, so there will be 3 concepts without having to add a new glossary. Then if you have separate terms for "Epistemic reason", "Moral reason", etc. you can set the 3rd sense of Reason as the parent record of these.