At 05:07 PM 11/20/2008, Diane I. Hillmann wrote:
>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.
No, the relationship to the Group 1 entities was based on explicit
text in FRBR.
>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.
That is because they do not agree with the explicit specifications in
FRBR. That is their right. I will not argue that FRBR is always
correct. However, they cannot call what they are doing an
application of FRBR if they refuse to abide by that is clearly and
explicitly stated in the text of the FRBR document.
>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.
In general that may be true, but RDA is based on FRBR as written --
not as some people feel it ought to have been written. I have no
objection to application profiles -- in fact, I think that we need
them -- but they cannot be profiles for applying FRBR if they ignore
or reject the FRBR specifications.
I am hoping that some of this may be easier to deal with when we have
the FRBR element set registered. That may clear up some things, such
as the internal relationships among the FRBR entities and attributes,
and allow us to relate the RDA elements directly to their FRBR equivalents.
>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.
I think you need to decide whether you are registering the RDA
attributes and relationships or the set of all attributes that might
have the same names. If you provide enough flexibility to ignore
explicit features of the FRBR model and the RDA element set -- and an
explicit and rigorous mapping between the two is an inherent part of
the RDA element set -- then you are NOT registering the RDA
attributes accurately.
If you are not willing to accept these specifications, then this
entire exercise has been mis-characterized as the registration of the
RDA element set.
>There are, as you mention below, no explicit elements of Creator and
>Contributor,
But Creator and Contributor ARE elements -- see RDA 19.2 and 20.2
respectively. It is the subcategories defined in Appendix I that are
not elements -- but which we have conceptualized as element sub-types.
>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.
This isn't clear to me and I need to consider it more carefully
before replying. I have been agreeing with Karen that it makes sense
to have a logical list that includes both the relationship elements
and the specific roles identified in Appendix I. I'm not sure what
that means in terms of the Registry. As I say, let me think some
more about that.
>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.
No argument, so long as it is clear the range of options within which
an Application Profile for RDA can operate.
In haste and some heat -- for which I apologize.
John Attig
