vault backup: 2025-12-17 17:03:56

2025-12-17.md

@@ -41,45 +41,51 @@ to the conceivably far more broad [spatial statistics](https://en.wikipedia.org/
 > such as in computer-aided design (CAD),
 > see [geometric modeling](https://en.wikipedia.org/wiki/Geometric_modeling "Geometric modeling").
 
-### Common Fallacies
+### Ambiguity
 
-* [Reification](https://en.wikipedia.org/wiki/Reification_(fallacy))
+New Note: [[ambiguity]]
 
-    > [!quote]
-    > **Reification** ... is a fallacy of ambiguity,
-    > ...it is the error of treating something that is not concrete...
-    > as a concrete thing.
+## 2025-12-17 12:32
 
-    See ["the map is not the territory"](https://en.wikipedia.org/wiki/Map-territory_relation "Map-territory relation").
+#topic/ambiguity
 
-    > [!aside]
-    > This one is very common among my peers in estimating.
-    > The problem with fallacies, of course,
-    > is that you can't simply say "Reification fallacy, booyah".
-    > If some one is overgeneralizing,
-    > they likely just have a different understanding of the term.
-    > Certainty of definition only occurs with some quorum,
-    > and I'd argue most of [[construction-estimating|ours]] don't meet it,
-    > and that the choice of any term over another ought to be based on utility.
-    >
-    > > Note also that a term's definition can be certain ~~on some axis~~,
-    > > but ambiguous ~~on another~~.
-    > > See ["I know it when I see it"](https://en.wikipedia.org/wiki/I_know_it_when_I_see_it)
-    > > which, as far as I'm concerned, is a perfectly legitimate definition.
+A while ago I heard a minor coding influencer lament
+that frameworks, packages, and tools
+often have ridiculous sounding names
 
-* [Equivocation](https://en.wikipedia.org/wiki/Equivocation "Equivocation")
+> `bubble-tea` and `ratatui`,
+> libraries for creating CLI's, come to my mind
 
-    The misleading use of a word with more than one meaning
+when, he suggests, they ought to just be called what they do.
 
-* [Composition](https://en.wikipedia.org/wiki/Fallacy_of_composition "Fallacy of composition")
+Unfortunately some people and organizations agree,
+giving us terms which mean both something very general
+and something very specific.
 
-    Assuming a whole has a property because its parts have that property
+> [[project-management-tm|"Project Management"]]
+> was my go to example, but weak
+> because it's difficult for me to articulate
+> the difference from construction project management
+> especially to someone un familiar with the specifics of either.
 
-* [Division](https://en.wikipedia.org/wiki/Fallacy_of_division "Fallacy of division")
+For lack of a better term I've been thinking of this as an SEO problem,
+but the bigger problem is that it invites [[ambiguity#Category Mistake|Category Mistake]],
+whereby the ignorant listener associates traits unique to the example
+to all things that the name could describe.
 
-    Assuming parts have a property because the whole has that property
+I thought to finally write about this problem
+while researching [[lighting-controls#Protocols|lighting control protocols]].
+The two most dominant examples:
 
-> [!quote] [Category mistake](https://en.wikipedia.org/wiki/Category_mistake)
-> An example is a person learning that the game of cricket involves team spirit,
-> and after being given a demonstration of each player's role,
-> asking which player performs the "team spirit".
+* [[lighting-controls#^dali|"Digital Addressable Lighting Interface (DALI)"]]
+* [[lighting-controls#^dmx|"Digital Multiplex (DMX)"]]
+
+while notably different in topology,
+are could both be described accurately with the other's name.
+
+> It is possible to avoid this problem
+> without the effort necessary to come up with a clever name.
+> Just stick an arbitrary, but reasonably unique word
+> in front of the generic description.
+> A person's name ("John's Digital Addressable Lighting Interface (JDALI)")
+> or your favorite animal ("Heron Digital Multiplex (HDMX)") are good options.