conflicts with IDs

[Peter McCartney]

Weve run accross an issue that i dont think has yet been discussed in
our many debates over identifiers and key definitions in the schemas. At
CAP we have made extensive use of embedding eml-dataset and eml-citation
documents inside the methods section of eml as a means of providing the
lineage of a dataset. our xylopia web services are all written to
automatically generate methods elements and embed the eml from input
data for each output metadata document. In submitting files to the LNO
harvester we have encountered several instances where identifiers from
the included document have conflicted with ones in the larger document.
while one can come up with a variety of solutions to avoid the
conflicts, they almost invariably involve creating some degree of
depencency between the two eml documents that we were not initally
prepared to deal with. For example, the identifiers used to identify
conenctionDefinitions is the same between the two documents and thus
conflicts. However, it seems awkward to change the ConnectionDefinition
element in the embedded one to use a <references> element pointing to
the same element in the enclosing EML, making that information useless
should someone attempt extract that embedded eml and use it
independently. I don't think we want this system to force us to use one
set of ids when i spit out eml for dataset 28 and another when i spit
that eml as a datasource within the eml for dataset 118.

We are encountering other id conflict issues when trying to submit to
the harvester that point to issues we have alread recognised as
problematic - specifically, we are assigning ids to eml-party sections
with the system scope option so that we can identify that this content
came from a specific source, but these ids can potentially conflict with
other ids defined under other systems (a ces_party id of 117 conflicting
with a ces_citation id of 117).

to me, the problem is that we clearly recognize that our handling of
identifiers within eml is not satisfactory, yet we are going ahead and
enforcing it with the key definitions that put constraints that are
turning out to be very difficult to reconcile. 

I dont really have a suggestion at this point - just putting in on the
table as something to think about.
-- 
Peter McCartney <peter.mccartney at asu.edu>