This may be of interest.
Trevor Reynolds
Collections Registrar, English Heritage
tel: +44 (0) 1904 601905. 37 Tanner Row, York, YO1 6WP
-----Original Message-----
From: Museum discussion list [mailto:[log in to unmask]] On Behalf Of Allison Smith
Sent: 31 August 2014 16:54
To: [log in to unmask]
Subject: PBCore, CIDOC CRM, FRBRoo
Dear List -
My name is Allison Smith and I'm part of a working group focused on identifying ways to streamline and/or expand the PBCore metadata schema which to date, has been collaboratively developed by a wide range of individuals from the broadcast, library, and archives communities to aid in the cataloguing and exchange of time-based media (sound and moving image).
However, I've come to understand the schema in a much broader way - that it could be used as a model for the cataloguing, management and exchange of all types of objects (physical and conceptual), as well as their surrogate copies (physical and digital) - a model which would essentially be the basis for a hybrid collections management/surrogate asset management system. Here is a link to more information about PBCore, the schema, and the model.
http://www.pbcore.org/elements/
Currently, the PBCore model only accommodates the idea of a CIDOC CRM / FRBR "Conceptual" parent object (identified as "Intellectual Content") to which child digital and physical copies of that resource can be linked (identified as "Instantiation"). Child records inherit all cataloguing information from the parent, but, like FRBR, the Instantiation class includes both original and surrogate resource(s). While I find that modeling PBCore like FRBR works well for published and distributed material in which the physical format/carrier is not considered historic or collectible, I do find this model problematic for the cataloguing of unique art, natural history, and collectible artifacts where the physical format is so integral to the understanding and value of that resource.
Therefore, I'm recommending that PBCore include 2 classes of parent objects (Physical and Intellectual - similar to CIDOC CRM) and 2 classes of child Objects (Digital and Physical), so that the PBCore schema can more closely resemble CIDOC CRM and FRBR combined. Both parent classes of objects would use the same PBCore/Dublin Core fields for cataloguing, with the exception that the parent Physical object class would include format, dimensions, and physical description fields (at this time, only found at the Instantiation/child level).
It should be noted however, that PBCore also accommodates the idea of using Extensions, so that other schema elements (VRA, CDWA, METS, PREMIS, etc.) not defined by PBCore can be accommodated in a PBCore record. So, I'm willing to concede that having a PBCore Physical Object class might not be absolutely necessary for museums to use PBCore for data exchange (or as a model for creating a hybrid collections/information management system). However, I think that having a Physical Object class would work to standardize and streamline the schema to the CIDOC CRM model, making the schema more flexible, open, and obviously accommodating to more (all?) types of institutions/collections/objects. It would also allow developers a more obvious means to create systems where the class of object determines its properties and behaviors, and allow cataloguers more flexibility in choosing how to catalogue and manage their bibliographic or time-based resources (using either the FRBR or CIDOC CRM model as they see fit, at the time of record creation).
I'm hoping some of you on the list have feedback for the schema team on this issue. The PBCore schema committee has opened up its Issues tracker page on GitHub to the public for feedback. The issue in questions is #52, but you should feel free to comment on any issue. Regarding this issue, I originally thought we needed perhaps 3 classes at the parent level: Intellectual Content, Physical Object, and Born Digital Object. However, I'm thinking now that born digital objects can be catalogued/treated as Intellectual content (Conceptual) objects, and would not need its own class. But, feel free to comment on that too.
The PBCore GitHub Issue tracker is here:
https://github.com/WGBH/PBCore2.0/issues
I/we welcome your feedback. If you think what I've outlined in this email is important, necessary, or makes sense (or even if you don't agree) - you should feel free to make your comments known to the PBCore group. Thank you! I appreciate your time in reading this email, and we look forward to your comments.
Also feel free to forward this email to other Museum related lists you might think interested.
Thanks again!
Allison Smith
PBCore Schema team
=========================================================
Important Subscriber Information:
The Museum-L FAQ file is located at http://www.finalchapter.com/museum-l-faq/ . You may obtain detailed information about the listserv commands by sending a one line e-mail message to [log in to unmask] . The body of the message should read "help" (without the quotes).
If you decide to leave Museum-L, please send a one line e-mail message to [log in to unmask] . The body of the message should read "Signoff Museum-L" (without the quotes).
This e-mail (and any attachments) is confidential and may contain personal views which are not the views of English Heritage unless specifically stated. If you have received it in error, please delete it from your system and notify the sender immediately. Do not use, copy or disclose the information in any way nor act in reliance on it. Any information sent to English Heritage may become publicly available.
Portico: your gateway to information on sites in the National Heritage Collection; have a look and tell us what you think.
http://www.english-heritage.org.uk/professional/archives-and-collections/portico/
****************************************************************
website: http://museumscomputergroup.org.uk/
Twitter: http://www.twitter.com/ukmcg
Facebook: http://www.facebook.com/museumscomputergroup
[un]subscribe: http://museumscomputergroup.org.uk/email-list/
****************************************************************
|
