All of this makes sense. BUT once someone HAS established a work for The
Conquest of Bread and filled in it's subjects, I shouldn't _have_ to go
assigning subjects every time I make a new manifestation record, should
I? I should be able to inherit from that work, such that when the work
subjects are changed (someoen does a better job), my manifestation knows
that too.
It needs to work both ways. And we definitely need to prepare for a
world where different pieces of the puzzle get filled in at different
times by different people. I shouldn't need to know everything when
cataloging an item in front of me, but when someoen else who does know
more adds more, it should all go together properly.
One hypothetical flow scenario: I make a manifestation record for
Conquest of Bread, and I fill in subjects for it. Later someone else
comes along and looks at our shared cataloging database, and says, gee,
this is really a part of this work set, and a record exists for that.
(Yes, a work is a SET, but a set can be an entity too! And can have
attributes!). They tie it to the work set. Maybe they're asked "You
want to merge in the subjects from the previous free-standing
manifestation, or discard them?"
Another workflow that's actually the same workflow, but is represented
differently in the record structure: I make a manifestation record for
Conquest of Bread, and I don't care to find a pre-existing work record
for it (maybe I don't have time, maybe one doesn't exist), but the
system automatically creates a placeholder work record for me, and
attaches my subjects to that. Later, that same someone else comes along
and says "Gee, this is really a part of this other existing work set",
and merges the two work records.
Those are actually the SAME workflows, these are system implementation
details. There are also workflow details to be worked out to deal with
_expecting_ different pieces of data to be added by different people at
different times (and 'data' includes relationships and set memberships).
But you've got to do all that on top of a formalized domain model.
Having a formalized domain model is what even gives us the language to
have this discussion. And the work you do on top of the formalized
domain model will no doubt give you insights suggesting changes in the
underlying formalized domain model, in an iterative process. That's
fine. But you've got to start sometime, and you've got to have a
formalized domain model.
Which I why I find it very counter-productive to be saying that basing
things on FRBR is a negative, and we should just go on without any
formalized domain model at all. Basing things on FRBR as a formalized
model doesn't decide things one way or the other in terms of the
implementation issues we'll have to work out to make the scenarios Karen
talks about possible. But going with FRBR as a formalized model to begin
with _allows_ us to start working on those implementation issues. As RDA
was trying to do -- whether it has been succesful or not is another
story, but that (at least starting a few years ago) it was _trying_ to
base itself on the FRBR model is not to it's detriment.
Jonathan
Karen Coyle wrote:
> Matthew & Jonathan:
>
> I agree with both Matthew's bottom-up and Jonathan's sets. To me, a Work
> is a grouping of Expressions, and that means that the "workness" exists
> even if you don't have the information you need to create a Work entity.
> (One of my problems with WEMI is that there seems to be an assumption
> that all of the information to fill in all of the entities will be
> there... which is not the case, see below.) Each level, to me, is the
> sum of the levels below it, so the manifestations add up to what you
> currently know about one or more expressions, and what you can deduce
> about the work. It's a build-up process.
>
> My "resource" btw was intended to be more "superWork" -- WEMI, in my
> mind, are parts of something, not wholes in themselves. The fact that
> they are not whole is what gives me a hard time in thinking of them as
> entities. A Manifestation doesn't have subjects? Or an author? Hmmmm. So
> WEMI is an interdependent set of descriptions, not separate entities.
> That gives me pause.
>
> So how will we, in practice, fill these in? I used as an example a book
> that I found on the street in Berkeley (I get great books out of boxes
> of discards here):
>
> The Conquest of Bread
> by Peter Kropotkin
> New York Vanguard Press1926
>
> No mention of translation. If I'm cataloging this and don't want to go
> hunting around for more info, I cannot fill in much relating to the W. I
> don't know the original Work title, I don't know what language it was
> originally written in. This is probably not the first version, since he
> died in 1921.
>
> I need to create a manifestation "entity" without a work "entity". But I
> want my manifestation to have an author and subject headings. What can I
> do? I think I should be able to create an entity based on what I know.
> And if it goes into a larger context where manifestation author: Peter
> Kropotkin and manifestation title: The conquest of bread matches a
> record that also has a link to a work with:
>
> Author Kropotkin, Petr Alekseevich, kni?az?, 1842-1921.
> Work Title Conquête du pain.
>
> Then my data can hook up to that data and in a sense gets connected to
> the W, which I couldn't do on my own. But maybe I gave it the subject
> "Agriculture and Communism" and the W it hooks up to gave it the subject
> "Anarchism". Then my subject enhances the W.
>
> So the W is an ever-changing set that is the sum of the E's and M's (and
> I's) in its universe. And if it's designed as linked data, all of these
> parts can more easily come together.
>
> [In my mind, which draws much better than my hands do, these are like
> tinker toys or jigsaw puzzle pieces, or even molecules, that float
> around and fit together when they meet. So I may have piece f, g, and l
> and the Work has piece g, s and z, and when they meet they form g, f, l,
> s, z.]
>
> kd
>
> -
> -----------------------------------
> Karen Coyle / Digital Library Consultant
> kcoyle@kcoyle.net http://www.kcoyle.net
> ph.: 510-540-7596 skype: kcoylenet
> fx.: 510-848-3913
> mo.: 510-435-8234
> ------------------------------------
>
>
Received on Wed Oct 21 2009 - 15:46:19 EDT