Final PBCore 2.0 Change Requests

Here is the final PBCore 2.0 changes document, which builds on the iterative work to define the PBCore requirements that’s been shared in previous postings here. With the PBCore 1.3 requirements addressing American Archive’s needs, version 2.0 addresses additional requirements for American Archive and includes changes culled from the recent public change request process.

Final PBCore 2.0 Change Request Report (XLS)

The same information is sorted and organized in several different layouts:

  • The 1st sheet are the changes for the schema, which consolidates similar requests that can be viewed in different layouts on the 2nd and 3rd sheets
  • The 2nd sheet represents the change requests by requestor
  • The 3rd sheet shows the change requests by type

This is the roadmap that will be used to develop 2.0. Stay tuned here for further developments and join the conversation!

One response to “Final PBCore 2.0 Change Requests”

  1. Marcos Sueiro

    Hi! I sent these to Courtney in an unofficial manner, but just in case below are some suggestions we have thought of at the WNYC Archives.

    We could use a repeatable dateIssued field in the Intellectual Content section. This is to avoid repetition (i.e. entering dateIssued in every related instantiation) and to give a sense of the “important” date related to a broadcast (the request for a repeatable field is to accommodate rebroadcasts). The date fields in the instantiation fields are also helpful, though.

    Make essenceIdentifier a repeatable field, preferably with an optional accompanying essenceIdentifierSource. This helps us in our current project, where we need to keep track of different instantiations and dubs of the same material (but divided in different and sometimes surprising ways). For example, the side of a disc may end up on a tape from which we make a digital dub –as well as a dub of the original disc.

    Create a repeatable essenceAnnotation field, with an optional drop-down “essenceAnnotationType” user-defined field (similar to descriptionType, but not controlled). Indeed, this would solve many our current or future problems, although perhaps it would be too flexible for it to be part of a standard.

    Create a user-defined instantiationAnnotationType: (Another idea would be adding a repeatable instantiationDescription with a companion instantationDescriptionType) field, just like it is in the Intellectual Content section. (Indeed, the more I look at this standard, the more I imagine an infinitely-nested taxonomy with a few variable required fields, but potentially almost all fields available in all layers –but I digress).

    Despite the above request, the following optional fields would be helpful:
    Quality (referring to the sound quality of the content), probably with a controlled vocabulary (from low to high)
    Condition (referring to the physical condition of the carrier) probably with a controlled vocabulary (from low to high)
    stockBrand (or Brand) (as in AES schema) – Is this already being implemented? This may be important for future prioritization projects.
    dimensions – Since archival practice recommends shelving by size, this is important for finding an original recording. The field should be repeatable so that we can add things like caliper or gauge or groove size if necessary. If an accompanying dimensionsUnit were added, complications related as to what type of dimension (diameter, thickness, etc.) would probably be avoided (this gets quite complicated in the upcoming AES standard). For example, imagine the following fields when describing a reel of tape:

    7
    inches

    0.25
    inches

    0.0015
    inches

    It would be obvious that these dimensions refer to diameter, gauge and thickness, respectively (perhaps it could even be extended to allow memory units (MB, GB) as sizes, thus substituting the current fileSize field).

    instantiationContributor (repeatable). This allows adding individual contributions to the various instantiations (e.g. re-recording engineer, or additional interviewee in that particular instantiation). Ideally, this would automatically include the cataloger of the record (i.e., whoever is logged in) as “dubbing engineer”, since they usually are the same person. Is this difficult to implement?

    Thanks for indulging me… Keep up the good work! And great presentation at IASA.

Leave a Reply