Eric has re-organised the qualifiers proposed by the Agents WG for the CCP 
elements, trying to use the framework provided by the Frankfurt Principles (revised). 

Ren notes that if we do anything other than vote on the proposals from the 
agent wg as delivered from them, that this puts a big question-mark
over our process.  

Andy, Ren and I all agree that the proposed agent qualifiers do not all fit 
into the slots provided by the Frankfurt Principles, but have
different views on what the implications of this for the vote is. 

At various times, considerable disquiet has been voiced about the risk of 
apparently breaking our 1:1 principle by including information in the
value of CCP elements that is descriptive of the *agent* rather than the 
resource being described.  

Tom has suggested that the "agent" deadlock might be resolved by 
partitioning-off the troublesome "qualifiers" into a distinct
"Agent-Core" to complement the Dublin-Core (presumably leaving the 
latter with a scope of resources-other-than-agents).  


I like a modular approach, so can see some merit in this, but we need to 
understand very very clearly what the components of an Agent-Core mean when used 
(a) as part of the value of a DCMES description
(b) as part of a Agent-Core description.  

Firstly, we need to understand that there is a subset of the DCMES whose 
values are themselves "resources":  these are CCP, Relation and Source, 
and (since "place" is in the DCT1 list) possibly Coverage.  For each of 
these properties, the value is another resource that may have its own 
description.  We have understood since the 1:1 discussions at Helsinki 
that it is bad practice to mix information describing a second resource 
into the description of the one in hand.  The correct way to handle this 
is for the value of the DCMES element to unambiguously *identify* the 
second resource, so  that a description of this can be retrieved separately, 
if available.  The "authority file" approach, if you like.  Thus, the 
values of CCP, Relation, Source, possibly Coverage, are all, like 
Identifier itself, *identifiers* of other resources.  

However, *identifiers* come in a variety of forms:  for web-retrievable 
resources we have the URL.  This can be generalised to URI, but these are 
not widely understood for non-retrievable resources yet.  

The canonical difficult case is *people*, which are often the value of the 
CCP elements.  Surrogates, such as homepage or mailto might be used at a pinch, 
but truthfully these are inadequate for lots of obvious reasons.  In the 
future these might be regularised somewhat, but for now lets put these aside.  
Of course, we have some traditional "identifiers" for people already: names!  
However, these have some inadequacies, primarily non-uniqueness, so various 
communities augment names with additional information in order to disambiguate 
the objects thus identified.  In the cultural and historical community birth 
and death date is often used, and in the scholarly community, affiliation at 
time of production is conventional.  Thus "Joe Bloggs, 1834-98" allows us to 
distinguish a particular Joe Bloggs from all the others, as does "Joe Bloggs, OCLC".  

Note that each of these identifiers includes several components:  
in the first case, family name, given name, year of birth, year of death; 
in the second case, family name, given name, affiliation.  So these 
identifiers might be structured more explicitly still only containing 
the same information in a form such as 

family:Bloggs;given:Joe;birthYear:1834;deathYear:1898;
family:Bloggs;given:Joe;affiliation:OCLC;

Looks like a structured description of Joe Bloggs himself, you are 
saying to yourself ...  But that breaks the 1:1 rule, doesn't it?  
Well not really, this time.  I would assert that, when used as a 
component of an identifier, which is all that the value of any of 
the CCP elements are allowed to be (see argument above), then these 
each of the components of these strings are there solely to 
disambiguate the identity of the guy himself.  They are totally 
legitimate parts of an identifer.  

OTOH, if you actually want to find out information about Joe Bloggs, 
are you going to go to the metadata of something that he created to 
find it?  Not the definitive version if you have any sense.  You might 
find some information that is useful in an informal setting, but just 
as you don't rely on information presented on the title page of a book 
or article to find a definitive bio of the author, you don't think of the 
information embedded in an identifier as the definitive description of 
the agent.  It will, hopefully, have enough detail to identify the agent.  
In order to accomplish this you might find some information that is 
descriptive of the agent, but the intention is not to describe them, 
but to identify them.  

So, if the agent-core does get up (might be a good idea, but it is a 
different project), then some pieces of the information that would be 
stored in that form might also appear as part of a particular form 
of identifier as well.  In fact, it might be useful for the people 
designing the two things to collaborate, but they should be quite 
clear that there are two tasks here:  identification, and description.  

-- 
Best			Simon