Re: AW: Re: FRBR and classes ('frbr:Works in the age of mechanical reproduction'...)

Quoting "Svensson, Lars" <L.Svensson@dnb.de>:

> I'm still digesting Dan's post, so I'll just comment briefly,  
> looking at Karen's mail in reversed order:
>
>> That said, it may be time to unbundle the inventory function (which is
>> necessary for library management: purchasing, circulation, estimating
>> storage needs) from the human knowledge function, and at least allow
>> the latter to evolve unfettered by the need to control the packages.
>> Perhaps what we need to do with FRBR is to remove the dependency of
>> the knowledge function from the physical inventory function, but link
>> them for services that intertwine intellectual discovery and item
>> delivery. (In fact, today's MARC-based records may do this better than
>> FRBR does.)
>
> Inventory, purchase, circulation, storage: This is all about  
> frbr:Items, right?

A lot of it is, but not all of it. To begin with, the FRBR item entity  
has little information about the contents of the "package." That  
information is carried in M+E+W. About the only thing that I can think  
of that is at a purely item level is circulation. (hmm, maybe binding  
and repair, also.) Functions like purchasing need to be informed more  
by the content of the package -- do you need a newer edition of this  
text? did the warehouse deliver the correct book? When users place a  
hold on a book, you want the hold attached to the manifestation, not  
the item, since users do not care which of x copies they actually  
check out. For purchasing decisions, of course, you need to know how  
well your library's current holdings cover that topic, and whether a  
new publication in that area fits into your collection. That's  
actually at the Work level.

A certain amount of this depends on how you define the Item in  
relation to WEM. FRBR seems to be best suited for mass-produced  
intellectual products (although it does handle unique instances as  
well, such as manuscripts). The M carries the physical attributes such  
as physical format, size, extent (# of pages, or length in minutes for  
sound data). It would make sense to record that for items, but one of  
the goals of FRBR is to reduce duplication of data; data is recorded  
at the highest logical level, not the lowest. There is some concept of  
inheritance where "lower" levels inherent characteristics from the  
upper ones, so each Item inherits physical characteristics from its  
Manifestation. [although this is also debated - 1]

>
>> Clearly, the issue here is not technology but *mission*. The mission
>> of the library is not to gather physical things into an inventory, but
>> to organize human knowledge that has been very inconveniently
>> packaged. While there is a case for modeling the packages as packages
>> (for example in warehouses that serve Amazon, or for library
>> circulation functions), the library catalog describes the package as a
>> secondary aspect (as you note below, Dan). The primary goal is to
>> describe what the content of these packages MEANS, in themselves and
>> in relation to each other, and over time. Obviously, MEANING in this
>> context is a very big word.
>
> Leaves WEM to take care of the rest: Content and Meaning.

Yes, as long as you accept that for many functions you need the whole  
WEMI (just now thinking of WEMI as an enchilada, and for those who  
don't get that it's a colloquialism that I promise to explain over a  
beer next time I see you :-)). And unfortunately the Item is really  
bare bones, often only having a barcode-type identifier and nothing  
else. I think a separation into physical aspects (the concrete thing)  
and content and meaning would probably result in a slightly different  
set of classes from WEMI.



>
> I still don't know what to do with this, so -- like Dan -- I'm  
> thinking aloud. Would one possibility be to say that WEM is a class  
> and the Items are instances? To me, it feels neither right nor  
> wrong...


What others have said is that WEM are all abstractions, and only Item  
is concrete. However, the concrete Item doesn't have the physical  
description, so I suspect it is of limited use.

But you said something intriguing here, which is that WEM is *a*  
class, not 3 classes. I did a blog post along those lines [2],  
although I posed it as a discussion of "what we can share." I had W as  
a class, W+E as a class, and W+E+M as a class (along with related  
group 2 and 3 entities). This is because there is no M without W+E, no  
E without W.

I could imagine a separation between the "thing" and the meaning, as  
you suggest. The "thing" would need to be able to stand alone for the  
"thing-ish" functions like circulation, replacement, storage, binding.  
In that world, Item would take on some of the properties that are now  
in M. This would not achieve the lack of duplication that FRBR  
attempts to enforce, but the increased functionality may justify the  
extra space requirements.

Another possibility, which your comments bring up for me, would be to  
follow Dan's suggestion that we not see WEMI as classes but organize  
the properties as needed for different functions. We could have Item  
functions (circulation, storage), product identification functions  
(ISBN, # of pages, size, what's written on the title page or cover),  
user discovery functions (subjects, related persons, other  
bibliographic relations) and what I'm thinking of as "bibliographic  
universe" functions (everything from citation indexing to chains of  
influence from one work to another; books turned into movies, plays  
turned into TV programs). My guess is that the result of this analysis  
would have a lot in common with FRBR but that there would also be some  
differences. If it is *compatible* with FRBR then we've got some  
interesting possibilities.

kc

[1] http://eprints.rclis.org/bitstream/10760/8622/1/Renear_Modeling.pdf
[2] http://kcoyle.blogspot.com/2010/05/frbr-and-sharability.html



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

Received on Monday, 21 March 2011 22:22:17 UTC