R26a: Provide guidance on how to or provide specific means to document information of the relationship being instantiations of an asset.

[pdpinch]

Within archival and production environments, assets will be represented by multiple instantiations to serve different purposes (DVD Master, broadcast copy, web copy, backup, etc). Typically all copies are derived from one another. Provide a means to track associations of formatRelatorType, formatRelatorID, and formatRelatorIDSource to allow representation of relationships such as 'is dub of', 'is copy of', 'is digitized from', etc. [Note DD also expressed need to express instantiation-specific rights statements]

[WeAreAVP]

I see the relation attributes are included for instantiation parts, but no relation attributes allow for instantiation themselves. Could this be resolved by adding the relationGroup set to instantiation as well. [ also a note that the documentation in relationGroup needs to be adjusted to apply to both assets or instantiations ]

[WeAreAVP]

Kara and I met last week and plotted out how some of the NDIPP use cases could be better handled in PBCore 2.0 and think through the latest schema draft. The addition of the instantiationPart helps tremendously at making complex instantiations more clear, but documenting the relationships between them was tricky.

Supposing an asset has two renditions, one is a tape and one is a set of files (a m2v, wav, and quicktime reference file from an Omneon). Thus 2 instantiations (one tape, one set of files), and the 2nd instantiation uses three instantiationParts to define each file.

For instantiation relationships we'd want to do two things:

1. Express a relationship that the set of files was generated from the tape: this use case can not be done with the new relationGroup since it only applies to instantiationParts and not the instantiations themselves.
2. Express the relationships among the files that the Omneon generated: This can be done to some extent with the relationGroup each file (instantiationPart) can relate to one (and at most one) other file.

But since each instantiationPart may only use the relationGroup to relate to one other thing, then relating mutliple instantiationParts is tricky. Say we have a three reel film with each reel as an instantiationPart. We'd want to say that the second reel is preceded by the first reel and followed by the third reel, but this is two relationships and we can only say one via relationGroup. Could we repurpose pbcoreRelation (as done with rights) and stick it in the instantiation element?

[kvanmalssen]

The addition of instantiationPart and relationGroup does partially solve the problem that we had with the Omneon files sets for the NDIIPP project, but as Dave mentions, we would only be able to relate one file to one other, not all three to each other. So that's still an issue.

I agree that have relation elements at the Instantiation level would be really useful. Especially because it would allow instantiations to be identified as derivatives of others -- which as I understand it was the original intention of this change request. That is a very common use case.

Allowing pbcoreRelation elements at Instantiation would also enable the support of a root-level Instantiation option.

[MarcosSueiro]

I agree. Multiple relation elements at the Instantiation (and even essenceTrack) levels would be very useful indeed. For example, a scan may be a derivative of a record album [asset], but also be used in a web story which is a different asset.

[pdpinch]

Covered in the documentation at http://pbcore.org/v2/elements/pbcoreDescriptionDocument/pbcoreInstantiation/instantiationRelation

[MarcosSueiro]

Please note that the link to InstantiationRelationType is dead.