On 11/30/12 3:49 AM, Gordon Dunsire wrote:
> Until this happens, the designator
> labels and definitions in the current Toolkit are the master versions, and
> it is unsafe to use the OMR versions.
> Hope this helps!
Not those who don't have access to the Toolkit, unfortunately. So many
of us will be working with out-of-date versions for a while. However, I
do want to say: Hooray for the OMR! Because it IS OPEN, and that is very
important. I look forward to the day when it is up to date and all of
the terms have definitions. (To John Attig: and I am willing to help
with the clerical aspect of updating if that is needed.)
>  http://www.rda-jsc.org/docs/6JSC-CILIP-rep-2.pdf
> -----Original Message-----
> From: Bibliographic Framework Transition Initiative Forum
> [mailto:[log in to unmask]] On Behalf Of Mark K. Ehlert
> Sent: 30 November 2012 09:16
> To: [log in to unmask]
> Subject: Re: [BIBFRAME] BIBFRAME relationship indicators & coding
> J. McRee Elrod <[log in to unmask]> wrote:
>> Mark said:
>>> There is no such designator in RDA. It's "composer (expression),"
>>> which I believe you export to your clients as simply "composer".
>> It is in the registry:
>> It is also in the version of RDA to which I have access at 184.108.40.206:
>> "For Example:
>> film producer
>> film director
>> composer of music for sound film"
>> Perhaps you looked in the wrong list?
> No, I looked in the correct list--the current version of RDA's Appendix I.
> The "composer of music for sound film" designation appeared in the November
> 2008 draft of RDA, but it was wiped out with a number of other terms to form
> the current Appendix I list first pushed out with the initial June 2010
> publication of RDA. The examples in Chapter 18 were revised too.
> I see that term is still classed as "new-proposed" at the Metadata Registry.
> Don't know if that means anything in this context.
>> One list in alphabetic order
>> would be much easier, perhaps coded for use with one or more of WEMI?
> I've already made a single alphabetical list with WEMI labels, to use as a
>>> If the intent is to use URIs to describe relationships currently
>>> depicted by our current use of MARC relator codes ...
>> The URIs lead to terms in English. The $4 MARC codes can be exported
>> in any language.
> The RDA relationship designators and other controlled terms are also
> "codes." They're given as English words in the text, but can be represented
> using URIs that can point to multiple language labels for the same concept.
> For instance, a number of the RDA terms at the Metadata Registry are
> available in both English and German, e.g.,
> <http://metadataregistry.org/schemaprop/show/id/374.html>. Though
> pointing at the same thing via a URI, an English catalog can be set up to
> display the English label, and the German catalog set up to display the
> German label. Or perhaps even set up to prefer certain words over others in
> a particular language.
> To your point about id.loc.gov, maybe LC and/or another group can work to
> develop sanctioned translation-synonyms for the MARC relator and other
>> So much of RDA and Bibframe is Anglocentric.
> Can't speak to the BIBFRAME since the coding part hasn't come up yet aside
> from references to or examples in RDF/XML and Turtle.
> But RDA? Yes, it is Anglocentric, certainly with regard to its
> vocabularies--it's directed at an English-speaking audience. Will those
> vocabularies still be Anglocentric when RDA gets translated into Spanish?
> And German? And French?
> Furthermore, will the RDA term "maps" *mean* the same thing with each
> language? Likely. Will that term be *represented* in the same way in each
> translation and in their respective bib records and catalogs?
> Likely no. English "maps" = German "Karten" = French "cartes". Using
> potentially the same URI. But we're still a long way from making this
> happen in a typical library catalog.
>> I wonder if our Quebec,
>> European, and Asian clients would accept Bibframe XML markup in
> Are they reading the mark-up? Or is the computer reading the mark-up and
> presenting it in a familiar form on the screen? Compare reading "raw" MARC
> to reading formatted MARC. Or reading HTML code versus viewing the content
> of a web page.
> If it's an issue, XML isn't limited to tags containing roman characters.
> Not sure about Turtle or other methods of markup.
>> They would certainaly not accept English inclusions in records for non
>> English resources.
> Understandable. It interferes with the parts of the record that should be
> read by the public--the spelled out bits. But do they balk at the
> quasi-English MARC codes "lat" and "ger" and "fre" and "eng", for instance?
[log in to unmask] http://kcoyle.net