Template talk:FormatInfo

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)

Done. AndyJackson (talk) 17:01, 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.
  • Detailed description of properties.
• Decision Criteria in Digital Preservation: What to Measure and How
• Impact Assessment of Decision Criteria in Preservation Planning
• UDFR Ontology
  • UDFR Final Report
  • Full list of Format entity properties

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)

I went through the above lists of properties and extracted what I thought were the most useful entries. I have enumerated them here. Does anyone have any feedback on these? AndyJackson (talk) 03:11, 4 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)

I'm rather less keen on this - I want to include interesting details about the format that may not be links, and I'm not sure why the 'datatype' of some of the information (hyperlink versus text-field, or enumeration, or whatever) should be enshrined in the template name. Is there an advantage to having a template that only includes links? What if some of the FormatInfo essentials are links? AndyJackson (talk) 15:31, 1 November 2012 (UTC)

Ok perhaps it's better just to have one template, and split things out when it gets too cumbersome. I don't think we're there yet.

A couple of items

Patent status should include "unknown" and "disputed."

Done. AndyJackson (talk) 18:01, 4 November 2012 (UTC)

Should there be a way to deal with commonly-used informal extensions, such as the various technical notes to TIFF that don't constitute a release but are an important part of how the format is used? --Gmcgath (talk) 17:31, 4 November 2012 (UTC)

I'm not sure how to do this in the infobox. Loosely speaking, I might treat them similarly to versions or variants of a format, and mention them in the TIFF page or as child pages if that is too long-winded (each with it's own infobox). However, I imagine we should document the format as it is used, rather that sticking to how it is specified. Maybe we need to cutdown/refine this infobox, then flesh out TIFF, and then revisit if we can make the model clearer? AndyJackson (talk) 17:59, 4 November 2012 (UTC)