JiscMail Logo
Email discussion lists for the UK Education and Research communities

Help for CIG-E-FORUM Archives


CIG-E-FORUM Archives

CIG-E-FORUM Archives


CIG-E-FORUM@JISCMAIL.AC.UK


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Proportional Font

LISTSERV Archives

LISTSERV Archives

CIG-E-FORUM Home

CIG-E-FORUM Home

CIG-E-FORUM  October 2012

CIG-E-FORUM October 2012

Options

Subscribe or Unsubscribe

Subscribe or Unsubscribe

Log In

Log In

Get Password

Get Password

Subject:

Re: Discussion of record 2

From:

Bernadette Mary O'Reilly <[log in to unmask]>

Reply-To:

Bernadette Mary O'Reilly <[log in to unmask]>

Date:

Wed, 24 Oct 2012 13:47:26 +0100

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (196 lines)

All points accept, but even if each FRBR and FRAD entity has a separate
record why would we want to give a work record two links to the same
other work for essentially the same relationship (Work A is about Work
B)?

And even when we have a system where data exists as separate records or
in more granular units and is compiled only at the point of delivery, we
still have to consider how to deliver a reasonably neat package without
unhelpful repetition.

Best wishes,
Bernadette

******************* 
Bernadette O'Reilly 
Catalogue Support Librarian 
01865 2-77134 
Bodleian Libraries, 
Osney One Building
Osney Mead
Oxford OX2 0EW.
******************* 


-----Original Message-----
From: CIG E-Forum [mailto:[log in to unmask]] On Behalf Of
Gordon Dunsire
Sent: 24 October 2012 13:32
To: [log in to unmask]
Subject: Re: [CIG-E-FORUM] Discussion of record 2

Bernadette and others

RDA is most effectively and efficiently used in the first of the RDA
Database Implementation Scenarios
(http://www.rda-jsc.org/docs/5editor2rev.pdf), where there are separate
records for each FRBR and FRAD entity. The records are linked; the most
effective and efficient type of link is a machine-readable identifier
rather than a human-readable access point. At global scale, this becomes
critical as there is no agreed universal and exclusive system for access
points.

As the document says, RDA data can be expressed in all three scenarios,
but this may be less effective and efficient in the second and third
scenarios.
Unfortunately, those scenarios are the ones used by most of the LMSs
currently available.

We (the cataloguing profession) are moving to a more distributed and
disaggregated view of bibliographic metadata, in the direction of linked
data where the focus is on the single statement (e.g. "This person is
the creator of that work") rather than the record. See my presentation A
short history of the evolution of the catalogue card
(http://www.gordondunsire.com/pubs/pres/EvolCatRec.ppt) for more
information. The utility of the record will remain, of course, but
records will be assembled from statements which may have sources other
than cataloguers, such as machines ("This Dewey number matches that
LCSH"), publishers, or end-users ("This film is a comedy about
librarians").

So I think it will be our long-term interests to use FRBR and RDA in all
their glory, than to hold back because of the limitations of current
library systems.

I think it is particularly important that, where at all possible, we
provide metadata at the finest level to support the widest range of
uses. For example, many people regard the introductions to each episode
of "Alfred Hitchcock presents" as works in their own right, and would, I
guess, appreciate being able to find, identify, and obtain them as such.

Of course, it can be difficult in practice to do this, especially during
a period of transition. But I don't think it will matter in the end;
presumably Hitchcock fans will do it for themselves, and someone else
will link their "Alfred Hitchcock" entity to VIAF - but whither the
cataloguing profession?

Cheers

Gordon


-----Original Message-----
From: CIG E-Forum [mailto:[log in to unmask]] On Behalf Of
Bernadette Mary O'Reilly
Sent: 24 October 2012 12:30
To: [log in to unmask]
Subject: Re: [CIG-E-FORUM] Discussion of record 2

Coming back very later to record 2: I very much hope that we will not go
in the direction of making RDA related-work (7XX) AAPs in records for
resources which are introductions, explanations, commentaries and
criticisms of other works. We have to make subject headings for them,
and that should be quite enough. 7XX would just be extra work and would
make records unnecessarily long and confusing for readers.  Even in
electronic records size matters - people don't want to be scrolling all
the time. 

Best wishes,
Bernadette 

*******************
Bernadette O'Reilly
Catalogue Support Librarian
01865 2-77134
Bodleian Libraries,
Osney One Building
Osney Mead
Oxford OX2 0EW.
******************* 


-----Original Message-----
From: CIG E-Forum [mailto:[log in to unmask]] On Behalf Of Helen
Doyle
Sent: 24 October 2012 11:59
To: [log in to unmask]
Subject: Re: [CIG-E-FORUM] Discussion of record 2

I'm not aware that AACR2 does anything like this, as this is pure FRBR. 

Also I am (sneakily) avoiding the MARC issue, as our LMS can't cope with
it!


HelenD.



Helen Doyle
Assistant Librarian
 
Royal Academy of Dance
36 Battersea Square
London
SW11 3RA
0207 326 8032


>>> Nicky Ransom <[log in to unmask]> 10/24/2012 11:36 am >>>
I can see what you mean. Is this a change from AACR2, or is it just that
I haven't understood AACR2 properly, never mind RDA!

If, for example, I'm cataloguing a manual about a computer program, I
would ordinarily have put the name of the computer program in a 630
field (title subject). But it should also go in 740 as a related title?

Nicky Ransom
Data Quality Manager & Cataloguer
University for the Creative Arts
Farnham
GU9 7DS

01252 892739
[log in to unmask]
________________________________________
From: CIG E-Forum [[log in to unmask]] on behalf of Helen Doyle
[[log in to unmask]]
Sent: 24 October 2012 11:28
To: [log in to unmask]
Subject: Re: [CIG-E-FORUM] Discussion of record 2

I did wonder about this. RDA 25.1 defines a related work as "a work
related to the resource being described (e.g., an adaptation,
commentary, supplement, sequel, part of a larger work)" and Vanda's book
is none of these. But, her book would not have been written if LCSH
hadn't been written first - like the example of "Bored of the Rings" she
took an existing Work and wrote her book around it, rather than just on
the same subject.

I've used this reasoning for other records later, so would be good to
know if any else has any thoughts on this!

HelenD.


Helen Doyle
Assistant Librarian

Royal Academy of Dance
36 Battersea Square
London
SW11 3RA
0207 326 8032


>>> Nicky Ransom <[log in to unmask]> 10/24/2012 11:03 am >>>
Is the relationship between the book and LCSH not one of subject, rather
than Work?

Nicky Ransom
Data Quality Manager & Cataloguer
University for the Creative Arts
Farnham
GU9 7DS
examples like that in downloaded RDA records.

Top of Message | Previous Page | Permalink

JiscMail Tools


RSS Feeds and Sharing


Advanced Options


Archives

April 2020
March 2020
February 2020
January 2020
December 2019
November 2019
October 2019
September 2019
August 2019
July 2019
June 2019
May 2019
April 2019
March 2019
February 2019
January 2019
December 2018
November 2018
October 2018
September 2018
August 2018
July 2018
June 2018
May 2018
April 2018
March 2018
February 2018
January 2018
December 2017
November 2017
October 2017
September 2017
August 2017
July 2017
June 2017
May 2017
February 2016
December 2015
September 2015
May 2015
April 2015
November 2014
July 2014
May 2014
February 2014
January 2014
October 2013
August 2013
June 2013
April 2013
October 2012
August 2012
April 2012
March 2012
February 2012
September 2011
May 2011
April 2011


JiscMail is a Jisc service.

View our service policies at https://www.jiscmail.ac.uk/policyandsecurity/ and Jisc's privacy policy at https://www.jisc.ac.uk/website/privacy-notice

Secured by F-Secure Anti-Virus CataList Email List Search Powered by the LISTSERV Email List Manager