Re: [RDA-L] "Work manifested" in new RDA examples

[Kevin M Randall]

James Weinheimer wrote:
> I have seen a video where, "it's a book about Napoleon but I don't
> remember the author or title, only that it had a really neat green cover".
> You Google "napoleon book" go to images, click on the color green
> (you'll find it) and you get books about Napoleon with green bindings.
> This kind of search was a librarian's joke not that long ago. Now it can be
> done!
> https://www.google.com/search?q=napoleon+book&hl=en&tbm=isch&p
> rmd=imvnsa&source=lnt&tbs=ic:specific,isc:green

Is this supposed to be an example of how FISO does *not* apply today?  I 
clicked on the link, and what happened?

a)  I FOUND a plethora of images related to the search terms "napoleon 
book"

b)  I IDENTIFIED several images that seemed to pertain to the subject 
of my search (books about Napoleon, with green covers)

c)  I SELECTED one of them as possibly the one I was looking for, in an 
edition appropriate to my needs

d)  I OBTAINED the book by clicking on through and purchasing it from 
an online vendor (well, not really, but just pretend I did for the purpose of 
this discussion); or, if I wanted to save money, I could have just followed the 
WorldCat link to see that it's available in my local library!

The data underlying this search and retrieval process supported the FISO tasks 
by linking together data pertaining to the work, expression, manifestation, and 
item.  And I believe that having more and more of our bibliographic data put 
into a structure such as the RDA Element Set can only help searches such as the 
example above to become more powerful.  For example, it might turn out that the 
"really neat green cover" was only on a limited edition, or only the cover was 
green but the jacket was really black and red, etc.; having links to different 
manifestations, different editions, etc. could be very helpful.

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] "Work manifested" in new RDA examples

[Karen Coyle]

On 6/7/12 11:24 PM, Heidrun Wiesenmüller wrote:


Allende, Isabel --- has place of birth (or, if seen the other way 
round: is place of birth of) ---  Lima


And the same goes for occupation:

Allende, Isabel --- has occupation (or, if seen the other way round: 
is occupation of) ---  author


In our authority records, this is brought out by links between the 
records and the use of certain codes which specify the relationship. 
If you want to see what it looks like in RDF:

http://d-nb.info/gnd/118869159/about/rdf



This is similar to the author entity in Open Library, which links to the 
works of the author but which also contains information about the 
author, including some introductory text about the author (sometimes 
from Wikipedia, sometimes from the publisher, other times keyed in by 
users):


http://openlibrary.org/authors/OL228079A/Isabel_Allende

Note that by gathering all of the subjects related to the name this page 
also gets links to the "Allende family" which is important in this case.


The RDF exports only the info from the author entity:

http://openlibrary.org/authors/OL228079A.rdf

The richness of the page displayed to users shows the value of linking.

Note that LibraryThing also has author pages with information about the 
author:


http://www.librarything.com/author/allendeisabel

It's not linked data, but it has the qualities of helping users learn 
more about the author beyond just seeing the authoritative name.


I believe, by the way, that this is one of the problems RDA faces with 
regard to the group 3 entities of FRBR. These can not only be used as 
subjects, but may appear in the "bibliographic universe" at many other 
places, e.g. as relationships to person entities.


The group 3 entities need to be generalized -- not only for RDA but  for 
other use. I keep thinking that we need a set of "universals" that cover 
place, time, and other commonly needed concepts. There are some in the 
vocab.org vocabularies, like BIO, but surely someone like W3C or Dublin 
Core could create these for general usage. It doesn't make sense to 
"re-define" something as common as "place" inside a vocabulary designed 
for a specific use. Then FRBR-based metadata could have "place as 
subject" as a more specific use of the concept.


Personally, I think that ANYTHING that can be identified should be 
allowed to be a subject in the most general case, and that taking 
subject concepts from, for example, LCSH or the GND subjects, would be a 
more specific case.



kc




Heidrun




--
Karen Coyle
kco...@kcoyle.net http://kcoyle.net
ph: 1-510-540-7596
m: 1-510-435-8234
skype: kcoylenet

Re: [RDA-L] "Work manifested" in new RDA examples

[Heidrun Wiesenmüller]

Karen,

I don't know what your authority records look like nor how they are 
exchanged and updated. Perhaps that's another difference, and 
something we could learn from German libraries?


O.k, so here is some basic information about cataloguing procedures in 
Germany. Beware - this is going to be a longish mail, even though I'll 
simplify things a lot. Also, I'll be only looking at academic libraries. 
For public libraries, the situation is a bit different.


There are three levels to take into account, which interact with each 
other and whose data are constantly synchronized:


1. The national level: This comprises the national authority file stored 
in the database of the German National Library (Deutsche 
Nationalbibliothek, DNB) and a national database for continuing resources.


2. The regional level: Today, we have five regional union databases (but 
perhaps we'll manage someday to bring it all into one database...), 
financed from public funds. One should add the Austrian union catalog, 
because Germany and Austria cooperate very closely in cataloging and 
share the same procedures. The union catalog I'm most familiar with is 
the regional catalog for Southwestern Germany (SWB), which covers three 
federal states: Baden-Wurttemberg, the Saarland and Saxony (this of 
course not being in the southwest...). With very few exceptions, every 
academic and special library in this area is a member of the SWB.  Also, 
all libraries of the Goethe Instituts worldwide participate in the SWB 
database. The SWB includes about 15 million title records with 53 
million holdings records. Each regional catalog has a service center, 
where not only the database is maintained but which offers lots of 
services for the member libraries and also acts as a central 
coordinating unit in all technical questions. This, of course, helps a 
lot whenever German libraries are faced with change processes, like the 
introduction of the new authority format.


3. The local level: The individual ILS of each library.

The regional catalogs work, I believe, a bit differently from 
Anglo-American union catalogs. The idea is not to use the regional 
catalog as a "quarry", from which useful bits are downloaded and then 
edited locally. Instead, _all_ cataloging is done only on the level of 
the regional catalog, so this really is a cooperatively built database. 
I'll use the SWB as an example and try to make myself somewhat clearer: 
If a cataloger has to start from scratch, he or she will create the new 
title record not in the local ILS, but in the SWB database. He or she 
will then also create a holdings record there, with the call number and 
perhaps other information which is only relevant locally. In most cases, 
though, the necessary title record will already be there in the SWB, 
having been created by another member library. Then, you only have to 
add your holdings record. Of course, there is also copy imported e.g. 
from the DNB, from other national libraries like LC, or from booksellers 
like Blackwells. This can also be used as a starting point for a new 
record. Records can also be taken from another regional catalog.


Note that there should (whith very few exceptions) always be only _one_ 
bibliographic record for the same title in the regional catalog, which 
is then used by _all_ libraries which own the book in question. It is 
not possible to say "I don't like this record, I'm going to make a new 
one". Of course one library may want to add some information (e.g. 
subject information or a scan of the TOC) to a record or may find a 
mistake or have other good reason to want something changed. There is a 
complicated system of authorization, which defines who is allowed to 
change which bits of a record. In many cases you can't do the change 
yourself but can request it from the library which originally 
contributed the record.


Usually, every night there will be an automatic data transfer process: 
All records which are either new or have been somehow changed, and which 
show a holdings record of a certain library, will be copied from the 
regional database to the library's local ILS. This also means that 
whenever another library improves or supplements a record, all other 
libraries automatically benefit from this, as they will all get an 
updated version automatically. I believe OCLC also offers some sort of 
updating processes, but I don't know any details about this.


The "mirror data" in the local ILS is normally the basis for the OPAC 
(but there are exceptions: the regional OPAC can be used as well, by 
limiting it to the holdings of the library in question), for the 
circulation processes and for acquisition.


As I said before, all libraries have to work with the same bibliographic 
record for a title. Some things can be stored in the holdings record, 
though, e.g. local classification numbers which are only valid in one 
library. Obviously, the libraries are not completely "free" to do what 
they want i

Re: [RDA-L] "Work manifested" in new RDA examples

[James Weinheimer]

On 07/06/2012 20:42, Brenndorfer, Thomas wrote:

> You still don't get it.
>
> Everything you're doing is based upon some data element somewhere that a user 
> must act upon. It doesn't have to be traditional bibliographic data for the 
> FRBR user task to apply. You're still looking for things, finding them 
> because the relevant data was somewhere, still having to make discernments 
> and decisions about what you're looking at, and still having to make some 
> decision about suitability. For example, one the data elements for an 
> expression entity that satisfies the "Select" user task is "Award." So if you 
> find something, anything that won an award, and that's important to you, then 
> you are "Selecting".
>
> There's nothing 19th century about doing that.


I believe I have demonstrated, as much as anyone has, that I get it. I
understand FRBR. It's really not all that complicated. It is just that I
don't believe it. It has never been demonstrated that it is what the
public wants, not even by Panizzi himself, but the limits of his
technology and his environment constrained him to come up with his type
of catalog, which we have inherited.

Certainly, we can ascribe some kind of transcendent meanings to find,
identify, select, and obtain, along with the entities, and say that
these are constants that people have needed and wanted, and will remain
so for as long as humans stay human. Therefore, no matter what are the
advances in "search" and how those results are presented to humans; no
matter how intellectual products are created, how those products are
metamorphosed and how we perceive them, someone can always label it all
as "variants of FISO WEMI by their ATS". Of course, that is the same as
maintaining that astrophysics is actually a subtype of astrology or that
biochemistry is really a variation on alchemy. That the periodic table
of the elements actually displays various aspects of fire, water, earth
and air. Someone could make such statements and probably even make an
interesting case for them. Yet, it would be obvious to us that anyone
who would maintain such attitudes today would actually be talking about
the state of his or her own mind and nothing about the actual materials
themselves.

So yes, maintaining the primacy of the FRBR user tasks is evidence of an
earlier way of thinking that stems from the 19th century and in many
ways from before that. And that's OK but so long as we maintain such an
attitude, we voluntarily limit our possibilities when compared to those
who are not constrained by such presuppositions.

-- 
*James Weinheimer* weinheimer.ji...@gmail.com
*First Thus* http://catalogingmatters.blogspot.com/
*Cooperative Cataloging Rules*
http://sites.google.com/site/opencatalogingrules/
*Cataloging Matters Podcasts*
http://blog.jweinheimer.net/p/cataloging-matters-podcasts.html

Re: [RDA-L] "Work manifested" in new RDA examples

[Heidrun Wiesenmüller]

Karen,

Heidrun, looking at these examples (which naturally do not tell the 
whole story) it seems to me that the authority records in your 
catalogs do more than just establish preferred name forms; instead, 
they approach what to me seems more like the description of a person 
entity. The inclusion of information like the name of a spouse or the 
occupation is more than one needs to convey the preferred and 
alternate name forms.


Information like dates, occupation, place of birth a.s.o. was originally 
included only to distinguish between different persons with the same 
name. Note that in our cataloguing tradition, information like the dates 
is never part of the heading itself, but stored in different categories 
of the record. Because of our linking technique, we don't need 
unambiguous textual headings. The disambiguation is done by linking to 
the right authority record. And to make sure that you've got the correct 
one, you can look at all the information stored in the record, like 
dates, profession a.s.o. In a catalog display, it is of course possible 
to show one or more of these additional bits of information together 
with the name. E.g. in VIAF, German authority forms are always shown as 
a combination of the heading (the name only) and the dates (taken from 
field 548). So in VIAF they are made to look like name headings 
according to the Anglo-American tradition, although they follow a 
different "cataloguing philosophy".


You are quite right: Nowadays we do much more than only list some 
identifying information in the authority records. We like to think of 
our authority records as a "web of data" and love to have as many links 
as possible between authority records. For example, in the record for 
Thomas Mann (the author of works like "Buddenbrooks" and "Lotte in 
Weimar : the beloved returns") there are no less than 15 relationships 
to other persons. The record is shown here:

http://d-nb.info/gnd/118577166/about/html
or in RDF: http://d-nb.info/gnd/118577166/about/rdf
Whenever something is shown in blue in the HTML version, it is a link to 
another authority record. You can click on it and work your way through 
the web of the authority file.





This fits in with some thoughts I've been having about authority 
control and entities. Although the FRBR entity is called Person, the 
data is really only about the person's name, not about the person 
him/herself. In contrast, if you look at FOAF [1], the entity clearly 
represents the Person, with the name being one of many attributes. 
Person entries in resources like Wikipedia, Freebase [2], and Open 
Library [3] are also about the person, not the name.


I have thought that a good mix would be to use the library authority 
data as an identifier, but to connect that to these other, more ample 
resources to link to information about the person.


Definitely. Another of my "pet ideas" is a vision of a catalog which, 
starting off from a bibliographic record the user is looking at, 
presents him or her with lots of possibilities of things which might 
also be interesting. Some of these possibilities would stem from the 
catalog itself, but others would be derived from other sources.


You may want to look at slides 63 and 64 in a presentation of mine:
http://www.vdb-online.org/veranstaltungen/543/3_wiesenmueller.pdf

They give some ideas of the options which could be shown to a user 
looking at a title record for Thomas Mann's "Lotte in Weimar : the 
beloved returns". I'll give a translation of what is shown on the slides:


Slide 63:
About the author:
- Wikipedia article "Thomas Mann"
- Search "Thomas Mann" in Google
Biographies:
... (titles taken from the catalog)
General literature:
... (titles taken from the catalog)
Important works:
... (this information would be taken from DBpedia)
People around Thomas Mann:
... (taken from the authority record)
This author was influenced by:
... (taken from DBpedia)

Slide 64:
This author has influenced the following:
... (taken from DBpedia)
More titles from this author:
... (titles taken from the catalog)

About the work:
- Wikipedia article "Lotte in Weimar"
- Search on Google for "Lotte in Weimar"
Other editions:
... (titles taken from the catalog)
Free electronic editions:
... (taken from the tool "Umlaut" or something similar)
Secondary literature on this work:
... (titles taken from the catalog)

On slides 67 and 68 you can find a second example for a collection on 
renewable energy. Among other things, I've included links to the 
personal website of the editor or his profile in a social networks, a 
link to the institution where he works (taken from the authority 
record), links to Google Books and a scan of the table of contents, and 
the Wikipedia articles on the topics covered in the work. On slide 68 
there is a section "Find similar books", which would not only give 
similar titles from the catalog, but also recommend suitable databases 
for articles. There is also a section "related

Re: [RDA-L] "Work manifested" in new RDA examples

[Heidrun Wiesenmüller]

Thomas said:


And a further point, as is brought up in some entity-relationship modeling 
discussions...

Attributes can become entities.

Normally, an attribute is some value by itself. However, that value could also 
be pulled in from a table where that value has associated other values or 
attributes.

A good example is the value for "Place" or "Occupation". Are these free-text 
strings? Or are they entities in their own right, with their own set of attributes and 
relationships to other entities?



Yes, and this can be seen very well in the examples for German authority 
records I gave before. Originally, place of birth and occupation were 
seen basically as attributes of the person, helping to distinguish 
between persons with the same name. In the beginning, they were input as 
mere text strings. But as there already exist authority records for 
places (for use in subject cataloguing and also used when a publication 
emanates from a city as a jurisdiction) and for occupations (for use in 
subject cataloguing), one can establish an actual relationship between 
the two entities. So, if Isabel Allende was born in Lima, this can be 
seen as a relationship in the sense of a triple:


Allende, Isabel --- has place of birth (or, if seen the other way round: 
is place of birth of) ---  Lima


And the same goes for occupation:

Allende, Isabel --- has occupation (or, if seen the other way round: is 
occupation of) ---  author


In our authority records, this is brought out by links between the 
records and the use of certain codes which specify the relationship. If 
you want to see what it looks like in RDF:

http://d-nb.info/gnd/118869159/about/rdf

I believe, by the way, that this is one of the problems RDA faces with 
regard to the group 3 entities of FRBR. These can not only be used as 
subjects, but may appear in the "bibliographic universe" at many other 
places, e.g. as relationships to person entities.


Heidrun


--
-
Prof. Heidrun Wiesenmueller M.A.
Stuttgart Media University
Faculty of Information and Communication
Wolframstrasse 32, 70191 Stuttgart, Germany
www.hdm-stuttgart.de/bi

Re: [RDA-L] "Work manifested" in new RDA examples

[Karen Coyle]

Heidrun, looking at these examples (which naturally do not tell the 
whole story) it seems to me that the authority records in your catalogs 
do more than just establish preferred name forms; instead, they approach 
what to me seems more like the description of a person entity. The 
inclusion of information like the name of a spouse or the occupation is 
more than one needs to convey the preferred and alternate name forms.


This fits in with some thoughts I've been having about authority control 
and entities. Although the FRBR entity is called Person, the data is 
really only about the person's name, not about the person him/herself. 
In contrast, if you look at FOAF [1], the entity clearly represents the 
Person, with the name being one of many attributes. Person entries in 
resources like Wikipedia, Freebase [2], and Open Library [3] are also 
about the person, not the name.


I have thought that a good mix would be to use the library authority 
data as an identifier, but to connect that to these other, more ample 
resources to link to information about the person.


kc


[1] http://xmlns.com/foaf/spec/
[2] http://www.freebase.com/
[3] http://openlibrary.org/


On 6/7/12 11:40 AM, Heidrun Wiesenmüll er wrote:

Karen said:

I don't know what your authority records look like nor how they are 
exchanged and updated. Perhaps that's another difference, and 
something we could learn from German libraries? 


I'll give you a couple of examples from the brand-new "Common 
Authority File" (Gemeinsame Normdatei, GND), leaving out a few of 
categories for the sake of simplicity. I include translations and 
comments in square brackets. But basically, you'll find your way 
through the records, as the format is now quite close to MARC authority.


One of the objectives of the GND was to have data structures which are 
better suited for the semantic web. This is one of the reasons we now 
have lots of subfields (for things which used to be only marked by 
brackets or some similar method before) and many codes, which express 
e.g. the kind of a variant name or the kind of a relationship. 1XX are 
for preferred names, 4XX are for variant names, and 5XX are for 
relationships to another entity. If the relationship is to a place 
(say, a place of birth), this will go in 551 and get a code specifying 
the relationship (e.g. "ortg" for place of birth; in German: 
Geburtsort). If the relationship is to a person, this will be in 500, 
a.s.o.


A person:

005 Tpv [code for record type: authority, person, fully established]
006 http://d-nb.info/gnd/118869159[URI]
008 piz[code for an "ordinary" person]
035 gnd/118869159[control number]
043 XD-CL;XD-US[country codes for Chile and the USA]
065 12.2p[GND classification code for literary persons; input only 
if the person is also used as subject heading]

100 Allende, Isabel
400 Allende, Isabell
500 [Link via control number to authority record for]Gordon, William 
C. $4 bezf $v Ehemann["bezf": family relationship, "Ehemann": husband]
548 1942 $4 datl["datl": dates of live, year only. Date of death 
would go in $b]

548 02.08.1942 $4 datx ["datl": dates of live, exact]
550 [Link via control number to authority record for]Journalistin $4 
berc ["berc": characteristic occupation, here: journalist. The "berc" 
code is there to mark the occupation which is most useful to display 
in addition to the name of the person]
550 [Link via control number to authority record for]Schriftstellerin 
$4 beru ["beru": occupation, here: author]
551 [Link via control number to authority record for]Lima $4 ortg 
["ortg": place of birth]

670 B 1986[source: the dictionary "Brockhaus"]
678 $b Chilenische Journalistin u. Schriftstellerin; lebt heute in 
Kalifornien [biographical information: Chilean journalist and other, 
today lives in California]


A topical term:

005 Tsv[code for record type: authority, topical, fully established]
006 http://d-nb.info/gnd/4038953-4[URI]
008 saz[code for a topical term]
035 gnd/4387112-4[control number]
065 19.5[GND classification code for meteorology and climatology]
083 T1---015515[mapping to DDC]
083 551.5
150 Meteorologie
450 Wetterkunde
550 [Link via control number to authority record for]Geowissenschaften 
$4 obge ["obge": broader term, generic; here: earth sciences]
550 [Link via control number to authority record for]Wetter $4 vbal 
["vbal": related term; here: weather]

670 M[source: the dictionary "Mayer"]

Note: The true links to the authority records for broader and related 
terms have been only introduced with the GND. Before, we had the 
authorized form of the other headingmere textstrings in the 
corresponding categories.


A work by two authors:

005 Tuv[authority, work, fully established]
006 http://d-nb.info/gnd/7668078-2
008 wit[code for a work]
035 gnd/7668077-0
043 XA-DE[country code for Germany]
065 14.1 [GND classification code for music, general]
130 Composing for the fil

Re: [RDA-L] "Work manifested" in new RDA examples

[Simon Spero]

What makes you such an expert on the second objective of the catalog? Oh,
right   (1994 :-)

According to Madison (2005), the draft versions of the IFLA report had a
"relate" task.

In the earliest discussion document (drafted by Tillett in December 1993
and based on discussions with Svenonius and Tucker), slightly different
terminology was used that denoted the functions of the catalog (i.e.,
identify, relate, assist in the choice, and provide access). By 1995, five
functions were described abstractly with a user focus (find, identify,
choose, obtain, and relate). While the “relate” function was later dropped
in the 1996 worldwide review version, the final report notes its important
role (in a sense a “fifth user task”) in assisting the user to relate one
entity to another or to “navigate” the universe of entities represented in
a bibliographic file or database.

 "Relate"  would seem to have been a good home for the second objective.
 I'm not sure why it fell out in final drafts.  In Barbara Tillett's
dissertation, the "Shared Characteristic Relationship" was included in the
taxonomy of bibliographic relationships, and  "is the most pervasive of all
relationships since it cccurs whenevern access point is duplicated"  Tillet
(1987, p.83).  It is so pervasive that it could be explained in a single
page, and was not covered in the empirical part of the dissertation.

Interestingly, if one accepts some form of relative
identity ,
and starting from individual items, allow more properties to differ to form
different equivalent classes, it is possible to derive many of all of  the
FRBR group one entities using only the characteristics that are shared.

This is almost the same as "Near Equivalence"  (Yee 1993). The idea that
the different users  may have different criteria for whether an item is
"close enough" to match a request (and that the same user may have
different  criteria for different tasks) is identical.  A musicologist with
young children, who is studying the handwritten annotations on scores of
scores may require every copy of a specific manifestation, from multiple
institutions, in order to be able to do their research, but may only need
"anything by Dr. Seuss" in order to be allowed to do their research.

Simon

References

Carlyle, A. (1994). The second objective of the catalog: an evaluation of
collocation in online catalog displays. PhD thesis, University of
California, Los Angeles.

Madison, O. M. A. (2005). The Origins of the IFLA Study on Functional
Requirements for Bibliographic Records. Cataloging & Classification
Quarterly, 39(3-4):15–37

Tillett, B. B. (1988). Bibliographic relationships : toward a conceptual
structure of biblio- graphic information used in cataloging. PhD thesis,
University of California, Los Angeles.

Yee, M. (1993). Moving Image Works and Manifestations. PhD thesis,
University of California, Los Angeles.


On Thu, Jun 7, 2012 at 2:48 PM, Allyson Carlyle  wrote:

>
> It's the second object that points to the need for collocation (authority
> control):
>
> [The catalog should] show what the library has by a given author, on a
> given subject, ...
>




> In other words, if I do a search on an author, I should retrieve all the
> works of the author that the library has. He doesn't say it explicitly, but
> I believe he would have agreed it would be nice also if they were in a
> helpful (bow to Ranganathan) order. The second objective is about enabling
> a user to make a selection from among retrieved items, not finding a
> particular edition (first object). I don't believe we've ever had a catalog
> (other than a book catalog, and it had its limitations) that has done this
> effectively. Amazon et al. are also not very good at this.
>
> Cutter did not mention showing the works of a given author. I believe this
> is because the catalogs at the time collocated the editions of a work under
> author name, so he didn't need to say it (you can look at the catalog he
> worked on at the Boston Athenaeum or other large book catalogs published at
> the time for evidence).
>
> Lubetzky suggested an expansion of the second objective for the Paris
> Principles to explicitly recognize the need for the catalog to collocate
> the editions of a work:
>
> "[The catalog should], Second, ... relate and bring together the editions
> which a library has of a given work and the works it has of a given
> author."  (He did not include subject because it subject access was not
> included in the Paris discussions.)
>
> This object, the collocating (vs. finding) object, allows the user who is
> interested in a particular work to make a selection from among the editions
> held by the library. I don't read Chinese, so I select the English language
> version, or vice versa.
>
> In FRBR and the recent statement of international principles, the first
> and second objects were combined into a sin

Re: [RDA-L] "Work manifested" in new RDA examples

[Brenndorfer, Thomas]

You still don't get it.

Everything you're doing is based upon some data element somewhere that a user 
must act upon. It doesn't have to be traditional bibliographic data for the 
FRBR user task to apply. You're still looking for things, finding them because 
the relevant data was somewhere, still having to make discernments and 
decisions about what you're looking at, and still having to make some decision 
about suitability. For example, one the data elements for an expression entity 
that satisfies the "Select" user task is "Award." So if you find something, 
anything that won an award, and that's important to you, then you are 
"Selecting".

There's nothing 19th century about doing that.

Thomas Brenndorfer
Guelph Public Library


From: Resource Description and Access / Resource Description and Access 
[RDA-L@LISTSERV.LAC-BAC.GC.CA] On Behalf Of James Weinheimer 
[weinheimer.ji...@gmail.com]
Sent: June-07-12 1:58 PM
To: RDA-L@LISTSERV.LAC-BAC.GC.CA
Subject: Re: [RDA-L] "Work manifested" in new RDA examples

On 07/06/2012 18:49, Brenndorfer, Thomas wrote:


I think part of the problem is that James believes that FISO (find, intentify, 
select, obtain) applies only to "traditional access points of author, title, 
and subject".

That's incorrect.

Any element, big or small, belonging to any entity can be the target of these 
elementary tasks.

When people fill out any form, it's to provide bits of data so people can find 
the form, identify what's on the form, and do things with the data, such as 
select (which is the basis of limits and filters and other kinds of operations).

When James is saying entities are changing into all kinds of strange new things 
("entirely new and never seen before") he's ignoring the main point -- just get 
the data you need so we can continue to do useful search and retrieval on these 
strange new things. As anyone who has set up a database will say -- design the 
system to get the job done, and that means deciding what data are important and 
what needs to be related to what.



That is the theory, and how it was supposed to work in the old days. While it 
is true that the entities are changing into strange new things, "find" is not 
an entity. It is a behavior of the people, and based on the powerful new, and 
constantly changing capabilities of systems today, people are able to find 
things in an entire variety of ways that only the wildest science fiction 
writers could have imagined 30 years ago. As I said before, Google "the russian 
that killed the old pawnbroker" 
https://www.google.com/search?q=the+russian+that+killed+the+old+pawnbroker That 
information is nowhere in the bib record, nor does it need to be. It works, 
that is if you are looking for the novel Crime and Punishment, but if it is the 
name of some musical group, you may have a problem.

I have seen a video where, "it's a book about Napoleon but I don't remember the 
author or title, only that it had a really neat green cover". You Google 
"napoleon book" go to images, click on the color green (you'll find it) and you 
get books about Napoleon with green bindings. This kind of search was a 
librarian's joke not that long ago. Now it can be done! 
https://www.google.com/search?q=napoleon+book&hl=en&tbm=isch&prmd=imvnsa&source=lnt&tbs=ic:specific,isc:green

The modern information agencies are collecting vast amounts of information 
about each person that even we don't know about ourselves, to use it to find 
things I am not even aware I am searching for. This is what Tim Berners-Lee's 
"mechanical agent" is all about. Whether I love it or hate it is irrelevant; it 
is happening now.

But we must see that it is something profoundly different from what we had 
before.

--
James Weinheimer weinheimer.ji...@gmail.com<mailto:weinheimer.ji...@gmail.com>
First Thus http://catalogingmatters.blogspot.com/
Cooperative Cataloging Rules http://sites.google.com/site/opencatalogingrules/
Cataloging Matters Podcasts 
http://blog.jweinheimer.net/p/cataloging-matters-podcasts.html

Re: [RDA-L] "Work manifested" in new RDA examples

[Heidrun Wiesenmüller]

Karen said:

I don't know what your authority records look like nor how they are 
exchanged and updated. Perhaps that's another difference, and 
something we could learn from German libraries? 


I'll give you a couple of examples from the brand-new "Common Authority 
File" (Gemeinsame Normdatei, GND), leaving out a few of categories for 
the sake of simplicity. I include translations and comments in square 
brackets. But basically, you'll find your way through the records, as 
the format is now quite close to MARC authority.


One of the objectives of the GND was to have data structures which are 
better suited for the semantic web. This is one of the reasons we now 
have lots of subfields (for things which used to be only marked by 
brackets or some similar method before) and many codes, which express 
e.g. the kind of a variant name or the kind of a relationship. 1XX are 
for preferred names, 4XX are for variant names, and 5XX are for 
relationships to another entity. If the relationship is to a place (say, 
a place of birth), this will go in 551 and get a code specifying the 
relationship (e.g. "ortg" for place of birth; in German: Geburtsort). If 
the relationship is to a person, this will be in 500, a.s.o.


A person:

005 Tpv [code for record type: authority, person, fully established]
006 http://d-nb.info/gnd/118869159[URI]
008 piz[code for an "ordinary" person]
035 gnd/118869159[control number]
043 XD-CL;XD-US[country codes for Chile and the USA]
065 12.2p[GND classification code for literary persons; input only 
if the person is also used as subject heading]

100 Allende, Isabel
400 Allende, Isabell
500 [Link via control number to authority record for]Gordon, William C. 
$4 bezf $v Ehemann["bezf": family relationship, "Ehemann": husband]
548 1942 $4 datl["datl": dates of live, year only. Date of death 
would go in $b]

548 02.08.1942 $4 datx ["datl": dates of live, exact]
550 [Link via control number to authority record for]Journalistin $4 
berc ["berc": characteristic occupation, here: journalist. The "berc" 
code is there to mark the occupation which is most useful to display in 
addition to the name of the person]
550 [Link via control number to authority record for]Schriftstellerin $4 
beru ["beru": occupation, here: author]
551 [Link via control number to authority record for]Lima $4 ortg 
["ortg": place of birth]

670 B 1986[source: the dictionary "Brockhaus"]
678 $b Chilenische Journalistin u. Schriftstellerin; lebt heute in 
Kalifornien [biographical information: Chilean journalist and other, 
today lives in California]


A topical term:

005 Tsv[code for record type: authority, topical, fully established]
006 http://d-nb.info/gnd/4038953-4[URI]
008 saz[code for a topical term]
035 gnd/4387112-4[control number]
065 19.5[GND classification code for meteorology and climatology]
083 T1—015515[mapping to DDC]
083 551.5
150 Meteorologie
450 Wetterkunde
550 [Link via control number to authority record for]Geowissenschaften 
$4 obge ["obge": broader term, generic; here: earth sciences]
550 [Link via control number to authority record for]Wetter $4 vbal 
["vbal": related term; here: weather]

670 M[source: the dictionary "Mayer"]

Note: The true links to the authority records for broader and related 
terms have been only introduced with the GND. Before, we had the 
authorized form of the other headingmere textstrings in the 
corresponding categories.


A work by two authors:

005 Tuv[authority, work, fully established]
006 http://d-nb.info/gnd/7668078-2
008 wit[code for a work]
035 gnd/7668077-0
043 XA-DE[country code for Germany]
065 14.1 [GND classification code for music, general]
130 Composing for the films[preferred title of the work]
377 eng[language code]
430 Komposition für den Film $v ÖB-Alternative[variant title, marked 
as preferred form for public libraries]
500 [Link via control number to authority record for]Adorno, Theodor W. 
$4 aut1 ["aut1": first author]
500 [Link via control number to authority record for]Eisler, Hans $4 
auta ["auta": author who is not first author]

548 $c 1947 $4 datj["datj": year of publication]
670 Oxford Music Online[source]

Note: Unfortunately, up to now we only have a small number of authority 
records for works - only for those used in subject headings and for 
musical works.


Before the GND, we would have had two authority records for this work. 
The first one included the text string "Adorno, Theodor W. / Composing 
for the films" and the second one the text string "Eisler, Hans / 
Composing for the films", and both would have been applied to literature 
on this work. So, this was fairly similar to the name-title string. Now, 
an author is rather seen as a relationship, and this is brought out by a 
link.


How do you like the format? I think it's really well thought out. But 
there are also some drawbacks, as the new authority format in a way is 
"too 

Re: [RDA-L] "Work manifested" in new RDA examples

[James Weinheimer]

On 07/06/2012 18:49, Brenndorfer, Thomas wrote:

> I think part of the problem is that James believes that FISO (find, 
> intentify, select, obtain) applies only to "traditional access points of 
> author, title, and subject".
>
> That's incorrect.
>
> Any element, big or small, belonging to any entity can be the target of these 
> elementary tasks.
>
> When people fill out any form, it's to provide bits of data so people can 
> find the form, identify what's on the form, and do things with the data, such 
> as select (which is the basis of limits and filters and other kinds of 
> operations).
>
> When James is saying entities are changing into all kinds of strange new 
> things ("entirely new and never seen before") he's ignoring the main point -- 
> just get the data you need so we can continue to do useful search and 
> retrieval on these strange new things. As anyone who has set up a database 
> will say -- design the system to get the job done, and that means deciding 
> what data are important and what needs to be related to what.


That is the theory, and how it was supposed to work in the old days.
While it is true that the entities are changing into strange new things,
"find" is not an entity. It is a behavior of the people, and based on
the powerful new, and constantly changing capabilities of systems today,
people are able to find things in an entire variety of ways that only
the wildest science fiction writers could have imagined 30 years ago. As
I said before, Google "the russian that killed the old pawnbroker"
https://www.google.com/search?q=the+russian+that+killed+the+old+pawnbroker
That information is nowhere in the bib record, nor does it need to be.
It works, that is if you are looking for the novel Crime and Punishment,
but if it is the name of some musical group, you may have a problem.

I have seen a video where, "it's a book about Napoleon but I don't
remember the author or title, only that it had a really neat green
cover". You Google "napoleon book" go to images, click on the color
green (you'll find it) and you get books about Napoleon with green
bindings. This kind of search was a librarian's joke not that long ago.
Now it can be done!
https://www.google.com/search?q=napoleon+book&hl=en&tbm=isch&prmd=imvnsa&source=lnt&tbs=ic:specific,isc:green


The modern information agencies are collecting vast amounts of
information about each person that even we don't know about ourselves,
to use it to find things I am not even aware I am searching for. This is
what Tim Berners-Lee's "mechanical agent" is all about. Whether I love
it or hate it is irrelevant; it is happening now.

But we must see that it is something profoundly different from what we
had before.

-- 
*James Weinheimer* weinheimer.ji...@gmail.com
*First Thus* http://catalogingmatters.blogspot.com/
*Cooperative Cataloging Rules*
http://sites.google.com/site/opencatalogingrules/
*Cataloging Matters Podcasts*
http://blog.jweinheimer.net/p/cataloging-matters-podcasts.html

Re: [RDA-L] "Work manifested" in new RDA examples

[James Weinheimer]

On 07/06/2012 18:38, Stephen Early wrote:

>
> James Weinheimer wrote:
>
>  
>
> 
> Find is morphing into something that is really entirely new and never
> seen before. *And with the resources themselves that get more mashed
> up and vivisected both manually and automatically, it's increasingly
> difficult to even say what an "item" is*, which has major
> repercussions on what is a work, expression or manifestation, which I
> still say are all based on physical materials. And finally, focusing
> on the traditional access points of author, title, and subject is
> almost forgotten by the public. Certainly they do it, but they do it
> through natural language searches which goes far beyond ATS in the
> expectation that the system will sort it all out. And very often, it
> does.
> 
>
> A couple definite examples of the mashed up resources please, with
> explanation as to how and why they don't fit WEMI so that those more
> deeply involved in this discussion may be able to review them and then
> clearly agree or disagree with your points.
>
>  
>
> You may have done this before, but I mostly skim over these posts.
> However, I'm sensing a lot of repetition of arguments without a lot of
> progress being made.
>


They are all over the place. There is Google News, which mashes up all
kinds of things. Programmableweb is a good place to find mashups:
http://www.programmableweb.com/   where you can find a lot of them. To
understand what they are, there is a great, and short youtube video by
ZDNet that explains it really well
http://www.youtube.com/watch?v=ZRcP2CZ8DS8. It explains what an API is
and how people can put them together to make their very own mashups.

Here is one called Apartable http://apartable.com. It takes all the APIs
found here http://www.programmableweb.com/mashup/apartable which is
Facebook, Amazon, and several from Google to make something brand new
that may actually help someone find an apartment. I am sure that all of
the information exists on those separate websites, and nothing much is
on the apartable.com site, which merely brings it all together. If it's
good, people may be willing to pay for a service like this.

Here is Google Public Data Explorer,
http://www.google.com/publicdata/directory which uses the statistics
held at Eurostat, the US Census Bureau, etc. to mashup new views based
on Google's graphs and map capabilities. All of these are dynamic, i.e.
they are generated on the fly, so it is difficult to call anything an
"item." These mashups are bits and pieces of all kinds of things brought
together to make something very personal, very often just for you.
Anybody can make these mashups now and they do.

It is important to realize that the bibliographic world is headed
precisely into these directions, whether it will be using the so-called
linked data or through other means. Our records will be available
through APIs (Worldcat has some now) and webmasters will be able to
include our records into whatever they make. Developers cannot do so now
because of our lousy formats but once we turn output in XML, they will
be able to.

Some believe that the reason web developers do not use our records now
is precisely because of our obsolete format and once we do have better
formats, developers will want our data. I do not agree since I believe
the challenges faced by libraries are much more profound than a simple
problems in formats, but I admit I would like to be wrong. In any case,
we need to change our formats.

-- 
*James Weinheimer* weinheimer.ji...@gmail.com
*First Thus* http://catalogingmatters.blogspot.com/
*Cooperative Cataloging Rules*
http://sites.google.com/site/opencatalogingrules/
*Cataloging Matters Podcasts*
http://blog.jweinheimer.net/p/cataloging-matters-podcasts.html

Re: [RDA-L] "Work manifested" in new RDA examples

[Karen Coyle]

"mashups"

http://www.freebase.com/view/en/ray_bradbury
http://www.librarything.com/author/bradburyray
http://openlibrary.org/authors/OL24137A/Ray_Bradbury

and follow links from there. All of these systems have ingested library 
bibliographic data along with data from other sources and user-supplied 
data. Yet you won't find a "traditional" library bibliographic display 
in any of these.


kc

On 6/7/12 9:38 AM, Stephen Early wrote:


James Weinheimer wrote:


Find is morphing into something that is really entirely new and never 
seen before. *And with the resources themselves that get more mashed 
up and vivisected both manually and automatically, it's increasingly 
difficult to even say what an "item" is*, which has major 
repercussions on what is a work, expression or manifestation, which I 
still say are all based on physical materials. And finally, focusing 
on the traditional access points of author, title, and subject is 
almost forgotten by the public. Certainly they do it, but they do it 
through natural language searches which goes far beyond ATS in the 
expectation that the system will sort it all out. And very often, it 
does.



A couple definite examples of the mashed up resources please, with 
explanation as to how and why they don't fit WEMI so that those more 
deeply involved in this discussion may be able to review them and then 
clearly agree or disagree with your points.


You may have done this before, but I mostly skim over these posts. 
However, I'm sensing a lot of repetition of arguments without a lot of 
progress being made.


Stephen T. Early

Cataloger

Center for Research Libraries

6050 S. Kenwood

Chicago, IL  60637

773-955-4545

sea...@crl.edu

CRL website: www.crl.edu

*From:*Resource Description and Access / Resource Description and 
Access [mailto:RDA-L@LISTSERV.LAC-BAC.GC.CA] *On Behalf Of *James 
Weinheimer

*Sent:* Thursday, June 07, 2012 10:55 AM
*To:* RDA-L@LISTSERV.LAC-BAC.GC.CA
*Subject:* Re: [RDA-L] "Work manifested" in new RDA examples

On 07/06/2012 14:51, Brenndorfer, Thomas wrote:


It shouldn't be that hard to understand. And it shouldn't be "amazing" as it 
was fully explained to you previously.
  
John F. Myers, in an earlier post, explained the elementary nature of the FRBR user tasks:
  
"No matter what tool or platform is used, there has to be sufficient hooks associated with the resources it is describing in order for it to return a set of results for the FIND task. There has to be sufficient ancillary data, hook-like or otherwise, provided in those results for the user accomplish the IDENTIFY and SELECT task. And lastly, there has to be some further aspect of the record for the user to complete the OBTAIN task.
  
In Google, the hooks are the data compiled and indexed by its spiders, the ancillary data is the brief description below the link, the obtain aspect is the actual link. Similar pieces of data arise from the other web services.
  
One may argue about the elements one designates for accomplishing these tasks, one may argue about the validity of a given element for a certain population's accomplishment of these tasks, and one may argue about the elements appropriate to specific kinds of resources, but in the end we still need to have a mechanism that returns something whenever a user casts his/her net into the information universe, lets them discriminate amongst the fish captured, and then haul one out."




As I have tried to point out, this is not how it works today for 
modern information search and retrieval. FISO WEMI by ATS describes in 
idealistic terms what it was to use a library in the old days. Many 
never did manage to learn it, or didn't want to and preferred to just 
go in the stacks to browse randomly, or they would return to their 
"favorite shelves". But all is different now. For instance, today with 
full-text, you can identify and select something only *after* you have 
obtained it. That has to have a consequence on something.


Find is morphing into something that is really entirely new and never 
seen before. And with the resources themselves that get more mashed up 
and vivisected both manually and automatically, it's increasingly 
difficult to even say what an "item" is, which has major repercussions 
on what is a work, expression or manifestation, which I still say are 
all based on physical materials. And finally, focusing on the 
traditional access points of author, title, and subject is almost 
forgotten by the public. Certainly they do it, but they do it through 
natural language searches which goes far beyond ATS in the expectation 
that the system will sort it all out. And very often, it does.


Anybody can see this the moment they do a Google search. Certainly the 
public does.


I don't enjoy bringing these matters up, but somebody has to talk 
about them. As a result, what is 

Re: [RDA-L] "Work manifested" in new RDA examples

[Brenndorfer, Thomas]

I think part of the problem is that James believes that FISO (find, intentify, 
select, obtain) applies only to "traditional access points of author, title, 
and subject".

That's incorrect.

Any element, big or small, belonging to any entity can be the target of these 
elementary tasks.

When people fill out any form, it's to provide bits of data so people can find 
the form, identify what's on the form, and do things with the data, such as 
select (which is the basis of limits and filters and other kinds of operations).

When James is saying entities are changing into all kinds of strange new things 
("entirely new and never seen before") he's ignoring the main point -- just get 
the data you need so we can continue to do useful search and retrieval on these 
strange new things. As anyone who has set up a database will say -- design the 
system to get the job done, and that means deciding what data are important and 
what needs to be related to what.

Thomas Brenndorfer
Guelph Public Library


From: Resource Description and Access / Resource Description and Access 
[RDA-L@LISTSERV.LAC-BAC.GC.CA] On Behalf Of Stephen Early [sea...@crl.edu]
Sent: June-07-12 12:38 PM
To: RDA-L@LISTSERV.LAC-BAC.GC.CA
Subject: Re: [RDA-L] "Work manifested" in new RDA examples

James Weinheimer wrote:


Find is morphing into something that is really entirely new and never seen 
before. And with the resources themselves that get more mashed up and 
vivisected both manually and automatically, it's increasingly difficult to even 
say what an "item" is, which has major repercussions on what is a work, 
expression or manifestation, which I still say are all based on physical 
materials. And finally, focusing on the traditional access points of author, 
title, and subject is almost forgotten by the public. Certainly they do it, but 
they do it through natural language searches which goes far beyond ATS in the 
expectation that the system will sort it all out. And very often, it does.


A couple definite examples of the mashed up resources please, with explanation 
as to how and why they don’t fit WEMI so that those more deeply involved in 
this discussion may be able to review them and then clearly agree or disagree 
with your points.

You may have done this before, but I mostly skim over these posts. However, I’m 
sensing a lot of repetition of arguments without a lot of progress being made.

Stephen T. Early

Cataloger
Center for Research Libraries
6050 S. Kenwood
Chicago, IL  60637
773-955-4545
sea...@crl.edu
CRL website: www.crl.edu

From: Resource Description and Access / Resource Description and Access 
[mailto:RDA-L@LISTSERV.LAC-BAC.GC.CA] On Behalf Of James Weinheimer
Sent: Thursday, June 07, 2012 10:55 AM
To: RDA-L@LISTSERV.LAC-BAC.GC.CA
Subject: Re: [RDA-L] "Work manifested" in new RDA examples

On 07/06/2012 14:51, Brenndorfer, Thomas wrote:



It shouldn't be that hard to understand. And it shouldn't be "amazing" as it 
was fully explained to you previously.



John F. Myers, in an earlier post, explained the elementary nature of the FRBR 
user tasks:



"No matter what tool or platform is used, there has to be sufficient hooks 
associated with the resources it is describing in order for it to return a set 
of results for the FIND task. There has to be sufficient ancillary data, 
hook-like or otherwise, provided in those results for the user accomplish the 
IDENTIFY and SELECT task. And lastly, there has to be some further aspect of 
the record for the user to complete the OBTAIN task.



In Google, the hooks are the data compiled and indexed by its spiders, the 
ancillary data is the brief description below the link, the obtain aspect is 
the actual link. Similar pieces of data arise from the other web services.



One may argue about the elements one designates for accomplishing these tasks, 
one may argue about the validity of a given element for a certain population’s 
accomplishment of these tasks, and one may argue about the elements appropriate 
to specific kinds of resources, but in the end we still need to have a 
mechanism that returns something whenever a user casts his/her net into the 
information universe, lets them discriminate amongst the fish captured, and 
then haul one out."


As I have tried to point out, this is not how it works today for modern 
information search and retrieval. FISO WEMI by ATS describes in idealistic 
terms what it was to use a library in the old days. Many never did manage to 
learn it, or didn't want to and preferred to just go in the stacks to browse 
randomly, or they would return to their "favorite shelves". But all is 
different now. For instance, today with full-text, you can identify and select 
something only *after* you have obtained it. That has to have a consequence on 
something.

Find is morphing into something that 

Re: [RDA-L] "Work manifested" in new RDA examples

[Stephen Early]

James Weinheimer wrote:


Find is morphing into something that is really entirely new and never seen 
before. And with the resources themselves that get more mashed up and 
vivisected both manually and automatically, it's increasingly difficult to even 
say what an "item" is, which has major repercussions on what is a work, 
expression or manifestation, which I still say are all based on physical 
materials. And finally, focusing on the traditional access points of author, 
title, and subject is almost forgotten by the public. Certainly they do it, but 
they do it through natural language searches which goes far beyond ATS in the 
expectation that the system will sort it all out. And very often, it does.


A couple definite examples of the mashed up resources please, with explanation 
as to how and why they don't fit WEMI so that those more deeply involved in 
this discussion may be able to review them and then clearly agree or disagree 
with your points.

You may have done this before, but I mostly skim over these posts. However, I'm 
sensing a lot of repetition of arguments without a lot of progress being made.

Stephen T. Early
Cataloger
Center for Research Libraries
6050 S. Kenwood
Chicago, IL  60637
773-955-4545
sea...@crl.edu
CRL website: www.crl.edu

From: Resource Description and Access / Resource Description and Access 
[mailto:RDA-L@LISTSERV.LAC-BAC.GC.CA] On Behalf Of James Weinheimer
Sent: Thursday, June 07, 2012 10:55 AM
To: RDA-L@LISTSERV.LAC-BAC.GC.CA
Subject: Re: [RDA-L] "Work manifested" in new RDA examples

On 07/06/2012 14:51, Brenndorfer, Thomas wrote:



It shouldn't be that hard to understand. And it shouldn't be "amazing" as it 
was fully explained to you previously.



John F. Myers, in an earlier post, explained the elementary nature of the FRBR 
user tasks:



"No matter what tool or platform is used, there has to be sufficient hooks 
associated with the resources it is describing in order for it to return a set 
of results for the FIND task. There has to be sufficient ancillary data, 
hook-like or otherwise, provided in those results for the user accomplish the 
IDENTIFY and SELECT task. And lastly, there has to be some further aspect of 
the record for the user to complete the OBTAIN task.



In Google, the hooks are the data compiled and indexed by its spiders, the 
ancillary data is the brief description below the link, the obtain aspect is 
the actual link. Similar pieces of data arise from the other web services.



One may argue about the elements one designates for accomplishing these tasks, 
one may argue about the validity of a given element for a certain population's 
accomplishment of these tasks, and one may argue about the elements appropriate 
to specific kinds of resources, but in the end we still need to have a 
mechanism that returns something whenever a user casts his/her net into the 
information universe, lets them discriminate amongst the fish captured, and 
then haul one out."


As I have tried to point out, this is not how it works today for modern 
information search and retrieval. FISO WEMI by ATS describes in idealistic 
terms what it was to use a library in the old days. Many never did manage to 
learn it, or didn't want to and preferred to just go in the stacks to browse 
randomly, or they would return to their "favorite shelves". But all is 
different now. For instance, today with full-text, you can identify and select 
something only *after* you have obtained it. That has to have a consequence on 
something.

Find is morphing into something that is really entirely new and never seen 
before. And with the resources themselves that get more mashed up and 
vivisected both manually and automatically, it's increasingly difficult to even 
say what an "item" is, which has major repercussions on what is a work, 
expression or manifestation, which I still say are all based on physical 
materials. And finally, focusing on the traditional access points of author, 
title, and subject is almost forgotten by the public. Certainly they do it, but 
they do it through natural language searches which goes far beyond ATS in the 
expectation that the system will sort it all out. And very often, it does.

Anybody can see this the moment they do a Google search. Certainly the public 
does.

I don't enjoy bringing these matters up, but somebody has to talk about them. 
As a result, what is the purpose of library metadata? What is the purpose of 
the local catalog? These are logical enough questions. I think there are major 
purposes to library metadata and local catalogs since they could potentially 
provide the public with useful tools found nowhere else. But we must get away 
from thinking that FRBR tasks are what the users want. Librarians want them and 
need them, of this I have no doubt, but the users haven't done them ever since 
keyword was introduced int

Re: [RDA-L] "Work manifested" in new RDA examples

[Heidrun Wiesenmüller]

I find I have to clarify my retrieval examples on Horace and Tolstoy a bit:

For the search in LC's catalogue I deliberately did not do a "general 
keyword" search but combined a keyword search in the author index 
("name: personal (KPNC)") with a keyword search in the title index 
("title: all (KTIL)"). In this combination, if you search "horace" and 
"odes", there are 142 hits. But if you search "horatius" and "odes", 
there is no hit.


If you do a "keyword anywhere" (GKEY) search instead, there are indeed 7 
hits, but they result from other parts of the bibliographic description 
(e.g. "Horatius" as part of the title, the statement of responsibility 
or a note) and are therefore a bit random. Also you get other things as 
well, which are not editions of Horace's odes. I had deliberately wanted 
to rule out such results, and that's why I chose this admittedly rather 
complicated way. But obviously I should have explained that.


Now compare a similar search in our regional catalogue. Let's use the 
Tolstoy example here. Again, I deliberately don't use a simple general 
keyword search. So I choose the advanced search

http://swb.bsz-bw.de/DB=2.1/ADVANCED_SEARCHFILTER
and combine the options "title (keyword) [TIT]" and "person, author 
(keyword) [PST].


I get the following results:
- combination of "leo tolstoy" and "war and peace": 28 hits
- combination of "lew tolstoi" and "war and peace": 28 hits
- combination of "leo tolstoj" and "war and peace": 28 hits
a.s.o.

- combination of "leo tolstoy" and "krieg und frieden" (the German 
title): 98 hits

- combination of "lew tolstoi" and "krieg und frieden": 98 hits
- combination of "leo tolstoj" and "krieg und frieden": 98 hits
a.s.o.

So, this was not an example about mixing different language forms for 
the author and the title. What I wanted to demonstrate was that it 
really doesn't matter which form of name is used: All forms of names 
which are stored in the linked authority record are available for retrieval.


Heidrun




Am 07.06.2012 12:12, schrieb Heidrun Wiesenmüller:

Thomas,


As for the RDA Chapter 17 objectives, the question is quite simple: 
does the resource contain the specific work or expression or not? Set 
the value. Encode and design search engines as one pleases.


It's the same principle for the authority controlled form of an 
author's name. This is so we can find ALL resources attached to the 
person within the library.


Maybe I haven't made myself clear enough. In fact I believe that the 
collocating function is one of the most important features that 
library data have (as opposed to most bibliographic data provided by 
other suppliers). Indeed it is one of our greatest assets - but only, 
if the collocated results can be retrieved easily by ordinary users. 
That is why I oppose the use of text strings (e.g. authorized name 
forms or name-title strings), at least unless there are additional 
mechanisms in place. It's simply not enough to have an authority 
record in which all variant forms of a name are stored, unless people 
can make use of this information in a simple keyword search, without 
first having to find out what the preferred name is.


Correct me if I've misunderstood how Anglo-American catalogs work. 
I've just tried it out in your own catalog: Typing in, e.g. "lew 
tolstoi war peace" in "keyword" doesn't give me even one edition, let 
alone all of them ... The only way to reach my goal via the name-title 
string seems to be to use the browse index with the option "author" 
and type in "tolstoi lew" (not: "lew tolstoi", of course). Then I'll 
have to click on the link "SEE: Tolstoy, Leo, graf, 1828-1910". This 
brings me to a new section of the browse menu. Now I have to click 
four more times on "next 10 headings", until finally I can see an 
entry "Tolstoy, Leo, graf, 1828-1910. War and peace", under which 
there is a link "SEE: Tolstoy, Leo, graf, 1828-1910. Voina i mir. 
English". Clicking on this again brings me to a new section of the 
browse menu with the entry "Tolstoy, Leo, graf, 1828-1910. Voina i 
mir. English". One final click on this and - voila! - there are 16 hits.


This may be o.k. for librarians and some specialist users - but it is 
simply awful to present ordinary people with such a difficult and 
cumbersome way of reaching their goal. The basic problem behind all 
this is, I believe, the Anglo-American technique of using text strings 
for collocation, and the fact, that there is no real path between the 
different records. E.g. the variant names for Leo Tolstoy are only in 
the authority record for this person, but not in the authority record 
for "Tolstoy, Leo, graf, 1828-1910. Voĭna i mir. English" as well. But 
still: All the information we need is already there, somewhere. So 
it's only a question of better data processing.


It is technically possible to transform authorized text strings into 
real links. As I said in an earlier mail, we just did that in Germany 
for broader and related

Re: [RDA-L] "Work manifested" in new RDA examples

[Karen Coyle]

On 6/7/12 3:12 AM, Heidrun Wiesenmüller wrote:



Correct me if I've misunderstood how Anglo-American catalogs work. 
I've just tried it out in your own catalog: Typing in, e.g. "lew 
tolstoi war peace" in "keyword" doesn't give me even one edition, let 
alone all of them ... The only way to reach my goal via the name-title 
string seems to be to use the browse index with the option "author" 
and type in "tolstoi lew" (not: "lew tolstoi", of course). Then I'll 
have to click on the link "SEE: Tolstoy, Leo, graf, 1828-1910". This 
brings me to a new section of the browse menu. Now I have to click 
four more times on "next 10 headings", until finally I can see an 
entry "Tolstoy, Leo, graf, 1828-1910. War and peace", under which 
there is a link "SEE: Tolstoy, Leo, graf, 1828-1910. Voina i mir. 
English". Clicking on this again brings me to a new section of the 
browse menu with the entry "Tolstoy, Leo, graf, 1828-1910. Voina i 
mir. English". One final click on this and - voila! - there are 16 hits.


I think this is more than how "A-A catalogs" work, but is inherent in 
the authority data that is being created. In the early 80's when I was 
working on the design for the Univ. of California system we tried to 
integrate the authority records with the bibliographic records. We 
discovered that the cross references were only on the name authority 
record, not the name/title record, or, in the case of corporate names, 
the record for the first portion of the name. (e.g. "U.S. Dept. of 
State" did not have a cross reference from "United States. Department of 
State", only the entry for "U.S." alone was linked to "United States".) 
We considered doing string matches and proliferating the cross 
references over the pre-composed headings, but realized that updates to 
those records coming from LC would over-write our changes, and we didn't 
at the time have the computing power to re-check all such potential 
links every time we got an authority update.


The fact that the production of name authorities (and subject 
authorities as well, which followed a similar pattern) did not change 
from their card catalog format made it very hard to integrate these into 
systems. This may be an area where the wide-spread sharing of data was 
something of a hindrance, since none of us could change unless LC (and 
NACO, the name authority consortium) changed.


I don't know what your authority records look like nor how they are 
exchanged and updated. Perhaps that's another difference, and something 
we could learn from German libraries?


kc



This may be o.k. for librarians and some specialist users - but it is 
simply awful to present ordinary people with such a difficult and 
cumbersome way of reaching their goal. The basic problem behind all 
this is, I believe, the Anglo-American technique of using text strings 
for collocation, and the fact, that there is no real path between the 
different records. E.g. the variant names for Leo Tolstoy are only in 
the authority record for this person, but not in the authority record 
for "Tolstoy, Leo, graf, 1828-1910. Voĭna i mir. English" as well. But 
still: All the information we need is already there, somewhere. So 
it's only a question of better data processing.


It is technically possible to transform authorized text strings into 
real links. As I said in an earlier mail, we just did that in Germany 
for broader and related terms in our subject authority headings. But, 
as I've also already pointed out, you don't necessarily have to 
introduce record linking. An alternative possibility would be to 
expand the title records with the relevant information taken from the 
authority records, and then use this e.g. for indexing in a catalog 
interface based on search engine technology (like VuFind). In this 
case, all the text strings could be kept as they are in the underlying 
MARC data. They would be used as "pointers" for the expansion process. 
E.g. when there is an authorized string "Tolstoy, Leo, graf, 
1828-1910", this tells the algorithm to expand it with all the variant 
names from the authority record ("Tolstoi, Lew", "Tolstoj, Lav 
Nikolajević" a.s.o.).


I'm sorry if I've got carried away a bit... But I've so often seen the 
look of shock and disbelief in the eyes of my students when I 
demonstrate a keyword search for e.g. the odes of Horace in the LC 
catalog, using a variant name like the Latin "Horatius". This 
inevitably leads to zero hits and the funny notice "Please note: The 
Library of Congress does not keep a copy of every title ever 
published." The students, of course, are used of getting the same 
number of hits, regardless of whether they use the preferred or a 
variant name in a keyword search, as it is standard in German catalogs.


As somebody who hasn't grown up with the Anglo-American way of 
cataloguing, when I look at it from the outside I am both awed and 
dismayed. I am awed because you take so much more effort, and include 
so much more inform

Re: [RDA-L] "Work manifested" in new RDA examples

[James Weinheimer]

On 07/06/2012 14:51, Brenndorfer, Thomas wrote:

> It shouldn't be that hard to understand. And it shouldn't be "amazing" as it 
> was fully explained to you previously.
>
> John F. Myers, in an earlier post, explained the elementary nature of the 
> FRBR user tasks:
>
> "No matter what tool or platform is used, there has to be sufficient hooks 
> associated with the resources it is describing in order for it to return a 
> set of results for the FIND task. There has to be sufficient ancillary data, 
> hook-like or otherwise, provided in those results for the user accomplish the 
> IDENTIFY and SELECT task. And lastly, there has to be some further aspect of 
> the record for the user to complete the OBTAIN task.
>
> In Google, the hooks are the data compiled and indexed by its spiders, the 
> ancillary data is the brief description below the link, the obtain aspect is 
> the actual link. Similar pieces of data arise from the other web services.
>
> One may argue about the elements one designates for accomplishing these 
> tasks, one may argue about the validity of a given element for a certain 
> population’s accomplishment of these tasks, and one may argue about the 
> elements appropriate to specific kinds of resources, but in the end we still 
> need to have a mechanism that returns something whenever a user casts his/her 
> net into the information universe, lets them discriminate amongst the fish 
> captured, and then haul one out."


As I have tried to point out, this is not how it works today for modern
information search and retrieval. FISO WEMI by ATS describes in
idealistic terms what it was to use a library in the old days. Many
never did manage to learn it, or didn't want to and preferred to just go
in the stacks to browse randomly, or they would return to their
"favorite shelves". But all is different now. For instance, today with
full-text, you can identify and select something only *after* you have
obtained it. That has to have a consequence on something.

Find is morphing into something that is really entirely new and never
seen before. And with the resources themselves that get more mashed up
and vivisected both manually and automatically, it's increasingly
difficult to even say what an "item" is, which has major repercussions
on what is a work, expression or manifestation, which I still say are
all based on physical materials. And finally, focusing on the
traditional access points of author, title, and subject is almost
forgotten by the public. Certainly they do it, but they do it through
natural language searches which goes far beyond ATS in the expectation
that the system will sort it all out. And very often, it does.

Anybody can see this the moment they do a Google search. Certainly the
public does.

I don't enjoy bringing these matters up, but somebody has to talk about
them. As a result, what is the purpose of library metadata? What is the
purpose of the local catalog? These are logical enough questions. I
think there are major purposes to library metadata and local catalogs
since they could potentially provide the public with useful tools found
nowhere else. But we must get away from thinking that FRBR tasks are
what the users want. Librarians want them and need them, of this I have
no doubt, but the users haven't done them ever since keyword was
introduced into our catalogs.  Judging by how quickly people abandoned
the traditional methods in favor of keyword, I don't think the users
cared much for the so-called FRBR "user" tasks anyway. Nobody complained
and they moved on. They want something different today.

-- 
*James Weinheimer* weinheimer.ji...@gmail.com
*First Thus* http://catalogingmatters.blogspot.com/
*Cooperative Cataloging Rules*
http://sites.google.com/site/opencatalogingrules/
*Cataloging Matters Podcasts*
http://blog.jweinheimer.net/p/cataloging-matters-podcasts.html

Re: [RDA-L] "Work manifested" in new RDA examples

[Brenndorfer, Thomas]

That's a fantastic analysis, and it mirrors a lot of my thoughts and 
experiences.

The problems with using headings only to bring together resources is what drew 
me to FRBR in the first place-- at least here was a description of what was 
happening in a catalog that didn't depend on collocated headings specifically, 
but on targeted relationships between entities of interest.

Creative web design can show the way. In one system I customized, I focused on 
creating hyperlinks out of headings and the decisions were: should it point to 
a browse search, a keyword search, or a result list with records that have 
heading.

A different approach (not yet possible in many catalogs) is to point to a web 
page dedicated to that entity.

So, War and Peace can be an entity represented not by its heading only which 
quickly gives way to bibliographic descriptions beneath the heading, but by a 
web page which in turns embeds all attributes and relationships about that 
entity, as in how LibraryThing does it:

http://www.librarything.com/work/995

Likewise, if I'm interested in an author entity, instead of a browse list of 
headings that drop me immediately into a result set of bibliographic records, I 
can view all relevant attributes and relationships about that entity at once, 
as in WorldCat Identities' page for Virginia Woolf:

http://www.worldcat.org/identities/lccn-n79-41870

FRBR and RDA essentially "disintegrate" catalog records and allow the granular 
bits of data -- elements being either attributes of an entity or relationships 
between entities -- to be "reintegrated" as needed for whatever display is 
required, and at the same time allow the user to accomplish the elementary 
tasks in finding resources relevant to their needs.

Which is not to say browse lists aren't still useful. I'm fortunate enough to 
have a library system that supports faceted, relevancy-ranked keyword search 
results along with Boolean search features and with browse search features. But 
it certainly is frustrating to not have all those pieces fitting together in 
ways similar to the two examples above (although each improvement to the 
catalog over time has seemed to move in that direction).

As for authority maintenance, the processes I have to work with have improved. 
Currently, a weekly flow of updated MARC authority records are pulled from the 
vendor's web site and replace existing authority records through the control 
number (yes!) but replace the heading in the attached bibliographic record only 
by the text string (boo!).

Likewise, when I load a new bibliographic record, all of the attached authority 
records are also pulled down from the remote site. I already work in a 
multi-record environment-- bibliographic and authority records saved all at 
once -- and in turn the bibliographic records in the public interface connect 
to enriched content services, building a display on-the-fly. Holdings records 
(Item entities) are deeply interconnected in the database to other entities 
(library users and branch locations), and have rich additional fields that 
supplement the bibliographic fields. Some of the search mechanisms can scan 
across both bibliographic and item record fields -- but I wish the same could 
be done with bibliographic and authority record fields! The ability to search 
the rich data in authority records (history notes, references especially) would 
be a great addition to the catalog.

Thomas Brenndorfer
Guelph Public Library






From: Resource Description and Access / Resource Description and Access 
[RDA-L@LISTSERV.LAC-BAC.GC.CA] On Behalf Of Heidrun Wiesenmüller 
[wiesenmuel...@hdm-stuttgart.de]
Sent: June-07-12 6:12 AM
To: RDA-L@LISTSERV.LAC-BAC.GC.CA
Subject: Re: [RDA-L] "Work manifested" in new RDA examples

Thomas,


> As for the RDA Chapter 17 objectives, the question is quite simple: does the 
> resource contain the specific work or expression or not? Set the value. 
> Encode and design search engines as one pleases.
>
> It's the same principle for the authority controlled form of an author's 
> name. This is so we can find ALL resources attached to the person within the 
> library.

Maybe I haven't made myself clear enough. In fact I believe that the
collocating function is one of the most important features that library
data have (as opposed to most bibliographic data provided by other
suppliers). Indeed it is one of our greatest assets - but only, if the
collocated results can be retrieved easily by ordinary users. That is
why I oppose the use of text strings (e.g. authorized name forms or
name-title strings), at least unless there are additional mechanisms in
place. It's simply not enough to have an authority record in which all
variant forms of a name are stored, unless people can make use of this
information in a simple keyword search, without

Re: [RDA-L] "Work manifested" in new RDA examples

[Brenndorfer, Thomas]

It shouldn't be that hard to understand. And it shouldn't be "amazing" as it 
was fully explained to you previously.

John F. Myers, in an earlier post, explained the elementary nature of the FRBR 
user tasks:

"No matter what tool or platform is used, there has to be sufficient hooks 
associated with the resources it is describing in order for it to return a set 
of results for the FIND task. There has to be sufficient ancillary data, 
hook-like or otherwise, provided in those results for the user accomplish the 
IDENTIFY and SELECT task. And lastly, there has to be some further aspect of 
the record for the user to complete the OBTAIN task.

In Google, the hooks are the data compiled and indexed by its spiders, the 
ancillary data is the brief description below the link, the obtain aspect is 
the actual link. Similar pieces of data arise from the other web services.

One may argue about the elements one designates for accomplishing these tasks, 
one may argue about the validity of a given element for a certain population’s 
accomplishment of these tasks, and one may argue about the elements appropriate 
to specific kinds of resources, but in the end we still need to have a 
mechanism that returns something whenever a user casts his/her net into the 
information universe, lets them discriminate amongst the fish captured, and 
then haul one out."

Thomas Brenndorfer
Guelph Public Library


From: Resource Description and Access / Resource Description and Access 
[RDA-L@LISTSERV.LAC-BAC.GC.CA] On Behalf Of James Weinheimer 
[weinheimer.ji...@gmail.com]
Sent: June-07-12 3:27 AM
To: RDA-L@LISTSERV.LAC-BAC.GC.CA
Subject: Re: [RDA-L] "Work manifested" in new RDA examples

On 06/06/2012 22:16, Brenndorfer, Thomas wrote:

The FRBR user tasks are like breathing and eating, and, no, a user doesn't have 
to have a full understanding of the bibliographic universe for them to pertain.


I believe that this may be the most amazing statement I have read in all of my 
studies on cataloging and of all the messages on all the lists I have read. The 
FRBR user tasks are like eating and breathing?! I confess that I have seen 
people stop breathing, and they have died. I have not personally seen anyone 
stop eating and die (although I recently saw the movie "Hunger"), but I believe 
it has been firmly demonstrated that if someone did stop eating they would die.

Maintaining that the FRBR user tasks are as natural as eating and breathing of 
course, flies in the experience of each person each and every time they use a 
full text search engine. Search "call me ishmael" in Google and see what you 
get. Search "the book about the russian who killed an old pawn broker". The 
examples are endless.

The fact is: the FRBR user tasks describe how to work a specific tool designed 
in the 19th century, that is, the library catalog. This should not be extended 
to saying that these are the tasks (most) users want to do. There is no 
evidence for that at all, and in fact, there is a lot of evidence to the 
contrary.

So long as the fiction is adhered to that FRBR provides what the majority of 
the users want, it will be very difficult for libraries to move ahead. We must 
approach matters in a much less dogmatic way, and be more scientific in our 
reasoning.
--
James Weinheimer weinheimer.ji...@gmail.com<mailto:weinheimer.ji...@gmail.com>
First Thus http://catalogingmatters.blogspot.com/
Cooperative Cataloging Rules http://sites.google.com/site/opencatalogingrules/
Cataloging Matters Podcasts 
http://blog.jweinheimer.net/p/cataloging-matters-podcasts.html

Re: [RDA-L] "Work manifested" in new RDA examples

[James Weinheimer]

On 07/06/2012 12:12, Heidrun Wiesenmüller wrote:

> I'm sorry if I've got carried away a bit... But I've so often seen the
> look of shock and disbelief in the eyes of my students when I
> demonstrate a keyword search for e.g. the odes of Horace in the LC
> catalog, using a variant name like the Latin "Horatius". This
> inevitably leads to zero hits and the funny notice "Please note: The
> Library of Congress does not keep a copy of every title ever
> published." The students, of course, are used of getting the same
> number of hits, regardless of whether they use the preferred or a
> variant name in a keyword search, as it is standard in German catalogs.
>
> As somebody who hasn't grown up with the Anglo-American way of
> cataloguing, when I look at it from the outside I am both awed and
> dismayed. I am awed because you take so much more effort, and include
> so much more information in your cataloguing data than we do. To take
> just one example: According to the German cataloguing code only the
> first editor gets an access point, whereas it's up to three in AACR2.
> So, I am very favourably impressed by the richness of Anglo-American
> cataloguing data, and I often wish we had the same attitude towards
> cataloguing here.
>
> On the other hand, I am sometimes a bit dismayed when I look at the
> way this great data is stored, handled and processed. Compared with
> conventions and practices here, to me it often seems rather
> inefficient and not really suited to this day and age. Collocation via
> text strings is only one example. Another would be authority
> maintenance, where - if I understand correctly - our customs are quite
> different: We're used to automatic updating processes. Whenever a
> heading is changed or a variant name added, this only has to be done
> once, in the national authority file. It will then be automatically
> copied to the correspondent authority files in the regional networks,
> and from there, the changed data will be delivered to the local
> library systems, again automatically. Due to this system and the links
> between authority records and title records, there is no need for any
> locally done cleanup. And then, of course, there is the MARC format.
> When I teach MARC to students, who are already familiar with another
> input format (the PICA format used in the Southwestern German Library
> Network), they find it very hard to understand why suddenly they have
> to input ISBD punctuation and must type in a parallel title twice (in
> 245 $b and 246). "Isn't this superfluous?", they ask. "Why doesn't the
> machine do it for me?".


The only way I have been able to get people to understand a lot of
American library catalogs is to explain how card catalogs used to work.
*IF*--and that is a very big IF--people kept listening, they could
understand some of the basics of how to search the library catalog. I
have tended to have the best success with people with a historical bent,
because I can show them scanned catalogs online, both book and cards,
and some have gotten genuinely interested seeing these old tools. But
not many. The old catalogs had a logic that is missing in the full-text
search engines today.

In the earliest online catalogs, before browsers, everything was text
based and I think everything may have worked better, but once keyword
was added and the web interfaces, nothing was ever really rethought. And
after Google and Facebook and Twitter, and so on and so on, we are faced
with completely different user expectations.

In the field of "information architecture", one of the key assumptions
is that if someone takes an information resource in one format and
simply transfers it into another format, the final product will normally
be inferior to the original. That is because the resource was originally
designed for another environment. Still, it may be almost impossible for
the people who were experts in the previous format even to be aware of
the deficiencies in the new format. The result for someone who knows
nothing is sheer incomprehension of this resource. As one example, we
saw this in the early days of the web, where the information on many
sites was arranged according to internal bureaucratic hierarchies and
someone who had no idea about the internal workings of the organization
could not even know where to begin. Thus we see the need for the
"information architect".

The library catalog has never been "re-architected" (how is that for a
word?). It is still a card catalog transformed into MARC21 with keyword
capability. The RDA/FRBR project shows me that in the future, we will
have a card catalog in RDF with keyword and semantic web capability
(whatever that will really mean).

-- 
*James Weinheimer* weinheimer.ji...@gmail.com
*First Thus* http://catalogingmatters.blogspot.com/
*Cooperative Cataloging Rules*
http://sites.google.com/site/opencatalogingrules/
*Cataloging Matters Podcasts*
http://blog.jweinheimer.net/p/cataloging-matters-podcasts.html

Re: [RDA-L] "Work manifested" in new RDA examples

[Heidrun Wiesenmüller]

Thomas,



As for the RDA Chapter 17 objectives, the question is quite simple: does the 
resource contain the specific work or expression or not? Set the value. Encode 
and design search engines as one pleases.

It's the same principle for the authority controlled form of an author's name. 
This is so we can find ALL resources attached to the person within the library.


Maybe I haven't made myself clear enough. In fact I believe that the 
collocating function is one of the most important features that library 
data have (as opposed to most bibliographic data provided by other 
suppliers). Indeed it is one of our greatest assets - but only, if the 
collocated results can be retrieved easily by ordinary users. That is 
why I oppose the use of text strings (e.g. authorized name forms or 
name-title strings), at least unless there are additional mechanisms in 
place. It's simply not enough to have an authority record in which all 
variant forms of a name are stored, unless people can make use of this 
information in a simple keyword search, without first having to find out 
what the preferred name is.


Correct me if I've misunderstood how Anglo-American catalogs work. I've 
just tried it out in your own catalog: Typing in, e.g. "lew tolstoi war 
peace" in "keyword" doesn't give me even one edition, let alone all of 
them ... The only way to reach my goal via the name-title string seems 
to be to use the browse index with the option "author" and type in 
"tolstoi lew" (not: "lew tolstoi", of course). Then I'll have to click 
on the link "SEE: Tolstoy, Leo, graf, 1828-1910". This brings me to a 
new section of the browse menu. Now I have to click four more times on 
"next 10 headings", until finally I can see an entry "Tolstoy, Leo, 
graf, 1828-1910. War and peace", under which there is a link "SEE: 
Tolstoy, Leo, graf, 1828-1910. Voina i mir. English". Clicking on this 
again brings me to a new section of the browse menu with the entry 
"Tolstoy, Leo, graf, 1828-1910. Voina i mir. English". One final click 
on this and - voila! - there are 16 hits.


This may be o.k. for librarians and some specialist users - but it is 
simply awful to present ordinary people with such a difficult and 
cumbersome way of reaching their goal. The basic problem behind all this 
is, I believe, the Anglo-American technique of using text strings for 
collocation, and the fact, that there is no real path between the 
different records. E.g. the variant names for Leo Tolstoy are only in 
the authority record for this person, but not in the authority record 
for "Tolstoy, Leo, graf, 1828-1910. Voĭna i mir. English" as well. But 
still: All the information we need is already there, somewhere. So it's 
only a question of better data processing.


It is technically possible to transform authorized text strings into 
real links. As I said in an earlier mail, we just did that in Germany 
for broader and related terms in our subject authority headings. But, as 
I've also already pointed out, you don't necessarily have to introduce 
record linking. An alternative possibility would be to expand the title 
records with the relevant information taken from the authority records, 
and then use this e.g. for indexing in a catalog interface based on 
search engine technology (like VuFind). In this case, all the text 
strings could be kept as they are in the underlying MARC data. They 
would be used as "pointers" for the expansion process. E.g. when there 
is an authorized string "Tolstoy, Leo, graf, 1828-1910", this tells the 
algorithm to expand it with all the variant names from the authority 
record ("Tolstoi, Lew", "Tolstoj, Lav Nikolajević" a.s.o.).


I'm sorry if I've got carried away a bit... But I've so often seen the 
look of shock and disbelief in the eyes of my students when I 
demonstrate a keyword search for e.g. the odes of Horace in the LC 
catalog, using a variant name like the Latin "Horatius". This inevitably 
leads to zero hits and the funny notice "Please note: The Library of 
Congress does not keep a copy of every title ever published." The 
students, of course, are used of getting the same number of hits, 
regardless of whether they use the preferred or a variant name in a 
keyword search, as it is standard in German catalogs.


As somebody who hasn't grown up with the Anglo-American way of 
cataloguing, when I look at it from the outside I am both awed and 
dismayed. I am awed because you take so much more effort, and include so 
much more information in your cataloguing data than we do. To take just 
one example: According to the German cataloguing code only the first 
editor gets an access point, whereas it's up to three in AACR2. So, I am 
very favourably impressed by the richness of Anglo-American cataloguing 
data, and I often wish we had the same attitude towards cataloguing here.


On the other hand, I am sometimes a bit dismayed when I look at the way 
this great data is stored, handled and processed. Compared with

Re: [RDA-L] "Work manifested" in new RDA examples

[James Weinheimer]

On 06/06/2012 22:16, Brenndorfer, Thomas wrote:

The FRBR user tasks are like breathing and eating, and, no, a user
doesn't have to have a full understanding of the bibliographic universe
for them to pertain.


I believe that this may be the most amazing statement I have read in all
of my studies on cataloging and of all the messages on all the lists I
have read. The FRBR user tasks are like eating and breathing?! I confess
that I have seen people stop breathing, and they have died. I have not
personally seen anyone stop eating and die (although I recently saw the
movie "Hunger"), but I believe it has been firmly demonstrated that if
someone did stop eating they would die.

Maintaining that the FRBR user tasks are as natural as eating and
breathing of course, flies in the experience of each person each and
every time they use a full text search engine. Search "call me ishmael"
in Google and see what you get. Search "the book about the russian who
killed an old pawn broker". The examples are endless.

The fact is: the FRBR user tasks describe how to work a specific tool
designed in the 19th century, that is, the library catalog. This should
not be extended to saying that these are the tasks (most) users want to
do. There is no evidence for that at all, and in fact, there is a lot of
evidence to the contrary.

So long as the fiction is adhered to that FRBR provides what the
majority of the users want, it will be very difficult for libraries to
move ahead. We must approach matters in a much less dogmatic way, and be
more scientific in our reasoning.
-- 
*James Weinheimer* weinheimer.ji...@gmail.com
*First Thus* http://catalogingmatters.blogspot.com/
*Cooperative Cataloging Rules*
http://sites.google.com/site/opencatalogingrules/
*Cataloging Matters Podcasts*
http://blog.jweinheimer.net/p/cataloging-matters-podcasts.html

Re: [RDA-L] "Work manifested" in new RDA examples

[Brenndorfer, Thomas]

The FRBR user tasks are like breathing and eating, and, no, a user doesn't have 
to have a full understanding of the bibliographic universe for them to pertain.

There's also a point from project management -- avoid scope creep! RDA's scope 
is only translating AACR2 (and some planned updates) into an 
entity-relationship model. There are placeholders for subject entities and 
their relationship designators, and there is extensibility built into the 
vocabulary lists in places. Getting all that in place is a significant 
undertaking but it's nowhere declared as an endpoint.

For example, the descriptive work relationships (J.2.3) offer hints at 
expansion when subject treatment of works will be added ("review of (work)", 
"critique of (work)"). There will be a natural continuum to the relationships 
between entities when subject entities are added into RDA. For example, works 
about persons or corporate may be designated more specifically than generic 
subject relationships (for example, there could separate designators for 
biography vs autobiography for the WORK <> PERSON subject relationship). There 
is the possibility of using subject-related controlled terms in other elements, 
and this already occurs with RDA Chapter 16 on Places (which only has the AACR2 
information about Places, not the full set of instructions where places are 
also treated as subjects). The instructions for Place values are in Chapter 16 
(a chapter in the subject area of RDA), but the values can be used in other 
elements in RDA.

Other functions like readers advisory can be added to catalogs. We integrated 
NoveList into the catalog which helps with some of the needs you've identified. 
We're just beginning with user-supplied data services and social networking. 
We've added extensive links to external resources through services like 
Syndetics-- but these are stymied by the lack of good FRBRization. One record 
may have lots of links; another record for the same work may be missing those 
very useful links (not unusual in a collection built out of American, Canadian 
and some British sources).

A user with very little knowledge may be pleased or disappointed with the 
results -- but catalogers will often know why a user may become disappointed, 
and it's generally because of a lack of good data (or misses in keyword 
searches), a lack of elements to filter, limit and sort on (or even not 
realizing that browsing an arrangement of books classified by topic can help), 
or a lack of consistent relationships that point users off into pertinent 
directions, or a lack of clear displays with easy navigation and easy search 
and filter options, or a lack of records altogether (circulation goes up when 
records are added to the catalog, even records for e-books which are also found 
in their silo on a vendor's website).

Cataloging has always been more than a description of physical items, more than 
an inventory of widgets. It's always been about ways of connecting content, of 
showing users all works by an author or on a subject or all editions or 
versions of a work (regardless of how that content has been conveyed 
physically). That there are more and better ways of doing those things doesn't 
negate the effort done already-- rather it's a matter of taking a very good 
idea (essentially going beyond the physical item and distinguishing between 
content and carrier) and building upon it.

Thomas Brenndorfer
Guelph Public Library



From: Resource Description and Access / Resource Description and Access 
[RDA-L@LISTSERV.LAC-BAC.GC.CA] On Behalf Of Karen Coyle [li...@kcoyle.net]
Sent: June-06-12 1:47 PM
To: RDA-L@LISTSERV.LAC-BAC.GC.CA
Subject: Re: [RDA-L] "Work manifested" in new RDA examples

On 6/6/12 10:09 AM, Brenndorfer, Thomas wrote:
> But that's the Select user task at play in this discussion. Users can select 
> from amongst a result set, or they can pre-filter search results with limits, 
> or algorithms can produce relevancy ranked results. Current catalogs have all 
> kinds of responses.
...
>
> The latter point is important. A user may know of a work, but may not know 
> that there was another book written about the work (a subject relationship). 
> In order to FIND that other work, a relationship needs to be established and 
> this needs to be part of what is presented to the user. The user may not be 
> aware of any search criteria to use to find the other book-- part of the 
> purpose of the catalog is to show the user the relationships between 
> resources and allow them to explore or navigate the terrain (and EXPLORE is a 
> FRSAD user task).

So here's where we differ. *My* user isn't very knowledgeable. He
doesn't really know what he is looking for, and he definitely does not
have a particular work or edition in mind. He&

Re: [RDA-L] "Work manifested" in new RDA examples

[Karen Coyle]

On 6/6/12 10:09 AM, Brenndorfer, Thomas wrote:

But that's the Select user task at play in this discussion. Users can select 
from amongst a result set, or they can pre-filter search results with limits, 
or algorithms can produce relevancy ranked results. Current catalogs have all 
kinds of responses.

...


The latter point is important. A user may know of a work, but may not know that 
there was another book written about the work (a subject relationship). In 
order to FIND that other work, a relationship needs to be established and this 
needs to be part of what is presented to the user. The user may not be aware of 
any search criteria to use to find the other book-- part of the purpose of the 
catalog is to show the user the relationships between resources and allow them 
to explore or navigate the terrain (and EXPLORE is a FRSAD user task).


So here's where we differ. *My* user isn't very knowledgeable. He 
doesn't really know what he is looking for, and he definitely does not 
have a particular work or edition in mind. He's looking for some 
information, or a good read, or more on a topic; a good first book on 
astronomy, a book for someone who loved Harry Potter. If your user comes 
to the library with full knowledge of the bibliographic universe, then 
the FRBR user tasks pertain. But if your user comes, like so many do, to 
discover, then the catalog isn't much help. A bibliographic listing, 
even if the user arrives at a relevant retrieved set, does not answer 
the needs I just posed.


If we view the catalog as an inventory for users looking for specific 
works, editions or manifestations, then we can say that it fulfills that 
need. However, I think that need is a minority need among users -- not 
just library users, because we have trained them to only come to the 
library catalog when they are seeking something specific, but people 
seeking information/works/etc., most of whom do that searching on the 
Internet but who could possibly be served by library materials if they 
could discover them.


If you maintain that is not the role of the library catalog, then we 
need to review our services, what they cost, and the benefit that all 
users derive. I honestly think that the "bang for the buck" of the 
library catalog would not turn out to be justifiable except in some 
specific research libraries.


kc

p.s. "Explore" is a FRSAD task, but RDA specifically does not enter into 
subject access. As Michael Gorman made clear in his "AACR3? Not!" essay, 
cataloging is a description of a physical object. I have elsewhere 
called for more attention to subject access, but that is not within the 
RDA purview.






Thomas Brenndorfer
Guelph Public Library


From: Resource Description and Access / Resource Description and Access 
[RDA-L@LISTSERV.LAC-BAC.GC.CA] On Behalf Of Karen Coyle [li...@kcoyle.net]
Sent: June-06-12 11:36 AM
To: RDA-L@LISTSERV.LAC-BAC.GC.CA
Subject: Re: [RDA-L] "Work manifested" in new RDA examples

On 6/6/12 8:16 AM, Brenndorfer, Thomas wrote:

The users that benefit from seeing all the resources that embody particular 
works and expressions include those with roles in acquisition, preservation, 
and reference. The idea that it's OK to not necessarily find all the resources 
is an odd assertion in this discussion thread.

Thomas, I think the question is whether this is the only possible
retrieval result. There is a difference between someone who wants or
needs ALL and someone who wants or needs A. That difference is
exemplified in search engine results, which retrieve ALL but offer to
the user SOME by employing ranking, with the assumption (which I think
can be proven) that the user who wants ALL is in a small minority. ALL
is available, but is by no means the default.

One area where I think library catalogs are weak is that they seem to
have only one type of response, and that response is often the one
suitable for the minority of users.

kc


The name-title string is still the basis behind how catalogs functions. I don't 
think they're ideal, and whether they're adequate is often dependent on how 
well a system can handle them.

As a case in point, the first web-based catalog I used could have hyperlinks 
attached to name-title headings. That's great -- except the 1XX+24X fields 
would not be caught in this net, even though those fields mean exactly the same 
thing as the 7XX name-title heading-- an identifier for a work. This was less 
than adequate and would mean anyone who clicked the link would get some related 
works but not all of them, and in fact, genearlly not the main ones that the 
library held because those were represented with the preferred title 
overlapping the 245 title proper.

Thomas Brenndorfer
Guelph Public Library



From: Resource Description and Access / Resource Description a

Re: [RDA-L] "Work manifested" in new RDA examples

[Brenndorfer, Thomas]

But that's the Select user task at play in this discussion. Users can select 
from amongst a result set, or they can pre-filter search results with limits, 
or algorithms can produce relevancy ranked results. Current catalogs have all 
kinds of responses. But the backdrop still would have all the primary 
relationships established. It's not as if we wouldn't be setting those 
relationships in anticipation that the only search result forced on users is to 
display all of them.

The holdings screen is a good example of how flexibility can be built in. There 
can be pre-filters on availability (available copies only); there can be 
automatic sorts based on location (local physical branch copies displayed 
first), there can other filters and sorts based upon other criteria. Or users 
can see ALL items and choose from among them because that logic is encoded from 
the ground up.

As for the RDA Chapter 17 objectives, the question is quite simple: does the 
resource contain the specific work or expression or not? Set the value. Encode 
and design search engines as one pleases.

It's the same principle for the authority controlled form of an author's name. 
This is so we can find ALL resources attached to the person within the library. 
A user can continue to find or select a resource (that ONE book) as needed, but 
that's based upon other criteria that's captured in elements and made available 
for displays or indexes or search engines. Without a convention that links the 
resources to the person in a consistent fashion, the resource stands or falls 
on its own -- cataloging imposes order on the resources.

Cutter's objectives continued where he does imply "all" books ...

2. To show what a library has
(D) by a given author
(E) on a given subject
(F) in a given kind of literature

3. To assist in the choice of a book
(G) as to its edition (bibliographically)
(H) as to its character (literary or topical)

The main differences today are the expansions on these terms: "what" and "book" 
are expanded into Group 1 entities; "author" is expanded into Group 2 entities; 
"subject" is expanded into Group 3 entities (which subjects can contain Group 1 
and Group 2 entities).

The latter point is important. A user may know of a work, but may not know that 
there was another book written about the work (a subject relationship). In 
order to FIND that other work, a relationship needs to be established and this 
needs to be part of what is presented to the user. The user may not be aware of 
any search criteria to use to find the other book-- part of the purpose of the 
catalog is to show the user the relationships between resources and allow them 
to explore or navigate the terrain (and EXPLORE is a FRSAD user task).


Thomas Brenndorfer
Guelph Public Library


From: Resource Description and Access / Resource Description and Access 
[RDA-L@LISTSERV.LAC-BAC.GC.CA] On Behalf Of Karen Coyle [li...@kcoyle.net]
Sent: June-06-12 11:36 AM
To: RDA-L@LISTSERV.LAC-BAC.GC.CA
Subject: Re: [RDA-L] "Work manifested" in new RDA examples

On 6/6/12 8:16 AM, Brenndorfer, Thomas wrote:
>
> The users that benefit from seeing all the resources that embody particular 
> works and expressions include those with roles in acquisition, preservation, 
> and reference. The idea that it's OK to not necessarily find all the 
> resources is an odd assertion in this discussion thread.

Thomas, I think the question is whether this is the only possible
retrieval result. There is a difference between someone who wants or
needs ALL and someone who wants or needs A. That difference is
exemplified in search engine results, which retrieve ALL but offer to
the user SOME by employing ranking, with the assumption (which I think
can be proven) that the user who wants ALL is in a small minority. ALL
is available, but is by no means the default.

One area where I think library catalogs are weak is that they seem to
have only one type of response, and that response is often the one
suitable for the minority of users.

kc

>
> The name-title string is still the basis behind how catalogs functions. I 
> don't think they're ideal, and whether they're adequate is often dependent on 
> how well a system can handle them.
>
> As a case in point, the first web-based catalog I used could have hyperlinks 
> attached to name-title headings. That's great -- except the 1XX+24X fields 
> would not be caught in this net, even though those fields mean exactly the 
> same thing as the 7XX name-title heading-- an identifier for a work. This was 
> less than adequate and would mean anyone who clicked the link would get some 
> related works but not all of them, and in fact, genearlly not the main ones 
> that the library held because those were represented with the pre

Re: [RDA-L] "Work manifested" in new RDA examples

[Karen Coyle]

On 6/6/12 8:16 AM, Brenndorfer, Thomas wrote:


The users that benefit from seeing all the resources that embody particular 
works and expressions include those with roles in acquisition, preservation, 
and reference. The idea that it's OK to not necessarily find all the resources 
is an odd assertion in this discussion thread.


Thomas, I think the question is whether this is the only possible 
retrieval result. There is a difference between someone who wants or 
needs ALL and someone who wants or needs A. That difference is 
exemplified in search engine results, which retrieve ALL but offer to 
the user SOME by employing ranking, with the assumption (which I think 
can be proven) that the user who wants ALL is in a small minority. ALL 
is available, but is by no means the default.


One area where I think library catalogs are weak is that they seem to 
have only one type of response, and that response is often the one 
suitable for the minority of users.


kc



The name-title string is still the basis behind how catalogs functions. I don't 
think they're ideal, and whether they're adequate is often dependent on how 
well a system can handle them.

As a case in point, the first web-based catalog I used could have hyperlinks 
attached to name-title headings. That's great -- except the 1XX+24X fields 
would not be caught in this net, even though those fields mean exactly the same 
thing as the 7XX name-title heading-- an identifier for a work. This was less 
than adequate and would mean anyone who clicked the link would get some related 
works but not all of them, and in fact, genearlly not the main ones that the 
library held because those were represented with the preferred title 
overlapping the 245 title proper.

Thomas Brenndorfer
Guelph Public Library



From: Resource Description and Access / Resource Description and Access 
[RDA-L@LISTSERV.LAC-BAC.GC.CA] On Behalf Of Heidrun Wiesenmüller 
[wiesenmuel...@hdm-stuttgart.de]
Sent: June-06-12 1:51 AM
To: RDA-L@LISTSERV.LAC-BAC.GC.CA
Subject: Re: [RDA-L] "Work manifested" in new RDA examples

Thomas said:


The Find user task needs to be satisfied. In card catalog conventions, the main entry 
heading collocates related works. Using some sort of (standardized) method for the value 
of the "Work manifested" means that other works can specify something that will 
link back to the work in this mix of data. The objective in RDA 17.2 is:

"Find>>all<<   resources that embody a particular work or expression" -- this 
implies some convention is needed beyond a set of loosely related elements like Creator and Title 
proper.

I very much doubt that having a name-title string in the data is an
adequate tool to satisfy this user task, at least unless there are
additional mechanisms in place.

Somebody who wants to "find _all_ resources that embody a particular
work" (let's leave out the expression level for the moment), certainly
would have a right to expect the following possibilities in order to get
there:
- keyword searching
- using any name (preferred or variant) for the first creator
- if there is more than one creator: searching for one of the other
creators instead of the first creator, again using any name (preferred
or variant)
- using any title for the work (not only the uniform title, but also any
other title under which it has been published, e.g. the title of a
translation)

In a world of composite descriptions and current catalog technology, I
can think of three approaches to achieve this:

1. Linked authority records:
Every title record would have to be linked to an authority record for
the work.

2. Expansion of title records for use with search engine technology:
Every title record would have to be expanded with the necessary
information (especially variant names for creators and variant titles
for the work). This could then be indexed in a catalog based on search
engine technology.

3. Work clustering algorithms:
In a first step, only _one_ manifestation of the work in question has to
be found (it doesn't matter which). In a second step, all manifestations
belonging to the same work are retrieved by making use of a work
clustering algorithm.

Method 3 may be especially interesting. In German catalogs, which
already have links to authority records for persons and corporate bodies
(which means that variant names can be used for searching), it should be
easy to retrieve at least _one_ manifestation of a certain work, even if
a variant title for the work is used (provided the catalog is of a
certain size and also includes a fair sample of material in different
languages). Also, there are already implementations of work clustering
algorithms which work reasonably well. For instance, in some Primo
catalogs, other manifestations of the same work are automatically
retrieved and can be displayed by clicking on a button. Of cours

Re: [RDA-L] "Work manifested" in new RDA examples

[Brenndorfer, Thomas]

I think there's a different aspect of the Find user task involved here.

For example, if one is presented with a manifestation, the user task is to Find 
all items that exemplify that manifestation. One doesn't retrace steps and do 
keyword searches and browse searches hoping that some new result set can find 
all the related items attached to one manifestation. Rather, one is presented 
immediately with all the items because a convention for a relationship element 
is in place that links a manifestation to all the items. Essentially, catalogs 
work that way now-- with bibliographic records displaying above or before all 
of the holdings on a screen.

The users that benefit from seeing all the resources that embody particular 
works and expressions include those with roles in acquisition, preservation, 
and reference. The idea that it's OK to not necessarily find all the resources 
is an odd assertion in this discussion thread.

The name-title string is still the basis behind how catalogs functions. I don't 
think they're ideal, and whether they're adequate is often dependent on how 
well a system can handle them.

As a case in point, the first web-based catalog I used could have hyperlinks 
attached to name-title headings. That's great -- except the 1XX+24X fields 
would not be caught in this net, even though those fields mean exactly the same 
thing as the 7XX name-title heading-- an identifier for a work. This was less 
than adequate and would mean anyone who clicked the link would get some related 
works but not all of them, and in fact, genearlly not the main ones that the 
library held because those were represented with the preferred title 
overlapping the 245 title proper.

Thomas Brenndorfer
Guelph Public Library



From: Resource Description and Access / Resource Description and Access 
[RDA-L@LISTSERV.LAC-BAC.GC.CA] On Behalf Of Heidrun Wiesenmüller 
[wiesenmuel...@hdm-stuttgart.de]
Sent: June-06-12 1:51 AM
To: RDA-L@LISTSERV.LAC-BAC.GC.CA
Subject: Re: [RDA-L] "Work manifested" in new RDA examples

Thomas said:

>> The Find user task needs to be satisfied. In card catalog conventions, the 
>> main entry heading collocates related works. Using some sort of 
>> (standardized) method for the value of the "Work manifested" means that 
>> other works can specify something that will link back to the work in this 
>> mix of data. The objective in RDA 17.2 is:
>>
>> "Find>>all<<  resources that embody a particular work or expression" -- this 
>> implies some convention is needed beyond a set of loosely related elements 
>> like Creator and Title proper.

I very much doubt that having a name-title string in the data is an
adequate tool to satisfy this user task, at least unless there are
additional mechanisms in place.

Somebody who wants to "find _all_ resources that embody a particular
work" (let's leave out the expression level for the moment), certainly
would have a right to expect the following possibilities in order to get
there:
- keyword searching
- using any name (preferred or variant) for the first creator
- if there is more than one creator: searching for one of the other
creators instead of the first creator, again using any name (preferred
or variant)
- using any title for the work (not only the uniform title, but also any
other title under which it has been published, e.g. the title of a
translation)

In a world of composite descriptions and current catalog technology, I
can think of three approaches to achieve this:

1. Linked authority records:
Every title record would have to be linked to an authority record for
the work.

2. Expansion of title records for use with search engine technology:
Every title record would have to be expanded with the necessary
information (especially variant names for creators and variant titles
for the work). This could then be indexed in a catalog based on search
engine technology.

3. Work clustering algorithms:
In a first step, only _one_ manifestation of the work in question has to
be found (it doesn't matter which). In a second step, all manifestations
belonging to the same work are retrieved by making use of a work
clustering algorithm.

Method 3 may be especially interesting. In German catalogs, which
already have links to authority records for persons and corporate bodies
(which means that variant names can be used for searching), it should be
easy to retrieve at least _one_ manifestation of a certain work, even if
a variant title for the work is used (provided the catalog is of a
certain size and also includes a fair sample of material in different
languages). Also, there are already implementations of work clustering
algorithms which work reasonably well. For instance, in some Primo
catalogs, other manifestations of the same work are automatically
retrieved a

Re: [RDA-L] Mini Tutorial: Keeping order in RDF and ISO Common Logic/IKL (was Re: [RDA-L] "Work manifested" in new RDA examples)

[James Weinheimer]

On 06/06/2012 02:43, Simon Spero wrote:*
*
> In situations where only some authors are given numeric rank, and the
> rest are ordered by some other principal (e.g. lexicographic order, or
> no order specified), we can just state the constraints on authorship
> are, and leave the ordering to be determined by the computer.  We
> could then indicate that JohnSmith was principal investigator; that
> no-one goes behind Golgo 13, and the relative contributions of all
> authors,  then calculate appropriately ordered lists of authors based
> on context (which might be that of the query, or that of the work, or
> some other set of rules.  
>
> This is where the advantages of representing data as logical
> propositions, rather than as strings should become immediately obvious
> to anyone who has ever done work on  scientometrics.   Also, many
> people may be disappointed to learn that their college courses in
> philosophy might turn out to be of practical use.  
>
> It should be clear why no one should reasonably expect catalogers to
> enter this sort of information directly.  It should also be clear that
> the Rules for a Knowledge Based need to be developed with direct input
> from Subject Matter Experts  who understand the  theory behind the
> practice.  Most important of all, it ought to be obvious that any new
> Bibliographic Framework needs to consider all the changes to work
> flows and practice that can be helped or hindered by different
> choices, and which cost/benefit tradeoffs need to be made.   


A couple of points here. First, if there is an order imposed, it should
possibly be based on the manifestation instead of on the work. I have
seen author order moved around on different manifestations and it should
probably not constitute a new work.

But second, the question should not be "It should be clear why no one
should reasonably expect catalogers to enter this sort of information
directly" but rather, what the catalog can actually provide. Since there
are literally millions of records that do not have the t.p. order in the
encoding--it is only in the statement of responsibility--any search that
utilizes that limits to "order on t.p." (or whatever) the result will
necessarily be limited only to the set of records that have that
information, i.e. a tiny, tiny percentage. This is similar to the
earlier thread on "Card catalogue lessons" where there are unavoidable
(and probably insurmountable) practical issues with adding the relator
codes. Sure, you can do it, but it doesn't solve anything for the
*user.* Here is one of my postings.
http://blog.jweinheimer.net/2012/03/re-rda-l-card-catalogue-lessons_6269.html

If we were building a catalog from scratch, I would agree that almost
anything can be done. Or if we were dealing with a corporate database or
almost any other type of database except a library catalog, we could
perhaps get away by just archiving all the old records and start a brand
new database, but the fact is, the greatest value that catalogers have
now is precisely this huge database that has been built up over many,
many years by our predecessors. Libraries do not have the same options
as businesses that often consider anything over 5 or 10 years old is
semi-obsolete information and less valuable. Libraries are different in
this way.

So, the first thing that someone who wanted to do scientometric research
using library catalog data would have to understand is: it *cannot*
work. Why? Because that information has never been input. *Any* results
they got would be fatally tainted, just as I mentioned in the previous
thread, searching for Mary Pickford *as a film producer* will retrieve
zero, which would be a false result because you can find her without
limiting to film producers. How can you possibly explain that away?

If there were the necessary funding in place to pay people to update the
information in the records that already exist, that might be another
factor but I have heard of nothing like this. It would be a tremendous
waste of money to do so anyway when so much needs to be done.

I believe we are in a very delicate time right now. Libraries should be
very careful to avoid setting themselves up for failure.

-- 
*James Weinheimer* weinheimer.ji...@gmail.com
*First Thus* http://catalogingmatters.blogspot.com/
*Cooperative Cataloging Rules*
http://sites.google.com/site/opencatalogingrules/
*Cataloging Matters Podcasts*
http://blog.jweinheimer.net/p/cataloging-matters-podcasts.html

Re: [RDA-L] Mini Tutorial: Keeping order in RDF and ISO Common Logic/IKL (was Re: [RDA-L] "Work manifested" in new RDA examples)

[Heidrun Wiesenmüller]

Many thanks to Simon for this very useful roundup. It's good to be 
assured that there are ways of coping with ordered values in the 
representation languages.


So now we "only" need to adjust RDA. I still wonder whether this 
apparent gap in the code (unless I've missed something important) was a 
deliberate choice?


By the way, I checked the examples for more than one creator in RDA 
19.2.1.3. Interestingly, the access points are always listed in the 
order in which the correspondent persons appear in the statement of 
responsibility - but that doesn't help, of course. A striking example 
for the problems we'll have without a possibility to mark different 
levels of responsibility is this one:


Beyard, Michael D.
Braun, Raymond E.
McLaughlin, Herbert
Phillips, Patrick L.
Rubin, Michael S.
Bald, Andre
Fader, Steven, 1951--
Jerschow, Oliver
Lassar, Terry J.
Mulvihill, David A.
Takesuye, David
Authorized access points representing the creators for: Developing 
retail entertainment destinations / principal authors, Michael D. 
Beyard, Raymond E. Braun, Herbert McLaughlin, Patrick L. Phillips, 
Michael S. Rubin ; contributing authors, Andre Bald, Steven Fader, 
Oliver Jerschow, Terry Lassar, David Mulvihill, David Takesuye


I've also looked again at the list of relationship designators for 
creators (I.2.1), but couldn't find anything suitable. There is, 
however, an option to introduce new relationship designators: "If none 
of the terms listed in this appendix is appropriate or sufficiently 
specific, use a term indicating the nature of the relationship as 
concisely as possible." (I.1). But I don't believe this applies to 
something like the missing "rank" aspect.


Heidrun



Am 06.06.2012 02:43, schrieb Simon Spero:
On Tue, Jun 5, 2012 at 11:53 AM, Karen Coyle > wrote:


Keeping an exact order is less intuitive in RDF. I'm not sure how
that would be done.

This would be good time to try and go over  some of the ways that one 
can represent this kind of ordered  values  using some different types 
of knowledge representation languages.


*Introduction*

Instead of just focusing on the RDF, I'll also look at some related 
languages for networked knowledge representation (KR) - primarily ISO 
Common Logic and IKL (with maybe a little CyCL).   These languages use 
parentheses to mark the beginning and end of expressions. The first 
thing inside the parentheses is the predicate.  Thus, for example,  to 
say that   Gene loves Jezebel one would write:


(loves Gene Jezebel)

In RDF/XML this corresponds to"




(authors work1 JohnSmith FredBloggs PaulErdos Golgo13)


In RDF, predicates can only have two arguments (these arguments, 
together with the predicate name, are the three parts of the triple). 
 However, the various syntaxes for RDF have special support for 
handling lists or sets of arguments.


In RDF/XML we can build a list using the "Collection" syntax:











This states that work1 has a value for authors that is a list of four 
names.


However, because RDF only traffics in triples, this notation requires 
some transformation.  What happens is that the contents of the 
"Collection" element is used to build an explicit rdf:List object.   
 For details see Appendix 1.


The drawback of using a single assertion to maintain the order is that 
it becomes much harder to work with the data, as we are no longer 
making statements about the relationship between an individual  author 
and a specific work


*Approach #2: Use multiple assertions, with the rank of the author 
included. *


This approach is very simple to use in Common Logic et al.  Since we 
can use predicates with more than two arguments, we can define an 
author predicate that takes as arguments a work, an author, and the 
rank of this author for this work.  For example:


(author work1 JohnSmith 1)
(author work1 FredBloggs 2)
(author work1 PaulErdos 3)
(author work1 Golgo13 4)

In RDF the situation is slightly more complicated, since we can only 
use predicates with two arguments. However, the situation is not too 
bad; we just need to create an extra object for each value;


_:w1a1 :author <#JohnSmith> .
_:w1a1 :rank "1" .
_:w1a2 :author <#FredBloggs> .
_:w1a2 :rank "2" .
_:w1a3 :author <#PaulErdos> .
_:w1a3 :rank "3" .
_:w1a4 :author <#Golgo13> .
_:w1a4 :rank "4" .
<#work1> :rankedAuthor _:w1a1 .
<#work1> :rankedAuthor _:w1a2 .
<#work1> :rankedAuthor _:w1a3 .
<#work1> :rankedAuthor _:w1a4 .

We can use a feature of OWL 2 called Property Role Chains to associate 
the value of author from the rankedAuthor objects  without having to 
explicitly look at the rankedAuthor objects.


It is important to note here that, unlike in the first example, we do 
not know that there is nobody behind Golgo 13. This can be handled in 
a few different ways.
In CyC, one can state that the complete extent of  pr

Re: [RDA-L] "Work manifested" in new RDA examples

[Heidrun Wiesenmüller]

Karen said:

One advantage of clustering, in my view, is that bibliographic items 
can be clustered based on different criteria if desired. Thus 
communities that have a different view of Work or Expression from the 
*standard* RDA view can see the Work that meets their needs without 
having to re-catalog or to translate/crosswalk data. This seems more 
flexible than having just one definition of 
Work/Expression/Manifestation -- instead, it allows interoperability 
between different such views.


A very good point. For instance, a cluster could also be on the "super 
work" level and include, e.g., film adaptations as well - or, as you 
say, it could follow a somewhat modified FRBR view according to special 
needs of a community.


Users will also often want to look at only a segment of all expressions, 
e.g. all audio books in a certain language. A very good way of 
presenting this is a drill-down menu as we can see it in WorldCat. I 
also liked the implementation within FictionFinder (by the way: is 
FictionFinder _ever_ going online again??). Actually, if there is an 
option to dynamically cluster manifestations according to different 
criteria and individual needs, you might no longer need the entity 
"expression" at all. I believe this was part of the reasoning behind the 
presentation in FictionFinder.


Heidrun

--
-
Prof. Heidrun Wiesenmueller M.A.
Stuttgart Media University
Faculty of Information and Communication
Wolframstrasse 32, 70191 Stuttgart, Germany
www.hdm-stuttgart.de/bi

Re: [RDA-L] "Work manifested" in new RDA examples

[Karen Coyle]

On 6/5/12 10:51 PM, Heidrun Wiesenmüller wrote:

Thomas said:

The Find user task needs to be satisfied. In card catalog 
conventions, the main entry heading collocates related works. Using 
some sort of (standardized) method for the value of the "Work 
manifested" means that other works can specify something that will 
link back to the work in this mix of data. The objective in RDA 17.2 
is:


"Find>>all<<  resources that embody a particular work or expression" 
-- this implies some convention is needed beyond a set of loosely 
related elements like Creator and Title proper.


I very much doubt that having a name-title string in the data is an 
adequate tool to satisfy this user task, at least unless there are 
additional mechanisms in place.


I agree. I also wonder about the "find all" and concur with your 
conclusion below that most people looking for a work want to find A copy 
of that work, not ALL copies of the work. Note that Cutter's famed user 
tasks were worded like:


"1. To enable a person to find a book of which either
  (A) the author
  (B) the title
  (C) the subject ... is known"

Note that he says "a book" not "all books," although this could just be 
a turn of phrase on his part. Yet, headings in his word serve not to 
retrieve but to "collocate" -- that is to put the entries near each 
other in location. There is no expectation that the user will (or must) 
view every card before making a selection, and there is no concept of 
"find all," as far as I can see. That concept seems to have come about 
with retrieval, and retrieval depends on concepts introduced by the 
computer.



3. Work clustering algorithms:
In a first step, only _one_ manifestation of the work in question has 
to be found (it doesn't matter which). In a second step, all 
manifestations belonging to the same work are retrieved by making use 
of a work clustering algorithm.


I have recently been thinking about Work as a cluster rather than a 
*thing*. It may not be analogous, but my mental model is that of VIAF, 
where authority records are clustered such that the cluster represents a 
named person or corporate body, etc., in spite of minor differences in 
cataloging practices. The clustering does not change the content of the 
clustered records, which to me is an important elements.


I haven't figured out where Expression fits into this model, but it 
makes sense to me that a Work is a cluster or set of all of its 
Expressions/Manifestations; and that a Work does not exist unless there 
is at least one Expression/Manifestation/(Item?).


I did a blog post with the beginnings of this thought in 2009:
  http://kcoyle.blogspot.com/2009/08/what-is-frbr-work.html

To me, this bottom-up approach makes more sense than a top-down one 
because we only really encounter Items in real life -- the rest is 
abstract. With you, I wonder if WEM isn't something that we interpret 
from bibliographic data, assuming that the data contains appropriate 
elements. Given a large corpus of bibliographic data, I would think that 
such clustering could be nearly as accurate as would be created by human 
catalogers, and would be much more efficient in terms of time.


One advantage of clustering, in my view, is that bibliographic items can 
be clustered based on different criteria if desired. Thus communities 
that have a different view of Work or Expression from the *standard* RDA 
view can see the Work that meets their needs without having to 
re-catalog or to translate/crosswalk data. This seems more flexible than 
having just one definition of Work/Expression/Manifestation -- instead, 
it allows interoperability between different such views.


kc



Method 3 may be especially interesting. In German catalogs, which 
already have links to authority records for persons and corporate 
bodies (which means that variant names can be used for searching), it 
should be easy to retrieve at least _one_ manifestation of a certain 
work, even if a variant title for the work is used (provided the 
catalog is of a certain size and also includes a fair sample of 
material in different languages). Also, there are already 
implementations of work clustering algorithms which work reasonably 
well. For instance, in some Primo catalogs, other manifestations of 
the same work are automatically retrieved and can be displayed by 
clicking on a button. Of course, we also know the "view all editions 
and formats" link from WorldCat.


I believe that ideas like this are one of the reasons for the German 
decision to implement RDA in scenario 2 instead of aiming at scenario 
1. It is felt that FRBRization can be achieved by technical measures 
and be shown on a surface level (only "virtually", as it were), 
without having to change too much in the underlying data structures 
itself.


Having to create an authority record for _every_ work, as it would be 
necessary for method 1 (and perhaps also for method 2, as the work 
information obviously must come from somewhere)

Re: [RDA-L] "Work manifested" in new RDA examples

[Heidrun Wiesenmüller]

Thomas said:


The Find user task needs to be satisfied. In card catalog conventions, the main entry 
heading collocates related works. Using some sort of (standardized) method for the value 
of the "Work manifested" means that other works can specify something that will 
link back to the work in this mix of data. The objective in RDA 17.2 is:

"Find>>all<<  resources that embody a particular work or expression" -- this 
implies some convention is needed beyond a set of loosely related elements like Creator and Title 
proper.


I very much doubt that having a name-title string in the data is an 
adequate tool to satisfy this user task, at least unless there are 
additional mechanisms in place.


Somebody who wants to "find _all_ resources that embody a particular 
work" (let's leave out the expression level for the moment), certainly 
would have a right to expect the following possibilities in order to get 
there:

- keyword searching
- using any name (preferred or variant) for the first creator
- if there is more than one creator: searching for one of the other 
creators instead of the first creator, again using any name (preferred 
or variant)
- using any title for the work (not only the uniform title, but also any 
other title under which it has been published, e.g. the title of a 
translation)


In a world of composite descriptions and current catalog technology, I 
can think of three approaches to achieve this:


1. Linked authority records:
Every title record would have to be linked to an authority record for 
the work.


2. Expansion of title records for use with search engine technology:
Every title record would have to be expanded with the necessary 
information (especially variant names for creators and variant titles 
for the work). This could then be indexed in a catalog based on search 
engine technology.


3. Work clustering algorithms:
In a first step, only _one_ manifestation of the work in question has to 
be found (it doesn't matter which). In a second step, all manifestations 
belonging to the same work are retrieved by making use of a work 
clustering algorithm.


Method 3 may be especially interesting. In German catalogs, which 
already have links to authority records for persons and corporate bodies 
(which means that variant names can be used for searching), it should be 
easy to retrieve at least _one_ manifestation of a certain work, even if 
a variant title for the work is used (provided the catalog is of a 
certain size and also includes a fair sample of material in different 
languages). Also, there are already implementations of work clustering 
algorithms which work reasonably well. For instance, in some Primo 
catalogs, other manifestations of the same work are automatically 
retrieved and can be displayed by clicking on a button. Of course, we 
also know the "view all editions and formats" link from WorldCat.


I believe that ideas like this are one of the reasons for the German 
decision to implement RDA in scenario 2 instead of aiming at scenario 1. 
It is felt that FRBRization can be achieved by technical measures and be 
shown on a surface level (only "virtually", as it were), without having 
to change too much in the underlying data structures itself.


Having to create an authority record for _every_ work, as it would be 
necessary for method 1 (and perhaps also for method 2, as the work 
information obviously must come from somewhere), seems to be a daunting 
task. But now I come to think about it, I wonder: Wouldn't it be 
possible to generate work authority records automatically? Based on work 
clustering, we could e.g. collect all variant titles for a work from the 
various manifestations. Maybe this is a direction worth looking at.


I'm sure there are more methods than the three I've mentioned. And of 
course, linked data, could also play a part (one possibility of handling 
variant personal names could be a tool which makes use of VIAF in RDF, 
for example).


Heidrun

--
-
Prof. Heidrun Wiesenmueller M.A.
Stuttgart Media University
Faculty of Information and Communication
Wolframstrasse 32, 70191 Stuttgart, Germany
www.hdm-stuttgart.de/bi

[RDA-L] Mini Tutorial: Keeping order in RDF and ISO Common Logic/IKL (was Re: [RDA-L] "Work manifested" in new RDA examples)

[Simon Spero]

On Tue, Jun 5, 2012 at 11:53 AM, Karen Coyle  wrote:

Keeping an exact order is less intuitive in RDF. I'm not sure how that
> would be done.
>

This would be good time to try and go over  some of the ways that one can
represent this kind of ordered  values  using some different types of
knowledge representation languages.

*Introduction*

Instead of just focusing on the RDF, I'll also look at some related
languages for networked knowledge representation (KR) - primarily ISO
Common Logic and IKL (with maybe a little CyCL).   These languages use
parentheses to mark the beginning and end of expressions. The first thing
inside the parentheses is the predicate.  Thus, for example,  to say that
Gene loves Jezebel one would write:

(loves Gene Jezebel)

In RDF/XML this corresponds to"


   
   
  
  
  
  
   



This states that work1 has a value for authors that is a list of four
names.

However, because RDF only traffics in triples, this notation requires some
transformation.  What happens is that the contents of the "Collection"
element is used to build an explicit rdf:List object.For details see
Appendix 1.

The drawback of using a single assertion to maintain the order is that it
becomes much harder to work with the data, as we are no longer making
statements about the relationship between an individual  author and a
specific work

*Approach #2: Use multiple assertions, with the rank of the author
included. *

This approach is very simple to use in Common Logic et al.  Since we can
use predicates with more than two arguments, we can define an author
predicate that takes as arguments a work, an author, and the rank of this
author for this work.  For example:

(author work1 JohnSmith 1)
(author work1 FredBloggs 2)
(author work1 PaulErdos 3)
(author work1 Golgo13 4)

In RDF the situation is slightly more complicated, since we can only use
predicates with two arguments. However, the situation is not too bad; we
just need to create an extra object for each value;

_:w1a1 :author <#JohnSmith> .
_:w1a1 :rank "1" .
_:w1a2 :author <#FredBloggs> .
_:w1a2 :rank "2" .
_:w1a3 :author <#PaulErdos> .
_:w1a3 :rank "3" .
_:w1a4 :author <#Golgo13> .
_:w1a4 :rank "4" .
<#work1> :rankedAuthor _:w1a1 .
<#work1> :rankedAuthor _:w1a2 .
<#work1> :rankedAuthor _:w1a3 .
<#work1> :rankedAuthor _:w1a4 .


We can use a feature of OWL 2 called Property Role Chains to associate the
value of author from the rankedAuthor objects  without having to explicitly
look at the rankedAuthor objects.

It is important to note here that, unlike in the first example, we do not
know that there is nobody behind Golgo 13. This can be handled in a few
different ways.
In CyC, one can state that the complete extent of  predicate is known,
which means that if the system cannot infer that that there are any more
authors, it is can infer that there aren't.   This "World Closing" can also
be done at query time, using Negation as  Failure semantics (e.g. using the
"NOT EXISTS" filter in a SPARQL query.

We can also make explicit assertions; for example, in the CL family, we can
assert that there can for all works there can only be one author at each
rank, and that there for a specific work there is no author whose rank is
greater than 4.In IKL, CycL, and OWL, we can also state that the work1
is something that has exactly four values of author.

*Approach 3:  Use constraints and rules *

In situations where only some authors are given numeric rank, and the rest
are ordered by some other principal (e.g. lexicographic order, or no order
specified), we can just state the constraints on authorship are, and leave
the ordering to be determined by the computer.  We could then indicate that
JohnSmith was principal investigator; that no-one goes behind Golgo 13, and
the relative contributions of all authors,  then calculate appropriately
ordered lists of authors based on context (which might be that of the
query, or that of the work, or some other set of rules.

This is where the advantages of representing data as logical propositions,
rather than as strings should become immediately obvious to anyone who has
ever done work on  scientometrics.   Also, many people may
be disappointed to learn that their college courses in philosophy might
turn out to be of practical use.

It should be clear why no one should reasonably expect catalogers to enter
this sort of information directly.  It should also be clear that the Rules
for a Knowledge Based need to be developed with direct input from Subject
Matter Experts  who understand the  theory behind the practice.  Most
important of all, it ought to be obvious that any new Bibliographic
Framework needs to consider all the changes to work flows and practice that
can be helped or hindered by different choices, and which cost/benefit
tradeoffs need to be made.

*References: *

Information about ISO Common Logic and IKL, as well as relevant portions of
RDF can be found in Pat Hayes's guide at
http://www.ihmc

Re: [RDA-L] "Work manifested" in new RDA examples

[Karen Coyle]

On 6/5/12 4:54 AM, Heidrun Wiesenmüller wrote:

T

But I think this raises a very important point: RDA only has one 
(repeatable) element "creator". Indeed, one wonders why it's not 
possible to express the notion of the most important creator somehow. 
Wouldn't the obvious solution be a relationship designator?


In academic journal articles, order of the authors (of which there are 
often many) is highly significant. This is from the Wikipedia article on 
"Academic authorship"



   Order of authors in a list

Rules for the order of multiple authors in a list vary significantly 
between fields of research, but are generally consistent within a 
particular field.^[24] 
 
Some fields list authors in order of their degree of involvement in the 
work, with the most active contributors listed first; other fields, such 
as Mathematics, list them alphabetically.^[25] 
 
Biologists tend to place a principal investigator 
 (supervisor or lab 
head) last in an author list; organic chemists might put him or her 
first.^[18] 
 



Although listing authors in order of the involvement in the project 
seems straighforward, it often leads to conflict. A study in the 
Canadian Medical Association Journal found that more than two-thirds of 
919 corresponding authors disagreed with their coauthors regarding 
contributions of each author.^[26] 
 






That RDA cannot handle this will be interpreted by academic journal 
authors as not serving their needs. This however then becomes an area 
for extension of RDA for those situations and disciplines that have a 
need for more detail about the creator relationship to the work. 
Extension can happen within in RDA, or it can be separate but related to 
the RDA element.


From the Wikipedia description it seems to me that in some cases this 
might be satisfied with a role, as Heidrun suggests. Because it looks 
like different communities will be interested in different roles, what 
may be most appropriate are community-defined role designators.  The 
specific roles can all be linked such that:


xxx:primary author -- is a type of -- rda:creator
xxx:co-author -- is a type of -- rda:creator
rda:thesis advisor -- is a type of -- dc:collaborator
etc., with 'xxx' representing a namespace outside of RDA

Keeping an exact order is less intuitive in RDF. I'm not sure how that 
would be done. But it would be important to indicate that RDA is not a 
closed box but can be extended as needed. Linked data makes such 
extension possible.


kc




Bay the way, in the new German common authority file we use a code 
"aut1" to mark the first creator of a work, e.g.:


130 Buddenbrooks
500 [Link to authority control number for the record of "Mann, 
Thomas"]$4aut1


Come to think of it, this seems to be a general flaw in RDA: For 
instance, if there is more than one statement of responsibility, we're 
told to "record the statements in the order indicated by the sequence, 
layout, or typography of the source of information" (2.4.1.6). But how 
can this be done? As with creator, there is only one data element 
"statement of responsibility". So how can am I supposed to specify 
which is the first statement and which the second? RDA doesn't state 
this explicitly, but there seems to be an underlying presupposition 
here that in the encoding format it will somehow be possible to bring 
out the correct sequence. Yet, as a content standard, RDA is certainly 
incomplete here (and in similar cases elsewhere). If the information 
about sequence is important, RDA should provide a way of giving it.




But there are some new conventions that sweep away the often contorted way 
AACR2 handled two or more works within a resource.

Instead of having work 1 title in a 240 and work 2 title in an analytical 700 
name-title added entry, RDA has this idea of having the entities a little more 
clearly identified in consistent conventions:


100  $a Miller, Arthur, $d 1915-2005
240  $a Plays. $k Selections
245  $a Two plays / $c Arthur Miller.
505  $a The Archbishop’s ceiling -- The American clock.
700  $a Miller, Arthur, $d 1915-2005. $t Archbishop’s ceiling.
700  $a Miller, Arthur, $d 1915-2005. $t American clock.


So here the compilation is Work 1, the Archbishop's ceiling is Work 2, and 
American clock is Work 3.


This is a very interesting example, which also brings us back to the 
neverending problem of aggregate works. I agree that there are three 
works manifested here: The compilation itself (work 1) and - on a 
different level - the individual works (2 and 3). RDA says (17.8): "If 
more than on

Re: [RDA-L] "Work manifested" in new RDA examples

[Brenndorfer, Thomas]

>From: Resource Description and Access / Resource Description and Access 
>[mailto:RDA-L@LISTSERV.LAC-BAC.GC.CA] On >Behalf Of Heidrun Wiesenmüller
>Sent: June 5, 2012 7:55 AM
>To: RDA-L@LISTSERV.LAC-BAC.GC.CA
>Subject: Re: [RDA-L] "Work manifested" in new RDA examples

...
>>In RDA though, just pointing to a Creator element is not sufficient -- there 
>>is no order being specified if there >>is more than one Creator. The idea of 
>>a "first named" appears only in the construction of the authorized access 
>>>>point for the work, and that alone mimics the 100 + 245 construction and 
>>order of fields.

>Ah, I see what you mean. But still: Wouldn't it be rather odd to include the 
>data element "work manifested" in >record merely to make it possible to deduce 
>from this who the first creator is?


The Find user task needs to be satisfied. In card catalog conventions, the main 
entry heading collocates related works. Using some sort of (standardized) 
method for the value of the "Work manifested" means that other works can 
specify something that will link back to the work in this mix of data. The 
objective in RDA 17.2 is:

"Find >>all<< resources that embody a particular work or expression" -- this 
implies some convention is needed beyond a set of loosely related elements like 
Creator and Title proper.

A composite description is not efficient by comparison, as the burden is on the 
user to discern what relationships exist in the mix of data. Later on in RDA, 
one encounters "unstructured descriptions" as values for the Related Work 
element -- these provide eye-readable information to users but are not readily 
machine-processable.

But in turn one can argue that these are better than nothing, and in some cases 
it would be too complex or burdensome to provide more precise links to all the 
related entities. But that's where 'cataloguer's judgement' comes in -- one has 
to look at the FRBR user tasks to test if the needs of users are being met, and 
then decisions can be made to provide more precise data (and I would include 
adding data about repeatability and sequencing -- something that RDA does leave 
up to encoding schemes and policies).

Thomas Brenndorfer
Guelph Public Library

Re: [RDA-L] "Work manifested" in new RDA examples

[James Weinheimer]

On 05/06/2012 13:54, Heidrun Wiesenmüller wrote:

> Come to think of it, this seems to be a general flaw in RDA: For
> instance, if there is more than one statement of responsibility, we're
> told to "record the statements in the order indicated by the sequence,
> layout, or typography of the source of information" (2.4.1.6). But how
> can this be done? As with creator, there is only one data element
> "statement of responsibility". So how can am I supposed to specify
> which is the first statement and which the second? RDA doesn't state
> this explicitly, but there seems to be an underlying presupposition
> here that in the encoding format it will somehow be possible to bring
> out the correct sequence. Yet, as a content standard, RDA is certainly
> incomplete here (and in similar cases elsewhere). If the information
> about sequence is important, RDA should provide a way of giving it.


In ONIX, there is  within the  tag. See:
http://www.editeur.org/files/ONIX%203/ONIX_for_Books_Release3-0_docs+codes_Issue_17.zip,
open zip file, open the pdf file, and it is on p. 70.

-- 
*James Weinheimer* weinheimer.ji...@gmail.com
*First Thus* http://catalogingmatters.blogspot.com/
*Cooperative Cataloging Rules*
http://sites.google.com/site/opencatalogingrules/
*Cataloging Matters Podcasts*
http://blog.jweinheimer.net/p/cataloging-matters-podcasts.html

Re: [RDA-L] "Work manifested" in new RDA examples

[Heidrun Wiesenmüller]

Thomas,

thank you for this very instructive mail.




It is correct that one Creator element and one Title proper element can 
duplicate the Work Manifested element if the form used is the authorized access 
point for the work (name + title form), as opposed to an identifier (such as a 
URI).

But there can be multiple Creators for the one work...

Creator: Person K
Creator: Person R
Creator: Person Z

If the first name person on the resource is Person R, then the authorized 
access point is formed:

Person R. Preferred title.

Essentially, this is the AACR2 main entry rule, minus the Rule of Three.

In RDA though, just pointing to a Creator element is not sufficient -- there is no order 
being specified if there is more than one Creator. The idea of a "first named" 
appears only in the construction of the authorized access point for the work, and that 
alone mimics the 100 + 245 construction and order of fields.


Ah, I see what you mean. But still: Wouldn't it be rather odd to include 
the data element "work manifested" in record merely to make it possible 
to deduce from this who the first creator is? This is, by the way, only 
possible if "work manifested" is given by using the authorized access 
point for the work in the conventional way; you wouldn't get the 
information from an identifier in numerical form. What's more, the 
authorized access point for a work can also be given differently, 
without specifying the first creator: There is an option in RDA of 
contructing the access point for a collaborative work by including the 
authorized access points for _all_ creators (6.27.1.3, alternative).


But I think this raises a very important point: RDA only has one 
(repeatable) element "creator". Indeed, one wonders why it's not 
possible to express the notion of the most important creator somehow. 
Wouldn't the obvious solution be a relationship designator?


Bay the way, in the new German common authority file we use a code 
"aut1" to mark the first creator of a work, e.g.:


130 Buddenbrooks
500 [Link to authority control number for the record of "Mann, 
Thomas"]$4aut1


Come to think of it, this seems to be a general flaw in RDA: For 
instance, if there is more than one statement of responsibility, we're 
told to "record the statements in the order indicated by the sequence, 
layout, or typography of the source of information" (2.4.1.6). But how 
can this be done? As with creator, there is only one data element 
"statement of responsibility". So how can am I supposed to specify which 
is the first statement and which the second? RDA doesn't state this 
explicitly, but there seems to be an underlying presupposition here that 
in the encoding format it will somehow be possible to bring out the 
correct sequence. Yet, as a content standard, RDA is certainly 
incomplete here (and in similar cases elsewhere). If the information 
about sequence is important, RDA should provide a way of giving it.




But there are some new conventions that sweep away the often contorted way 
AACR2 handled two or more works within a resource.

Instead of having work 1 title in a 240 and work 2 title in an analytical 700 
name-title added entry, RDA has this idea of having the entities a little more 
clearly identified in consistent conventions:


100  $a Miller, Arthur, $d 1915-2005
240  $a Plays. $k Selections
245  $a Two plays / $c Arthur Miller.
505  $a The Archbishop’s ceiling -- The American clock.
700  $a Miller, Arthur, $d 1915-2005. $t Archbishop’s ceiling.
700  $a Miller, Arthur, $d 1915-2005. $t American clock.


So here the compilation is Work 1, the Archbishop's ceiling is Work 2, and 
American clock is Work 3.


This is a very interesting example, which also brings us back to the 
neverending problem of aggregate works. I agree that there are three 
works manifested here: The compilation itself (work 1) and - on a 
different level - the individual works (2 and 3). RDA says (17.8): "If 
more than one work is embodied in the manifestation, only the 
predominant or first-named work manifested is required" as a core 
element. Now, if you want to work out an RDA representation for this, 
similar to the JSC examples, which of the three works would you have to 
give as "work manifested"? As far as I know, LC's opinion is that it 
would be the first of the individual works. But personally, I think this 
is highly debatable.





But the ultimate point here is that these primary relationships were always 
implicit in traditional bibliographic records. The key to understanding RDA is 
that what was implicit is made explicit in such a way that the logic of what is 
happening in the resource is captured in the instructions-- but there is room 
for different conventions to carry that logic. One doesn't have to wait for a 
post-MARC environment to establish the primary relationships, but perhaps a 
post-MARC environment can be more efficient at processing and displaying those 
relationships.


I agree absolutely.

Still,

Re: [RDA-L] "Work manifested" in new RDA examples

[James Weinheimer]

On 05/06/2012 11:29, Heidrun Wiesenmüller wrote:

> We do lots of record exchange in Germany between various systems. In
> the exchange format, it's common to have both the heading in textual
> form and the national authority control number, but I'm fairly sure it
> would be no problem if only the control number were transported,
> without a text string. Whenever e.g. data from the German National
> Library is imported into the Southwestern German Library Network, I
> believe there is a procedure which automatically exchanges the
> national authority control number with the correspondent record
> numbers in our union catalog (where we have a complete and regularly
> updated duplicate of the national authority file) and re-builds the
> links. I hope I'm making sense here - there are certainly people who
> could explain this much better than me. But be assured it can be done
> (without having to wait for Linked Data) if there are unique
> identifiers (in our case, the national authority control number). So,
> it should also be possible to use the same techniques for linked WEMI
> records, if we had them.


As I have mentioned before, a URI does not have to be a number, but can
be any string of characters, so long as it is unique. Also, any entity
can have more than a single URI. Therefore, according to cataloging
practice of no conflicts in headings, the VIAF fulfills this role right
now since it can supply exact matches of preferred forms for specific
national libraries. So, a search for exact preferred forms for, e.g.
Fyodor Dostoyevsky, works now. All of these searches are for exact forms
restricted to national forms.
LC form:
http://viaf.org/viaf/search?query=local.names+exact+%22Dostoyevsky,%20Fyodor,%201821%201881%22+and+local.sources+any+%22lc%22&stylesheet=/viaf/xsl/results.xsl&sortKeys=holdingscount&maximumRecords=100

Czech form:
http://viaf.org/viaf/search?query=local.names+exact+%22Dostojevskij,%20Fedor%20Michajlovi%C4%8D,%201821%201881%22+and+local.sources+any+%22nkc%22&stylesheet=/viaf/xsl/results.xsl&sortKeys=holdingscount&maximumRecords=100

Israeli form:
http://viaf.org/viaf/search?query=local.names+exact+%22%D7%93%D7%95%D7%A1%D7%98%D7%95%D7%99%D7%91%D7%A1%D7%A7%D7%99,%20%D7%A4%D7%99%D7%95%D7%93%D7%95%D7%A8%20%D7%9E%D7%99%D7%9B%D7%90%D7%99%D7%9C%D7%95%D7%91%D7%99%D7%A5',%201821%201881%22+and+local.sources+any+%22nliara%20nlilat%20nlicyr%20nliheb%22&stylesheet=/viaf/xsl/results.xsl&sortKeys=holdingscount&maximumRecords=100


and so on. This way, it could work similarly to dbpedia which does not
base its URIs on numbers but on consistent textual strings, e.g.
http://dbpedia.org/page/Fyodor_Dostoyevsky, and brings together other
URIs through owl:SameAs.

Currently in VIAF, I have noticed some inconsistencies in search
results, e.g. the exact heading for Martin Luther,
http://viaf.org/viaf/search?query=local.names+exact+%22Luther,%20Martin,%201483%201546%22+and+local.sources+any+%22lc%22&stylesheet=/viaf/xsl/results.xsl&sortKeys=holdingscount&maximumRecords=100
,
which incorrectly pulls up three of his works in addition to his
personal record, although this is supposed to be an exact search. When
you switch to search for "Preferred Headings", you get 307
http://viaf.org/viaf/search?query=local.mainHeadingEl+all+%22Luther,%20Martin,%201483%201546%22+and+local.sources+any+%22lc%22&stylesheet=/viaf/xsl/results.xsl&sortKeys=holdingscount&maximumRecords=100

-- 
*James Weinheimer* weinheimer.ji...@gmail.com
*First Thus* http://catalogingmatters.blogspot.com/
*Cooperative Cataloging Rules*
http://sites.google.com/site/opencatalogingrules/
*Cataloging Matters Podcasts*
http://blog.jweinheimer.net/p/cataloging-matters-podcasts.html

Re: [RDA-L] "Work manifested" in new RDA examples

[Heidrun Wiesenmüller]

Mac said:


I failed the mention record exchange.  To exchange records, the
records need to be complete in themselves.  Just as UTLAS substituted
text for RSN in access points when exporting records, our ILS would
have to be capable of creating the complete textual record, not only
for display and searching, but for exchange.  It would be quite an
operation to to that, drawing from an expression authority record, a
work authority record, and access point authority records.  Karen says
linked data can do that, but the opportunity for glitzes abound.



We do lots of record exchange in Germany between various systems. In the 
exchange format, it's common to have both the heading in textual form 
and the national authority control number, but I'm fairly sure it would 
be no problem if only the control number were transported, without a 
text string. Whenever e.g. data from the German National Library is 
imported into the Southwestern German Library Network, I believe there 
is a procedure which automatically exchanges the national authority 
control number with the correspondent record numbers in our union 
catalog (where we have a complete and regularly updated duplicate of the 
national authority file) and re-builds the links. I hope I'm making 
sense here - there are certainly people who could explain this much 
better than me. But be assured it can be done (without having to wait 
for Linked Data) if there are unique identifiers (in our case, the 
national authority control number). So, it should also be possible to 
use the same techniques for linked WEMI records, if we had them.


Heidrun


--
-
Prof. Heidrun Wiesenmueller M.A.
Stuttgart Media University
Faculty of Information and Communication
Wolframstrasse 32, 70191 Stuttgart, Germany
www.hdm-stuttgart.de/bi

Re: [RDA-L] "Work manifested" in new RDA examples

[Brenndorfer, Thomas]

For the "Work manifested" example in 
http://www.rda-jsc.org/docs/6JSC_RDA_Complete_Examples_%28Bibliographic%29_Revised_2012.pdf
 there are some useful distinctions that can be made to facilitate a discussion 
of this topic.

It is correct that one Creator element and one Title proper element can 
duplicate the Work Manifested element if the form used is the authorized access 
point for the work (name + title form), as opposed to an identifier (such as a 
URI).

But there can be multiple Creators for the one work...

Creator: Person K
Creator: Person R
Creator: Person Z

If the first name person on the resource is Person R, then the authorized 
access point is formed:

Person R. Preferred title.

Essentially, this is the AACR2 main entry rule, minus the Rule of Three.

In RDA though, just pointing to a Creator element is not sufficient -- there is 
no order being specified if there is more than one Creator. The idea of a 
"first named" appears only in the construction of the authorized access point 
for the work, and that alone mimics the 100 + 245 construction and order of 
fields.

The idea of the "composite record" is a grandfathering convention, in that many 
records just have a jumble of sufficient identifying elements that can point 
out a "work manifested" or "expression of work" and so on. In the examples in 
RDA these identifying elements can appear anywhere in the record.

With regard to the Title proper being the same as the Preferred title, RDA 
6.2.2.4 has an example that accounts for the idea that many works have only one 
expression and one manifestation, and that the Preferred title is often the 
same as the Title proper:

Little acorn
Preferred title for work by Christa Kauble that has only one expression and 
only one manifestation. The manifestation was published under the title: The 
little acorn

But there are some new conventions that sweep away the often contorted way 
AACR2 handled two or more works within a resource.

Instead of having work 1 title in a 240 and work 2 title in an analytical 700 
name-title added entry, RDA has this idea of having the entities a little more 
clearly identified in consistent conventions:


100  $a Miller, Arthur, $d 1915-2005
240  $a Plays. $k Selections
245  $a Two plays / $c Arthur Miller.
505  $a The Archbishop’s ceiling -- The American clock.
700  $a Miller, Arthur, $d 1915-2005. $t Archbishop’s ceiling.
700  $a Miller, Arthur, $d 1915-2005. $t American clock.


So here the compilation is Work 1, the Archbishop's ceiling is Work 2, and 
American clock is Work 3.

If these titles were also collaborative works, each with multiple Creators, 
then the clumsy mess can be untangled best with authority records and 
references. Ideally though, it would be easier to do a Scenario 1 rendering on 
all of this, with the works all clearly delineated, and each work with clear 
relationships to its Creators, and the Manifestation record with its 
identifying information informing the construction of the authorized access 
points for the works, but kept apart from the records for the work entities. 
And authorized access points may not need to be made at all in Scenario 1-- it 
could be just identifiers and a compilation of the various elements for each 
entity, followed by the relationship elements to the Creators or Others 
associated with the Works.

The composite record approach allows us to just stick with the bibliographic 
record fields (such as the Contents note) without using identifiers or 
authorized access points to convey the same idea of the primary relationships.

But the ultimate point here is that these primary relationships were always 
implicit in traditional bibliographic records. The key to understanding RDA is 
that what was implicit is made explicit in such a way that the logic of what is 
happening in the resource is captured in the instructions-- but there is room 
for different conventions to carry that logic. One doesn't have to wait for a 
post-MARC environment to establish the primary relationships, but perhaps a 
post-MARC environment can be more efficient at processing and displaying those 
relationships.

Thomas Brenndorfer
Guelph Public Library








From: Resource Description and Access / Resource Description and Access 
[RDA-L@LISTSERV.LAC-BAC.GC.CA] On Behalf Of Heidrun Wiesenmüller 
[wiesenmuel...@hdm-stuttgart.de]
Sent: June-03-12 10:51 AM
To: RDA-L@LISTSERV.LAC-BAC.GC.CA
Subject: [RDA-L] "Work manifested" in new RDA examples

I am mulling over the data element "work manifested" in the examples for
RDA bibliographic records  released by the JSC some time ago:
http://www.rda-jsc.org/docs/6JSC_RDA_Complete_Examples_%28Bibliographic%29_Revised_2012.pdf

For instance, look at the example for Arlene Taylor's "The organization
of information" (book 1, p. 10): There, you'll not only fi

Re: [RDA-L] "Work manifested" in new RDA examples

[J. McRee Elrod]

Heidrun said:

>Maybe. But think of all the money and resources which has already been
>gone into RDA. Makes you wonder why it shouldn't be possible to invest
>some of it into an open source solution which would be available to all...
>But then, of course, this was mere fantasizing :-(

Certainly I hope you are correct in assuming this.

As I and others have said, it would have been better if the energy
which has gone into RDA development and now MARC replacement had been
devoted to much improved ILS free software capable of utilizing the
data we already have in MARC records.

I failed the mention record exchange.  To exchange records, the
records need to be complete in themselves.  Just as UTLAS substituted
text for RSN in access points when exporting records, our ILS would
have to be capable of creating the complete textual record, not only
for display and searching, but for exchange.  It would be quite an
operation to to that, drawing from an expression authority record, a
work authority record, and access point authority records.  Karen says
linked data can do that, but the opportunity for glitzes abound.

Sorry not to address your original question.  We intend to ignore all
such elements which do not now have utilization in our clients'
catalogues, so long as we are constructing MARC manifestation records.  
This includes the $i in 7XX BTW.


   __   __   J. McRee (Mac) Elrod (m...@slc.bc.ca)
  {__  |   / Special Libraries Cataloguing   HTTP://www.slc.bc.ca/
  ___} |__ \__

Re: [RDA-L] "Work manifested" in new RDA examples

[Heidrun Wiesenmüller]

Mac said:



Unless there is two tier linkage, i.e., the work authority record
access points in turn would consist of name authority RSNs (UTLAS
speak for record sequence, i.e., control, numbers), one stop updating
of name access points would not be possible.  Each work authority
record would require updating.


It wouldn't in a scenario where everything is linked. I'd imagine that a 
work authority record would, in turn, be linked to the authority record 
for the creator.




If one adds expression authorty
records to this mix, with three tier linkages, doesn't it become quite
complex?  The same would appliy to term subject access points.  Even
Ezekiel might be confused.


Well, I'm not an engineer, but I find it hard to believe that 
multi-level linking should pose an insurmountable barrier for a computer 
system. In Germany, we already have multi-level linking in many places: 
E.g. a title record is linked to an authority record for a person. In 
this authority record there may be a link to the authority record for 
the affiliated corporate body of this person. In the authority record 
for this affiliated corporate body there might be a link to the 
superordinate body or its predecessor a.s.o. Since the introduction of 
the new "Common authority file" (Gemeinsame Normdatei, GND) a couple of 
weeks ago, we have even more "real links" in our data: For instance, 
broader terms and related terms used to be stored as text strings only 
in our former subject headings authority file. Now, they have been 
converted into true links (using the control numbers) for the GND.


It's easy to follow a sequence of such links by simply clicking on the 
connected entity. Granted, even the PICA libary system, which is used in 
the Union catalog I'm most familiar with (the Southwestern German 
Library Network) and which handles linkings comparatively well, has its 
limits when it comes to exploit them for retrieval over several stages 
(but then the software has been around for many years, and they are 
already working on its successor...). But on principle, I think it 
should be possible to build a system which can do that adequately.


What's more: You could use a different tool for retrieval, couldn't you? 
I'm thinking of catalogs based on search engine technology. Search 
engines don't work like an ILS. They expect to get all information to be 
indexed in one single document, and therefore can't handle linked 
authority records. The solution is to have an additional step before the 
actual indexing process, during which information stored in the 
authority records (e.g. variant names) is copied into the title records 
according to certain rules. This is a method common for some catalogs 
here (some of which are using open source software, by the way). Such 
"expanding" can, I believe, be done over more than one level of linkage.




Even if national cataloguing agencies and major academmic libraries
are able to afford this, I doubt many smaller libraries will soon have
such ILS.


Maybe. But think of all the money and resources which has already been 
gone into RDA. Makes you wonder why it shouldn't be possible to invest 
some of it into an open source solution which would be available to all...

But then, of course, this was mere fantasizing :-(

I find this thread has gone in a completely different way than I had 
expected. Anybody out there still thinking about my original question, 
the data element "work manifested" in JSC's examples?


Heidrun


--
-
Prof. Heidrun Wiesenmüller M.A.
Hochschule der Medien
Fakultät Information und Kommunikation
Wolframstr. 32, 70191 Stuttgart
Tel. dienstl.: 0711/25706-188
Tel. Home Office: 0711/36565868
Fax. 0711/25706-300
www.hdm-stuttgart.de/bi

Re: [RDA-L] "Work manifested" in new RDA examples

[J. McRee Elrod]

Heidrun said:

>In German library systems, we're used to linking authority records 
>(mostly for persons and corporate bodies) to bibliographic records,
>using the authority control numbers as identifiers.
 
As did UTLAS decades ago.

>It would, on principle, also be possible to have an authority record for
>every work and link these to the bibliographic records. 

Unless there is two tier linkage, i.e., the work authority record
access points in turn would consist of name authority RSNs (UTLAS
speak for record sequence, i.e., control, numbers), one stop updating
of name access points would not be possible.  Each work authority
record would require updating.  If one adds expression authorty
records to this mix, with three tier linkages, doesn't it become quite
complex?  The same would appliy to term subject access points.  Even
Ezekiel might be confused.

Even if national cataloguing agencies and major academmic libraries
are able to afford this, I doubt many smaller libraries will soon have
such ILS.
  

   __   __   J. McRee (Mac) Elrod (m...@slc.bc.ca)
  {__  |   / Special Libraries Cataloguing   HTTP://www.slc.bc.ca/
  ___} |__ \__












In this case,
>there wouldn't be a need to repeat work level information (stored in the
>authority record) in the bibliographic record. So in the bibliographic
>record, I would expect to have a link to the work record (corresponding
>to the data element "work manifested"), but not also a link to the 
>authority record for the author (corresponding to the data element for 
>"creator") - this information would be stored in the authority record. 
>Of course, this wouldn't be true FRBR, as the remainder would still be a 
>mixture of expression and manifestation. It also wouldn't be a true 
>scenario 1 implementation, but rather a mixture between scenario 1 and 
>scenario 2.
>
>Using text strings instead of numbers to express relationships is, to my 
>mind, indeed somewhat archaic. Personally, I find it hard to understand 
>why it is still widespread in MARC systems. But we shouldn't forget that 
>the MARC format already allows for transporting authority control 
>numbers (in subfield $0), although nobody in the Anglo-American world 
>seems to use this option... So maybe it wouldn't be necessary to wait 
>for a true FRBR-modeled carrier for RDA. Linking via numbers is already 
>possible in MARC, as is having authority records for works. So why 
>shouldn't it be possible to upgrade the library systems accordingly, at 
>least as a first step on the way to the "perfect" carrier for RDA data?
>
>By the way: It was just announced that the the implementation of RDA in 
>the German speaking countries will conform to scenario 2. The 
>announcement can be found here (sorry, it's in German only):
>http://lists.ddb.de/pipermail/rak-list/2012-June/001983.html
>
>Heidrun
>
>Am 03.06.2012 23:40, schrieb Karen Coyle:
>> Heidrun,
>>
>> I've been assuming, perhaps incorrectly, that references to FRBR 
>> relationships in RDA, like "work manifested," are essentially unusable 
>> until there is a FRBR-modeled carrier for the bibliographic data. I 
>> have a similar assumption about things like "identifier for the 
>> expression," which really cannot exist until there is a FRBR-modeled 
>> carrier that allows -- nay, requires -- those identifiers in order to 
>> create the entities and their relationships.*
>>
>> It makes very little sense to me to be creating a text string for 
>> these relationships which have to be machine-actionable in order to 
>> have the scenario 1 data structures.
>>
>> kc
>>
>> *Hopefully without diverting this discussion, I think there is a 
>> difference between the system identifier for the expression *entity* 
>> and a string, like an ISBN, that might be considered to identify, or 
>> partially identify, an entity in the bibliographic description through 
>> its use in various contexts.
>>
>> On 6/3/12 7:51 AM, Heidrun Wiesenm=FCller wrote:
>>> I am mulling over the data element "work manifested" in the examples 
>>> for RDA bibliographic records  released by the JSC some time ago:
>>> http://www.rda-jsc.org/docs/6JSC_RDA_Complete_Examples_%28Bibliographi=
>c%29_Revised_2012.pdf 
>>>
>>>
>>> For instance, look at the example for Arlene Taylor's "The 
>>> organization of information" (book 1, p. 10): There, you'll not only 
>>> find the data element "creator" (Taylor, Arlene G., 1941-), but also 
>>> the data element "work manifested" (Taylor, Arlene G., 1941-. 
>>> Organization of information). Note the beautiful footnote: "No 
>>> equivalent encoding in MARC 21". In the earlier version of these 
>>> examples wich accompanied the full draft of 2008, this data element 
>>> wasn't there at all, and its appearance now strikes me as rather odd.
>>>
>>> Granted: "Work manifested" (17.8) is a core element in RDA (cf. 17.3: 
>>> "When recording primary relationships, include as a minimum the work 
>>> 

Re: [RDA-L] "Work manifested" in new RDA examples

[Heidrun Wiesenmüller]

Am 04.06.2012 16:22, schrieb Karen Coyle:
Heidrun, the difference I see between the current practice is that 
currently we can link between bibliographic and authority *records* -- 
while FRBR requires us to link between *entities*. The entities in 
FRBR have a somewhat different break-down to our authority data (for 
example our authority data still pre-combines data elements like title 
and date or title and language, rather than creating an entity to 
represent the Expression).


Quite true. At the moment, the representation of works and expressions 
is rather "muddled" in LC Authorities. The situation is even worse in 
the German authority file: At the moment we only have a very limited 
number of authority records for works (only for works of music and for 
works used as subject headings). Still, I don't find it difficult to 
visualize a "better" authority file with separate records for works and 
expressions - with links similar to what they've done in Spain, as 
mentioned in your blog post.


Representing entities by records, as such, seems a perfectly valid way 
of doing it, provided that it's neatly done. And I don't think having 
records in an application is somehow incompatible with Linked Data 
triplets - but let's not repeat the earlier discussion.




That said, I think scenario 2 is far superior to what most systems 
have today.


Probably true on a worldwide level. For the German speaking countries 
it's not such a big step; rather it corresponds to our present 
situation. There is great concern, however, that aiming at scenario 1 
would be too costly. But perhaps the German National Library (DNB) will 
go one step further and adopt something closer to scenario 1 a later stage.


Heidrun


--
-
Prof. Heidrun Wiesenmüller M.A.
Hochschule der Medien
Fakultät Information und Kommunikation
Wolframstr. 32, 70191 Stuttgart
Tel. dienstl.: 0711/25706-188
Tel. Home Office: 0711/36565868
Fax. 0711/25706-300
www.hdm-stuttgart.de/bi

Re: [RDA-L] "Work manifested" in new RDA examples

[Deborah Dauenheimer]

I have to apologize for posting to this group an internal message.  I guess it 
is Monday!  

Since I am writing now instead of being quiet, I want to send a huge Thank You 
to everyone that does participate because I learn so much from each of you.

Thank you,

Deborah


___
Deborah Dauenheimer
Catalog Librarian 
Jefferson County Public Library 
Library Service Center
10500 W. 38th Ave. 
Wheat Ridge, CO 80033 
deborah.dauenhei...@jeffcolibrary.org 
(303) 403-5182
(303)403-5195 fax
Find us on the web: http://jeffcolibrary.org 


-Original Message-
From: Resource Description and Access / Resource Description and Access 
[mailto:RDA-L@LISTSERV.LAC-BAC.GC.CA] On Behalf Of Heidrun Wiesenmüller
Sent: Sunday, June 03, 2012 8:51 AM
To: RDA-L@LISTSERV.LAC-BAC.GC.CA
Subject: [RDA-L] "Work manifested" in new RDA examples

I am mulling over the data element "work manifested" in the examples for RDA 
bibliographic records  released by the JSC some time ago:
http://www.rda-jsc.org/docs/6JSC_RDA_Complete_Examples_%28Bibliographic%29_Revised_2012.pdf

For instance, look at the example for Arlene Taylor's "The organization of 
information" (book 1, p. 10): There, you'll not only find the data element 
"creator" (Taylor, Arlene G., 1941-), but also the data element "work 
manifested" (Taylor, Arlene G., 1941-. Organization of information). Note the 
beautiful footnote: "No equivalent encoding in MARC 21". In the earlier version 
of these examples wich accompanied the full draft of 2008, this data element 
wasn't there at all, and its appearance now strikes me as rather odd.

Granted: "Work manifested" (17.8) is a core element in RDA (cf. 17.3: 
"When recording primary relationships, include as a minimum the work 
manifested."). But in 17.4.2, three conventions for recording primary 
relationships are outlined, and I believe that only the first and the second 
presuppose "work manifested" as a single data element: For these two methods, 
an identifier for the work (method 1) or the authorized access point 
representing the work (method 2), respectively, are used.

The third method, however, does not seem to require one single data element 
"work manifested": "Prepare a composite description that combines one or more 
elements identifying the work and/or expression with the description of the 
manifestation." So, in this case, the identification of the work is achieved by 
one or more elements which really belong on work level, although in the record 
they are mixed together with information on manifestation level. Typically, 
these will be the data elements for the first "creator" and for the "preferred 
title of the work" (vulgo: uniform title). I'd argue that in cases where 
there's no need to determine a uniform title (e.g. if there is only one 
manifestation of the work in question), the title of the manifestation can be 
used instead.

The RDA example for "book 1" mentioned earlier follows this third method for 
recording primary relationships, i.e. it is a "composite description", which 
basically looks like the conventional MARC record. 
Therefore, I find it hard to understand why the information about the work 
manifested is given _twice_ in the same record: Once _implicitly_ according to 
method 3 (by giving the data elements "creator" and "title proper" as part of 
the composite description) and a second time _explicitly_ according to method 2 
(by giving the authorized access point representing the work).

Shouldn't it be either the one (in a composite description) or the other (in a 
different implementation scenario for RDA, something closer to scenario 1)? As 
it stands now, the information given seems to be redundant.

Any ideas?

Heidrun

--
-
Prof. Heidrun Wiesenmueller M.A.
Stuttgart Media University
Faculty of Information and Communication Wolframstrasse 32, 70191 Stuttgart, 
Germany www.hdm-stuttgart.de/bi

Re: [RDA-L] "Work manifested" in new RDA examples

[Karen Coyle]

Heidrun, the difference I see between the current practice is that 
currently we can link between bibliographic and authority *records* -- 
while FRBR requires us to link between *entities*. The entities in FRBR 
have a somewhat different break-down to our authority data (for example 
our authority data still pre-combines data elements like title and date 
or title and language, rather than creating an entity to represent the 
Expression).


That said, I think scenario 2 is far superior to what most systems have 
today. Also look at the blog post[1]  I did on the National Library of 
Spain's linked data implementation, which is based on the concept of 
authorities but still uses FRBR.


kc
[1] http://kcoyle.blogspot.com/2012/05/frbr-frad-isbd-in-ld-by-bne.html

On 6/4/12 3:44 AM, Heidrun Wiesenmüller wrote:

Karen,

not necessarily, I believe.

In German library systems, we're used to linking authority records 
(mostly for persons and corporate bodies) to bibliographic records, 
using the authority control numbers as identifiers. The systems are 
able to extract information stored in the authority records for 
retrieval. This makes it e.g. possible to use variant names in keyword 
searching.


It would, on principle, also be possible to have an authority record 
for every work and link these to the bibliographic records. In this 
case, there wouldn't be a need to repeat work level information 
(stored in the authority record) in the bibliographic record. So in 
the bibliographic record, I would expect to have a link to the work 
record (corresponding to the data element "work manifested"), but not 
also a link to the authority record for the author (corresponding to 
the data element for "creator") - this information would be stored in 
the authority record. Of course, this wouldn't be true FRBR, as the 
remainder would still be a mixture of expression and manifestation. It 
also wouldn't be a true scenario 1 implementation, but rather a 
mixture between scenario 1 and scenario 2.


Using text strings instead of numbers to express relationships is, to 
my mind, indeed somewhat archaic. Personally, I find it hard to 
understand why it is still widespread in MARC systems. But we 
shouldn't forget that the MARC format already allows for transporting 
authority control numbers (in subfield $0), although nobody in the 
Anglo-American world seems to use this option... So maybe it wouldn't 
be necessary to wait for a true FRBR-modeled carrier for RDA. Linking 
via numbers is already possible in MARC, as is having authority 
records for works. So why shouldn't it be possible to upgrade the 
library systems accordingly, at least as a first step on the way to 
the "perfect" carrier for RDA data?


By the way: It was just announced that the the implementation of RDA 
in the German speaking countries will conform to scenario 2. The 
announcement can be found here (sorry, it's in German only):

http://lists.ddb.de/pipermail/rak-list/2012-June/001983.html

Heidrun



Am 03.06.2012 23:40, schrieb Karen Coyle:

Heidrun,

I've been assuming, perhaps incorrectly, that references to FRBR 
relationships in RDA, like "work manifested," are essentially 
unusable until there is a FRBR-modeled carrier for the bibliographic 
data. I have a similar assumption about things like "identifier for 
the expression," which really cannot exist until there is a 
FRBR-modeled carrier that allows -- nay, requires -- those 
identifiers in order to create the entities and their relationships.*


It makes very little sense to me to be creating a text string for 
these relationships which have to be machine-actionable in order to 
have the scenario 1 data structures.


kc

*Hopefully without diverting this discussion, I think there is a 
difference between the system identifier for the expression *entity* 
and a string, like an ISBN, that might be considered to identify, or 
partially identify, an entity in the bibliographic description 
through its use in various contexts.


On 6/3/12 7:51 AM, Heidrun Wiesenmüller wrote:
I am mulling over the data element "work manifested" in the examples 
for RDA bibliographic records  released by the JSC some time ago:
http://www.rda-jsc.org/docs/6JSC_RDA_Complete_Examples_%28Bibliographic%29_Revised_2012.pdf 



For instance, look at the example for Arlene Taylor's "The 
organization of information" (book 1, p. 10): There, you'll not only 
find the data element "creator" (Taylor, Arlene G., 1941-), but also 
the data element "work manifested" (Taylor, Arlene G., 1941-. 
Organization of information). Note the beautiful footnote: "No 
equivalent encoding in MARC 21". In the earlier version of these 
examples wich accompanied the full draft of 2008, this data element 
wasn't there at all, and its appearance now strikes me as rather odd.


Granted: "Work manifested" (17.8) is a core element in RDA (cf. 
17.3: "When recording primary relationships, include as a minimum 
the work manifested."). But in 17.4.2, three

Re: [RDA-L] "Work manifested" in new RDA examples

[Deborah Dauenheimer]

Cynthia,

FYI: Maybe this is something for our reference collection.  There is a new 
edition of Arlene Taylor's Organization of Information (2008).  

http://www.amazon.com/Organization-Information-Library-Science-Series/dp/159158700X

We have 1999, and 2004.  The 2008 ed. is referred to below in the RDA listserv. 
 

Deborah


___
Deborah Dauenheimer
Catalog Librarian 
Jefferson County Public Library 
Library Service Center
10500 W. 38th Ave. 
Wheat Ridge, CO 80033 
deborah.dauenhei...@jeffcolibrary.org 
(303) 403-5182
(303)403-5195 fax
Find us on the web: http://jeffcolibrary.org 


-Original Message-
From: Resource Description and Access / Resource Description and Access 
[mailto:RDA-L@LISTSERV.LAC-BAC.GC.CA] On Behalf Of Heidrun Wiesenmüller
Sent: Sunday, June 03, 2012 8:51 AM
To: RDA-L@LISTSERV.LAC-BAC.GC.CA
Subject: [RDA-L] "Work manifested" in new RDA examples

I am mulling over the data element "work manifested" in the examples for RDA 
bibliographic records  released by the JSC some time ago:
http://www.rda-jsc.org/docs/6JSC_RDA_Complete_Examples_%28Bibliographic%29_Revised_2012.pdf

For instance, look at the example for Arlene Taylor's "The organization of 
information" (book 1, p. 10): There, you'll not only find the data element 
"creator" (Taylor, Arlene G., 1941-), but also the data element "work 
manifested" (Taylor, Arlene G., 1941-. Organization of information). Note the 
beautiful footnote: "No equivalent encoding in MARC 21". In the earlier version 
of these examples wich accompanied the full draft of 2008, this data element 
wasn't there at all, and its appearance now strikes me as rather odd.

Granted: "Work manifested" (17.8) is a core element in RDA (cf. 17.3: 
"When recording primary relationships, include as a minimum the work 
manifested."). But in 17.4.2, three conventions for recording primary 
relationships are outlined, and I believe that only the first and the second 
presuppose "work manifested" as a single data element: For these two methods, 
an identifier for the work (method 1) or the authorized access point 
representing the work (method 2), respectively, are used.

The third method, however, does not seem to require one single data element 
"work manifested": "Prepare a composite description that combines one or more 
elements identifying the work and/or expression with the description of the 
manifestation." So, in this case, the identification of the work is achieved by 
one or more elements which really belong on work level, although in the record 
they are mixed together with information on manifestation level. Typically, 
these will be the data elements for the first "creator" and for the "preferred 
title of the work" (vulgo: uniform title). I'd argue that in cases where 
there's no need to determine a uniform title (e.g. if there is only one 
manifestation of the work in question), the title of the manifestation can be 
used instead.

The RDA example for "book 1" mentioned earlier follows this third method for 
recording primary relationships, i.e. it is a "composite description", which 
basically looks like the conventional MARC record. 
Therefore, I find it hard to understand why the information about the work 
manifested is given _twice_ in the same record: Once _implicitly_ according to 
method 3 (by giving the data elements "creator" and "title proper" as part of 
the composite description) and a second time _explicitly_ according to method 2 
(by giving the authorized access point representing the work).

Shouldn't it be either the one (in a composite description) or the other (in a 
different implementation scenario for RDA, something closer to scenario 1)? As 
it stands now, the information given seems to be redundant.

Any ideas?

Heidrun

--
-
Prof. Heidrun Wiesenmueller M.A.
Stuttgart Media University
Faculty of Information and Communication Wolframstrasse 32, 70191 Stuttgart, 
Germany www.hdm-stuttgart.de/bi

Re: [RDA-L] "Work manifested" in new RDA examples

[Heidrun Wiesenmüller]

Karen,

not necessarily, I believe.

In German library systems, we're used to linking authority records 
(mostly for persons and corporate bodies) to bibliographic records, 
using the authority control numbers as identifiers. The systems are able 
to extract information stored in the authority records for retrieval. 
This makes it e.g. possible to use variant names in keyword searching.


It would, on principle, also be possible to have an authority record for 
every work and link these to the bibliographic records. In this case, 
there wouldn't be a need to repeat work level information (stored in the 
authority record) in the bibliographic record. So in the bibliographic 
record, I would expect to have a link to the work record (corresponding 
to the data element "work manifested"), but not also a link to the 
authority record for the author (corresponding to the data element for 
"creator") - this information would be stored in the authority record. 
Of course, this wouldn't be true FRBR, as the remainder would still be a 
mixture of expression and manifestation. It also wouldn't be a true 
scenario 1 implementation, but rather a mixture between scenario 1 and 
scenario 2.


Using text strings instead of numbers to express relationships is, to my 
mind, indeed somewhat archaic. Personally, I find it hard to understand 
why it is still widespread in MARC systems. But we shouldn't forget that 
the MARC format already allows for transporting authority control 
numbers (in subfield $0), although nobody in the Anglo-American world 
seems to use this option... So maybe it wouldn't be necessary to wait 
for a true FRBR-modeled carrier for RDA. Linking via numbers is already 
possible in MARC, as is having authority records for works. So why 
shouldn't it be possible to upgrade the library systems accordingly, at 
least as a first step on the way to the "perfect" carrier for RDA data?


By the way: It was just announced that the the implementation of RDA in 
the German speaking countries will conform to scenario 2. The 
announcement can be found here (sorry, it's in German only):

http://lists.ddb.de/pipermail/rak-list/2012-June/001983.html

Heidrun



Am 03.06.2012 23:40, schrieb Karen Coyle:

Heidrun,

I've been assuming, perhaps incorrectly, that references to FRBR 
relationships in RDA, like "work manifested," are essentially unusable 
until there is a FRBR-modeled carrier for the bibliographic data. I 
have a similar assumption about things like "identifier for the 
expression," which really cannot exist until there is a FRBR-modeled 
carrier that allows -- nay, requires -- those identifiers in order to 
create the entities and their relationships.*


It makes very little sense to me to be creating a text string for 
these relationships which have to be machine-actionable in order to 
have the scenario 1 data structures.


kc

*Hopefully without diverting this discussion, I think there is a 
difference between the system identifier for the expression *entity* 
and a string, like an ISBN, that might be considered to identify, or 
partially identify, an entity in the bibliographic description through 
its use in various contexts.


On 6/3/12 7:51 AM, Heidrun Wiesenmüller wrote:
I am mulling over the data element "work manifested" in the examples 
for RDA bibliographic records  released by the JSC some time ago:
http://www.rda-jsc.org/docs/6JSC_RDA_Complete_Examples_%28Bibliographic%29_Revised_2012.pdf 



For instance, look at the example for Arlene Taylor's "The 
organization of information" (book 1, p. 10): There, you'll not only 
find the data element "creator" (Taylor, Arlene G., 1941-), but also 
the data element "work manifested" (Taylor, Arlene G., 1941-. 
Organization of information). Note the beautiful footnote: "No 
equivalent encoding in MARC 21". In the earlier version of these 
examples wich accompanied the full draft of 2008, this data element 
wasn't there at all, and its appearance now strikes me as rather odd.


Granted: "Work manifested" (17.8) is a core element in RDA (cf. 17.3: 
"When recording primary relationships, include as a minimum the work 
manifested."). But in 17.4.2, three conventions for recording primary 
relationships are outlined, and I believe that only the first and the 
second presuppose "work manifested" as a single data element: For 
these two methods, an identifier for the work (method 1) or the 
authorized access point representing the work (method 2), 
respectively, are used.


The third method, however, does not seem to require one single data 
element "work manifested": "Prepare a composite description that 
combines one or more elements identifying the work and/or expression 
with the description of the manifestation." So, in this case, the 
identification of the work is achieved by one or more elements which 
really belong on work level, although in the record they are mixed 
together with information on manifestation level. Typically, these 
will be the data el

Re: [RDA-L] "Work manifested" in new RDA examples

[Karen Coyle]

Heidrun,

I've been assuming, perhaps incorrectly, that references to FRBR 
relationships in RDA, like "work manifested," are essentially unusable 
until there is a FRBR-modeled carrier for the bibliographic data. I have 
a similar assumption about things like "identifier for the expression," 
which really cannot exist until there is a FRBR-modeled carrier that 
allows -- nay, requires -- those identifiers in order to create the 
entities and their relationships.*


It makes very little sense to me to be creating a text string for these 
relationships which have to be machine-actionable in order to have the 
scenario 1 data structures.


kc

*Hopefully without diverting this discussion, I think there is a 
difference between the system identifier for the expression *entity* and 
a string, like an ISBN, that might be considered to identify, or 
partially identify, an entity in the bibliographic description through 
its use in various contexts.


On 6/3/12 7:51 AM, Heidrun Wiesenmüller wrote:
I am mulling over the data element "work manifested" in the examples 
for RDA bibliographic records  released by the JSC some time ago:
http://www.rda-jsc.org/docs/6JSC_RDA_Complete_Examples_%28Bibliographic%29_Revised_2012.pdf 



For instance, look at the example for Arlene Taylor's "The 
organization of information" (book 1, p. 10): There, you'll not only 
find the data element "creator" (Taylor, Arlene G., 1941-), but also 
the data element "work manifested" (Taylor, Arlene G., 1941-. 
Organization of information). Note the beautiful footnote: "No 
equivalent encoding in MARC 21". In the earlier version of these 
examples wich accompanied the full draft of 2008, this data element 
wasn't there at all, and its appearance now strikes me as rather odd.


Granted: "Work manifested" (17.8) is a core element in RDA (cf. 17.3: 
"When recording primary relationships, include as a minimum the work 
manifested."). But in 17.4.2, three conventions for recording primary 
relationships are outlined, and I believe that only the first and the 
second presuppose "work manifested" as a single data element: For 
these two methods, an identifier for the work (method 1) or the 
authorized access point representing the work (method 2), 
respectively, are used.


The third method, however, does not seem to require one single data 
element "work manifested": "Prepare a composite description that 
combines one or more elements identifying the work and/or expression 
with the description of the manifestation." So, in this case, the 
identification of the work is achieved by one or more elements which 
really belong on work level, although in the record they are mixed 
together with information on manifestation level. Typically, these 
will be the data elements for the first "creator" and for the 
"preferred title of the work" (vulgo: uniform title). I'd argue that 
in cases where there's no need to determine a uniform title (e.g. if 
there is only one manifestation of the work in question), the title of 
the manifestation can be used instead.


The RDA example for "book 1" mentioned earlier follows this third 
method for recording primary relationships, i.e. it is a "composite 
description", which basically looks like the conventional MARC record. 
Therefore, I find it hard to understand why the information about the 
work manifested is given _twice_ in the same record: Once _implicitly_ 
according to method 3 (by giving the data elements "creator" and 
"title proper" as part of the composite description) and a second time 
_explicitly_ according to method 2 (by giving the authorized access 
point representing the work).


Shouldn't it be either the one (in a composite description) or the 
other (in a different implementation scenario for RDA, something 
closer to scenario 1)? As it stands now, the information given seems 
to be redundant.


Any ideas?

Heidrun



--
Karen Coyle
kco...@kcoyle.net http://kcoyle.net
ph: 1-510-540-7596
m: 1-510-435-8234
skype: kcoylenet

[RDA-L] "Work manifested" in new RDA examples

[Heidrun Wiesenmüller]

I am mulling over the data element "work manifested" in the examples for 
RDA bibliographic records  released by the JSC some time ago:

http://www.rda-jsc.org/docs/6JSC_RDA_Complete_Examples_%28Bibliographic%29_Revised_2012.pdf

For instance, look at the example for Arlene Taylor's "The organization 
of information" (book 1, p. 10): There, you'll not only find the data 
element "creator" (Taylor, Arlene G., 1941-), but also the data element 
"work manifested" (Taylor, Arlene G., 1941-. Organization of 
information). Note the beautiful footnote: "No equivalent encoding in 
MARC 21". In the earlier version of these examples wich accompanied the 
full draft of 2008, this data element wasn't there at all, and its 
appearance now strikes me as rather odd.


Granted: "Work manifested" (17.8) is a core element in RDA (cf. 17.3: 
"When recording primary relationships, include as a minimum the work 
manifested."). But in 17.4.2, three conventions for recording primary 
relationships are outlined, and I believe that only the first and the 
second presuppose "work manifested" as a single data element: For these 
two methods, an identifier for the work (method 1) or the authorized 
access point representing the work (method 2), respectively, are used.


The third method, however, does not seem to require one single data 
element "work manifested": "Prepare a composite description that 
combines one or more elements identifying the work and/or expression 
with the description of the manifestation." So, in this case, the 
identification of the work is achieved by one or more elements which 
really belong on work level, although in the record they are mixed 
together with information on manifestation level. Typically, these will 
be the data elements for the first "creator" and for the "preferred 
title of the work" (vulgo: uniform title). I'd argue that in cases where 
there's no need to determine a uniform title (e.g. if there is only one 
manifestation of the work in question), the title of the manifestation 
can be used instead.


The RDA example for "book 1" mentioned earlier follows this third method 
for recording primary relationships, i.e. it is a "composite 
description", which basically looks like the conventional MARC record. 
Therefore, I find it hard to understand why the information about the 
work manifested is given _twice_ in the same record: Once _implicitly_ 
according to method 3 (by giving the data elements "creator" and "title 
proper" as part of the composite description) and a second time 
_explicitly_ according to method 2 (by giving the authorized access 
point representing the work).


Shouldn't it be either the one (in a composite description) or the other 
(in a different implementation scenario for RDA, something closer to 
scenario 1)? As it stands now, the information given seems to be redundant.


Any ideas?

Heidrun

--
-
Prof. Heidrun Wiesenmueller M.A.
Stuttgart Media University
Faculty of Information and Communication
Wolframstrasse 32, 70191 Stuttgart, Germany
www.hdm-stuttgart.de/bi