At 03:26 PM 01/28/2000 +0800, Simon wrote (in response to Andy):
> >
> > In describing a Resource-A that has a Creator-B we have two things to
> > describe - therefore we should have two spearate, but related,
> > descriptions.  The '(resource) type' of Resource-A should be part of the
> > description of Resource-A.  The '(agent) type' of Creator-B should be part
> > of the description of Creator-B.
>
>Yes.  This is one guise of the 1:1 rule.
>
> > The current discussion seems to be based on the premise that it is somehow
> > useful and necessary to indicate the '(agent) type' of Creator-B as part
> > of the description of Resource-A.  I think this is fundamentally wrong.
>
>I would phrase it differently.
>The discussion is based on the premise that it should be possible for
>the Agent-type of Creator-B to be available through a description of 
>Resource-A.  In a clean implementation this is likely to be through an 
>indirect route.
>In "dirty" implementations, it might be stored embedded in the metadata 
>for Resource-A.
>
>The latter has already happened.
>So from here I see just a few alternatives:
>(a) consider the Agent-type to be part of the agent-identifier,
>according to some not-necessarily-pretty scheme;
>(b) have a clean model in mind in the background,
>and a clear way to map the dirty metadata into it;
>(c) paint ourselves whiter-than-white,
>but get left behind by all the implementors.
>
>IMHO a combination of (a) and (b) is both pragmatic and also
>does not do any real violence to the clean model.

This is basically how I see it, too.  What we're looking at here is a 
compromise, and it's vitally important that we recognize it as such and 
keep our focus on what a "clean model" would look like, NOT chaining 
ourselves to present limitations.  Andy wasn't there (but Simon was) at the 
first Datamodel WG I attended in Dublin, where I spent many frustrating 
hours trying to make the point that information on the "person-ness," 
"corporate-ness," etc. belonged with the description of the CCP, not the 
description of the resource.

Certainly a great deal of the push for this comes from the library 
community, where it is primarily a mapping consideration.  Without it, all 
names go into one field, and this makes people very uncomfortable.  The 
irony is that, even in the MARC world, the distinction thus maintained is 
largely irrelevant--processing for name headings is largely a text matching 
ritual, and the tag level indication of what KIND of name one is matching 
to is ignored.  Those libraries working in an environment of true linked 
authorities also ignore the distinction--the name is carried in the 
bibliographic record as a numeric value, which is called up for human 
display, but not maintained as a bibliographic heading.  The correct tag is 
generated by the tag value in the authority record, which maintains the 
name distinction we're talking about here.  I think that latter is the 
model we'd like to see for DC.

So, what we're now talking about, in essence, is making the same mistake in 
DC that we made in MARC, carrying information in the wrong place.  Well, 
I'm an old broad, and I've seen a lot of that sort of thing, so I say, "Let 
them that wants to do this stuff, go ahead and do it, and not learn from 
our mistakes."  We'll have our chance to say, "I told you so."

So, it's true that people say over and over that they want this--sadly, I 
think they know not what they ask.  The best we can do is find a way to let 
them do what they think they want to do, in some way that does not infect 
the rest of the qualifiers for ever more.  We need to be very explicit 
about this, I think, and Simon's proposal does that.

Diane


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%