Stephens, Owen wrote:
> I suppose I'm thinking, is it possible for these relationships to work
> in an implicit rather than explicit way? So, if I were to catalogue two
> items and explicitly state that they share the same author, same title,
> publisher, same publication date etc. do I also need to explicitly say
> that they are part of the same manifestation, or can this be deduced
> from the information available? Perhaps another way of looking at it, is
> given an item in the hand and an item in the catalogue, we expect a
> cataloguer to be able to make the decision that they belong to the same
> manifestation - would it be possible for a system to do the same?
That's what I've been suggesting in some other posts (possibly on the
RDA list -- I lose track of where I am). I don't know if it will work,
but I think it's one possibility we should think about. I assume that
the cataloger has the item in hand but not knowledge of the whole
bibliographic universe that relates to the work and its expressions. So
the cataloger can note certain relationships and can code certain data.
From that, the system could (hopefully) create a variety of displays,
links and other user aids based on that data and data found in other
records. What we need to figure out to see if this will work is: what
are the relationships inherent in defining an expression or a
manifestation? (I'm less sanguine about defining works, but it should be
included in our investigations.) So, for example, if I say "x is a
translation of y" can we infer that x and y are expressions of the same
work? If so, that gives them a relationship, and one that could be
integrated into a system such that retrieval of either brings up both in
the "work-level" display, even though you may not have coded what the
work is. (This is all vague yet, but it's similar to how systems
"frbr-ize" files. I think the difference is that the relationships would
be coded more explicitly and therefore would be more reliable in practice.)
Also, it should be possible to add the relationships between works
outside of the cataloging module. To me, this is like the difference
between creating a catalog entry and creating a bibliography. The
bibliographers in a large academic library will be better situated to
note relationships between works than, say, copy catalogers.
I also assume that the encoding of relationships will make use of
identifiers more than it will of strings. I don't know what kind of
interface we will provide to make this easy to code, but it's one of the
problems we must solve for all of this to be possible. We have examples
of connections (much simpler ones, yes) in a lot of our social software.
The very simple function in LibraryThing that allows you to say "these
two are the same book" is an example of how you can create an interface
that makes it very simple for a user to make an assertion of a
relationship. It isn't this simple when the number of relationships is
large, but we do have to quit thinking that humans will be sitting at
computers coding identifiers into records.
>
>> What I think scares many people is the idea of doing all of
>> this "extra"
>> coding of relationships in the records. That's where we need to 1)
>> figure out what relationships are actually needed and 2) determine the
>> most efficient way to get them into and out of records. That
>> #1 is part
>> of the work that Diane Hillmann keeps plugging, the RDA in
>> RDF project.
>>
> Can you recommend where I should start reading on this? (I'm just being
> lazy, but it is home time on Friday)
http://dublincore.org/dcmirdataskgroup/FrontPage
>
>> It is this need to establish and code relationships that convinces me
>> that we will need something either other than or in addition
>> to the MARC
>> record. MARC is capsule, a closed environment. It is not good
>> at linking
>> to other resources. As a matter of fact, it tends to try to pull into
>> itself related items (in the 77x and 78x fields). I think of it as a
>> kind of macrophage. Regardless of what we use as a communications
>> format, our internal formats will need to be more distributed, more
>> relational. In my experience, the data in MARC is far from
>> ideal for that.
>>
>> Until we do some real work on this it isn't possible to say what we DO
>> need and how different it will be from what we have today. That's why
>> the work is so essential. Right now, we're all discussing this without
>> having any data behind us. I'd rather be modeling.
>
> OK - what is the best thing I can do here? I'm very happy to contribute
> over the general throwing in my 2c worth, but don't want to do my own
> thing, and find the idea of doing a model from scratch slightly
> intimidating - but I'm ready to take part in something beyond just
> discussing it...
Unfortunately there are pre-requisites that we need before we can start
playing with these more operational ideas. I was hoping to use Martha
Yee's RDF to begin to map out the key elements and relationships, using
her work as the start for a kind of thought experiment. I'm having
trouble figuring out where to begin since it's a huge task. I've just
done a comparison of the defined classes in FRBR/RDF, FRBRoo, and
Marth's set, which I will try to blog today. I wanted to do this all on
the futurelib wiki, but both it and blogs make it hard to format
documents that are very complex. Anyway, look on my blog later today.
>
> Owen
>
>
--
-----------------------------------
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 Fri Dec 07 2007 - 12:39:47 EST