Subj : Re: BBSINFO Data Requirements
To   : tenser
From : Avon
Date : Sun Jun 07 2020 16:44:58

On 07 Jun 2020 at 05:43a, tenser pondered and said...
 
 te> Fundamentally, you want to describe the data, but in a
 te> structured and semantically meaningful way.  The exact
 te> serialization of that data into any particular format
 te> is a secondary consideration.
 te> 
 te> That said, I would strongly recommend JSON.  It's
 te> lightweight, and it's available pretty much everywhere.
 te> It does basically everything you need and can be
 te> upwards compatible if you add things to the schema.
 te> 
 te> I would strongly recommend _against_ an ersatz format,
 te> or an unstructured line-based thing a la the current
 te> nodelist format.

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

 te>  st>  te> ftnAddress := Zone? Net Node Point? Domain?
 te>  st>  te> ftnMember := NetName ftnAddress+
 te>  st>  te> Location := City State Country
 te>  st>  te> Service := Name Host Port?
 te>  st>  te> LoginType := (RealName|Handle|Either)
 te>  st>  te> CharEncoding := (UTF-8|ASCII|ISOLATIN1|CP437)
 te>  st>  te> BBSOtherData := NumNodes? AvgCallers? AvailTimes? LoginType?
 te>  st>  te> BBS := Name SysOp Location? Language* ftnMember* (Phone|Service)
 te>  st>  te>        BBSOtherData? LastVerifiedTime CharEncoding*
 te>  st> 
 te>  st> YES! And flat...
 te> 
 te> Not flat, no; notice how the different data nest
 te> within each other.  The point is that this describes
 te> the _structure_ of the data, but is independent of
 te> how one _formats_ that structure.

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

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

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

.