Subj : Re: BBSINFO Data Requirements
To   : Avon
From : tenser
Date : Mon Jun 08 2020 00:45:24

On 07 Jun 2020 at 04:44p, Avon pondered and said...
 
 Av> I've found myself falling down the rabbit hole of wanting to look at how
 Av> the data could / should be most usefully formatted first rather (e.g.
 Av> JSON) rather than focus on what data would be good to allow for and it's
 Av> structure and semantics. This is not an area of experience I've had much
 Av> to do with. But I do take the point about trying to nail down the what
 Av> before you look at the how. I hope I have understood this difference
 Av> correctly.

That's fair.  It's useful to be able to look at examples
to see if all the useful things are being captured.

What vs how is a great way to think about it.

 Av> What I'm trying to grapple with is how do we know when we think we have
 Av> captured enough possible data fields of interest to then be able to move
 Av> on to creating ways to store, share and modify it?

In short, you don't.  The trick is to structure the data
in such a way that's it is extensible in a backwards
compatible way.  That is, adding a field shouldn't break
existing software.  Formats like JSON are great for
applications like that since each datum is labeled with
a key; things like CSV or other unstructured line-based
formats are terrible since inserting a field between
existing fields breaks all existing software.

 Av> I'm also not clear if creating these data fields is a one shot deal or
 Av> will what we use to store it all in and/or build other things from using
 Av> the data, allow for new fields to be added e.g. let's say we 6 months
 Av> later wanted to add a co-sysop field just as an example..

Surely you'll want to add things over time.  New services
come, old ones will fall out of use, etc.  But by using
a structured data format with semantically meaningful tagging
and by having a well-defined, extensible schema, you can
accommodate those changes as they occur.

--- Mystic BBS v1.12 A46 2020/05/28 (Windows/32)
 * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

.