Everyone,
I am just catching up on the "CCP and Structured Values" discussion, so
apologies if these comments have arrived after the discussion is all over!
* I am personally comfortable with the idea of "Value Components" or
"Structured Values", probably because like many of you I did lots of
cataloguing in an earlier incarnation using MARC subfields. But I know
(based on discussions at some previous DC Workshops) that this concept is
opposed by a number of prominent members of the DCMI community. To them, an
element is an element and it can't be decomposed. Those who hold this view
need to explain how they propose to deal with the fact that some elements
are clearly related to other elements and that in many cases that
relationship has a whole/part aspect - such as the parts of a personal name,
or the parts of a postal address. My worry, though, is that we may be
spending time discussing a concept which is going to be rejected by the DCMI
community, and I wonder if we should not be re-testing the concept first.
(I missed DC-2001, so if all this was discussed in Tokyo I apologise).
* When an earlier manifestation of the Agents Group met in Frankfurt in
1999, it proposed the following four Value Components for Agent: Name,
Affiliation, Date range and Jurisdiction [the latter was intended to apply
only to corporate agents]. It was in the subsequent plenary discussion that
the concept of Value Components was questioned by some Workshop delegates.
Those four components were recommended on the basis that they may be needed
to IDENTIFY the agent. (The discussion at the Frankfurt Agents Group
meeting had questioned whether DC elements shouild be used to DESCRIBE
agents).
* I think the Value Component of "Jurisdiction" is an important one that is
not covered by Affiliation and probably not by Location either.
("Jurisidiction" can be defined as: The local, provincial, regional,
national or supranational authority to which a corporate body belongs.
Example: Jurisdiction may be "Australia" when Name is "Department of Finance
and Administration").
* I was interested in Robina's comment that "Affiliation" is "the agent's
affiliation at the time of the production of the resource". This made me
wonder whether there is an argument that the agent's affliation can be
regarded as an attribute of the resource, as well as being an attribute of
the agent. I am however, bothered by the fact that, strictly speaking, it
is difficult to define "Affiliation" as a "value component" for the agent.
It is an attribute that is related to the agent, but not really part of the
agent.
* When I had a go at a strawman Agent Element Set a couple of years ago (see
http://www.nla.gov.au/meta/drafts/dcagent2.html) I drafted the element
"Contact" rather than "Location". "Contact" was defined as "Postal or
electronic contact information pertaining to the agent" and I noted that the
vCard MIME Directory Profile (RFC 2426) specifies a range of elements that
could be considered to be components of "Contact". In normal cicumstances,
one of these elements would be the same as "Affiliation" but this does not
always apply: for example, an author may be based at one institution but
have have prepared the resource as a contractor under a different
affiliation.
I hope these comments are of some use - I am conscious that I have been
out-of-the-loop for some time. As a member of the Agents Group, and a
member of the "DELOS/NSF Working Group on Reference Models for Digital
Libraries: Actors and Roles", I'm happy to help with the discussion of the
Value Components ideas, so that we can (after more than 3 years of talking!)
get some closure on these issues.
Warwick
Warwick Cathro
Assistant Director-General, Information Technology
National Library of Australia
Ph: 02 6262 1358
Fax: 02 6273 3648
Mob: 0411 868 411
> ----------
> From: Clayphan, Robina[SMTP:[log in to unmask]]
> Reply To: Dublin Core Libraries Application Profile
> Sent: Friday, 15 March 2002 23:45
> To: [log in to unmask]
> Subject: Re: CCP and structured values
>
> Here is the simplified structured value to encompass all types of Agent.
> This presupposes that all the LC relator values can be refinements of the
> CCP elements as discussed. This is shown in HTML using dot notation -
> examples of how it may work in other syntaxes will follow in a separate
> email specifically about Roles.
>
> I have called the DCSV "DCMI Agent Detail" as I couldn't think of anything
> else and am reluctant to use "Agent" alone for fear of conflicting with
> anything produced by work on other aspects of Agent. Alternative
> suggestions welcomed.
>
> The assumption is that different domains will give guidance as to which
> components should be used for the types of agent identified in that
> domain.
> The Library AP would, if this proposal goes anywhere, provide guidance as
> to
> which components to use for agents appropriate to library objects.
>
> DCSV for all types of agent - DCMI Agent Detail
> FamilyName
> GivenNames
> Name
> AffiliationLocation
> Description (?for events and instrument/automata/service)
> DateTime (for events)
> ID (of the agent if such exists)
>
> 1) Parts of names are still included as I feel this may be of value for
> mapping to other structured values such as OpenURL.
> 2) I have made Affiliation and Location one component but I still feel
> uneasy about this as to me they seem to express different concepts in
> relation to the resource.
> 3) encoding schemes for components within the DCSV are shown using the
> namespace convention which may or may not be acceptable.
>
> Example 1 (HTML - leaning heavily on examples in Andy's Response)
> Showing a person as creator, organisation as sponsor and a publisher.
>
> <meta name="DC.Creator.author" scheme="DCMIAgentDetail"
> content="FamilyName=Clayphan;GivenName=Robina;AffiliationLocation=The
> BritishLibrary;ID=AAAA:xxxx">
> <meta name="DC.Contributor.sponsor" scheme="DCMIAgentDetail"
> content="Name=Some Organisation;AffiliationLocation=London,
> England;ID=BBBB:yyyy">
> <meta name="DC.Publisher" scheme="DCMIAgentDetail" content="Name=Some
> Publisher;AffiliationLocation=London, England;ID=CCCC:zzzz">
>
> The following examples are guesses at how other domains would use the DCSV
> for the types of agent that have been mentioned in past discussions -
> principally the instrument/automata/service agent and event agent (which
> equates to conferences in current library usage). I have not entered a
> role
> qualifier in either example as I do not what role terms would be used by
> other domains.
>
> Example 2: showing an instrument/automata/service agent.
> (This is for a sound recording of a steam engine.)
> <meta name="dc:contributor" scheme="DCMIAgentDetail"
> content="Name=The Flying Scotsman;Description=Steam Engine;ID=GNER:4472">
>
> Example 3: showing an event agent as contributor.
> <meta name="dc:contributor" scheme="DCMIAgentDetail"
> content="Name=Glastonbury Festival 2000;Description=Music and performing
> arts festival;DateTime=2000-06;Place=Glastonbury, UK">
>
> Regards,
> Robina
>
>
|
