I believe in all Berne convention countries, a copyright doesn't exist
until text is set down in physical form, so it's not a legal object in
that way, i dont' think, until it exists _somewhere_. (Maybe only in
manuscript form, but that's still a manifestation, even if it's locked
in a bank vault somewhere and you don't have it.)
How can you catalog something that doesn't exist, anyway?
But, sure, I suppose possibly in some edge cases there will be call to
catalog something which doesn't exist or which no cataloger actually has
access to. To me that seems a peculiar edge case which shouldn't
distract from the more general usefulness of considering expression (and
work) as a set of manifestations. Otherwise we get all platonic and
start talking about cataloging things that don't actually exist as a
general practice, which to me only leads to confusion. We don't
generally catalog abstractions, we catalog information resources (and in
my opinion sets of information resources like 'works', to the extent
that even today we sometimes attach "non preferred headings" (aka "lead
in terms") to uniform title records, essentially attaching an attribute
to the 'work', to the set of manifestations belonging to this work. But
the cases you'd create a uniform title record for something which has
_no_ manifestations anywhere are vanishingly few, if existing at all,
and I don't think that's a coincidence. )
Jonathan
Dan Matei wrote:
> Friends
>
> I beg to disagree on viewing the expressions (only) as sets of manifestations. As abstractions of manifestations, yes.
>
> Also, an expression could be a legal object, which exists even before one manifestation of it exists: it is the object
> of a copyright and it could be "reified" in the contract between the publisher and the right holder.
>
> Besides, when we say "this book is about The Bible", we mean "The Bible" not as a set of expressions, but as an
> abstraction of all its expressions.
>
> On the other hand, I agree with Karen that it could be (conceptually, or even technically) useful to have an
> abstraction of all the FRBR classes, say "entity", because they share some properties (e.g. being a subject of a work
> or having a type). See attached my ("ancient", i.e. 2003) UML diagram of FRBR :-)
>
> Dan Matei
>
>
> ------------------------------------------------------------------------
>
Received on Wed Oct 21 2009 - 16:50:41 EDT