I am doing two things at the moment
1) separating out the Role component
2) reworking the DCSVs in line with comments and also trying to see what
happens if I collapse them all into one.  This is based on the assumption
that since the components are optional different communities can give
guidance as to which components to use for their own types of agent.

Regards,
Robina

-----Original Message-----
From: Diane I. Hillmann [mailto:[log in to unmask]]
Sent: 14 March 2002 15:05
To: [log in to unmask]
Subject: Re: CCP and structured values


Rebecca:

I've been under the same cloud of "stuff" and have been unable to
participate much in the discussions, but I agree with your strategy
here.  It would be a shame to hold the role business hostage to structured
values--separation is the better idea.

Diane

At 04:27 PM 3/13/2002 -0500, you wrote:
>Sorry to have not responded sooner to this; Robina has put a lot of work
>into it. I have been overwhelmed with other stuff, but I also realize
>that every time I have looked at this it's given me a headache because it
>is so complex.
>
>At this point my preference would be to introduce these ideas to the
>Agents group, but really focus on the need to define a role element for
>CCP. That is what seemed to be our charge for the Agents group (that is,
>Robina and mine). Since it is necessary to define these for our DC-Lib AP,
>it makes sense to begin to air it here. Ann's comments have been very
>useful in formulating this proposal, so it has been fleshed out a bit. But
>I think if we concentrate on the role aspect and separate it from the rest
>perhaps we can accomplish one piece of it. I say this because it seems
>like there is consensus that the value of a role element would be a
>qualifier of the CCP elements. The difficult part is how to express it
>given the fact that the list of roles possible is quite long. I would
>suggest that we define the relator terms in the DC namespace, although
>have it maintained by LC in conjunction with our existing list (however
>that is done; did Rachel ever bring this issue up to DC-Architecture?).
>
>Then I think the structured values could be brought to DC-Agents as a
>separate proposal. I would question the need for as much complexity as
>below. The minimum needed (in my opinion) would be name type, affiliation
>(but that could be defined as an institution or an address so could apply
>to personal and corporate), role (considered separately), and ID (to link
>to another record for the name-- but isn't that a separate charge of the
>agents group?). I think we could do without structuring the name as
>below. And if we keep the parts to a minimum we might not need to separate
>those that apply to specific types.
>
>Other response to one of Robina's questions: I don't think the library
>community has use for Instrument or whatever it's called, so as far as the
>DC-Lib AP goes we could leave it out. Event could be used to correspond to
>what we know is conference name (although it's broader and indeed the MARC
>fields that use them include events.) The needs of the wider DC community
>may be different and that would be decided by DC-Agents.
>
>It would be nice to get some consensus on the technique of DCSV for these
>things to move the DC-Lib AP forward. But chances are it won't come that
>fast. So I'm not sure this will be finalized for the application
>profile; but at least maybe we can have a way to include roles at the
>least.
>
>Rebecca
>
>On Thu, 28 Feb 2002, Clayphan, Robina wrote:
>
> > Having had some discussion with Ann Apps regarding Structured Values
> here is
> > a simplified, reworked proposal for using structured values with the CCP
> > elements.
> >
> > Rationale for changes.
> > In my original prosposal I suggested qualifiers for the CCP elements -
one
> > for each agent type.  This followed the DCCite model which has a
Citation
> > qualifier.  The DCCite structured value is to be used, probably with the
> > qualifier, in the Identifier element and possibly others such as
Relation.
> > I suggest this is not necessary in the case of DCSVs for CCP as they can
> > apply directly to the element.  Consequently, the qualifiers of Person,
> > Organisation, Entity and Event superfluous and the proposal becomes much
> > simpler.  DCSVs are essentially encoding schemes.  As I see it, all that
is
> > needed is a DCSV for each agent type which can be used as an encoding
> scheme
> > for any of the CCP elements as appropriate.  I would appreciate any
> thoughts
> > on this.
> >
> > I have also included Publisher this time as, without the qualifiers,
> some of
> > the difficulties disappear.  To this end "Location" has been added as a
> > component in the Person DCSV as publishers are not always
> organisations.  In
> > accordance with the decision reached at the ALA meeting, all three CCP
> > elements are retained but, with the ability to express a role, they can
all
> > be collapsed if an implementor so desires.
> >
> > Other changes:
> > a) include a "Name" component for entering a person's name in its
entirety
> > in one field.  Guidelines will be needed as to whether to use the
separate
> > parts or the whole name or both, and how to enter a whole name.
> > b) include an "Affiliation" component in person.  This is the agent's
> > affiliation at the time of the production of the resource and is not
> > intended to be updated.
> > c)include a "Location" component to accommodate Publisher information.
> > Again, this is the location of the agent at the time of the production
of
> > the resource and is not updated.  Guidance needed as to when to put a
value
> > in this component.
> > d) a component cannot have its own scheme in the manner suggested
> previously
> > (Role (scheme=LCRelators)=Author) so a modification is suggested for
> > comment.
> > e) rename the "Entity" agent type as  ? Instrument ?
> > f) as use of these is not necessarily confined to the DC LAP the "lib"
has
> > been removed from the DCSV names.
> >
> > Outline Proposal
> >
> > The objective of these structured values is to enable extra information
to
> > be recorded about the agent in relation to the described resource.  It
is
> > NOT an attempt to describe the Agent or provide contact or rights
> > information.
> >
> > The four agent types that have been identified in the past are: Person,
> > Organisation, Instrument (variously called Entity, Service, Automata)
and
> > Event. The extra information needed for agents differs according to the
> Type
> > of agent - parts of names for people, dates for events etc.  A
structured
> > value is an encoding scheme: by defining a structured value for each
agent
> > type the components relevant to each type can be entered in a consistent
> > fashion which allows for further machine processing of the data.
> >
> > Components are all optional subject to the best practice recommendations
of
> > the using community.
> >
> > DCSV for personal agents - dcPerson
> > FamilyName
> > GivenNames
> > Name
> > Affiliation
> > Location
> > Role
> > ID (of the agent when it exists e.g. ISADN)
> >
> > Example:
> > <meta name="dc:creator" scheme="dcPerson"
> > content="FamilyName=Clayphan; GivenNames=Robina;
> > Name=Robina Clayphan; Affiliation=The British Library;
> > Role=Author;ID=xxxxx"
> >
> > --------------------------------------
> > DCSV for organisation agents - dcOrganisation
> > Name
> > Location
> > Type (govt, corporate etc)
> > Role
> > ID (of the agent if it exists)
> >
> > Examples:
> > <meta name="dc:contributor" scheme="dcOrganisation"
> > content="Name=Some Corporation; Location=London, England;
> > Type=Corporate;Role=Sponsor"
> >
> > <meta name="dc:publisher" scheme="dcOrganisation"
> > content="Name=Cambridge University Press; Location=Cambridge, UK;
> > Type=Corporate;ID=yyyy"
> > -----------------------------------------
> >
> > DCSV for instrument agents - dcInstrument
> > Name
> > Description
> > Role
> > ID (of the agent if it exists)
> >
> > Example:
> > (I am guessing at possible uses/values here - suggestions welcomed!)
> > <meta name="dc:contributor" scheme="dcInstrument"
> > content="Name=The Flying Scotsman;Description=Steam Engine;
> > Role=?producer of engine sounds?;ID=4472"
> > ---------------------------------------
> >
> > DCSV for event agents - dcEvent
> > Name
> > Date
> > Time
> > Place
> > Role
> > ID (of the agent if it exists)
> >
> > Example:
> > (Again - values/uses are guesswork - suggestions?)
> > <meta name="dc:contributor" scheme="dcEvent"
> > content="Name=Glastonbury Festival 2000;Date=2000-06;
> > Description=Music and performing arts festival;
> > Place=Glastonbury, UK;Role=?source of recording?"
> > --------------------------------------------
> >
> > Dumbdown.
> > A system that recognises these DCSVs can process the information
according
> > to its own way of working.  A simple dumbdown will result in the entire
> > content of the DCSV being rendered as one string in the DC element.
Thus
> > the first example above would appear as :
> > <meta name="dc:creator" content="FamilyName=Clayphan;
> > GivenNames=Robina;Name=Robina Clayphan; Affiliation=The British Library;
> > Role=Author;ID=xxxxx"
> >
> > Specifying a scheme for the Role component.
> > Specification of a scheme within a value component could be by including
it
> > within the value in parentheses but the  '=' would have to be escaped
> with a
> > '\=' giving:
> >
> > Role=(scheme\=LCrelators)Author
> >
> > all of which would show in a simple dumbdown and does not look very
nice.
> > Any suggestions as to how else this could be done are welcomed.
> >
> > Open questions:
> > 1) Is this a useful way to approach the whole issue?
> > 2) Is this still too complicated?
> > 3) Does the library sector want all four of these agent types?  What
about
> > other sectors?
> > 4) Are the components of each DCSV appropriate?
> > 5) How to specify a scheme for the value components.  The Role component
is
> > an example of this  but the same could apply to an ID or a Name (FNF)
etc.
> >
> > Regards,
> > Robina
> >
> >
> >
> >
> >
> > *********************************************************************
> > The information contained in this e-mail is confidential and may be
> > legally privileged. It is intended for the addressee(s) only. If you
> > are not the intended recipient, please delete this e-mail and notify
> > the [log in to unmask] : The contents of this e-mail must not be
> > disclosed or copied without the sender's consent.
> >
> > The statements and opinions expressed in this message are those of
> > the author and do not necessarily reflect those of the British
> > Library. The British Library does not take any responsibility for
> > the views of the author.
> > *********************************************************************
> >