DBMS2 analytic glossary — a new project
Enterprise software terminology is too often mired in confusion. I hope to lessen that by publishing a series of web pages that define and describe various industry terms, with one or several paragraphs per subject, and plenty of internal and external links.
Absent a better name, I’ll refer to this as an “analytic glossary”. I want users of the analytic glossary to learn or confirm:
- What terms mean.
- Which products exemplify which product categories.
- Which additional subjects to look into.
I will do or closely direct the core writing myself. I may hire outside help for ancillary tasks, such as adding links, or for various kinds of wordsmithing.
All this presupposes a site redesign, which hasn’t begun. But I’ve started to draft the content. As I do, I’ll post it here. And I very much want you to comment.
If you think I got something wrong or left anything out — even if it’s just a nuance — please speak up! Later, when the glossary pages are live, I’ll link them back to the original blog post discussions. Thus, your comments will be part of the permanent glossary record.
Analytic glossary draft sections posted so far
- Analytic platform
- Data warehouse appliance
- Database
- Database management system (DBMS)
- Hybrid in-memory DBMS
- In-database analytics
- In-memory DBMS
- Memory-centric data management
- Relational database management system (RDBMS)
Comments
5 Responses to “DBMS2 analytic glossary — a new project”
Leave a Reply
This is a huge service to the industry, and I applaud your doing this. Where I have specific knowledge, I’ll gladly contribute it. And I’ll reach out to the HR technology community on behalf of this project.
Thanks, Naomi!
I need guidance in a lot of different respects:
Some of that’s clearly general; other is specific to a particular entry.
And that’s even without considering UI and site redesign …
Curt, cool project. (I have been thinking, for the better part of a year, about doing a Text Analytics Glossary.) Much more useful than Yet Another White Paper. YAWP is right for new arguments and advocacy, but in a mature field, codifying — creating canonical, referenceable definitions — is the way to go.
The only concern I’d have is a listing “which products exemplify which product categories.” Imperfect category fit is still more the rule than the exception, no?, and you run the risk of putting disproportionate emphasis on aspects of a product that is more than the sum of its parts.
Seth,
I agree the “which products exemplify …” part is very hard to be even half-precise about. But I have an idea for a quick-and-dirty approach, or at least first cut:
Product P is viewed as exemplifying Category C if P’s entry says it’s a C.
Further, there’s (occasionally multiple) inheritance. If I say something is a data warehouse appliance, then from the link to the category for “data warehouse appliance” you will be able to see that also:
So, for example, in a category on DBMS, I might rattle off a few examples, and then indicate more examples may be found in the RDBMS entry. Going there, the reader might find some of the same names as before, some further names that weren’t in the DBMS entry, and a link to the analytic DBMS entry, where there would be yet more product names.
[…] are three closely-related draft entries for the DBMS2 analytic glossary. Please comment with any ideas you have for their […]