At 08:50 PM 11/17/2008, Karen Coyle wrote:
>Roles like "illustrator" would be defined in the scheme as being of
>type "rda: contributor", and contributor would be a class with a
>definition something like dcterms:contributor. So when you use
>"illustrator" it is implied that it is a member of the class
>"contributor" but you wouldn't include "contributor" in your actual
>data. The classes act like categories or groupings of properties; they
>aren't used as properties in the metadata.

OK, except that the RDA relationship elements (such as creator, 
contributor and publisher, but also manurfacturer, distributor, and 
owner) are not limited (or even necessarily equivalent) to the DC terms.

>The key thing is that the role *is* the property, not something added
>on to the property. This is very different from how we view agents
>today in our records.

In a sense I agree with this, although (using RDA language) the role 
is an attribute or property of an element -- the relationship of 
which it is a sub-category.  The fact that in RDA relationships have 
properties is one of the key structural requirements for supporting RDA data.

>Because the role is the property, roles would have a greater
>importance in the library metadata than they have today, where they
>are treated somewhat as "afterthoughts" on a field.

I agree completely with this.  One of the most obvious lessons of the 
FRBR model and attempts to mine current data to map it to FRBR 
entities and attributes is that we have not taken roles seriously enough.

>  That's why I said
>above that we will need some general properties for agents to indicate
>when the agent role is not being specified, such as for names
>illustrators or translators that are in headings without a role. There
>will need to be a property that is defined something like:
>"contributor without specified role."

It isn't clear to me that this is the only (or the best) way to 
handle this, but I won't press the point.

         John