 |
 |
Thanks for the quick response, i'm glad to hear that use of the elements is not so restricted. So, that means that you could use the rda carrierType element with the URI of, say, a PBCore instantiationPhysical? thanks greta On 9/29/2015 8:38 AM, Gordon Dunsire wrote: > > Greta > > 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] <mailto:[log in to unmask]> > > *From:*Gordon Dunsire [mailto:[log in to unmask]] > *Sent:* September 21, 2015 11:23 AM > *To:* [log in to unmask] <mailto:[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] <mailto:[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] <mailto:[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] <mailto:[log in to unmask]> http://kcoyle.net > > m: +1-510-435-8234 > > skype: kcoylenet/+1-510-984-3600 >