Taxonomy: Difference between revisions
Amwelladmin (talk | contribs) No edit summary |
Amwelladmin (talk | contribs) No edit summary |
||
| Line 2: | Line 2: | ||
We all do it, all the time. It is just that some people are in denial about it. | We all do it, all the time. It is just that some people are in denial about it. | ||
===A taxonomy of taxonomies=== | |||
====[[Risk taxonomy]]==== | |||
We wax lyrical about ''risk'' taxonomies [[Risk taxonomy|here]]. | |||
===[[Metadata taxonomy]]=== | |||
Eager [[reg tech]] providers may try to sell you some kind of [[Artificial intelligence|artificially intelligent]] automated taxonomy application that will categorise, tag and organise documents in an unstructured database (your email corpus, for example). We are skeptical, as these initiatives are predicated on the [[high-modernist]] delusion that all information an organisation handles cleaves to a common, static, uniform architecture, and the only challenge, past discovering it, is to apply it reliably to each file: that [[data]] has a single, unchanging nature that one can, as the saying goes, carve at its joints. | |||
This is rather like a central bureaucracy forecasting the population’s forthcoming need for spoons, rather than letting a competitive market sort this out by itself. | |||
We inhabit a dynamic, shape-shifting world. The “market” is a sprawling, inchoate patchwork of sprawling, inchoate, patchwork systems. What counts as a canonical category here is no use as a category there — even inside the same firms <ref>The best example is the “client”. A [[sales]] desk might categorise a client by its sector; the credit department by its market capitalisation; the legal department by its corporate form, [[compliance]] by its sophistication; [[Tax attorney|tax]] by its domicile. These categorisations are [[incommensurable]] — but need not ''be'' commensurated: all are relevant, and none has intellectual priority over the others. Building a system to manage these clients requires design choices.</ref> | |||
furthermore, the data we handle is already inundated with [[metadata]] — ''when'' it was sent; ''by'' and ''to'' whom; concerning ''what''; and so on — not to mention ''actual'' [[data]], being the text of the document and its attachments, none of which, broadly, is properly used. Rather than ignoring that trove and instead, imposing further arbitrary metadata on top of it<ref>With the [[tedious]] overheads that implies: software licence fees and a squadron of librarians chasing users up to validate the taxonomy and update it</ref> at least first make the most of it. | |||
Here something like unglamorous search — virtual folders; that kind of thing — is a better option. The search parameters are, of course, ad hoc; they may (but need not be) be impermanent; they categorise information in real time according to parameters the [[user]] at the time determines valuable. | |||
{{sa}} | {{sa}} | ||
*[[Systems analysis]] | *[[Systems analysis]] | ||
*[[Risk taxonomy]] | *[[Risk taxonomy]] | ||
{{ref}} | |||
Revision as of 09:21, 31 August 2021
|
A way of dividing up things. A narrative. An intellectual, and political, commitment, at the expense, as long as you’re using it, of all others.
We all do it, all the time. It is just that some people are in denial about it.
A taxonomy of taxonomies
Risk taxonomy
We wax lyrical about risk taxonomies here.
Metadata taxonomy
Eager reg tech providers may try to sell you some kind of artificially intelligent automated taxonomy application that will categorise, tag and organise documents in an unstructured database (your email corpus, for example). We are skeptical, as these initiatives are predicated on the high-modernist delusion that all information an organisation handles cleaves to a common, static, uniform architecture, and the only challenge, past discovering it, is to apply it reliably to each file: that data has a single, unchanging nature that one can, as the saying goes, carve at its joints.
This is rather like a central bureaucracy forecasting the population’s forthcoming need for spoons, rather than letting a competitive market sort this out by itself.
We inhabit a dynamic, shape-shifting world. The “market” is a sprawling, inchoate patchwork of sprawling, inchoate, patchwork systems. What counts as a canonical category here is no use as a category there — even inside the same firms [1]
furthermore, the data we handle is already inundated with metadata — when it was sent; by and to whom; concerning what; and so on — not to mention actual data, being the text of the document and its attachments, none of which, broadly, is properly used. Rather than ignoring that trove and instead, imposing further arbitrary metadata on top of it[2] at least first make the most of it.
Here something like unglamorous search — virtual folders; that kind of thing — is a better option. The search parameters are, of course, ad hoc; they may (but need not be) be impermanent; they categorise information in real time according to parameters the user at the time determines valuable.
See also
References
- ↑ The best example is the “client”. A sales desk might categorise a client by its sector; the credit department by its market capitalisation; the legal department by its corporate form, compliance by its sophistication; tax by its domicile. These categorisations are incommensurable — but need not be commensurated: all are relevant, and none has intellectual priority over the others. Building a system to manage these clients requires design choices.
- ↑ With the tedious overheads that implies: software licence fees and a squadron of librarians chasing users up to validate the taxonomy and update it