Add new element and vocabularies for instantiation container format

[kvanmalssen]

Currently, it is difficult to clearly express the container format of a digital file. This is a critical piece of data, and there is no clear place to put it now. There is ambiguity between instantiationStandard and instantiationDigital. Looking at definitions and recommended vocabs for each, it is not clear where you would put the full container format specification (e.g. MXF Op1a). This is often more specific than just a MIME type. As a result local practice for expressing container formats tends to vary greatly.

The addition of a field for instantiation container could help ensure consistence in expression of this data. This would be a similar approach to ebucore:containerFormat

[laurensorensen]

Great idea. Can container formats fit into instantiationStandard and can we nix instantiationDigital all together -- moving codec information to a new element under essenceTrack (will create a new ticket for that)?

[kvanmalssen]

I've been thinking about the same issues. Some thoughts:

-- instantiationDigital could be eliminated and replaced with a more specific mimeType element (again, aligning with ebucore:mimeType). That way both the full container format as well as the MIME type could be expressed

-- Codec is already well supported in essenceTrackEncoding. I feel this requirement is already met.

-- The definitions and vocabularies for instantiationStandard and essenceTrackStandard are both very ambiguous. I would suggest limiting the scope of these.

[laurensorensen]

Good points! I like these solutions.

Agree about definitions and vocabs. I especially find IANA to be limiting - no Matroska wrapper which is used in digital preservation environments, for example. Maybe more vocabularies would help, or we could refer users here: http://wiki.multimedia.cx/index.php?title=Main_Page Or we could consider recommending mapping from tools like Mediainfo and FFprobe. Wonder if it'd be worthwhile to look at how EBUcore handles these vocabs.

[jolene2323]

Hi there, I was commenting on issue #67 which brought me here. In my institution we don't use instantiationStandard (all of our recordings are sound) nor EssenceTrack currently, but we DO use instantiationDigital to distinguish that the instantiation is a digital file (not a physical item) and whether its a wav or mp3. The idea of eliminating instantiationDigital doesn't work for us. Is there a way to add the more specific container information without eliminating instantiationDigital?

[rguenther52]

In terms of vocabs, format information is complex and if this is intended to be used for preservation purposes, we need to also know the version. PREMIS covers this information in several elements, also including pointers to format information in a format registry. MIME type is fine but doesn't give version information. Sorry if I'm missing something since I'm new to this group-- but do we need this to be more controlled and expressive?

[kieranjol]

Sorry for the thread bump, but I'm noticing the exact same issues. I think a specific MIME element would suit instantiationDigital best. In fact, I think there's scope for having a very high level format type in instantiationDigital, like this could be where you say that the package is XDCAM/P2/DCP/DCDM etc.. There's no other place to put that information at the moment, unless you make up your own annotation..