allow instantiation at the top level

[WeAreAVP]

This didn't make it into the cut down schema request (though was requested by at least Kara and it's something I've found need for), but adding

at the top level would allow for use of PBCore as a fully technical standard (where appropriate) without requiring the descriptive part (sort of allowing the reverse of the instantiation minOccurs="0" where PBCore can now be used as a solely descriptive standard). Thoughts?

[dmaccarn]

Sounds OK, let's see if there are any other requests.

[kvanmalssen]

Yes, please! I've seen a need for this in a number of places (including NDIIPP). When an organization already has a good descriptive standard that they are happy with (like MODS or Dublin Core) but are in need of a technical standard, this would allow them to use PBCore to meet their needs and still be valid. Since PBCore is one of the few things out there that offers very rich technical metadata for AV objects, I know this would be quite useful. Plus it would play nicely with METS, BagIt, etc.

PREMIS does something similar - the root can be either or any of its entities like

[dmaccarn]

However, if this were allowed the only reference to the instantiation would be the ID number and the annotations. There is no other title or description.

[kvanmalssen]

PREMIS uses linkingIntellectualEntityIdentifier to solve this (and linkingEventIdentifier, linkingRightsStatement, relatedObjectIdentification, etc). So if there were relation elements at the Instantiation level, that could resolve the issue.

I mainly see this being used by folks that will have something else holding the whole thing together, like METS.

[dmaccarn]

But that would require an addition set of relation elements. Then why not use the ones we already have by entering though the pbcoreDescriptionDocument level?

[WeAreAVP]

...Because the pbcoreRelation element expresses information about the relationship between an 'asset' and something else (probably another asset). It does not relate instantiations. [note that instantiation relationship is another issue]

If a PBCore document only expresses a pbcoreInstantiation element than I don't think a title or description would be expected (otherwise the document would probably express an asset ).

I've found non-METS needs for this as well, such as when technical metadata of files or tapes needs to be compiled before any information is known about the content. Allowing a pbcoreInstantiation element at the top would allow for PBCore to be used as a purely technical standard if need be (and as Kara noted PBCore does this well in this regard compared to the other library-ish standards), but it's currently impossible to use PBCore technical abilities unless the parent intellectual content is described.

[dmaccarn]

I'm reluctant to provide an additional set of elements to support this but, how about the addition of a root element like this:

The question is whether you can live with the relationGroup as the only attributes?

[WeAreAVP]

Yes adding that root element would be very helpful. Any reason to change the name of the instantiation element (from 'pbcoreInstantitaion' to 'pbcoreInstantiationDocument') if its at the top? For instance 'pbcoreDescriptionDocument' is called 'pbcoreDescriptionDocument' whether it is the top level element or contained within 'pbcoreCollection'.

Re: instantiation relations we should switch comments to here.

[dmaccarn]

A new name allows for the entry to go to the instantiationPartType which includes the attributes for the instantiation relations. Otherwise we would have to have a new instantiationType with different relation attributes. Entry at the pbcoreInstantiation would have to have multiple parts to include the relation attributes.

[WeAreAVP]

If we allowed the relationGroup at instantationType instead of only instantiationPartType then we'd be able relate instantiations among themselves instead of only expresses relationship among parts of instantaitions. And we could use even less types. More comments on this at the instantiation relationship thread.

[dmaccarn]

The instantiationPart was in response to the instantiation thread.

I think I have a solution. We move the attribute up a level as you suggest and change the type of the instantiationPart.

I'll send you a new draft.

[WeAreAVP]

Sounds like a good step. A new draft would be helpful, the one we're reviewing is over two weeks old.

[foo4thought]

I initially objected to this because:

1. it's generally bad practice to codify for the exceptions instead of the rules, and this discussion is aimed to do exactly that;
2. content with metadata is a liability, so an instantiation-only record cannot be an asset.

PBCore has evolved from being a simple, flat and easy to understand structure, to one that has iteratively become more complex and hierarchical. Now we are poised to make it drastically more so; the Beast 2.0 will have different "heads" (root elements), either in tandem with or instead of (?) multiple "tails" (pbcoreExtension elements) to accommodate various needs of external data systems. But it will accommodate the need to catalog "miscellaneous?"

Heracles! Where are you now?

[jackbrighton]

I empathize with the concern about making PBCore overly complex. But like many of the changes in 2.0, this merely enables more complex applications of PBCore, it doesn't mandate them. We'll still be producing simple PBCore records, and then those who need it to do various acrobatics can use PBCore without breaking arms and limbs.

I think the biggest challenge here is in the documentation. One way to address that is a tiered approach. Most people won't even want to see the words METS or PREMIS when learning how to use PBCore, but advanced users will want to know how to embed (in this case) a PBCore instantiation in another wrapper. This merely makes it possible.

[pdpinch]

This has been addressed in draft 7: 8ae968bb99c5208f2dd9f36d722d0257356f72df

I think Kevin has been outvoted, but if I'm wrong, we can reopen this.

[WeAreAVP]

I agree and think this is resolved. Only slight hesitation was the renaming of the pbcoreInstantiation element to pbcoreInstantiationDocument if it's used at the top, but I can live with this (probably just have to add an 'or' statement to some XSLs).