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

Help for DC-RDA Archives


DC-RDA Archives

DC-RDA Archives


DC-RDA@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

DC-RDA Home

DC-RDA Home

DC-RDA  December 2008

DC-RDA December 2008

Options

Subscribe or Unsubscribe

Subscribe or Unsubscribe

Log In

Log In

Get Password

Get Password

Subject:

Re: RDA/FRBR relationships and identifiers

From:

Jonathan Rochkind <[log in to unmask]>

Reply-To:

List for discussion on Resource Description and Access (RDA)

Date:

Thu, 11 Dec 2008 11:06:51 -0500

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (122 lines)

See, the tricky thing is, that our existing 'access points' were used 
for TWO purposes, both identifying an entry for humans _and_ collocating 
related entries. (At least when the 'access points' are what we somehow 
used to call 'controlled headings'--what I _think_ RDA refers to as 
'preferred access points'. RDA's terminology is not helpful in clearing 
up confusion here).

That traditional 'collocating' function is pretty much completely 
analogous--from a pre-computer world--to the function of machine 
identifiers.   The properties that made these 'access points' suitable 
for collocating related entries are the same properties that make them 
suitable as machine identifiers.  (more or less, with some significant 
issues, but better than anything else we've got in our existing data and 
practices).

Yes, that we use the same device for both purposes does lead to some 
issues, but it's the legacy we inherit. It would be of value to separate 
these functions, but that doesn't seem in the cards at the moment.

Jonathan

Alistair Miles wrote:
> Hi Karen,
>
> Just a quick comment, I understood that "access points" were means of
> identifying an entity for humans. Isn't this separate from identifiers
> which are for use within software, which need not ever see the light
> of day outside software?
>
> Coming up with an author/title "access point" for a work or expression
> sounds like something quite different from coining a persistent URI to
> identify the same work or expression for use within web-based
> information systems.
>
> I understand that LC are creating "permalinks" for bibliographic
> records? I think the "permalink" idea is a great way to tackle the
> need for identifiers. I.e. if each authority created a permalink URI
> identifying each bibliographic entity for which they hold a record, we
> could then use the permalink URIs in our RDF/RDA metadata to link all
> the entities together.
>
> Cheers,
>
> Alistair
>
> On Mon, Dec 08, 2008 at 06:00:17PM -0800, Karen Coyle wrote:
>   
>> A recent discussion on the RDA-L list brought to light some
>> information about FRBR relationships and how RDA creates (or does not
>> create) identifiers for linking between work, expression,
>> manifestation, and item. (WEMI)
>>
>> The key information is in chapter 17, which is only 17 pages long (and
>> a lot of it is examples). What is significant for this project is that
>> links between WEMI consist of "preferred access points" that represent
>> the FRBR entity. For example, there can be an author/title access
>> point that represents the work ("Schumann, Clara, 1819-1896. Scherzos,
>> piano, no. 1, op. 10, D minor"). A expression access point represents
>> the expression of the work ("Blade runner (Motion picture : Final
>> cut"). Some works and expressions have LC authority records, and the
>> ID number of the authority record may be considered an identifier for
>> the FRBR entity.
>>
>> The chapter also shows examples using what I see as "external"
>> identifiers for the FRBR Group1 entities (WEMI). These include the
>> ISBN or music publisher numbers for manifestations, and the
>> International Standard Text Code for works. These external identifiers
>> strike me as problematic for a few reasons:
>>  - coverage is uneven: there are many works and manifestations that
>> don't have such a code
>>  - coverage is uneven: there are no such codes for expressions
>>  - these identifiers come from another information space, and creators
>> of RDA data cannot create or correct them when needed
>>
>> The upshot is that identifying and linking FRBR Group1 entities using
>> these external identifiers is spotty at best, and decidedly not
>> consistent enough to create reliable FRBR relationships.
>>
>> Now for the catch:
>>
>> RDA does not specify "preferred access points" for manifestations or
>> items. So we have no "identifier" for manifestations. (not having one
>> for items is a bit less of an issue, for various reasons). So we can
>> link from:
>>
>> manifestation (with an expression access point) to an expression (with
>> a work access point) to a work
>>
>> But we can't link from an item to a manifestation, nor can we create
>> relationships between manifestations. Well, not with what we have
>> today in RDA.
>>
>> This came up for us in Alistair's analysis of scenario 2, where he
>> used the ISBN for the manifestation identifier. I objected, but in
>> fact there is no actual manifestation identifier to use.
>>
>> I don't really know what to do at this point, but it would be good to
>> try to make use of RDA access points as WEMI identifiers in one or
>> more of the scenarios so we can illustrate the issue. I'll see what I
>> can do, but may need help.
>>
>> kc
>>
>> -- 
>> --  ---
>> Karen Coyle / Digital Library Consultant
>> [log in to unmask] http://www.kcoyle.net
>> ph.: 510-540-7596   skype: kcoylenet
>> mo.: 510-435-8234
>> ------------------------------------
>>     
>
>   

-- 
Jonathan Rochkind
Digital Services Software Engineer
The Sheridan Libraries
Johns Hopkins University
410.516.8886 
rochkind (at) jhu.edu

Top of Message | Previous Page | Permalink

JiscMail Tools


RSS Feeds and Sharing


Advanced Options


Archives

May 2021
April 2021
February 2021
November 2020
September 2020
August 2020
July 2020
June 2020
March 2020
February 2020
November 2019
October 2019
September 2019
August 2019
July 2019
June 2019
April 2019
February 2019
December 2018
September 2018
July 2018
June 2018
April 2018
December 2017
November 2017
June 2017
December 2016
October 2016
September 2016
August 2016
July 2016
May 2016
April 2016
February 2016
January 2016
December 2015
November 2015
October 2015
September 2015
August 2015
June 2015
May 2015
April 2015
March 2015
February 2015
January 2015
December 2014
November 2014
September 2014
August 2014
July 2014
June 2014
May 2014
April 2014
March 2014
February 2014
January 2014
December 2013
November 2013
October 2013
September 2013
August 2013
July 2013
June 2013
May 2013
April 2013
March 2013
February 2013
January 2013
December 2012
November 2012
October 2012
August 2012
July 2012
May 2012
April 2012
March 2012
February 2012
January 2012
October 2011
September 2011
August 2011
June 2011
March 2011
February 2011
January 2011
December 2010
November 2010
October 2010
September 2010
August 2010
June 2010
February 2010
January 2010
December 2009
November 2009
October 2009
June 2009
April 2009
March 2009
February 2009
January 2009
December 2008
November 2008
October 2008
September 2008
August 2008
July 2008
June 2008
May 2008
April 2008
March 2008
February 2008
January 2008
December 2007
August 2007
July 2007
June 2007
May 2007
April 2006
February 2006
January 2006
December 2005


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

For help and support help@jisc.ac.uk

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