Re: [RDA-L] Cataloging playaways
Julie, If you insist on a straight answer... If my library promoted them as Playaways and users knew them as Playaways, I would probably argue for calling them Playaways in the physical description. (As they say, What you do in the local catalog stays in the local catalog.) In an ideal world, where records carried more information in coded form, I would have a coded value in the record rather than a literal (something analogous to ONIX's AK) and would leave it up to the local library what literal they wanted to have display in their catalog. In a shared catalog like OCLC, I would probably follow standard practice to the extent it exists. In 2008 the Playaway Cataloging Joint Task Force-yes, there was such a thing-recommended 1 sound media player so I would probably go with that. http://www.olacinc.org/drupal/capc_files/playawaysPDF.pdf Ed From: Resource Description and Access / Resource Description and Access [mailto:RDA-L@LISTSERV.LAC-BAC.GC.CA] On Behalf Of Julie Moore Sent: Thursday, April 21, 2011 5:07 PM To: RDA-L@LISTSERV.LAC-BAC.GC.CA Subject: Re: [RDA-L] Cataloging playaways Ed, Are you saying that you would call it a: 300 1 pre-recorded MP3 player ? Just curious! Thanks, Julie On Wed, Apr 20, 2011 at 3:13 PM, Ed Jones ejo...@nu.edumailto:ejo...@nu.edu wrote: FWIW, ONIX calls it a pre-recorded MP3 player, which also seems to be the name used in the marketplace, if a Google search I just did is any indication (1.5 million results as a quoted string). The new product form was added to ONIX in early 2007. The RDA ONIX framework predates this (unless there is a newer version than version 1.0). http://www.onixtools.de/downloads/ONIX_Code_Lists_Issue_7_Changes.pdf Ed Jones -- Julie Renee Moore Catalog Librarian California State University, Fresno julie.renee.mo...@gmail.commailto:julie.renee.mo...@gmail.com 559-278-5813 There is more to life than simply increasing its speed. ~ Mahatma Gandhi
Re: [RDA-L] Linked files
Quoting J. McRee Elrod m...@slc.bc.ca:
So these identifiers link to *inhouse* files? Shakespeare once
rather than repeated as author, added entry, and subject, in multiple
bibliographic records?
Again, separate linking from identification. Identifiers identify.
That's what they do. There is great importance in identification for
sharing, as we know from library authority work. The difference
between identifiers and creating authorities, however, is that
authorities in libraries today are represented with text strings, thus
making them language dependent. Also, if you wish to change your
display you also change the string that identified the entity -- and
that breaks a fundamental rule of identification, which is that the
identifier must not change.
How you get from identifier to display is entirely up to you and your
system. It is influenced by a number of factors including how widely
you share your data, who you share it with, how robust your system is,
etc., etc. So do not assume that identification locks you into any
particular technology for managing display because there are many
possible solutions, and obviously your system should use the one that
works for your situation. This includes decisions about how often you
might update a local data store to match the primary authoritative
one. This is very similar to what most systems do today with authority
data -- they get updates on a regular schedule. None of that really
changes.
Almost all database systems use identifiers internally for data
elements, not text strings, so in a sense we already work in this
environment. The difference is, though, that within a database those
identifiers are only meaningful locally. Our goal in using identifiers
is for sharing so the identifiers themselves have to be shared. Maybe
we should have another name for these IDs, something that indicates
that they are public, shared, and intended to be meaningful outside of
individual DBMSs.
kc
UTLAS was doing this in 1979, with the authority RSN (001) in the
1XX/6XX/7XX of bibliographic records, rather than the text. When
doing original cataloguing, one could enter the RSN as opposed to the
text, or just shakespeare william 1564. and you would get the RSN in
the field of the bibliographic record when the record was verified.
If later a heading changed, the new form would of course be called up
by the RSN and displayed.
But from your writing, it seemed to me that the identifiers link to a
single international file. Sorry not to have understood you properly.
__ __ J. McRee (Mac) Elrod (m...@slc.bc.ca)
{__ | / Special Libraries Cataloguing HTTP://www.slc.bc.ca/
___} |__ \__
--
Karen Coyle
kco...@kcoyle.net http://kcoyle.net
ph: 1-510-540-7596
m: 1-510-435-8234
skype: kcoylenet
Re: [RDA-L] Cataloging playaways
Dear Ed, Thank you for your straight answer ... (which I think is really 3 if-then answers.) I am aware of the 2008 OLAC Playaway Cataloging Joint Task Force recommendations, but I take that with a grain of salt since RDA was not actually published yet. It was the best that they could come up with at the time, but a lot has happened with RDA since then. So I think that this document is rather dated, as far as RDA life is concerned. I think that this example illustrates that we are not quite there yet with RDA. I do not think that we've gotten to a final answer just yet on this ... and many other issues. Thanks kindly for your thoughtful response. Best wishes, Julie On Fri, Apr 22, 2011 at 7:58 AM, Ed Jones ejo...@nu.edu wrote: Julie, If you insist on a straight answer… If my library promoted them as Playaways and users knew them as Playaways, I would probably argue for calling them Playaways in the physical description. (As they say, What you do in the local catalog stays in the local catalog.) In an ideal world, where records carried more information in coded form, I would have a coded value in the record rather than a literal (something analogous to ONIX’s “AK”) and would leave it up to the local library what literal they wanted to have display in their catalog. In a shared catalog like OCLC, I would probably follow standard practice to the extent it exists. In 2008 the Playaway Cataloging Joint Task Force—yes, there was such a thing—recommended “1 sound media player” so I would probably go with that. http://www.olacinc.org/drupal/capc_files/playawaysPDF.pdf Ed *From:* Resource Description and Access / Resource Description and Access [mailto:RDA-L@LISTSERV.LAC-BAC.GC.CA] *On Behalf Of *Julie Moore *Sent:* Thursday, April 21, 2011 5:07 PM *To:* RDA-L@LISTSERV.LAC-BAC.GC.CA *Subject:* Re: [RDA-L] Cataloging playaways Ed, Are you saying that you would call it a: 300 1 pre-recorded MP3 player ? Just curious! Thanks, Julie On Wed, Apr 20, 2011 at 3:13 PM, Ed Jones ejo...@nu.edu wrote: FWIW, ONIX calls it a pre-recorded MP3 player, which also seems to be the name used in the marketplace, if a Google search I just did is any indication (1.5 million results as a quoted string). The new product form was added to ONIX in early 2007. The RDA ONIX framework predates this (unless there is a newer version than version 1.0). http://www.onixtools.de/downloads/ONIX_Code_Lists_Issue_7_Changes.pdf Ed Jones -- -- Julie Renee Moore Catalog Librarian California State University, Fresno julie.renee.mo...@gmail.com 559-278-5813 There is more to life than simply increasing its speed. ~ Mahatma Gandhi
Re: [RDA-L] Linked files
On 22/04/2011 18:33, Karen Coyle wrote: snip Quoting J. McRee Elrod m...@slc.bc.ca: So these identifiers link to *inhouse* files? Shakespeare once rather than repeated as author, added entry, and subject, in multiple bibliographic records? Again, separate linking from identification. Identifiers identify. That's what they do. There is great importance in identification for sharing, as we know from library authority work. The difference between identifiers and creating authorities, however, is that authorities in libraries today are represented with text strings, thus making them language dependent. Also, if you wish to change your display you also change the string that identified the entity -- and that breaks a fundamental rule of identification, which is that the identifier must not change. /snip There is another way of looking at our headings than solely as textual strings, which is not entirely correct, but rather as identifying something *unambiguously*. This is exactly what our headings are designed to do. An identifier does not have to be composed only of numbers, but any string. This is why I have suggested reconsidering our headings *as* identifiers, since catalogers have worked very, very hard for a long time to keep them unique, or unambiguous. We can see how this works in VIAF, which allows you to search exact name in the LCNAF form for, e.g. Tchaikovsky's heading, e.g. http://viaf.org/viaf/search?query=local.names+exact+%22Tchaikovsky,%20Peter%20Ilich,%201840%201893%22+and+local.sources+any+%22lc%22stylesheet=/viaf/xsl/results.xslsortKeys=holdingscountmaximumRecords=100, or for the Swedish form, http://viaf.org/viaf/search?query=local.names+exact+%22Tjajkovskij,%20Pjotr,%201840%201893%22+and+local.sources+any+%22selibr%22stylesheet=/viaf/xsl/results.xslsortKeys=holdingscountmaximumRecords=100. This works for all forms. I think it would only take a change in mindset for this to work. There is a VIAF api right now, and I would like to try to implement it. Has anyone done so? -- James Weinheimer weinheimer.ji...@gmail.com First Thus: http://catalogingmatters.blogspot.com/ Cooperative Cataloging Rules: http://sites.google.com/site/opencatalogingrules/
Re: [RDA-L] Linked files
I think Karen captures this very well below, and will add that the
linked data ecosystem should allow the local systems she describes to be
based on the very technologies that enable the web as a whole.
In 2009, when the original lchs.info went offline to be replaced by
id.loc.gov, Dan Chudnov posted an excellent essay on how the
well-understood techniques of caching and proxying web content might
also apply to web-based /data/.
http://onebiglibrary.net/story/caching-and-proxying-linked-data
This piece seems very relevant to the discussion of how to apply a
lots-of-copies mindset to this emerging approach to library metadata.
-Corey
On 4/21/2011 6:02 PM, Karen Coyle wrote:
If you are referring to me, I have to say that I did not expect
breaking out of the silos to be interpreted in this way... thus
another lesson in learning to convey these concepts.
Breaking of our silos has to do with sharing our data with other
communities, and that goes both ways: that we would be able to link to
data from any sources, and any sources would be able to link to library
data. Linking does not mean that the local system is incomplete in any
way. In fact, much like some discovery interfaces today, linking can
provide additional information or new paths for the user to follow. A
link can be this document cites this other document or this person
has a web page over here.
Linking is not the same as using identifiers rather than text strings
for entities, although both are considered best practices and linking
depends greatly on clear identification.
I agree with previous posts here that essential systems will probably
make use of caches for some data that has external dependencies, much as
they do today. In fact, when the British Library issued their National
Bibliography in a linked data format there was a lengthy discussion
about the best way to provide both identifiers and convenient display
forms at the same time (discussed, but not concluded, as I recall).
There are practical realities to all of this, and I can only reiterate
that we are in an experimental phase with a certain number of currently
unanswered questions. But the folks working on this in the library arena
are trying very hard to figure out what actually can work for us in a
practical way. Believe me, if there are obvious pitfalls, they are
visible to all of us.
kc
Quoting J. McRee Elrod m...@slc.bc.ca:
Mark Ehlert asked:
Once again, where do you get the idea that these links are switches
permanently set to the on position and the linked information not
locally cached in some manner?
Karen Doyle, takinng us out of our silos. Some other posters here
assume no linkage, no display of that complete bibliographic record.
Linkage for updating purposes is great, and should have occured
decades ago. UTLAS (blessed be its memory) was doing it in 1979.
If locally catched, fine. That's what we did with linked UTLAS files
But no OPAC should depend on offsite files being available to display
a complete bibliographic record, no matter how redundantly
available. The present NAF is not redundantly available, nor is it
likely to be.
__ __ J. McRee (Mac) Elrod (m...@slc.bc.ca)
{__ | / Special Libraries Cataloguing HTTP://www.slc.bc.ca/
___} |__ \__
--
Corey A Harper
Metadata Services Librarian
New York University Libraries
20 Cooper Square, 3rd Floor
New York, NY 10003-7112
212.998.2479
corey.har...@nyu.edu
Re: [RDA-L] Cataloging playaways
But what you do in the local catalog, does not actually stay in the local catalog, because records get batchloaded to WorldCat and other union catalogs (or catalogues) and, when that happens, what then will happen with the matching algorythms for deduping records if each record has a different SMD? 1 sound media player 1 pre-recorded MP3 player 1 pre-recorded digital audio player 1 Playaway 1 audio media player 1 digital media player 1) Is there an explicit code, currently in use in MARC--that we can use while we are creating RDA descriptions in a MARC environment, that will make it clear to a matching algorythm that this record is describing the same thing as that record, no matter what is in the 300$a? 2) And since this is the RDA-L not the MARC-L, is there a combination of RDA data elements that will reliably indicate that this description is describing the same thing as that description, no matter what is in the SMD, for whatever future matching we will need to do? 3) And/or is this another situation where The Registry could *really* help, so that every SMD is registered, before it is used in a description in a library environment, so that a matching algorythm can check the registry and match on 'variant' terms? And, if so, when will that become an integral part of our cataloging procedures? Deborah -- Deborah Fritz MARC Database Consultant The MARC of Quality www.marcofquality.com http://www.marcofquality.com/ Voice/Fax: (321) 676-1904 On Friday, April 22, 2011 10:58 AM , Ed Jones mailto:ejo...@nu.edu ejo...@nu.edu wrote: Julie, If you insist on a straight answer. If my library promoted them as Playaways and users knew them as Playaways, I would probably argue for calling them Playaways in the physical description. (As they say, What you do in the local catalog stays in the local catalog.) In an ideal world, where records carried more information in coded form, I would have a coded value in the record rather than a literal (something analogous to ONIX's AK) and would leave it up to the local library what literal they wanted to have display in their catalog. In a shared catalog like OCLC, I would probably follow standard practice to the extent it exists. In 2008 the Playaway Cataloging Joint Task Force-yes, there was such a thing-recommended 1 sound media player so I would probably go with that. http://www.olacinc.org/drupal/capc_files/playawaysPDF.pdf Ed On Thursday, April 21, 2011 5:07 PM , Julie Moore mailto:julie.renee.mo...@gmail.com julie.renee.mo...@gmail.com wrote: Ed, Are you saying that you would call it a: 300 1 pre-recorded MP3 player ? Just curious! Thanks, Julie On Wed, Apr 20, 2011 at 3:13 PM, Ed Jones ejo...@nu.edu wrote: FWIW, ONIX calls it a pre-recorded MP3 player, which also seems to be the name used in the marketplace, if a Google search I just did is any indication (1.5 million results as a quoted string). The new product form was added to ONIX in early 2007. The RDA ONIX framework predates this (unless there is a newer version than version 1.0). http://www.onixtools.de/downloads/ONIX_Code_Lists_Issue_7_Changes.pdf Ed Jones --
Re: [RDA-L] Cataloging playaways
I thought that RDA as a code used neither GMD _nor_ SMD, replacing those with the data elements that end up in the new mac 3xx fields? Can anyone confirm that, that there is no notion of 'smd' in RDA? If so, there would be no answer to having every SMD registered in the RDA registry, nor to way to indicate in RDA that the SMD should be ignored -- RDA already ignores the SMD. No? Matching algorithms in union catalogs may have to be updated to take account of RDA. Of course, if people are just entering free text in the new 3xx MARC fields for RDA, instead of using a controlled vocabulary, that could still be a problem for matching algorithms. Exact same sort of problem as if people were/are entering free text instead of controlled vocabulary in the GMD/SMD of course. From: Resource Description and Access / Resource Description and Access [RDA-L@LISTSERV.LAC-BAC.GC.CA] on behalf of Deborah Fritz [debo...@marcofquality.com] Sent: Friday, April 22, 2011 2:52 PM To: RDA-L@LISTSERV.LAC-BAC.GC.CA Subject: Re: [RDA-L] Cataloging playaways But what you do in the local catalog, does not actually stay in the local catalog, because records get batchloaded to WorldCat and other union catalogs (or catalogues) and, when that happens, what then will happen with the matching algorythms for deduping records if each record has a different SMD? 1 sound media player 1 pre-recorded MP3 player 1 pre-recorded digital audio player 1 Playaway 1 audio media player 1 digital media player 1) Is there an explicit code, currently in use in MARC--that we can use while we are creating RDA descriptions in a MARC environment, that will make it clear to a matching algorythm that this record is describing the same thing as that record, no matter what is in the 300$a? 2) And since this is the RDA-L not the MARC-L, is there a combination of RDA data elements that will reliably indicate that this description is describing the same thing as that description, no matter what is in the SMD, for whatever future matching we will need to do? 3) And/or is this another situation where The Registry could *really* help, so that every SMD is registered, before it is used in a description in a library environment, so that a matching algorythm can check the registry and match on 'variant' terms? And, if so, when will that become an integral part of our cataloging procedures? Deborah -- Deborah Fritz MARC Database Consultant The MARC of Quality www.marcofquality.comhttp://www.marcofquality.com/ Voice/Fax: (321) 676-1904 On Friday, April 22, 2011 10:58 AM , Ed Jones ejo...@nu.edumailto:ejo...@nu.edu wrote: Julie, If you insist on a straight answer… If my library promoted them as Playaways and users knew them as Playaways, I would probably argue for calling them Playaways in the physical description. (As they say, What you do in the local catalog stays in the local catalog.) In an ideal world, where records carried more information in coded form, I would have a coded value in the record rather than a literal (something analogous to ONIX’s “AK”) and would leave it up to the local library what literal they wanted to have display in their catalog. In a shared catalog like OCLC, I would probably follow standard practice to the extent it exists. In 2008 the Playaway Cataloging Joint Task Force—yes, there was such a thing—recommended “1 sound media player” so I would probably go with that. http://www.olacinc.org/drupal/capc_files/playawaysPDF.pdf Ed On Thursday, April 21, 2011 5:07 PM , Julie Moorejulie.renee.mo...@gmail.commailto:julie.renee.mo...@gmail.com wrote: Ed, Are you saying that you would call it a: 300 1 pre-recorded MP3 player ? Just curious! Thanks, Julie On Wed, Apr 20, 2011 at 3:13 PM, Ed Jones ejo...@nu.edumailto:ejo...@nu.edu wrote: FWIW, ONIX calls it a pre-recorded MP3 player, which also seems to be the name used in the marketplace, if a Google search I just did is any indication (1.5 million results as a quoted string). The new product form was added to ONIX in early 2007. The RDA ONIX framework predates this (unless there is a newer version than version 1.0). http://www.onixtools.de/downloads/ONIX_Code_Lists_Issue_7_Changes.pdf Ed Jones --
Re: [RDA-L] Cataloging playaways
Jonathan Rochkind rochk...@jhu.edu wrote: I thought that RDA as a code used neither GMD _nor_ SMD, replacing those with the data elements that end up in the new mac 3xx fields? Can anyone confirm that, that there is no notion of 'smd' in RDA? The 300 $a includes what could be called an SMD, but in RDA it (called a type of unit) and its number are referred to as Extent, e.g., 3 videodiscs. The fine print is given under RDA 3.1 and 3.4. The terms for the 300 $a are to be taken from the Carrier Type list under 3.3.1.3, much like some chapters of AACR2 have lists of terms to choose from. RDA also follows AACR2 in allowing for made-up terms to inhabit the 300 $a, such as those in common usage or trade names. Quoting from 3.4.1.5: Use a term in common usage (including a trade name, if applicable) to designate the type of unit: a.) if the carrier is in a newly developed format that is not yet covered in the list under 3.3.1.3; b.) if none of the terms listed under 3.3.1.3 is appropriate; or c.) as an alternative to a term listed under 3.3.1.3, if preferred by the agency preparing the description Other formats take a differ tack, such as text, which uses the pagination approach (RDA 3.4.5), and still images, which draw from a different vocabulary under 3.4.4 (and allow for terms to be made up if none on the list fit the thing being cataloged). These exceptions are found under 3.4.1.3. A registry sounds like a good idea. -- Mark K. Ehlert Minitex Coordinator University of Minnesota Bibliographic Technical 15 Andersen Library Services (BATS) Unit 222 21st Avenue South Phone: 612-624-0805 Minneapolis, MN 55455-0439 http://www.minitex.umn.edu/
Re: [RDA-L] Cataloging playaways
OK, you caught me on that one. You are correct-the term 'SMD' is not used in RDA-the term used at 3.4.1.3 (Recording Extent) is an appropriate term for the type of carrier as listed under 3.3.1.3 (Recording Carrier Type). That instruction then says to use one or more of the terms listed below, none of which even closely resemble the terms on the list I compiled from the previous messages on this topic. But then there is 3.4.1.5 (Other terms used to designate the type of unit) which says Use a term in common usage (including a trade name, if applicable) to designate the type of unit and, under that instruction, point c) even goes so far as to say we can do this as an alternative to a term listed under 3.3.1.3 if preferred by the agency preparing the description So, I apologise for using an AACR term in an RDA reference (I *will* get them straight someday), but my questions still hold-just replace anywhere I said SMD with 'term for type of carrier' or 'type of unit'. People *will* be entering free text as this RDA element, so I would like to know whether anyone has figured out some way that matching algorythms will be able to reliably match descriptions without the use of consistent terms in this element. If not, then maybe we should at least *try* to use consistent carrier/unit terms in the RDA MARC records that we are making at this time, to try to allow more reliable matching, at least until something else is in place that will allow us to get as wild and crazy as we please, without breaking machine matching any worse than it already is. Thanks, Deborah -- Deborah Fritz MARC Database Consultant The MARC of Quality www.marcofquality.com Voice/Fax: (321) 676-1904 -Original Message- From: Resource Description and Access / Resource Description and Access [mailto:RDA-L@LISTSERV.LAC-BAC.GC.CA] On Behalf Of Jonathan Rochkind Sent: Friday, April 22, 2011 3:06 PM To: RDA-L@LISTSERV.LAC-BAC.GC.CA Subject: Re: [RDA-L] Cataloging playaways I thought that RDA as a code used neither GMD _nor_ SMD, replacing those with the data elements that end up in the new mac 3xx fields? Can anyone confirm that, that there is no notion of 'smd' in RDA? If so, there would be no answer to having every SMD registered in the RDA registry, nor to way to indicate in RDA that the SMD should be ignored -- RDA already ignores the SMD. No? Matching algorithms in union catalogs may have to be updated to take account of RDA. Of course, if people are just entering free text in the new 3xx MARC fields for RDA, instead of using a controlled vocabulary, that could still be a problem for matching algorithms. Exact same sort of problem as if people were/are entering free text instead of controlled vocabulary in the GMD/SMD of course. From: Resource Description and Access / Resource Description and Access [RDA-L@LISTSERV.LAC-BAC.GC.CA] on behalf of Deborah Fritz [debo...@marcofquality.com] Sent: Friday, April 22, 2011 2:52 PM To: RDA-L@LISTSERV.LAC-BAC.GC.CA Subject: Re: [RDA-L] Cataloging playaways But what you do in the local catalog, does not actually stay in the local catalog, because records get batchloaded to WorldCat and other union catalogs (or catalogues) and, when that happens, what then will happen with the matching algorythms for deduping records if each record has a different SMD? 1 sound media player 1 pre-recorded MP3 player 1 pre-recorded digital audio player 1 Playaway 1 audio media player 1 digital media player 1) Is there an explicit code, currently in use in MARC--that we can use while we are creating RDA descriptions in a MARC environment, that will make it clear to a matching algorythm that this record is describing the same thing as that record, no matter what is in the 300$a? 2) And since this is the RDA-L not the MARC-L, is there a combination of RDA data elements that will reliably indicate that this description is describing the same thing as that description, no matter what is in the SMD, for whatever future matching we will need to do? 3) And/or is this another situation where The Registry could *really* help, so that every SMD is registered, before it is used in a description in a library environment, so that a matching algorythm can check the registry and match on 'variant' terms? And, if so, when will that become an integral part of our cataloging procedures? Deborah -- Deborah Fritz MARC Database Consultant The MARC of Quality www.marcofquality.comhttp://www.marcofquality.com/ Voice/Fax: (321) 676-1904 On Friday, April 22, 2011 10:58 AM , Ed Jones ejo...@nu.edumailto:ejo...@nu.edu wrote: Julie, If you insist on a straight answer. If my library promoted them as Playaways and users knew them as Playaways, I would probably argue for calling them Playaways in the physical description. (As they say, What you do in the local
Re: [RDA-L] Cataloging playaways
And herein lies my point ... I am seeking consistency! Julie On Fri, Apr 22, 2011 at 11:52 AM, Deborah Fritz debo...@marcofquality.comwrote: But what you do in the local catalog, does *not* actually stay in the local catalog, because records get batchloaded to WorldCat and other union catalogs (or catalogues) and, when that happens, what then will happen with the matching algorythms for deduping records if each record has a different SMD? 1 sound media player 1 pre-recorded MP3 player 1 pre-recorded digital audio player 1 Playaway 1 audio media player 1 digital media player 1) Is there an explicit code, currently in use in MARC--that we can use while we are creating RDA descriptions in a MARC environment, that will make it clear to a matching algorythm that this record is describing the same thing as that record, no matter what is in the 300$a? 2) And since this is the RDA-L not the MARC-L, is there a combination of RDA data elements that will reliably indicate that this description is describing the same thing as that description, no matter what is in the SMD, for whatever future matching we will need to do? 3) And/or is this another situation where The Registry could *really* help, so that every SMD is registered, before it is used in a description in a library environment, so that a matching algorythm can check the registry and match on 'variant' terms? And, if so, when will that become an integral part of our cataloging procedures? Deborah -- Deborah Fritz MARC Database Consultant The MARC of Quality www.marcofquality.com Voice/Fax: (321) 676-1904 On Friday, April 22, 2011 10:58 AM , Ed Jones ejo...@nu.edu wrote: Julie, If you insist on a straight answer… If my library promoted them as Playaways and users knew them as Playaways, I would probably argue for calling them Playaways in the physical description. (As they say, What you do in the local catalog stays in the local catalog.) In an ideal world, where records carried more information in coded form, I would have a coded value in the record rather than a literal (something analogous to ONIX’s “AK”) and would leave it up to the local library what literal they wanted to have display in their catalog. In a shared catalog like OCLC, I would probably follow standard practice to the extent it exists. In 2008 the Playaway Cataloging Joint Task Force—yes, there was such a thing—recommended “1 sound media player” so I would probably go with that. http://www.olacinc.org/drupal/capc_files/playawaysPDF.pdf Ed On Thursday, April 21, 2011 5:07 PM , Julie Moore julie.renee.mo...@gmail.com wrote: Ed, Are you saying that you would call it a: 300 1 pre-recorded MP3 player ? Just curious! Thanks, Julie On Wed, Apr 20, 2011 at 3:13 PM, Ed Jones ejo...@nu.edu wrote: FWIW, ONIX calls it a pre-recorded MP3 player, which also seems to be the name used in the marketplace, if a Google search I just did is any indication (1.5 million results as a quoted string). The new product form was added to ONIX in early 2007. The RDA ONIX framework predates this (unless there is a newer version than version 1.0). http://www.onixtools.de/downloads/ONIX_Code_Lists_Issue_7_Changes.pdf Ed Jones -- -- Julie Renee Moore Catalog Librarian California State University, Fresno julie.renee.mo...@gmail.com 559-278-5813 There is more to life than simply increasing its speed. ~ Mahatma Gandhi
Re: [RDA-L] Cataloging playaways
Amanda
Is the source of acquisition field really where you want to put this? Your
attachment puts it both in 037 $f and in 300 $a. I like the use of other audio
carrier faute de mieux, but ideally one would want something that captured the
idea of an integrated intermediation tool.
I think this all points out the need to have a rapid response mechanism in
RDA for dealing with new phenomena. Even an interim authoritative label would
make post-hoc cleanup easier when a more permanent label became available. This
seems to have happened in ONIX as pre-recorded MP3 player has given way to
pre-recorded audio player.
(I should mention in response to an earlier post that what I meant to say was
What I do in my local catalog stays in my local catalog.)
Ed
From: Resource Description and Access / Resource Description and Access
[mailto:RDA-L@LISTSERV.LAC-BAC.GC.CA] On Behalf Of Amanda Xu
Sent: Friday, April 22, 2011 12:44 PM
To: RDA-L@LISTSERV.LAC-BAC.GC.CA
Subject: Re: [RDA-L] Cataloging playaways
Julie and Ed:
Here is what I would do for cross-mapping between ONIX 2.1 MARC 21
considering the fact that 1) what is the easiest way to conversion; 2) much of
our data are still in AACR2:
ONIX Tag
b012
b333
b210
ONIX Reference Name
ProductFormAK/ProductForm
ProductFormDetailpre-recorded MP3 player/ProductFormDetail
NumberOfPieces1/NumberOfPieces
MARC 21 Data Element
037 $f {1 pre-recorded MP3 player}
For specific mapping that incorporates RDA elements for audio file, and
downloadable version for podcasts online, please check attachment. The
assumption is based on the piece to be cataloged is an spoken audiobook in .mp3
format.
For additional references, please check:
1. Library of Congress. Network Development and MARC Standards Office. ONIX
to MARC 21 Mapping. Retrieved 4/22/2011 from
http://www.loc.gov/marc/onix2marc.htmhttp://www.loc.gov/marc/onix2marc.html
2. OCLC ONIX-MARC Mapping, ONIX for Books, Release 2.1. Retrieved
4/22/2011 from http://www.editeur.org/96/ONIX-and-MARC21/
Cheers,
Amanda Xu
On Thu, Apr 21, 2011 at 7:07 PM, Julie Moore
julie.renee.mo...@gmail.commailto:julie.renee.mo...@gmail.com wrote:
Ed,
Are you saying that you would call it a:
300 1 pre-recorded MP3 player ?
Just curious!
Thanks,
Julie
On Wed, Apr 20, 2011 at 3:13 PM, Ed Jones ejo...@nu.edumailto:ejo...@nu.edu
wrote:
FWIW, ONIX calls it a pre-recorded MP3 player, which also seems to be the
name used in the marketplace, if a Google search I just did is any indication
(1.5 million results as a quoted string). The new product form was added to
ONIX in early 2007. The RDA ONIX framework predates this (unless there is a
newer version than version 1.0).
http://www.onixtools.de/downloads/ONIX_Code_Lists_Issue_7_Changes.pdf
Ed Jones
--
Julie Renee Moore
Catalog Librarian
California State University, Fresno
julie.renee.mo...@gmail.commailto:julie.renee.mo...@gmail.com
559-278-5813tel:559-278-5813
There is more to life than simply increasing its speed. ~ Mahatma Gandhi
Re: [RDA-L] Cataloging playaways
Ed:
Thank you so much for your quick response. 037$f and 300$a are used for
different purpose. One is to record the term used by source of acquisition,
and the other is to record the term used by cataloger.
Without revealing the format of the audio files (at least MIME Type ready),
it's hard for to users to launch the appropriate player, e.g. Real player,
iTune, Media Player, etc.
According to OCLC's mapping table for ONIX 2.1, the Code 'AK' is for
'pre-recorded MP3 player.' That is the code that you are using as well when
you replied to Julie's message. Therefore, I can't comment on ONIX's change
of “pre-recorded audio player.” Thanks a million for the discussion!
Sincerely yours,
Amanda
On Fri, Apr 22, 2011 at 3:34 PM, Ed Jones ejo...@nu.edu wrote:
Amanda
Is the “source of acquisition” field really where you want to put this?
Your attachment puts it both in 037 $f and in 300 $a. I like the use of
“other audio carrier” faute de mieux, but ideally one would want something
that captured the idea of an integrated intermediation tool.
I think this all points out the need to have a “rapid response” mechanism
in RDA for dealing with new phenomena. Even an interim “authoritative” label
would make post-hoc cleanup easier when a more permanent label became
available. This seems to have happened in ONIX as “pre-recorded MP3 player”
has given way to “pre-recorded audio player”.
(I should mention in response to an earlier post that what I meant to say
was “What I do in my local catalog stays in my local catalog”.)
Ed
*From:* Resource Description and Access / Resource Description and Access
[mailto:RDA-L@LISTSERV.LAC-BAC.GC.CA] *On Behalf Of *Amanda Xu
*Sent:* Friday, April 22, 2011 12:44 PM
*To:* RDA-L@LISTSERV.LAC-BAC.GC.CA
*Subject:* Re: [RDA-L] Cataloging playaways
Julie and Ed:
Here is what I would do for cross-mapping between ONIX 2.1 MARC 21
considering the fact that 1) what is the easiest way to conversion; 2) much
of our data are still in AACR2:
*ONIX Tag*
*b012*
*b333*
*b210*
*ONIX Reference Name*
ProductFormAK/ProductForm
ProductFormDetailpre-recorded MP3 player/ProductFormDetail
NumberOfPieces1/NumberOfPieces
*MARC 21 Data Element*
037 $f {1 pre-recorded MP3 player}
For specific mapping that incorporates RDA elements for audio file, and
downloadable version for podcasts online, please check attachment. The
assumption is based on the piece to be cataloged is an spoken audiobook in
.mp3 format.
For additional references, please check:
1. Library of Congress. Network Development and MARC Standards
Office. ONIX to MARC 21 Mapping. Retrieved 4/22/2011 from
http://www.loc.gov/marc/onix2marc.htmhttp://www.loc.gov/marc/onix2marc.html
2. OCLC ONIX-MARC Mapping, ONIX for Books, Release 2.1. Retrieved
4/22/2011 from http://www.editeur.org/96/ONIX-and-MARC21/
Cheers,
Amanda Xu
On Thu, Apr 21, 2011 at 7:07 PM, Julie Moore julie.renee.mo...@gmail.com
wrote:
Ed,
Are you saying that you would call it a:
300 1 pre-recorded MP3 player ?
Just curious!
Thanks,
Julie
On Wed, Apr 20, 2011 at 3:13 PM, Ed Jones ejo...@nu.edu wrote:
FWIW, ONIX calls it a pre-recorded MP3 player, which also seems to be the
name used in the marketplace, if a Google search I just did is any
indication (1.5 million results as a quoted string). The new product form
was added to ONIX in early 2007. The RDA ONIX framework predates this
(unless there is a newer version than version 1.0).
http://www.onixtools.de/downloads/ONIX_Code_Lists_Issue_7_Changes.pdf
Ed Jones
--
Julie Renee Moore
Catalog Librarian
California State University, Fresno
julie.renee.mo...@gmail.com
559-278-5813
There is more to life than simply increasing its speed. ~ Mahatma Gandhi
