John:

I went back to the original document, and tried to reconstruct my 
thinking as I was adding the roles.  It's coming back, but slowly.

As I was adding those roles to the registry, I had two thoughts.  One 
was that the relationship to the Group 1 entities explicit in the 
document itself seemed to be based on a particular point of view of how 
WEMI entities would be described in one particular part of the 
community--traditional text based catalogers.  At that point we were 
deep into the discussions of the Scenarios that I had put up on the 
DCMI/RDA TG wiki, and it was becoming really clear that the specialized 
communities of practice weren't looking at the FRBR-based description in 
the same way.  So the issue of making that relationship, from these 
roles to the Group 1 entity to which they are associated, is, in a sense 
almost more a function of an Application Profile, rather than a part of 
the formal representation of that particular role.  It's only by making 
the relationship there between the roles and the Group 1 entities (which 
I think Gordon is planning on registering as classes, not elements), 
that we can have the flexibility to allow, say, the people cataloging 
novels and those cataloging films or other kinds of multimedia the 
ability to express how they see "works" being described and related to 
other Group I entities in their particular environment.  If these 
relationships are explicitly made, as the document seems to suggest we 
do, that doesn't allow for any of that flexibility--applications will be 
built that only allow one view, and everyone who uses RDA will have to 
use that one view, or build other roles in parallel to the ones already 
there, but related to different entities.  Though we know that the 
current list of roles is only a first stab, it seems a tough sell to 
insist that those with a different view have to declare new properties 
with different relationships to use RDA the way they want and need to 
use it.

There are, as you mention below, no explicit elements of Creator and 
Contributor, because these notions seem in RDA a kind of shorthand for 
the envisioned relationships with one or another of the Group I 
entities.  The problem is, that without specific properties of Creator 
or Contributor, you can't make these roles into sub-properties. It may 
be, that if the WEMI entities are to be considered classes, the roles 
might be subclasses, but that doesn't sound right to me, and I start 
getting into deep water even thinking about it.  There is probably more 
than one way to do this, but it seemed to me when I was adding the roles 
to the Registry that there were still unanswered questions, at least in 
my mind.

However, what this suggests to me is that getting to the point of 
thinking concretely about Application Profiles is something we ought to 
be doing sooner, rather than later.

Diane

John Attig wrote:

At 03:13 PM 11/19/2008, Karen Coyle wrote:
> Thanks, John. Some comments below:
>
> On Wed, Nov 19, 2008 at 10:41 AM, John Attig <[log in to unmask]> 
> wrote:
> > 1) Although they are set out in different parts of RDA, my 
> understanding is
> > that the list of roles under contributor (RDA Appendix I.3.1) are in 
> fact
> > conceptually subproperties of the contributor relationships (RDA 20.2).
>
> I think the relevant question is: will an RDA description ever have a
> property "contributor" or will a specific contributor always be used?
> I believe that with the former, you then have contributor and
> subproperties of contributor; with the latter, contributor may be seen
> as being abstract, and thus a class rather than a property.
>
> In DC, "contributor" is a property that can be used alone in metadata
> without any further subproperties.

Yes, the role element is not required and would be used only when a 
cataloger chooses to assign a more specific category than simply 
"contributor". We hope that application guidelines will encourage 
catalogers to record specific roles, but that is definitely in the 
application profile, not RDA itself.

> > I can't disagree with any of this -- particularly because you will 
> find both
> > the RDA chapters on relationships (section 6, chapters 18-22) and the
> > corresponding sections of Appendix I are divided into relationships to
> > works, expressions, manifestations, and items.  The owner or binder 
> has a
> > relationship to the item; the printer has a relationship to the
> > manifestation, etc.
> >
> > Perhaps part of the hang-up is that you seem to be taking 
> "contributor" in
> > its DC sense; in RDA, the scope of Contributor is very restricted: a
> > contributor is a person, family, or corporate body that has a role in
> > realizing an expression.  We do not use the term contributor for any 
> other
> > type of relationship; therefore the owner, binder, and printer are NOT
> > contributors in RDA.
>
> Thanks for clarifying this. Is there some "bucket" description that
> would work for owner, binder, and printer, or are they kind of on
> their own?

No, because these related to different FRBR entities.  Owner is a 
specified relationship to an _item _(RDA 22.2). Binder is a subcategory 
of "Other person ... associated with the _item_" (RDA 22.4) and is 
listed in Appendix I (I.5.2). Printer is a subcategory of "Manufacturer" 
which is a specified relationship to a _manifestation_ (RDA 21.5); 
printer is listed in Appendix I (I.4.1).  We are trying to be rigorous 
in assigning attributes and relationships to the proper FRBR Type 1 
entity, so that we can design data structures and services around these 
entities.

> > It would be helpful to specify instruction numbers when citing 
> definitions
> > -- or are these from the glossary?
>
> Sorry, I was looking at the glossary (since I'm trying to update the
> elements in the registry with the current definitions, it's on my
> desktop at all times). I haven't gotten back into the text for a
> while, I admit. It's on my to-do list.

That isn't a problem except when the missing context of the definitions 
is important.

>  In any case, the definition of
> > Publisher's Name is from 2.8.41, this is followed by an instruction 
> on how
> > to record the Publisher's Name that (eventually) takes you back to
> > instructions that specify transcription from a specified source and 
> provide
> > details about what is meant by transcription.  So, while you may be 
> correct
> > that the definition itself does not limit this element to a transcribed
> > string, the instructions as a whole are very clear that it is 
> exactly that.
>
> OK, so we can treat Publisher's Name as transcribed data -- which
> basically makes it a non-linking element (e.g. it won't have a URI for
> the publisher in it).

That would be my assumption; if you need a linking element, you would 
use the Publisher relationship element and give either an access point 
or an identifier for the related corporate body.

> > Your other definition is, I believe, taken from 21.3.1.1.  This 
> element is a
> > relationship between the manifestation and the person or corporate 
> body that
> > acts as publisher.  While there is a logical relationship between the
> > Publisher's Name as an attribute of a manifestation, and the Publisher
> > relationship, they are not identical; the latter is a relationship 
> between
> > two entities and may consist of the access point for the related 
> entity;
> > access points are normalized strings that apply to all instances of the
> > entity, and are not necessarily the same as the Publisher's Name as it
> > appears on any given manifestation.
>
> So RDA describes both a transcribed publisher name and a Publisher
> entity? That's good news. Now I need to read the "core" elements
> section, I think.

Again, we have tried to make a clear distinction between the attributes 
of the resource -- most of which are non-linking in your terminology, 
and relationships whose purpose is to link to a related entity.  In a 
sense, we are forcing catalogers to be explicit about relationships 
rather than attempting to construct them from descriptive elements.  
[The 490/8XX distinction that was considered by MARBI recently is 
another aspect of this same tendency.]

We have not made relationship elements that correspond to every 
attribute.  In the general taxonomy of bibliographic relationships 
proposed by Barbara Tillett, there is a "shared characteristics" 
relationship; the JSC decided that this did not need to be formally 
treated as a relationship, because it is essentially just the presence 
of the same value in the same attribute in different metadata records.  
With so many controlled vocabularies for RDA elements, this should work 
quite well in practice.

For a while I had a pr