Re: what info should a dsk image archive store?

["Michael J. Mahon" <mjmahon@aol.com>]

mdj wrote:
> On Aug 2, 6:12 am, "Michael J. Mahon" <mjma...@aol.com> wrote:
>
> > jonnosan wrote:
> >
> > > Thanks for all the good ideas.
> >
> > > Here's a summary of suggestions so far:
> > > ###############################################################
> > > CATALOG INFO:
> > > - Application Name
> > > - Application Publisher
> > > - Application Author(s) (if known)
> > > - Year of publication
> > > - what type of protection was used?
> > > - what group/cracker released the disk?
> > > - media type (5.25 / 3.5 / HD image / cassette?)
> > > - disk format (DOS, ProDOS, Pascal, CP/M, custom)
> > > - total number of disk sides (Wizardry is 2, Time Zone is 10)
> > > - platforms supported ("any", "enhanced //e or later", "IIgs")
> > > - how much memory is needed to run it (ie. 4KB, 48KB, 64KB, 128KB,
> > > 2MB)
> > > - supports Mockingboard sound (y/n)
> > > - input devices required (joystick, paddles, mouse)
> > > - original legal status (freeware, shareware, commercial
> > > - current status as some have been reclassified as public domain,
> > > freeware or shareware
> >
> > > DOCS:
> > > - Documentation should include both official and cracker docs, if
> > > available
> > > - link to Wikipedia or other relevant articles
> >
> > > DSK IMAGES:
> > > - Include supplemental disks such as dictionary/thesaurus modules for
> > > word processors, or picture libraries for The Print Shop
> > > - For games with multiple releases (such as Akalabeth), an image of
> > > each release
> > > - For games cracked by multiple groups, include an image of each
> > > crack
> > > (or better to have one archive for each crack or version, but have a
> > > 'related works' item to record relationships?)
> >
> > > CATEGORIES:
> > > - Application Category (needs to have some kind of constrained and
> > > structured list of categories e.g. "Applications/Word Processor"
> > > "Games/Arcade"
> > > - Include a category for "underground" software such as Hayes
> > > Hackamatic and Phantom Access
> > > - Include a category for user-group disks (old electronic
> > > newsletters,  program compilations, etc.)
> >
> > > COMMENTARY:
> > > - Notations about issues with emulators, e.g. Wizardry 1 only runs
> > > properly in AppleWin if you open it as read-only, Galactic Prospector
> > > doesn't boot at all
> > > - personal notes on where disk came from
> > > ###############################################################
> >
> > > Next question: if this info was in a file to be included in a zip (or
> > > similar format) file along with docs and dsks, would it be easier to
> > > have the file in an XML format or something easier to create by hand
> > > in notepad?
> >
> > I think what Matt was getting at in suggesting XML was creating a
> > machine-understandable format.  From a practical perspective, this
> > suggests a "packaging tool" that prompts the submitter for all the
> > relevant information and properly incorporates it into XML.
>
>
> I was getting at two things: One - use of the existing XPackage
> 'standard' for the archive descriptor. See
> http://www.globalmentor.com/reference/specifications/xpackage/specification/
> for details.
>
> XPackage will take care of how the archive itself organises the
> various media types that make it up.
>
> Further to that, you need to define the descriptor, which is what
> we're really talking about here. This kind of capture exercise lends
> itself quite nicely to RDF, but you could also use 'plain' XML with a
> Schema. Whether or not you use official XML Schema or one of the
> competing Schema definition languages is out of scope :-)
>
> I had assumed this application would be primarily web based? It seems
> a little redundant to have it offline these days, and raises the
> complexity considerably when you want to merge them later.
>
>
> > Anything done with a text editor is going to allow lots of non-
> > standard "keywords" and other data, inevitably.
>
>
> And require google-like software to make it useful. Not a good
> solution for a reasonably well defined capture exercise.
>
>
> > BTW, I half-humorously suggested a "parallel bit vector" to
> > indicate whether the corresponding "compatibility bit" was
> > valid.  A better approach is to make the compatibility field
> > something besides a Boolean.  Likely values might be: "certainly
> > incompatible", "possibly compatible", "certainly compatible",
> > and "unknown".
>
>
> I think that's going a bit too far. There's only a small list of
> machines to consider, and a list of compatible ones seems the most
> sensible thing to record.
>
> What you mention here seems to be determinable via inference. eg. If
> the app runs on a //e and a //c and was released after 1987, it is
> more than likely IIgs compatible. Only things that are known should be
> actually recorded.

I agree--so each "machine" field takes at least 3 values--a bit
vector won't do it--so I was only going "[half] a bit too far".  ;-)

> > You get the idea.  Lots of desirable attributes of images will
> > not be known by submitters, and this must be explicitly represented
> > rather than forcing a likely erroneous choice.
> >
> > "Bad information drives out good", so you want to do everything
> > possible to preserve the best information.  Otherwise, its value
> > will be undermined and it will not be used.
>
>
> Right. I think the important thing is to only mandate the necessary
> information. Forcing humans to enter data they either don't know or
> need to research, is one of the best ways to unleash the forces of
> chaos on your dataset. Realistically, only a Title and one or more
> disk images (either by inclusion or linkage) is required. Keeping the
> rest of it optional will ensure that only the people who know and/or
> care will enter it.

Absolutely.

-michael

NadaNet file server for Apple II computers!
Home page:  http://members.aol.com/MJMahon/

"The wastebasket is our most important design
tool--and it's seriously underused."