- From: Dan Brickley <danbri@danbri.org>
- Date: Tue, 22 Mar 2011 00:10:54 +0100
- To: public-lld <public-lld@w3.org>
[resending from right address] On 21 March 2011 23:56, Dan Brickley <danbri2011@danbri.org> wrote: > On Monday, 21 March 2011, Karen Coyle <kcoyle@kcoyle.net> wrote: >> Quoting "Svensson, Lars" <L.Svensson@dnb.de>: > >> 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] > > On this last point, are there any scenarios where prototypical > characteristics of some Manifestation might inerestingly vary in > practice? Most obvious I can think of is number of pages, but I cant > think of reasons it would be useful. Reason to ask is that if it were > important to describe both the typical and actual values that some > property has, then a bit of care is needed to get the rdf > representations right. > > >> 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. > > > Is it ok for these different 'functions' to be making me think both of > DC application profiles and also of stored/shared query templates...? > > Btw On this business of non-duplication, data sharing standards are > intrinsically about having extra copies floating around. If they > attach eg the work's subject info directly alongside item properties, > that doesn't seem costly. What's costly is *managing* work-level facts > separately for each item. so long as things are managed sanely behind > the scenes, flat records don't seem such a crime. > > Dan > > >> 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 23:11:31 UTC