Template talk:FormatInfo

Revision as of 15:15, 1 November 2012

About Template:FormatInfo...

e.g. Should it be called ElectronicFormatInfo to avoid confusion?

Conditional logic has been added to the template; all parameters are now optional. The link to IANA has been moved to Template:Mimetype. And why is this discussion not taking place at Template talk:FormatInfo? Gphemsley (talk) 09:14, 1 November 2012 (UTC)

Thanks! AndyJackson (talk) 13:34, 1 November 2012 (UTC)

+1 for moving the conversation to Template_talk:FormatInfo Edsu (talk) 14:31, 1 November 2012 (UTC)

What properties should be included?

Here are list of sources of properties we could consider including:

• Wikipedia Infobox_file_format template
• PRONOM Vocabulary
• LoC sustainability factors, e.g. here's the page for SVG 1.1.
• Decision Criteria in Digital Preservation: What to Measure and How
• Impact Assessment of Decision Criteria in Preservation Planning

Please add more if you know of them. However, as I've said before, I think massively complex models are dangerous unless the need for a machine-readable version of the information is clear. There's no point spending vast amounts of time marking un minutiae that are better served by prose. AndyJackson (talk) 13:44, 1 November 2012 (UTC)

Question 1 from CR: Is there a way to add signature information to your InfoBox style?

Easy enough to add a field, although I'm uncertain as to how useful it is. Much more information is needed to actually perform identification, and IMO this is much easier to manage in source code rather than. However, I'd be happy to add the field, with the proviso that I would prefer it to reflect what the specs say the magic is, rather than try to be complete enough to drive identification. AndyJackson (talk) 15:15, 1 November 2012 (UTC)

Question 2 from CR: How do we best reflect similar and different information for different versions?

I think we should just repeat the information. If this becomes onerous, we could look at adding a convention so that, when machine-read, 'child formats' inherited properties from 'parent formats'. Not aware of any clever MediaWiki trick to avoid this. AndyJackson (talk) 15:15, 1 November 2012 (UTC)

(Sorry, I don't really know how I'm supposed to do "Talk" in this context! - CR)

To use talk in this context, put a colon (:) before your sentence and then type, ultimately clicking on that second-from-the-right button that looks like a signature. If you're responding to a sentence with a colon in front of it, put two, a la ::. Regarding the infobox, I really feel there's some really hardcore well-made infoboxes out there, and it would behoove you to go and research those instead of re-inventing the wheel. --Jason Scott (talk) 03:36, 1 November 2012 (UTC)

Do we really need a hardcore infobox (they can get quite complicated), when something simple like what Andy is proposing would be a good way to get started? If so could you point at an example of one you particularly like? Edsu (talk) 08:13, 1 November 2012 (UTC)

I'll certainly be leaning on existing models, but I want to be careful about including everything as it may get in the way of contribution and, frankly, much of it is too ambiguous to be modelled directly and is better suited to prose/discussion. AndyJackson (talk) 13:34, 1 November 2012 (UTC)

I added a PRONOM option to the template. But perhaps it belongs in a separate template, like what Wikipedia does with its Authority Control template? The advantage to doing it separately is that it wouldn't clutter up the actual pertinent information with weird IDs and links, which could be located at the bottom of the page instead?

I have an idea about that - see below... AndyJackson (talk) 13:34, 1 November 2012 (UTC)

PROPOSAL: Two Info Boxes Are Better Than One

To avoid the more complex and fine-grained models getting in the way of contribution and readability, I propose we have two 'infoboxes':

• A short, simple one for 'basic information' (e.g. other identifiers like file extension, really simple stuff that most formats can be expected to have), which should always be there and is included at the top of the page.
• A longer, complex one for the details (e.g. licensing, PUIDs, etc.) that goes into a table at the bottom of the page.

Any field that is considered of interest can go in the longer one. Only critical discovery information goes in the short one. It should also look better than stuffing everything into one long thin box.

What do you think? AndyJackson (talk) 13:39, 1 November 2012 (UTC)

I like the idea of having FormatInfo be for the essentials, and then a second one FormatLinks? for identifier driven links to PRONOM, UDFR, etc. Edsu (talk) 14:35, 1 November 2012 (UTC)