Tim Spalding wrote:
> conversation about," "get reading recommendations for." Rather than
> getting caught in narrow and contentious arguments about essence,
> LibrayThing members are asked to consider how a given combination will
> affect LibraryThing's social system and the features that depend on
> it. Needless to say, the social test is also answered socially.
>
So, decisions about metadata in LibraryThing's universe can be made for
a very particular application---"LibraryThing's social system and the
features that depend on it." In the library world, many of us are
assuming that we don't have a very particular and defined application
for our metadata, but that instead we are trying to design metadata as
flexibly as possible, to support many (any?) application, both ones we
can think of now and ones we will think of in the future.
This makes the task quite a bit harder then knowing exactly what the
application supported by the metadata is, and deciding how particular
metadata will effect that specific application. In fact, I think that
many of the problems we currently have with our library
cataloging/metadata system, is that it WAS designed for a very
particular application---the printed card catalog. Rules and individual
decisions were made for that application in mind. Many of them still
are, even though that application is long gone.
So the response from some is now that we need to design the metadata for
some particular new application, but we need to design the metadata to
flexibly support many (any?) applications. Are we wrong to be thinking
this? Is this a sisiphean task? Do we need to specify the bounds on
what sorts of applications we mean to support better (the FRBR user
tasks are one attempt to do this; are they sufficient? Why or why not?).
Should we specify the bounds all the way down to something as specific
as one particular application? (The 'online public access catalog'?
Surely not!)
Jonathan
> To simplify matters we use the "cocktail party test," that is, if
> someone asked you at a cocktail party "Hey, have you read Harry Potter
> and the Sorceror's Stone," you would assent no matter what edition you
> had read, even if it was the British one, _Harry Potter and the
> Philosopher's Stone_.
>
> The test produces some results I find appropiate. So, for example, we
> distinguish between the ancient Indian love manual _The Kama Sutra_
> and the recent joke book _The Pop-up Kama Sutra_. Worldcat doesn't (
> http://worldcat.org/isbn/1584793023 ). From an "essentialist"
> perspective, the pop-up version is the same work. From a social
> perspective it isn't. "Have you read the Kama Sutra?" "No, but I've
> got this hysterical pop-up version with all these amazing strings and
> motions."
>
> Ultimately the binary relationships of both FRBR and LibraryThing's
> system aren't enough. The relations between books are as irresolvably
> complex as their subjects. This is why I favor "tagging
> relationships," bringing Weinberger's "kind-of sort-of" world to this
> area as well. But whatever the mechanics, there's something to
> reconsidering the basis. I'm not necessarily arguing that "get laid"
> should be added to the FRBR tasks, but if we're talking about sites
> like IMDB, Netflix or Flixster, maybe it should.
>
> Tim
>
> On 5/19/07, Brenndorfer, Thomas <tbrenndorfer_at_library.guelph.on.ca>
> wrote:
>> >> So when a person or a concept gets its own page in some service
>> like IMDb.com or LibraryThing, and is the focus for other activities,
>> I have to say, hey,that's what the original 1997 FRBR paper was
>> talking about.
>>
>> Or to use more precise words, I inferred from the 1997 FRBR report
>> where things were going. The Find and Identify user tasks as they
>> relate to Persons or Concepts are in FRAD (Functional Requirements
>> for Authority Data) at
>> http://www.ifla.org/VII/d4/FRANAR-ConceptualModel-2ndReview.pdf
>> <http://anthony.library.guelph.on.ca/exchweb/bin/redir.asp?URL=http://www.ifla.org/VII/d4/FRANAR-ConceptualModel-2ndReview.pdf>
>>
>>
>> Sorting through the way tasks, entities, attributes, and
>> relationships are mapped in FRBR/FRAD, I tried to categorize some the
>> recent discussion topics according to user tasks in ways that might
>> be useful:
>>
>> >Find<
>>
>> Person, Family, Corporate Body, Work, Expression, Manifestation,
>> Item, Concept, Object, Event, Place, Name, Identifier, Controlled
>> Access Point
>>
>> Some discussion of what type of identifier would best be used to find
>> these entities might fall into this category-ex., match points on
>> readable headings, URIs, etc.
>>
>> >Identify<
>>
>> Person, Family, Corporate Body, Work, Expression, Manifestation,
>> Item, Concept, Object, Event, Place, Name, Identifier, Controlled
>> Access Point, Rules, Agency
>>
>> Some discussion of disambiguating identical names might fall into
>> this category. Check out the list of attributes to use to help
>> disambiguate names in FRAD. I mentioned that IMDb.com has a keyword
>> result screen that sorts the results roughly by type of entity with a
>> lot of data to help disambiguate similar names.
>>
>> >Select<
>>
>> Work, Expression, Manifestation, Item
>>
>> Some discussion of using human-readable descriptive data vs
>> machine-readable fixed field data might fall into this category.
>> Limits and facet filter options are used to select these entities
>> based upon content or carrier attributes. I would characterize some
>> of the new facet-based interfaces like Endeca as putting the Select
>> user task on steroids-a lot of the data in MARC records are brought
>> to the surface and exploited quite well in these interfaces. Note
>> that at this stage we are getting closer to picking a resource that
>> matches our exact needs based upon criteria such as media or format.
>>
>> >Obtain<
>>
>> Manifestation, Item
>>
>> One can only "obtain" the most concrete entities.
>>
>> >Contextualize<
>>
>> Person, Family, Corporate Body, Work, Expression, Place, Name,
>> Controlled Access Point
>>
>> >Justify<
>>
>> Person, Corporate Body, Work, Controlled Access Point, Rules
>>
>> ************************
>>
>> Going back to the original post about services against collections,
>> which refers to new services that are based upon full-text indexing,
>> I think we still have to pass through the gates of these basic user
>> tasks as defined in FRBR/FRAD for many of the service-based
>> activities we perform in libraries.
>>
>> Service to the user is always of paramount importance, but it's also
>> a matter of the degree to what we rely on the catalogue to do for us.
>> I do reference work as well and I use that opportunity to think about
>> customer service in relation to the catalogue. There were three cases
>> today that were instructive:
>>
>> 1. A patron had used the catalogue to successfully locate a
>> government publication. It was in storage and I had to retrieve it. I
>> told the patron she could have selected an online copy of the
>> publication, but she said that she specifically selected the print
>> copy because of ease-of-use. Hmmm, I thought, this seems to confirm
>> my view that public library users are not as driven to the online
>> world as academic library users. Certainly the use of electronic
>> resources is rising, but so is the use of traditional material.
>>
>> 2. A social networking tool that has been around for a while is the
>> Just Returned truck. A patron had found vol. 8 of a Nero Wolfe DVD
>> set on the Just Returned truck and wanted to know if we had vol. 1
>> (this person was probably too intimidated to use the catalogue). I
>> found the item on the shelf for the patron after searching the
>> catalogue [I also glanced with curiousity as to if this was an
>> analyzed title (it was) or part of single record set]. Capturing
>> usage statistics and social networking data is a great new direction
>> for libraries, but we have to be sure that people don't fall through
>> the cracks when thinking about these services.
>>
>> 3. A patron required books to help him learn Italian. After further
>> questioning and after helping him examine the books our library held,
>> we determined that a simpler book with somewhat larger print and with
>> pronunciation guides (he didn't have a CD or cassette player for our
>> language audio items) would be best. How many of those criteria that
>> were used for selection would have made it into our catalogue? Not
>> many it seems-- I really only used the subject heading then the call
>> number range to find these books. So there's always going to be a
>> sliding scale in terms of providing the level of detail to help the
>> user accomplish his tasks. Cataloguing and other information services
>> will always be part of some balancing act. My view has been that we
>> should always be doing what we have been doing, but better and more
>> economically (I'm thinking of series control specifically) because
>> the nature of shared cataloguing and distributed work should allow us
>> to do that. The same tools (!
> co!
>> mputers, the web, etc.) should also allow us to add new functionality.
>>
>> Thomas Brenndorfer, B.A, M.L.I.S.
>> Guelph Public Library
>> 100 Norfolk St.
>> Guelph, ON
>> N1H 4J6
>> (519) 824-6220 ext. 276
>> tbrenndorfer_at_library.guelph.on.ca
>>
>
--
Jonathan Rochkind
Sr. Programmer/Analyst
The Sheridan Libraries
Johns Hopkins University
410.516.8886
rochkind (at) jhu.edu
Received on Tue May 22 2007 - 08:12:46 EDT