Jonathan Rochkind
Thu, 11 Dec 2008 08:07:03 -0800
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 [EMAIL PROTECTED] 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 University410.516.8886 rochkind (at) jhu.edu