The RDA vocabulary for carrier details is not open.  It is possible that additional rules could be added, but they are likely to be few and infrequent.


I would support the use of classes.  It makes sense and we certainly considered it.  But there has been resistance to adding a lot to BIBFRAME in support of any one cataloging code.  In the end, we chose a method that does not require any additional properties or classes.




From: Bibliographic Framework Transition Initiative Forum [mailto:[log in to unmask]] On Behalf Of Karen Coyle
Sent: Monday, September 14, 2015 10:25 PM
To: [log in to unmask]
Subject: Re: [BIBFRAME] Proposal on carrier details


Could these be modeled as SKOS vocabularies? And I don't see a reason why many classes is a problem (although it could also be many properties, modeled as properties/subproperties, which is how it would be in SKOS). The number of them is the same whether you have them as strings, properties, or classes, isn't it? Or is the RDA vocabulary "open"? (That is, not finitely defined.)


On 9/14/15 8:02 PM, Joseph Kiegel wrote:

When describing physical carriers, RDA provides data elements for technical details such as Base Material, Generation, Polarity, Sound Characteristic, Video Characteristic, etc.


Previous work on a mapping from RDA to BIBFRAME showed there is no immediately obvious way to treat these technical details in BIBFRAME when mapping directly from RDA. This situation differs from MARC encoding of carrier technical details, where they are part of MARC fields that have a more obvious mapping.


This proposal describes a way to treat carrier technical details in BIBFRAME using existing properties and classes. While it focusses on carrier details in RDA, it should work with other cataloging codes.


The proposal, which was written by Theo Gerontakos and me,  is attached and also available at:





Karen Coyle
[log in to unmask]
m: +1-510-435-8234
skype: kcoylenet/+1-510-984-3600