Extend COPTR Formats to legacy media form factors

[anjackson]

Raised by @LeontienT in PR-SIG Collab Cafe. Because many tools for floppy disks are very specific, lodging everything under Disk Image is not much use. Other resources are more specific:

• Just Solve: Floppy disk - Just Solve the File Format Problem
• Just Solve: Category:Floppy disk - Just Solve the File Format Problem.
• Also noting Overview carriers - Kenjedrager from meemoo, which doesn't cover floppies but it would be nice to have something similar?
• And also Floppy Disks | Museum of Obsolete Media

So, following these (and perhaps retaining some of their naming conventions?), we could add formats to Category:Formats - COPTR that refer to specific types of legacy media so tools can be linked to them directly.

Is this a good idea? Can we align with or link the related resources together? Could the Disk Image and other Content Type pages also link to related Formats to make things easier to find?

Note also the related idea of linking into COPTR from the Bit List of endangered digital resources. Compare Bit List Categories and Category:Content Types - COPTR

[thorsted]

I agree this is needed and would also like to suggesting adding a resource for specific brands and models of hardware needed for DP. What model of USB floppy works best? What brand of 3.5 floppy drive works best with greazeweazle? Etc.

[asciim0]

IMO this would be a very helpful addition to COPTR!

Since Tyler mentioned greazeweasle .. would a follow-up of this though be to also have a hardware category in COPTR? I'd consider hardware a tool in a wider sense, so it seems in scope - and the need is clearly there, going by the frequent questions around imaging hw on mailing lists.

[LeontienT]

I might be overthinking this, but I’m wondering if part of the challenge is where we draw the line between format and type, and what sits alongside that.

It seems useful to separate out the physical carrier (3.5", 5.25", optical, tape, etc.). But then there are also things like:

Encoding (MFM vs GCR)
Density / capacity
Track/sector layout

Those feel tied to the carrier, but also more specific, so I’m not sure if they still sit under format, or if that’s really another layer (and do we even want another layer? Probably not?).

Then on top of that there’s the logical side:

Filesystems (FAT, HFS, ISO9660, etc.)
Higher-level structures (Audio CD, DVD-Video)

And I’m also wondering how this connects to the more practical side of things:

Different transfer approaches (file copy vs disk image vs flux capture)
The tools/hardware used for those (e.g. flux readers vs standard drives, this also ties in to the brands and types of hardware to use)
And how to represent compatibility between tools (e.g. one device producing something another tool can read, even if the hardware itself isn’t interchangeable, Greaseweazle and Applesauce for example)

I’m not sure if those belong as separate layers again, or if they should be tied back to format/type somehow.

Very open to hear how others are thinking about structuring this!

[cyn0matic]

Vintage Computing Obsolete Carrier Controlled Vocabulary -- a white paper we produced in 2016 at Living Computers: Museum + Labs.

MOYA_Cynde_WINDLEHARTH_Travis_Vintage_Computing_Obsolete_Carrier_Controlled_Vocabulary.pdf

[anjackson]

I also came across the Extended eLectronic Metadata Schema (ELMS) from The NEXT. It's much coarser grained, aimed at cataloguing for access rather than fine-grained description of processing, I think. But folks might be interested in looking at the "Media Format" facet, e.g. starting with all the works you can then select 3.5-inch Floppy Disk (except maybe I broke it because all of a sudden it seems to be down?!)

[anjackson]

Had a nice conversation about this with @thorsted and @cyn0matic on the PR-SIG call last night. As I said there, I'm struggling a bit to know how to help, as I don't really understand the media, the workflows, and what metadata is needed for appraisal/cataloguing. Multiple different but related possible shared resources came up:

• Worked-through workflow examples to complement the Copy That Floppy! guide, e.g. Applesauce end-to-end.
• A 'identify your carrier' style resources, written by experts, guiding new folks, bridging them from the media they have to the tools (inc. hardware) that they need. e.g. we recommend these drives for the Greaseweasle.
• A place for experts to share e.g. CSV files with information about drives and tools combinations, successes and failures, to help identify which drives work well etc. A kind of aggregator, a bit like I've done for formats etc.
• Some wrapping or extension of things like Greaseweasle to make it easier to gather information about which drives do well (somewhat inspired by how dbPowerAmp ranks optical media drives: CD Drive Accuracy 2024 - dBpoweramp Forum)
• Standards for cataloguing media so people can talk about what they have in a consistent way across forums/systems. It was noted that the 'tree' of floppy formats might be just as wild and broken as the 'tree' of file formats. So we hit the usual issue of having to decide what level of granularity is practical.

As usual, my first question is to focus on the labour. Who will populate these things? Who will use these things? How do we make this sharing as easy as possible?

As such, my impulse is to focus on the practical issue of "what do I do with this thing, and has it even worked?!", and try to imagine how we might build up a shared triage process that bridges from the media people have to the tools and hardware they need.

But it might make more sense to turn the table on you, and demand that you all be more specific! What information do you want to share, and why!? If we can't find two people who want to share the same kind of information, then we might want to rethink!

I'd be very glad to hear thoughts on this, but it's all sufficiently complicated that I think maybe it might be better if try to get a bunch of us together to talk things through? Happy to arrange some kind of virtual 'summit' if that makes sense!

[ross-spencer]

But it might make more sense to turn the table on you, and demand that you all be more specific! What information do you want to share, and why!?

This is a good question.

Also, if I read correctly, then the complication seems to be how is this information aggregated? but before aggregation, a list of new potential COPTR records might be helpful. At the end of the day, a resource is likely to be built up of discrete entries, for:

hardware type a,
hardware type b,
media category a,
media category b,
media a,
media b,
software a,
software b,

and they can all be described, as I say discretely. So maybe if some basic controlled vocab can be suggested, and used in info boxes, borrowing from Cynde's resource, for example.

Then the records created, and if necessary, just added to a mezzanine special page capturing legacy media related records, and then in aggregate, we can figure out how different information can be combined as needed.

But yeah, as a wiki, there shouldn't be a huge burden creating records, and then learning how to work with those.

Deeper modelling exercises can be done with more data available.

[anjackson]

Okay, we had a useful conversation about this in yesterdays PR-SIG (see rolling notes). To summarise:

• The (articulated, I hope) purpose of the COPTR is not to tell you what to use, but give you a list of tools to try out.
• The (under articulated, I think!) purpose of the COPTR navigation facets (lifecycle stage/content type/format/workflows/etc) is to narrow the candidates down enough so that the list to tools to try out is not overwhelming. e.g. no more than ten (probably relevant!) tools.
• Also under-articulated: that the whole thing is tool-driven, i.e. we make the categories we need to talk about the tools. We don't make or import taxonomies wholesale, leaving most of the 'leaves' are empty because there are no tools there.
• Especially in the absence of additional time/funding, any changes to COPTR should be as simple and coarse-grained as possible. Alignment with existing taxonomies is preferred, with terms pulled in as needed.

More concretely, I offered to spend a little time looking at the following (broadly along the lines @ross-spencer mentioned above):

• How well do the pages for FC5025, Kryoflux and Greaseweasle make it clear what media and file formats they support?
• Does the 7-Zip page make it clear that it can read .img floppy image files? What needs to change to make that clear?
• What is the relationship between COPTR Content Type and Formats?
• Do the Formats help narrow down the options on the Content Type pages? Could they?
• Would it be useful to add a Content Type > Storage Media? (I think this might act as our "mezzanine special page"?)
• Where would a Floppy Disk > (3.5" Floppy Disk | 3" Floppy Disk | etc...) hierarchy go? i.e. work at the granularity of 'what is this physical thing I have in my hand', and only make it more find-grained if it's necessary to make the tool lists manageable. But is this a Content Type under Storage Media, or a Format?!

Having looked at that, I'd maybe experiment with a few records and write up a proposed approach. But this already seems quite a lot! I'd appreciate some feedback on this general idea before going further.

As for some of the other issues raised above, my feeling from the conversation was that they maybe needed different approaches. Specifically, the following may still make sense as pages on COPTR, but they are distinct from the tool part and I'm not planning to pursue them at this time.

• A 'identify your carrier' resource probably needs it's own thing, and is probably a lot of work.
• Worked-through examples for training/start-up probably need additional funding, and work better elsewhere. Although more real workflows on this matter in the Workflow:Community Owned Workflows - COPTR section would be helpful.
• Data or lists of 'known good drive models' could maybe be on (or linked from) a Hardware section on the the 3.5" Floppy Disk page?