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


> Cheers
> Gordon
> [1]
> 2096BDAA8364E2E#3
> [2]
> [3]
> rep_notes/2012/11/report-of-the-meeting-of-the-joint-steering-committee-6-no
> vember-2012.html
> -----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
>> "For Example:
>>     film producer
>>     film director
>>     actor
>>     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
> cheat-sheet.
>>> 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.,
> <>.   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, maybe LC and/or another group can work to
> develop sanctioned translation-synonyms for the MARC relator and other
> codes.
>> 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
>> English?
> 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?

Karen Coyle
[log in to unmask]
ph: 1-510-540-7596
m: 1-510-435-8234
skype: kcoylenet