On Fri, 7 Mar 2025 21:28:05 +0000, Timothy Collinson wrote:

>While I'm here, woke up yesterday having slept on my revision overnight.
>
>I'm in a real quandary over whether it's not a mistake to move away from
>having edition as a top level.
>
>I think either approach would work, but it's hard to work out how best to
>make the decision about which way to jump!
>
>And my initial effort at getting char gen into an overarching inclusion of
>all editions, showed just how hard it might be.
>
>Ah well
>  Will keep thinking.

This is the core problem of any sort of classification system: What is the
"right" hierarchy for what you are intending to accomplish? Except that it
may be the _wrong_ question:

Even when you make your top-level categories "loose", you can run into
problems; there are, for example, several articles in _Freelance
Traveller_'s history that have been (quietly) reclassified, and it's rare
for more than a couple of issues to go by without running into a submission
where I spend quite a bit of time deciding whether it goes _here_ or
_there_. That _could_ be a deficiency in my organization - but I rather
tend to believe that it's because the people writing the articles aren't
(_and shouldn't be_) thinking in terms of the magazine structure, but
instead thinking about what they want to say in their presentation, and how
best to do so.

That is, ultimately, an advantage that using blog-style organization brings
into play - the articles themselves are effectively dumped into an
unorganized heap, and each is tagged with hashtags that are relevant to the
subject matter, so that if Joe Bloggs wants to find Classic Traveller
character generation, he just filters on the tags #classic #chargen. If
he's interested in Navy articles for Classic-compatible versions, the
filter becomes something like #navy not(#gurps or #t20), or some such. Your
obligation as the Librarian is to use a consistent set of hashtags
consistently, _without_ trying to hierarchise them.

The hierarchical structure of Dewey and Library of Congress have their
place when you're managing a _physical_ collection, where you have to know
where to find a specific object. When you're managing an _electronic_
collection, where retrieval of the object is also done electronically, why
do you need the hierarchy, rather than simply tagging each entity with the
relevant categorisations?

I'm not going to try to deny that this is the kind of direction that an IT
guy is going to be looking at the problem from; I am, after all, an IT guy.
But the fundamental question is one that appears all over; it's also why
most general-purpose databases now implement the relational structure
rather than the hierarchical structure of the early days of computing. Yes,
there are hierarchical databases in use today, but that reflects a natural
representation of the natural structure of what they're representing. That
natural structure may not exist in this project, however - or there may be
too many possible "natural" structures that you, as the database designer,
have to choose from. So don't unnecessarily constrain your structure; make
it as accommodating to your users as you can.

®Traveller is a registered trademark of
Mongoose Publishing, 1977-2025. Use of
the trademark in this notice and in the
referenced materials is not intended to
infringe or devalue the trademark.

--
Jeff Zeitlin, Editor
Freelance Traveller
    The Electronic Fan-Supported Traveller® Resource
xxxxxx@freelancetraveller.com
http://www.freelancetraveller.com

Freelance Traveller extends its thanks to the following
enterprises for hosting services:

onCloud/CyberWeb Enterprises (http://www.oncloud.io)