[RDA-L] Reprint cataloging
Hi all, Does anyone feel they understand the linking field structure for a reprint well enough to review one I have? I'm not sure I'm phrasing the note in the 775 correctly and would like another opinion. It's no. 73 in the Save file. Pat Patricia Sayre McCoy 1121 E. 60th Street Head, Law Cataloging Serials Chicago, IL 60637 D'Angelo Law Library 773-702-9620 University of Chicago p...@uchicago.edu
Re: [RDA-L] rdacontent terms - dataset
Brunelle Longo wrote:
Is there any rationale for having two RDA content terms
(cartographic dataset and computer dataset) instead of just the
simple DC 'dataset'?
There may be rationale, but no rationality. These content terms are
used with another core element, carrier, and optionally media type,
Given ISBD's Areao 0 electronic, and carrier computer disk or online
resource, the longer phrase is clearly redundant, as are other longer
phrases.
In addition to which, those longer phrases do not lend them selves to
compact display. SLC itends to shorten them for display.
__ __ J. McRee (Mac) Elrod (m...@slc.bc.ca)
{__ | / Special Libraries Cataloguing HTTP://www.slc.bc.ca/
___} |__ \__
Re: [RDA-L] RDA and MARC (was Linked data)
I have heard from a couple people who were unable to open the slides. This seems to be because Firefox is sometimes not associating .ppx files with PowerPoint. There are a couple ways to get around this (navigate to open with PowerPoint or save the file, open that folder and open with PowerPoint), but to make things easier for anyone having trouble, I have put the presentation up as a PDF at http://pages.uoregon.edu/kelleym/KM_MWpresentation.pdf Kelley -Original Message- From: Resource Description and Access / Resource Description and Access [mailto:RDA-L@LISTSERV.LAC-BAC.GC.CA] On Behalf Of Kelley McGrath Sent: Thursday, February 10, 2011 4:21 PM To: RDA-L@LISTSERV.LAC-BAC.GC.CA Subject: [RDA-L] RDA and MARC (was Linked data) There was a discussion a while ago now about the problems (or not) with MARC. I gave a presentation at ALA Midwinter called Will RDA Kill MARC? I was sort of waiting for the official version to be posted, but, although the person organizing the presentation has tried to post it on the ALA/ALCTS site, apparently the site down a lot. So in order to belatedly get my two cents in, I've put the presentation up at http://pages.uoregon.edu/kelleym/KM_MWpresentation.pptx for anyone who might be interested. I guess my point is that we could make MARC do at least most of the things we need it to do to support RDA, but that's probably not the best use of our limited resources. Interestingly, one of the audience members asked rather if MARC will kill RDA... Kelley
Re: [RDA-L] Reprint cataloging
Hi Pat, Please copy and paste the 773 (and the 580 if the 1st indicator on the 773 is 1). I worked on a two-year project cataloging reprints and analytics; and, 15 years later, they are still part of my workflow. R. -- Robert C.W. Hall, Jr. Technical Services Associate Librarian Concord Free Public Library, Concord, MA 01742 978-318-3343 -- FAX: 978-318-3344 -- http://www.concordlibrary.org/ bh...@minlib.net -- -Original Message- From: Pat Sayre McCoy p...@uchicago.edu To: RDA-L@LISTSERV.LAC-BAC.GC.CA Date: Mon, 14 Feb 2011 10:18:45 -0600 Subject: [RDA-L] Reprint cataloging Hi all, Does anyone feel they understand the linking field structure for a reprint well enough to review one I have? I'm not sure I'm phrasing the note in the 775 correctly and would like another opinion. It's no. 73 in the Save file. Pat Patricia Sayre McCoy 1121 E. 60th Street Head, Law Cataloging Serials Chicago, IL 60637 D'Angelo Law Library773-702-9620 University of Chicago p...@uchicago.edu
Re: [RDA-L] Reprint cataloging
I accidently sent this to the wrong list, but thanks for such a quick response! Thanks. Pat Patricia Sayre McCoy 1121 E. 60th Street Head, Law Cataloging Serials Chicago, IL 60637 D'Angelo Law Library773-702-9620 University of Chicago p...@uchicago.edumailto:p...@uchicago.edu From: Resource Description and Access / Resource Description and Access [mailto:RDA-L@LISTSERV.LAC-BAC.GC.CA] On Behalf Of Bob Hall Sent: Monday, February 14, 2011 10:34 AM To: RDA-L@LISTSERV.LAC-BAC.GC.CA Subject: Re: [RDA-L] Reprint cataloging Hi Pat, Please copy and paste the 773 (and the 580 if the 1st indicator on the 773 is 1). I worked on a two-year project cataloging reprints and analytics; and, 15 years later, they are still part of my workflow. R. -- Robert C.W. Hall, Jr. Technical Services Associate Librarian Concord Free Public Library, Concord, MA 01742 978-318-3343 -- FAX: 978-318-3344 -- http://www.concordlibrary.org/ bh...@minlib.net -- -Original Message- From: Pat Sayre McCoy p...@uchicago.edu To: RDA-L@LISTSERV.LAC-BAC.GC.CA Date: Mon, 14 Feb 2011 10:18:45 -0600 Subject: [RDA-L] Reprint cataloging Hi all, Does anyone feel they understand the linking field structure for a reprint well enough to review one I have? I'm not sure I'm phrasing the note in the 775 correctly and would like another opinion. It's no. 73 in the Save file. Pat Patricia Sayre McCoy 1121 E. 60th Street Head, Law Cataloging Serials Chicago, IL 60637 D'Angelo Law Library773-702-9620 University of Chicago p...@uchicago.edu
Re: [RDA-L] RDA and MARC (was Linked data)
James Weinheimer wrote... But I wonder if what you point out is a genuine problem, especially in an RDA/FRBR universe. The user tasks are to find, identify, yadda -- works, expressions, manifestations, and *items*. Not sub-items. This record seems to allow everything that FRBR requires, plus it allows even more because if I am looking for Boykan's First string quartet, there is a beautiful controlled analytic. This level of analysis is rarely followed in regular cataloging of other materials. So, as far as finding goes, there is absolutely no problem. It is just that in order to *see* the metadata associated with this particular piece (remember, I can still *find* it!), I have to look at the description for the entire item. Nevertheless, it can be found--and in a controlled way as well since the cataloger did a good job--and this information is available for the later user tasks of identifying, selecting and obtaining. This seems to fall squarely within the FRBR requirements... None of this would allow for more *access* than what we have right now however, since people would still be able to find exactly what they can today -- Jim, I do actually think this is a problem and that by structuring the data differently we could provide more access. As others have pointed out, what people often want when they're looking for music is not items, but the works and expressions on those items. The tragedy of this record (and so many others) is that the cataloger took the time to figure out and record various pieces of information about the work and expression, but they are now useless for anything except recognition by a human already looking at the record unless all that work is redone. There are so many other questions that we could answer if we had structured the data differently. What are all the works by Boykin with certain instrumentation? With certain performers? Conducted by a certain conductor? You could answer other kinds of questions, too, if we had structured the data so that it created a computer-interpretable web. Find all the works created for a certain instrumentation created during a certain time period. Find all the violin sonatas by a certain performer. Now if you try these searches you get many false drops and suffer from missing or inconsistently-constructed data. (Forgive me if the examples make no sense as I am not a music person; I hope the sense of possibilities comes through). To see a system that is beginning to move in this direction for music, check out what the Variations 3 project at Indiana University is doing: http://webapp1.dlib.indiana.edu/scherzo/. Kelley
Re: [RDA-L] RDA and MARC
Kelly McGrath posted:
http://pages.uoregon.edu/kelleym/KM_MWpresentation.pdf
The author says, among other things, that MARC field 245 is maxed out
for subfields. With number subfields, 26 more can be added. How many
does he want?
Subfields need not be in numerical or alphabetic order, e.g., 245$h,
and 111 subfields since the changes in entry form for conferences.
He also objects to the number codes, and would prefer labels in
English. In our multilingual situation, the language neutrality of
numbers is one of MARC's advantages.
Certainly one has to agree with the author that coding RDA in MARC is
craming a square peg in a round hole, withness two elemements in
260$c. Certainly MARC can not utilise the FRBR WEMI distinctions.
But am I sure I want to?
At least RDA should be delayed until there is a coding system which
can handle it.
I do have difficulties with MARC: the redundancy in fixed field
coding, the inconsistency of fixed field meanings between formats, the
mess which is 5XX number order, the placement of 336-338 which should
be in advance of other data in accord with ISBD Area 0, but I don't
see the difficulties seen by this and others writing abut MARC.
__ __ J. McRee (Mac) Elrod (m...@slc.bc.ca)
{__ | / Special Libraries Cataloguing HTTP://www.slc.bc.ca/
___} |__ \__
Re: [RDA-L] RDA and MARC
Quoting J. McRee Elrod m...@slc.bc.ca:
Kelly McGrath posted:
http://pages.uoregon.edu/kelleym/KM_MWpresentation.pdf
The author says, among other things, that MARC field 245 is maxed out
for subfields. With number subfields, 26 more can be added. How many
does he want?
I'm not sure how you calculate this. There are only 9 single-digit
numbers (0-8, since 9 is for local use only), and most of them have
already been used: 0, 2, 3, 4, 5, 6, 7, 8. A decision was made early
on that the number subfields, to the extent possible, would retain the
same meaning in each field in which they were used.
Perhaps you were thinking about using upper case letters, which would
indeed give us 26 more options. That has been suggested many times at
MARBI and never accepted even for discussion.
The MARC record structure would allow the use of more than one
character for the subfield code, e.g. aa instead of just a. (Up to
9, BTW, since it's a one byte numeric field). That would give us scads
more possibilities, but would require a lot of coding changes for
software that processes MARC records. The number of characters in the
subfield code is encoded in the leader, so we could actually mix
1-char and 2-char records in a single dataset, but most code that
reads and writes MARC doesn't use that Leader byte to control the
number of characters -- we tend to assume 1.
There are possibilities, but I don't think any of them could be
considered cheap. At the same time, maybe it would be worth thinking
some of them through before rejecting the ideas outright.
kc
Subfields need not be in numerical or alphabetic order, e.g., 245$h,
and 111 subfields since the changes in entry form for conferences.
He also objects to the number codes, and would prefer labels in
English. In our multilingual situation, the language neutrality of
numbers is one of MARC's advantages.
Certainly one has to agree with the author that coding RDA in MARC is
craming a square peg in a round hole, withness two elemements in
260$c. Certainly MARC can not utilise the FRBR WEMI distinctions.
But am I sure I want to?
At least RDA should be delayed until there is a coding system which
can handle it.
I do have difficulties with MARC: the redundancy in fixed field
coding, the inconsistency of fixed field meanings between formats, the
mess which is 5XX number order, the placement of 336-338 which should
be in advance of other data in accord with ISBD Area 0, but I don't
see the difficulties seen by this and others writing abut MARC.
__ __ 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] rdacontent terms - dataset
I'm hoping that someone from the JSC can explain better, but it looks to me that a cartographic dataset has come particular characteristics. Section 3.19.7.3 of RDA says: 3.19.7.3 R ecording Digital Representation of Cartographic Data For digitally encoded cartographic data, record the following information if it can be readily ascertained and is considered important for identification or selection: ? data type (i.e., raster, vector, or point) ? object type (i.e., point, line, polygon, or pixel) ? number of objects used to represent spatial information. The definition in chapter 6 of RDA for computer dataset says: Content expressed through a digitally encoded dataset intended to be processed by a computer. Includes numeric data, environmental data, etc., used by applications software to calculate averages, correlations, etc., or to produce models, etc., but not normally displayed in its raw form. For data intended to be perceived visually in the form of notation, image, or three-dimensional form, see notated movement, notated music, still image, text, three-dimensional form, three-dimensional moving image and two-dimensional moving image. For data intended to be perceived in an audible form, see performed music, sounds, and spoken word. For cartographic data see cartographic dataset. --- I can't explain WHY this is the case, but at least there is evidence in RDA that the two were thought of differently. As for the possible use of dc:dataset, one thing to remember is that every RDA property is associated with a single FRBR entity. (Which is why there are things like Extent(Manifesation) and Extend(Item). None of the DC terms are bound to a FRBR entity, so they would be more general than an RDA property of similar semantics. kc Quoting Brunella Longo brunella.lo...@yahoo.com: Is there any rationale for having two RDA content terms (cartographic dataset and computer dataset) instead of just the simple DC 'dataset'? See - http://www.loc.gov/standards/valuelist/rdacontent.html - http://metadataregistry.org/search?term=dataset? - http://dublincore.org/usage/terms/history/#Dataset-003 - http://openuplabs.tso.co.uk/datasets Brunella Longo 7 New College Court London NW3 5EX T +44 (0)20 72095014 (home) - +44 (0) 75 49921488 (mobile) http://www.brunellalongo.info (http://www.brunellalongo.it) [with apologies for cross posting] -- Karen Coyle kco...@kcoyle.net http://kcoyle.net ph: 1-510-540-7596 m: 1-510-435-8234 skype: kcoylenet
Re: [RDA-L] RDA and MARC
Hi, On Mon, Feb 14, 2011 at 1:39 PM, Karen Coyle li...@kcoyle.net wrote: The MARC record structure would allow the use of more than one character for the subfield code, e.g. aa instead of just a. (Up to 9, BTW, since it's a one byte numeric field). That would give us scads more possibilities, but would require a lot of coding changes for software that processes MARC records. The number of characters in the subfield code is encoded in the leader, so we could actually mix 1-char and 2-char records in a single dataset, but most code that reads and writes MARC doesn't use that Leader byte to control the number of characters -- we tend to assume 1. Indeed, actually requiring that MARC parsers respect the Leader/11 would break many of them, and I suspect a fair amount of ILSs have the assumption that a subfield code is one octet wide baked in higher up the application stack. At least as far as most software is concerned, permitting upper case subfield codes would be easier to handle. Out of curiosity, does anybody know if there are (or were) any ISO2709-based formats that ever set the subfield label length to any value other than 2 or set the Leader/10, Leader/20, Leader/21, and Leader/22 to values other than '2', '4', '5', or '0', respectively? Regards, Galen -- Galen Charlton gmcha...@gmail.com
Re: [RDA-L] RDA and MARC
At 12:39 PM 2/14/2011, Karen Coyle wrote: There are possibilities, but I don't think any of them could be considered cheap. At the same time, maybe it would be worth thinking some of them through before rejecting the ideas outright. (Brand-new subscriber jumps in with both feet, eyes closed.) There are a number of things in the ISO standard that aren't implemented in MARC21; the possibility of field length over 10,000 bytes is another that comes to mind. All of these would, as Karen indicates, entail significant expense to implement. Since reources aren't infinite, it would be better to develop a coding scheme that does what we need to do now and in the forseeable future, than to spend time putting more patches on MARC21. Gary L. Strawn, Authorities Librarian, etc. Northwestern University Library, 1970 Campus Drive, Evanston IL 60208-2300 e-mail: mrsm...@northwestern.edu voice: 847/491-2788--now even newer! fax: 847/491-8306 Forsan et haec olim meminisse iuvabit. BatchCat version: 2007.22.416
Re: [RDA-L] RDA and MARC
Karen Coyle correctly said:
I'm not sure how you calculate this. There are only 9 single-digit
numbers (0-8, since 9 is for local use only),
Thanks for catching that slip up. I was of course thinking of Hal
Cain's oft repeated suggestion for upper case codes. Would they
require additional programming?
Double letter would indeed be expensive, and nigh impossible. How
would a cataloguing module know whether the second letter is a code or
the first letter of the word followwing? You can't go by caps; some
terms now begin with lower case latters.
__ __ J. McRee (Mac) Elrod (m...@slc.bc.ca)
{__ | / Special Libraries Cataloguing HTTP://www.slc.bc.ca/
___} |__ \__
Re: [RDA-L] RDA and MARC
Ms. McGrath, author of the presentation, readily identifies as red herrings the issues on which Mac focuses his rebuttal. There are more substantial issues presented by the author, namely the structural difficulties of MARC both with respect to encoding reliably machine-actionable data and to addressing adequately the relationships that are the underpinning of Entity-Relationship data structures. As to the delay of RDA implementation, the author closes with the observation that banking was in a similar bind of relying on 1960s era coding as the foundation of its software until forced to change by the prospect of Y2K. RDA would be our equivalent to force us to recast our coding for upgrading to 21st century systems and needs. John F. Myers, Catalog Librarian Schaffer Library, Union College 807 Union St. Schenectady NY 12308 518-388-6623 mye...@union.edu -Original Message- J. McRee Elrod wrote: The author says, among other things, that MARC field 245 is maxed out for subfields. With number subfields, 26 more can be added. How many does he want? Subfields need not be in numerical or alphabetic order, e.g., 245$h, and 111 subfields since the changes in entry form for conferences. He also objects to the number codes, and would prefer labels in English. In our multilingual situation, the language neutrality of numbers is one of MARC's advantages. [snip] At least RDA should be delayed until there is a coding system which can handle it.
[RDA-L] Fwd: [RDA-L] rdacontent terms - dataset
-- Forwarded message -- From: Gene Fieg gf...@cst.edu Date: Mon, Feb 14, 2011 at 12:06 PM Subject: Re: [RDA-L] rdacontent terms - dataset To: kco...@kcoyle.net Just a thought: can we get back to speaking/writing in clear English. Without that type of English for RDA, it appears that we will have to have a high priesthood of translators. On Mon, Feb 14, 2011 at 10:59 AM, Karen Coyle li...@kcoyle.net wrote: I'm hoping that someone from the JSC can explain better, but it looks to me that a cartographic dataset has come particular characteristics. Section 3.19.7.3 of RDA says: 3.19.7.3 R ecording Digital Representation of Cartographic Data For digitally encoded cartographic data, record the following information if it can be readily ascertained and is considered important for identification or selection: ? data type (i.e., raster, vector, or point) ? object type (i.e., point, line, polygon, or pixel) ? number of objects used to represent spatial information. The definition in chapter 6 of RDA for computer dataset says: Content expressed through a digitally encoded dataset intended to be processed by a computer. Includes numeric data, environmental data, etc., used by applications software to calculate averages, correlations, etc., or to produce models, etc., but not normally displayed in its raw form. For data intended to be perceived visually in the form of notation, image, or three-dimensional form, see notated movement, notated music, still image, text, three-dimensional form, three-dimensional moving image and two-dimensional moving image. For data intended to be perceived in an audible form, see performed music, sounds, and spoken word. For cartographic data see cartographic dataset. --- I can't explain WHY this is the case, but at least there is evidence in RDA that the two were thought of differently. As for the possible use of dc:dataset, one thing to remember is that every RDA property is associated with a single FRBR entity. (Which is why there are things like Extent(Manifesation) and Extend(Item). None of the DC terms are bound to a FRBR entity, so they would be more general than an RDA property of similar semantics. kc Quoting Brunella Longo brunella.lo...@yahoo.com: Is there any rationale for having two RDA content terms (cartographic dataset and computer dataset) instead of just the simple DC 'dataset'? See - http://www.loc.gov/standards/valuelist/rdacontent.html - http://metadataregistry.org/search?term=dataset? - http://dublincore.org/usage/terms/history/#Dataset-003 - http://openuplabs.tso.co.uk/datasets Brunella Longo 7 New College Court London NW3 5EX T +44 (0)20 72095014 (home) - +44 (0) 75 49921488 (mobile) http://www.brunellalongo.info (http://www.brunellalongo.it) [with apologies for cross posting] -- Karen Coyle kco...@kcoyle.net http://kcoyle.net ph: 1-510-540-7596 m: 1-510-435-8234 skype: kcoylenet -- Gene Fieg Cataloger/Serials Librarian Claremont School of Theology gf...@cst.edu -- Gene Fieg Cataloger/Serials Librarian Claremont School of Theology gf...@cst.edu
Re: [RDA-L] RDA and MARC
Karen Coyle wrote: snip I'm not sure how you calculate this. There are only 9 single-digit numbers (0-8, since 9 is for local use only), and most of them have already been used: 0, 2, 3, 4, 5, 6, 7, 8. A decision was made early on that the number subfields, to the extent possible, would retain the same meaning in each field in which they were used. Perhaps you were thinking about using upper case letters, which would indeed give us 26 more options. That has been suggested many times at MARBI and never accepted even for discussion. The MARC record structure would allow the use of more than one character for the subfield code, e.g. aa instead of just a. (Up to 9, BTW, since it's a one byte numeric field). That would give us scads more possibilities, but would require a lot of coding changes for software that processes MARC records. The number of characters in the subfield code is encoded in the leader, so we could actually mix 1-char and 2-char records in a single dataset, but most code that reads and writes MARC doesn't use that Leader byte to control the number of characters -- we tend to assume 1. /snip Of course, this all assumes continuing the completely 100% obsolete ISO2709 format from the 1960s. For example, is the Unicode set valid for subfield codes? If not, why? Why can't we have a subfield lambda or rho? Why not a Chinese character or Church Slavic? If these were allowed, then we would have 1,114,112 possibilities, according to the high authority of Wikipedia http://en.wikipedia.org/wiki/Mapping_of_Unicode_characters. That should be enough. The answer is, such a suggestion is ridiculous since not everybody understand Chinese or Church Slavic. I agree, so the obvious question is: why do we have to be stuck with ISO2709 and single subfield codes? The instant we switch to an XML structure, even MARCXML, we can begin to add subfield codes that are 2, 3, 4, 5 or as many characters as we would like. It's time to get rid of the leader, the directory and the entire structure of the ISO2709 record. It served its time but has long been detrimental to the further development and sharing of library metadata. I still don't understand. Here we are discussing changing cataloging rules (well, not so much the procedures, but the numbering and structure of the rules) spending money so that every cataloger will have to be retrained and catalogs will have to be retooled; yet this lousy ISO2709 format seems to be sacrosanct. Why? It absolutely must be dumped overboard, and the sooner the better. James L. Weinheimer j.weinhei...@aur.edu Director of Library and Information Services The American University of Rome Rome, Italy First Thus: http://catalogingmatters.blogspot.com/
Re: [RDA-L] rdacontent terms - dataset
Check out this document which contains a recent mapping of the new ISBD Area 0 terms to the RDA terms for content and media types (ISBD does not have values for carrier types). The RDA/ONIX Framework (ROF) is the larger framework from which RDA got its content, media, and carrier types: http://www.ifla.org/files/cataloguing/isbdrg/area-0-analysis.pdf Equivalence in ISBD and RDA is determined by how they map to categories of something called a base content category in the bigger RDA/ONIX Framework. The base content category is derived from a unique combination of values for character, sensory mode, image dimensionality, and image movement. After the base content category is matched up, then one can look at the additional qualifiers. In the RDA/ONIX Framework, cartographic and computer are actually form/genre qualifiers that are not part of the base content category, but are allowed attributes as form/genre (an open value set) in the RDA/ONIX Framework (see Recommendation #3 at http://www.loc.gov/marc/marbi/2007/5chair10.pdf). --- Comparing ISBD and RDA: ISBD: dataset (cartographic) RDA: cartographic dataset ISBD: dataset RDA: computer dataset --- Interestingly, in full 1:1 mapping of RDA to ISBD, sometimes RDA is shorter than ISBD: Example: ISBD: image (cartographic ; still ; 2-dimensional ; tactile) RDA: cartographic tactile image Considering ISBD's image (cartographic ; still ; 2-dimensional ; tactile), the attributes that are captured are these (in an order which is similar to the RDA/ONIX Framework's): form, type (for the form/genre cartographic), motion, dimensionality, sensory specification. --- For those interested in coming up with shorter labels for Content Type the key then is to map a Content Type term to combinations of the more basic RDA/ONIX Framework categories: From http://www.dlib.org/dlib/january07/dunsire/01dunsire.html: Basic higher-level content and carrier categories are constructed by taking a single primary value from one or more attributes of the content and carrier attribute sets respectively. ... For example, the basic content category defined by Character=image + SensoryMode=sight + ImageDimensionality=two-dimensional + ImageMovement=moving is equivalent to code 06 of ONIX list 81, which has the descriptive label moving images. The basic carrier category defined by StorageMediumFormat=file server + HousingFormat=not applicable + IntermediationTool=computer is equivalent to code DH of ONIX list 7, with the descriptive label online resource. The framework allows for communities to devise their own labels. But in devising new labels, one has to map them correctly to the specific combination of values in the RDA/ONIX Framework. --- As an interesting example of a different label, the equivalent to RDA's spoken word in ONIX is performance - spoken word (List 81, Code 02). http://www.editeur.org/files/ONIX%20for%20books%20-%20code%20lists/ONIX_BookProduct_CodeLists_Issue_12.html ONIX has the content type Data (List 81, Code 09). Interestingly, a new content type appears in ONIX List 81, Code 12-- Maps and/or other cartographic content, which would be allowed under the RDA/ONIX Framework form/genre attribute for Content Type. So RDA's cartographic dataset and ISBD's dataset (cartographic) might not then map to a single ONIX term, but to two separate ones. Dataset (or Data or Program) seems to be a Content Type that falls outside the scope of the regular Contents Types based on human perception. The FRBR expression in this case is digital content processed (perceived?) by a computer. --- Other links: ISBD Area 0 at http://www.ifla.org/files/cataloguing/isbd/area-0_2009.pdf RDA/ONIX Framework - http://www.loc.gov/marc/marbi/2007/5chair10.pdf Thomas Brenndorfer Guelph Public Library -Original Message- From: Resource Description and Access / Resource Description and Access [mailto:RDA-L@LISTSERV.LAC-BAC.GC.CA] On Behalf Of Karen Coyle Sent: February 14, 2011 1:59 PM To: RDA-L@LISTSERV.LAC-BAC.GC.CA Subject: Re: [RDA-L] rdacontent terms - dataset I'm hoping that someone from the JSC can explain better, but it looks to me that a cartographic dataset has come particular characteristics. Section 3.19.7.3 of RDA says: 3.19.7.3 R ecording Digital Representation of Cartographic Data For digitally encoded cartographic data, record the following information if it can be readily ascertained and is considered important for identification or selection: ? data type (i.e., raster, vector, or point) ? object type (i.e., point, line, polygon, or pixel) ? number of objects used to represent spatial information. The definition in chapter 6 of RDA for computer dataset says: Content expressed through a digitally encoded dataset intended to be processed by a computer.
Re: [RDA-L] RDA and MARC
John Myers said:
RDA would be our equivalent to force us to recast our
coding for upgrading to 21st century systems and needs.
But shouldn't that coding horse preceed that rule cart? Why adopt
rules we can't code?
__ __ J. McRee (Mac) Elrod (m...@slc.bc.ca)
{__ | / Special Libraries Cataloguing HTTP://www.slc.bc.ca/
___} |__ \__
Re: [RDA-L] RDA and MARC
Mac Elrod wrote: John Myers said: RDA would be our equivalent to force us to recast our coding for upgrading to 21st century systems and needs. But shouldn't that coding horse preceed that rule cart? Why adopt rules we can't code? My guess is that since we need *both* the new horse *and* the new cart, we have to start with at least one of them. If we design the cart, then we'll know more what kind of horse we'll need to breed... (In other words, if we don't know exactly the kind of data we're going to collect, and how we want to use the data, then we won't know exactly how to encode the data.) Kevin M. Randall Principal Serials Cataloger Bibliographic Services Dept. Northwestern University Library 1970 Campus Drive Evanston, IL 60208-2300 email: k...@northwestern.edu phone: (847) 491-2939 fax: (847) 491-4345
Re: [RDA-L] RDA and MARC
-Original Message- From: Resource Description and Access / Resource Description and Access [mailto:RDA-L@LISTSERV.LAC-BAC.GC.CA] On Behalf Of Kevin M. Randall Sent: February 14, 2011 6:14 PM To: RDA-L@LISTSERV.LAC-BAC.GC.CA Subject: Re: [RDA-L] RDA and MARC Mac Elrod wrote: John Myers said: RDA would be our equivalent to force us to recast our coding for upgrading to 21st century systems and needs. But shouldn't that coding horse preceed that rule cart? Why adopt rules we can't code? My guess is that since we need *both* the new horse *and* the new cart, we have to start with at least one of them. If we design the cart, then we'll know more what kind of horse we'll need to breed... (In other words, if we don't know exactly the kind of data we're going to collect, and how we want to use the data, then we won't know exactly how to encode the data.) This might be of help: http://www.rda-jsc.org/docs/5editor3.pdf (although it's now dated, since the registration of the RDA element set discussed has now happened). In the interim, MARC21, MODS, and Dublin Core/XML can be used as proxies for RDA. With the element set now defined, the horse is definitely in front of the cart. The cart (MARC) is serviceable, but one would expect a trade-in at some point in the future. Thomas Brenndorfer Guelph Public Library
Re: [RDA-L] RDA and MARC
I like the idea of subfields with multiple letters. Perhaps we could name them after important or well known catalogers? For example subfield $jim subfield $mac subfield $karen We could have a commission to determine the names, perhaps something along the methods used for naming hurricanes and other tropical storms? ;-) Sorry, couldn't resist some Monday afternoon rainy day humor. ^^ Adam L. Schiff Principal Cataloger University of Washington Libraries Box 352900 Seattle, WA 98195-2900 (206) 543-8409 (206) 685-8782 fax asch...@u.washington.edu http://faculty.washington.edu/~aschiff ~~ On Mon, 14 Feb 2011, Weinheimer Jim wrote: Karen Coyle wrote: snip I'm not sure how you calculate this. There are only 9 single-digit numbers (0-8, since 9 is for local use only), and most of them have already been used: 0, 2, 3, 4, 5, 6, 7, 8. A decision was made early on that the number subfields, to the extent possible, would retain the same meaning in each field in which they were used. Perhaps you were thinking about using upper case letters, which would indeed give us 26 more options. That has been suggested many times at MARBI and never accepted even for discussion. The MARC record structure would allow the use of more than one character for the subfield code, e.g. aa instead of just a. (Up to 9, BTW, since it's a one byte numeric field). That would give us scads more possibilities, but would require a lot of coding changes for software that processes MARC records. The number of characters in the subfield code is encoded in the leader, so we could actually mix 1-char and 2-char records in a single dataset, but most code that reads and writes MARC doesn't use that Leader byte to control the number of characters -- we tend to assume 1. /snip Of course, this all assumes continuing the completely 100% obsolete ISO2709 format from the 1960s. For example, is the Unicode set valid for subfield codes? If not, why? Why can't we have a subfield lambda or rho? Why not a Chinese character or Church Slavic? If these were allowed, then we would have 1,114,112 possibilities, according to the high authority of Wikipedia http://en.wikipedia.org/wiki/Mapping_of_Unicode_characters. That should be enough. The answer is, such a suggestion is ridiculous since not everybody understand Chinese or Church Slavic. I agree, so the obvious question is: why do we have to be stuck with ISO2709 and single subfield codes? The instant we switch to an XML structure, even MARCXML, we can begin to add subfield codes that are 2, 3, 4, 5 or as many characters as we would like. It's time to get rid of the leader, the directory and the entire structure of the ISO2709 record. It served its time but has long been detrimental to the further development and sharing of library metadata. I still don't understand. Here we are discussing changing cataloging rules (well, not so much the procedures, but the numbering and structure of the rules) spending money so that every cataloger will have to be retrained and catalogs will have to be retooled; yet this lousy ISO2709 format seems to be sacrosanct. Why? It absolutely must be dumped overboard, and the sooner the better. James L. Weinheimer j.weinhei...@aur.edu Director of Library and Information Services The American University of Rome Rome, Italy First Thus: http://catalogingmatters.blogspot.com/
Re: [RDA-L] RDA and MARC
- Original Message - From: Adam L. Schiff I like the idea of subfields with multiple letters. Perhaps we could name them after important or well known catalogers? For example subfield $jim subfield $mac subfield $karen Maybe ... but I would definitely draw the line at subfield $ranganathan David Moody Cataloging Librarian University of Detroit Mercy mood...@udmercy.edu (313) 578-0402 Visit the University's re:search portal: http://research.udmercy.edu A sheltered life can also be a daring one. For all serious daring begins from within. -- Eudora Welty, One writer's beginning
[RDA-L] Cataloguing non print materials
I've had not one suggestion on or off list with any provision in RDA
which makes it easier to catalogue electronic resources than using
AACR2, which might have been added to AACR2.
According to the Sanchez survey, many of us feel RDA is also better
than AACR2 for other nonprint material.
I beg to differ. If one adds the number of units to the listed
media carrier, as RDA instructs, there would be no difference in
description between: print and large print; DVD, HD, and Blu-ray;
electronic texts, websites, streaming videos, etc. I hope most will
have enough gumption to ignore that instruction and use the option to
use popular terms.
__ __ J. McRee (Mac) Elrod (m...@slc.bc.ca)
{__ | / Special Libraries Cataloguing HTTP://www.slc.bc.ca/
___} |__ \__
