No, it wouldn’t.

There is no such requirement in RDA or built-in to the RDA elements.

There is a general guideline in RDA that says any named vocabulary encoding scheme can be used as a substitute for the given scheme.

The RDA Registry properties do not specify what VES to use. In linked data, this is usually specified in a separate application profile; a basic AP for RDA, indicating what VES to use with an RDA property, is under development.

Currently, the RDA Registry does not even specify a range for these properties, on the assumption that the value may be a literal (the preferred name or label of the vocabulary value) or an object (the URI of the vocabulary value). RDA data applications are expected to refine the RDA property to satisfy local conditions. However, the Registry may well offer a complete set of such refinements in future, depending on the outcome of proposals to develop RDA under discussion by the JSC and its constituencies.

I agree that the RDA VES for Encoding format is inadequate. Although it is a Manifestation element, the VES mixes its semantics with content designations that should be confined to the Expression. The JSC welcomes suggestions for improving the vocabulary, or for suitable external vocabularies.

Cheers

Gordon

From: Bibliographic Framework Transition Initiative Forum [mailto:[log in to unmask]] On Behalf Of Greta de Groat
Sent: 29 September 2015 15:54
To: [log in to unmask]
Subject: Re: [BIBFRAME] Proposal on carrier details

Would that imply (or require) that the rda.rdf element would need to contain RDA vocabulary for that element? For example the prescribed vocabulary for 3.19.3.3 for encoding format is quite inadequate to the real-world situation of many newer format types and complicated digital objects like games.

Greta de Groat
Stanford University Libraries

On 9/21/2015 1:28 PM, Boehr, Diane (NIH/NLM) [E] wrote:

This discussion seems to be the perfect use case to justify a modular approach to BIBFRAME. We already have a perfectly good vocabulary of linked data elements to record content and carrier characteristics. Why do we need to re-create each of these as properties or classes in BF? If you want to describe technical details as required in RDA, just augment your BF description with rda.rdf elements.

Diane Boehr

Head of Cataloging and Metadata Management

National Library of Medicine

8600 Rockville Pike

MSC 3823

Bethesda, MD 20894

301-435-7059

[log in to unmask]

From: Gordon Dunsire [mailto:[log in to unmask]]
Sent: September 21, 2015 11:23 AM
To: [log in to unmask]
Subject: Re: [BIBFRAME] Proposal on carrier details

All

To clarify:

The “RDA vocabulary” that Joe is referring to is a major part of the element set for the RDA Manifestation entity [1]. Most Manifestation elements fall into one of two categories: carrier details, and self-descriptive data (how the resource describes itself via title, publication statement, etc.). Most of the carrier detail elements, for example Carrier type, Base material [2], etc., are associated with RDA vocabulary encoding schemes represented in RDF as SKOS value vocabularies. The RDA element set vocabularies are represented in RDF using RDFS and a little light OWL.

The basic RDA content and carrier categories are defined by the RDA/ONIX Framework for Resource Categorization (ROF) [3]. The specified ROF categories are all exhaustive; that is, they use vocabulary encoding schemes that represent all possible values. The corresponding RDA categories therefore form part of an exhaustive set. Other RDA carrier detail elements have counterparts in ROF, for example Base material, so developing RDA to be more consistent with ROF may result in changes to the “RDA vocabulary”. The JSC recently published guidelines on extending RDA categories using ROF [4].

Cheers

Gordon

[1] http://www.rdaregistry.info/Elements/m/

[2] http://www.rdaregistry.info/termList/RDAbaseMaterial/

[3] http://www.rdaregistry.info/Elements/rof/

[4] http://www.rda-jsc.org/node/349

From: Bibliographic Framework Transition Initiative Forum [mailto:[log in to unmask]] On Behalf Of Joseph Kiegel
Sent: 15 September 2015 22:21
To: [log in to unmask]
Subject: Re: [BIBFRAME] Proposal on carrier details

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.

Joe

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.)

kc

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:

http://www.lib.washington.edu/msd/pubcat/ld/uw-carrier-details-proposal

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