________________________________________
From: Heidrun Wiesenmüller [wiesenmuel...@hdm-stuttgart.de]
Sent: January-11-12 3:53 AM
To: Resource Description and Access / Resource Description and Access
Cc: Brenndorfer, Thomas
Subject: Re: [RDA-L] Some comments on the Final Report of the FRBR Working 
Group on Aggregates

>Thomas Brenndorfer wrote:

> >That's an excellent point, and I see the difference better now. I had
> >begun mulling over the comparison of an "aggregate" -- a collection in
> >the conventional sense -- and "aggregating", a new concept referring
> >to the effort to bring things together. The aggregating work and
> >aggregating expression are entirely new entities that refer to an
> >effort of arrangement, and not the collective effort for the
> >individual works.

.....

>So a large part of the things which are normal for works do not apply to
>aggregating works. I find it especially problematic that there are
>almost no relationships, as FRBR (as I understand it) is all about
>making connections between things (entities). Taken together, I get the
>strong impression that an aggregating work is no proper work at all, but
>only a "pseudo work".

I think (at this point in my explorations) "aggregating work" and "aggregating 
expression" are not the right tools to use to describe what's going, although 
they do point to an interesting problem.

The tools to use shouldn't be something like Group 1 entities, but rather 
something like relationship elements.

There are three tools to use: entity, attribute element, relationship element.

The "-ing" word "aggregating" points to an effort, an activity, a role. There 
are numerous relationship designators that capture those kinds of processes in 
RDA already.

Specifically, the RDA relationship designators "editor of compilation" and 
"illustrator" are useful to look at.

These are "contributor" relationship designators between persons (or corporate 
bodies or families) and expressions.

But the report on aggregates follows up on the FRBR revision for expressions, 
where "augmentations, such as illustrations, notes, glosses, etc. that are not 
integral to the intellectual or artistic realization of the work, such 
augmentations are considered to be separate expressions of their own separate 
work(s)." ( http://archive.ifla.org/VII/s13/frbr/frbr_current3.htm#3.2 )

Therefore, something like "illustrator" as a contributor to an expression is 
problematic. An illustration augmenting a work is now considered an expression 
of a separate work, not part of the expression of the original work. So the 
"illustrator" shouldn't really have a relationship to an expression, but rather 
be considered a Creator (specifically with the RDA designator "artist") of an 
illustrative work that augments another work. The report would then have the 
two works (original work and illustration) realized as two expressions found 
together in an aggregating expression. There is a problem here, but maybe there 
are better solutions.

RDA would have it differently...

RDA 20.2.1.1:
"For expressions consisting of a primary work accompanied by commentary, etc., 
illustrations, additional musical parts, etc., the writers of commentary, etc., 
illustrators, composers of additional parts, etc., are considered to be 
contributors."

This gives greater weight to what a "contributor" is -- I think this even 
removes the need for the aggregating work and aggregating expression, but it 
might lead to a redefinition of the existing elements.

For example, in this light, here's how I would recast what an illustrator is....

Illustrator - is a person who supplements (or augments) a work by creating an 
illustrative work that is expressed with an expression of the work

That tiny designator, "illustrator" packs quite a punch -- it carries within it 
a notion of a work (the illustrative work), and it points to the two 
expressions combined together that form a specific, augmented expression that 
explicitly realizes only one work -- the original "primary work".

The problem is: what to make of that augmented expression. Is it two 
expressions realizing two works? Or is it one expression explicitly realizing 
one primary work, but also capturing a hidden relationship to another work via 
the relationship designator "illustrator"?

I think the latter definition is OK. If FRBR was revised to avoid the 
proliferation of expressions, then an "aggregating expression" just 
reintroduces the problem, as aggregating expressions exist in principle for 
every instance in which there are augmentations.

In RDA, these are attributes of expressions that point to augmentations that in 
principle are expressions of other works:


7.12  Language of the Content
Examples:
Commentary in English
In Polish; tables of contents and summaries in Polish, Russian and English

7.14 Accessibility Content
Example:
Closed captioning in German

7.15 Illustrative Content
Example:
illustrations

7.16 Supplementary Content
Example:
Includes index



>> 2. An expression with components embodied in the manifestation (whole-part 
>> relationships can be found here, with relationships between the individual 
>> >> expressions and the whole). These whole-part relationships are still 
>> allowed in the report with its suggested rewording in FRBR 3.4.

>This has me completely mystified. Perhaps it really means that an
>aggregating work and a conventional aggregate work can coexist at the
>same time (although the Working Group couldn't be bothered about how
>this should be modeled). But what, I wonder, could be the point of
>having both at the same time, especially as there can be no
>relationships between them?





The definition of aggregate as being more than one expression in a 
manifestation leads to a paradox with an expression of a collective work. If 
it's "one" expression, then there is no aggregate, by definition, as there is 
only "one" expression embodied in a manifestation. But if each work has its 
component works identified, then there are suddenly many expressions embodied 
in the manifestation. In this case there still really shouldn't be an 
aggregating expression and aggregating work, because the original collective 
work has all the roles covered. Who's left to do the aggregating? The original 
creator(s) responsible for the different works in the collective work have 
already done the arrangements.



For works that are arranged in a new collective work later...

In RDA, when someone comes along after the fact, a relationship designator is 
used connecting a person to the collective expression of the work.



The RDA contributor relationship designator, "editor of compilation":

Definition: "A person, family, or corporate body contributing to a collective 
or aggregate work by selecting and putting together works, or parts of works, 
by one or more creators."



So, while this person contributes to a collective work , the relationship is 
that of contributor to the expression. There isn't a need to create phantom 
entities like aggregating work, since the process or role of aggregating is 
what matters, and that can be defined as a relationship.



That the relationship element is connected to an expression means that there 
might be a lot more expressions, which runs against the grain of the FRBR 
revision to expressions. But I think this could be preferable to the 
proliferation of pseudo-entities like aggregating expression and aggregating 
work.



I think further exploration should look at the relationship elements, and 
perhaps the attributes, as the tools to use. Relationship elements can become 
entities, in that they may need to be described with attributes, and have new 
kinds of relationships with other entities. To get the idea from something 
similar, in RDA, there is one outlier relationship element -- the "Numbering of 
Part" relationship element. It wouldn't exist on its own and would need to be 
paired with a relationship designator like "in series". Perhaps the 
"contributor" relationship element can be embellished with distinctions to 
relationships to the primary work and to augmentations.



Thomas Brenndorfer

Guelph Public Library

Reply via email to