make objectxmlwrap available in c/cxx

[regineheberlein]

I propose making objectxmlwrap, which is currently only available in relation and source, available in c/cxx to facilitate using descriptive fields from other namespaces.

Creator of issue

1. Regine Heberlein
2. Princeton University
3. heberlei@princeton.edu

The issue relates to

• EAD schema issue

Wanted change/feature

Allow objectxmlwrap on c/cxx as an alternative to did and its siblings (I'm envisioning EITHER objectxmlwrap OR current children of c being allowed, but not both, meaning the entire component record would be either in EAD or in another namespace.)

Context

My use case for this relates to item-level description. When describing single items frequently embedded in archival collections--e.g. books, ephemera, drawings, memorabilia--it would be desirable to be able to describe them using domain-specific fields. (This is all the more true because the reason those resources were singled out for item-level description in the first place is likely due to certain features that call for granular description.) EAD3 doesn't easily accommodate a rich structured description of items, thus currently forcing a combination of creative hacks and stringy data.

If it were possible to use elements from different namespaces, that would allow us to create structured descriptions following existing descriptive standards (and encode, say, the publisher or binding of a book (using MARC); the attribution of a painting (using VRACore); the type/attribute/legend/die state of a coin relative to its side (using NUDS) etc.). This in turn would facilitate search functionality and data integration in our library ILS.

I believe the proposed change to be in line with ISAD(G) 1.4: "Manuals setting out descriptive rules for such [special] materials already exist. This standard should be used in conjunction with these manuals to enable appropriate description of special materials."

[karinbredenberg]

Its only when its the lowest c-level so when the level is describing a/an item?
I would suggest either XML-wrap or pointing to another document following the standards (Like in METS and PREMIS).
Not sure I can agree upon removing all the c-level information though, that needs to be investigated.

[regineheberlein]

My particular use case is for terminal item-level c's, yes. I'm not proposing limiting objectxmlwrap to terminal c's, though. In fact, I could see uses for it in ancestral c's as well.

As to allowing objectxmlwrap in conjunction with current children of did--my proposal is to enforce a choice, but if there's a need for allowing them in conjunction, I think it would be perfectly appropriate to leave more restrictive rules to local implementation.

[noahgh221]

Hi @regineheberlein , we discussed this request a bit in our last EAD team call. The group generally opposed modifying the schema to remove the requirement that a c/cxx must have a child did element.

Still, one way to achieve what you are proposing using the current relations model (and without modifying the schema) would be to add a relations element as a child of c/cxx and then use objectxmlwrap inside of relation.

Here's an example:

<c02 level="item">
          <did>
            <unittitle>A Very Expensive Manuscript</unittitle>
          </did>
          <relations>
            <relation relationtype="resourcerelation" arcrole="identity">
              <objectxmlwrap>
                <oai_dc:dc>
                  <dc:title>A Very Expensive Manuscript</dc:title>
                  <dc:creator>Galileo</dc:creator>
                  <dc:date>1600</dc:date>
                  <dc:identifier>ABC.123</dc:identifier>
                </oai_dc:dc>
              </objectxmlwrap>
            </relation>
          </relations>
        </c02>

[regineheberlein]

Thanks @noahgh221. It's a workaround, but it goes against what the relation element is intended for, no? Which is to establish a relationship between entities, agents, events etc. Per the tag library:

"relation records descriptive information about a relationship between the materials being described and a related entity, such as: an archival, bibliographic, or other resource; a corporate body, person, or family; a function; or any other entity."

The hack you propose shoehorns the descriptive purpose--describing an entity itself--into the relationship model by saying the thing itself has a relationship with itself called "identity". But "identity" is just another way of saying "being itself." So that's not right--the thing itself doesn't have a relationship with itself, it IS itself.

My feeling is therefore that this solution is not conceptually sound, and also introduces unnecessary complexity. Why not simply allow <objectxmlwrap> directly to describe it in whatever namespace is appropriate, and avoid the contortions?

[rockivist]

I'm going to chime in with my support for using "identity" relations in this use case. Identity relations are entirely in scope for <relations> - they are used extensively, for example, in SNAC to indicate that two CPF descriptions refer to the same entity, either because those records have yet to be merged, or represent different personas, or for some other reason. We regularly described archival records in multiple schemas - EAD/MARC/MODS, etc. An identity relation is just saying this is the same as that. I'll concede the language in the tag library doesn't make this explicit, but insofar as I can vouch for our intentions, I think it is conceptually sound. We're somewhat blurring the line between relationships among entities being described and relationships among descriptions of entities, but I think that is a separate issue.

Regarding complexity, my feeling is that not requiring a <did> element is far more onerous to the global EAD user base than requiring <relations> in this narrow use case. The contortions here are necessary because there is an obligation to maintain a minimal level of predictability for metadata exchange. EAD is already at the bare minimum of required data, to loosen that even more would worsen that situation. Requiring - and allowing external systems to ignore whatever is in <objectxmlwrap> if necessary - is literally the least we can do with any hope that System A can process EAD from System B.

[regineheberlein]

@rockivist, I agree that the identity ("sameAs") relationship is legitimate when we have two descriptions referring to the same thing. However, that's not the case here--rather, the proposed hack REQUIRES us to create those two descriptions at the same time, in the same record, just to be able to use a namespace other than EAD. I find that problematic.

You would use the identity relationship to assert a sameAs relationship when you have multiple descriptions in different places--say, when you want to link your local MARC record to an OCLC/BIBFRAME record, or your Very Expensive Manuscript described in a finding aid to the same Very Expensive Manuscript described in your catalog (which happens, data management issues aside).

The use case here is different, though: we want to describe one thing, one time, just in a different namespace. I don't see why we would require practitioners to create the same description twice just to be able to accommodate a non-EAD namespace in the second one.

Hence my original proposal: in the c/cxx, require EITHER the did (+siblings) and create the description in EAD, OR require objectxmlwrap and create the description in another applicable standard.

[rockivist]

I get it. My bottom line is that not requiring <did> is an unacceptable loss of interoperability.

[wisserk]

What about making this functionality as a subelement of <did> directly? I'm not sure that that doesn't address the interoperability issue that Mike brings up but it does provide a way to reuse existing descriptive data.

To my mind, each component needs to be identified and that is the function the did performs. Within the <did>, though there are a variety of ways to identify the component. Only one subelement is required, but it can be any subelement. Therefore, making another element an option in the <did>, I don't believe, compromises interoperability more than the other choices already there.

[kerstarno]

Issue review in preparation to upcoming EAD subteam call on 23 September:

@regineheberlein - would the most recent suggestion, having <objectxmlwrap> as a subelement of <did>, work for the use case you have in mind? I.e. something like:

<c02 level="item">
   <did>
     <objectxmlwrap>
       <oai_dc:dc>
         <dc:title>A Very Expensive Manuscript</dc:title>
         <dc:creator>Galileo</dc:creator>
         <dc:date>1600</dc:date>
         <dc:identifier>ABC.123</dc:identifier>
       </oai_dc:dc>
     </objectxmlwrap>
   </did>
</c02>

And, @regineheberlein - would you maybe have an example of descriptive information being encoded in another standard that includes elements, where there doesn't exist an equivalent in EAD3?

@rockivist - any thoughts re the interoperability aspect of this? <did> would still be required in this scenario and it would still be required to at least have one subelement, which could then also be <objectxmlwrap>.

While, in terms of EAD in general, there'd therefore still be a certain pattern that can be expected by users and implementers, I would assume that any information encoded in another standard would need to be converted to EAD anyway, when we talk about aggregation. Especially, if <objectxmlwrap> would be used in such a central place as <did>, which is likely to be used in a central search index or as basis for a standardised display within an aggregated service.

[regineheberlein]

Yes, that could work. I don’t have a data example but something along the lines of a use case. We, as many other institutions, have large author libraries that we treat as archives for a number of reasons. The tend to represent resources on the item or title level. EAD doesn’t fully accommodate bibliographic information, so in our case, we’ve fallen back on a rather ugly hack involving odd. Allowing objectxmlwrap would facilitate the use of proper marcxml fields instead: <c level="file" id="RBD1_c8541"> <did> <unitid type="shelfmark">1.1.1.8</unitid> <unittitle>Post-ality : Marxism and postmodernism</unittitle> <unitdate normal="1995">1995, Spring</unitdate> <container type="folder" parent="RBD1_i192">3</container> <physdesc> <extent>1 folder</extent> </physdesc> </did> <odd> <p>Series: Transformation. Marxist Boundary Work in Theory, Economics, Politics and Culture</p> <p altrender="490$v">v. 1 no. 1</p> <p altrender="260_3">Washington: Maisonneuve Press</p> </odd> <scopecontent> <p>Includes manuscript material.</p> <p>Dealer note: Insérée entre les pages, une courte lettre des éditeurs de la revue Transformation (demande de recension).</p> <p>Check-in observation: Dog-eared page 115.</p> </scopecontent> <controlaccess> <subject source="lcsh">Communism</subject> <subject source="lcsh">Marxian school of sociology</subject> <subject source="lcsh">Postmodernism -- Social aspects</subject> <subject source="lcsh">Post-communism</subject> <genreform source="rbprov">Insertions (Provenance)</genreform> </controlaccess> </c>

[rockivist]

I still object to this change. My bottom line is that it is fine for EAD to include xml in other schemas, hence my support for including objectxmlwrap in EAD3, but at minimum an EAD instance should meet minimal descriptive standards independent from data encoded in objectxmlwrap. If an EAD instance had only objectxmlwrap as a child of the did (at any level), it would effectively cease to be shareable. Another way of putting it would be that any EAD-enabled services should be able to ignore objectxmlwrap and still have an intelligible description to parse.

The current data model - requiring a did as currently constructed and allowing an optional relations/relation/objectxmlwrap - supports this.

I'm not enthusiastic about it, but I might be convinced to allow objectxmlwrap as optional within did, but only if the content model still required one of the current set of did children.

[MicheleCombs]

Sound logic. I agree. Michele

[kerstarno]

Thanks, @regineheberlein and @rockivist for your replies, and thanks, @MicheleCombs, for the further input.

Working for an aggregator, I certainly see Mike's point. On the other hand, working for an aggregator, I also know that the current model does not guarantee that there's an intelligible description to parse. Just saying ;-)

EAD Team will have another look at this issue on Monday and provide further feedback/input afterwards.

[erussey]

I am replying to this thread following a call for comments on the EAD listserv, 12/4. I agree with @rockivist that there needs to be a minimum description within the <did>, even if it's just an identifier.

While I agree in principle with @regineheberlein to reuse/integrate schemas in EAD rather than translating information, in this case, I think it's problematic for generating linked data from EADXML. If implementers are allowed to only provide a <objectxmlwrap> within the <did> at the <c> level, that would mean that the identifier/URI (or the information needed to generate one) for the resource being described would be embedded within the <objectxmlwrap> and possibly unable to be read/parsed (essentially rendering <relations> unusable for any <c> that contains <objectxmlwrap> because there's no resource to relate the information encoded in <relations> to).

I realize this is not a huge concern for most, but something to consider for institutions that are/will be relying on EAD3 to generate linked data rather than storing it natively. Until we have a solid ontology for archival metadata, it's important to keep that functionality intact.

[markcarlsonuw]

I don't think it's prudent to use metadata from a different namespace/standard as a means to replace or supplant some or all of the metadata that the EAD standard allows. If the XML standard you are using is EAD, then the metadata should follow what is allowed in that standard. Otherwise it becomes a data mapping/crosswalking issue between standards that XML itself is not prepared to handle. It seems as others have said that relation should be able to accommodate parallel metadata from other standards either inline or external.

[kerstarno]

Hi @erussey and @markcarlsonuw - just a quick thank you for your initial comments. Good to get a better understanding of the community's thoughts.

[ewg118]

I agree with @rockivist and others that the embedded metadata from a different namespace should not replace the core requirements for the c/did. If I remember correctly, the core requirements for the <did> are fairly minimal. Unit title? Perhaps also Unit date/id and origination? It looks like the EAD 3 schema doesn't technically require anything, but DACS requires at least a little something.

If it is necessary to embed VRA Core, NUDS, etc. directly within your EAD finding aid (rather than store these separately and simply link to them from within the finding aid), how feasible is it to parse out these minimum requirements from your VRA Core and NUDS and automatically insert the did/unittitle, did/origination (with a persname/corpname, etc. linking to a vocabulary system), etc. into each item in the finding aid?

I'm not sure I agree with the semantic application of an "identity" relation here. You are saying that two descriptions (represented by two different URIs) are in fact the same entity. Unless the item has a stable URI in a different system, the identity relation doesn't seem to apply. It's a workable hack, but it seems more logical to introduce <objectxmlwrap> into <odd> and enable a new attribute that allows you to disambiguate odds that have other types of embedded metadata from the odds that are just random catch-alls.

[regineheberlein]

I just don't think it's ever a good idea to describe resources in separate systems based on format. I'd much rather have the ability to describe them natively in the same system. Archival resources are by definition composed of a diverse range of formats. EAD doesn't currently support describing all of them in a comprehensive and structured way. Allowing item-level description from other namespaces would.

[ewg118]

I think we fundamentally disagree on systems and whether or not one monolithic data model can accommodate a wide range of descriptions. Princeton owns over 100,000 coins. There's no way you can or should implement item level metadata for this collection in a finding aid. I pioneered the application of EAD to numismatics. And then I designed the NUDS schema, based examples from TEI, EAD, and EAC-CPF, with a heavy reliance on LOD terminologies, because the EAD approach wasn't comprehensive enough, nor was it scalable.

[regineheberlein]

No, I’m absolutely not arguing for whole-sale item-level description… for anything. Goodness no! I am saying however that there is a need for item-level description in some cases, and so the model needs to accommodate the range of resources concerned. I would think allowing objectxmlwrap is the opposite of one monolithic data model--it would facilitate the description of items in their archival context but in the format-specific standard--i.e., a coin described in its context in an EAD but with the appropriate NUDS fields. At least for as long as we're not describing things in triples, that is. But that's a different topic. Regine Heberlein Library IT Data Analyst 609-258-6156 heberlei@princeton.edu

[kerstarno]

Hi @ewg118 and @regineheberlein - a quick thank you for your further engagement in this topic.

Personally, I understand arguments in favour of both perspectives. As EAD team lead within TS-EAS, I'd hence like to emphasise our plea for use cases and (encoding) examples, as this would really help us in understanding what exactly is needed and in thinking about possible solutions.

[regineheberlein]

Thanks @kerstarno ! Going back to the use case I cited earlier, I suppose it could then look something like this (not claiming perfection here!), which gives structured access to the publisher and series natively in the bibliographic standard, however imperfect it may be:

<ead xmlns="urn:isbn:1-931666-22-9" xmlns:marc21="http://www.loc.gov/MARC21/slim"
    xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="urn:isbn:1-931666-22-9 http://www.loc.gov/ead/ead.xsd" audience="external">
[...]
    <c level="file" id="RBD1_c8541">
        <marc21:record>
            <marc21:datafield ind1=" " ind2=" " tag="035">
                <marc21:subfield code="a">(OCoLC)32590363</marc21:subfield>
            </marc21:datafield>
            <marc21:datafield ind1="0" ind2="0" tag="050">
                <marc21:subfield code="a">HX44.5</marc21:subfield>
                <marc21:subfield code="b">.P67 1995</marc21:subfield>
            </marc21:datafield>
            <marc21:datafield ind1=" " ind2=" " tag="084">
                <marc21:subfield code="b">1.1.1.8</marc21:subfield>
            </marc21:datafield>
            <marc21:datafield ind1="0" ind2="0" tag="245">
                <marc21:subfield code="a">Post-ality :</marc21:subfield>
                <marc21:subfield code="b">Marxism and postmodernism /</marc21:subfield>
                <marc21:subfield code="c">edited by Masʻud Zavarzadeh, Teresa L. Ebert, Donald Morton.
                </marc21:subfield>
            </marc21:datafield>
            <marc21:datafield ind1=" " ind2=" " tag="260">
                <marc21:subfield code="a">Washington, D.C. :</marc21:subfield>
                <marc21:subfield code="b">Maisonneuve Press,</marc21:subfield>
                <marc21:subfield code="c">1995.</marc21:subfield>
            </marc21:datafield>
            <marc21:datafield ind1=" " ind2=" " tag="300">
                <marc21:subfield code="a">v, 334 p. :</marc21:subfield>
                <marc21:subfield code="b">map ;</marc21:subfield>
                <marc21:subfield code="c">23 cm.</marc21:subfield>
            </marc21:datafield>
            <marc21:datafield ind1="1" ind2=" " tag="490">
                <marc21:subfield code="a">Transformation--Marxist boundary work in theory, economics,
                    politics, and culture ; </marc21:subfield>
                <marc21:subfield code="v">1</marc21:subfield>
            </marc21:datafield>
            <marc21:datafield ind1=" " ind2=" " tag="500">
                <marc21:subfield code="a">Includes manuscript material. </marc21:subfield>
            </marc21:datafield>
            <marc21:datafield ind1=" " ind2=" " tag="500">
                <marc21:subfield code="a">Dealer note: Insérée entre les pages, une courte lettre des
                    éditeurs de la revue Transformation (demande de recension). </marc21:subfield>
            </marc21:datafield>
            <marc21:datafield ind1=" " ind2=" " tag="562">
                <marc21:subfield code="a">Check-in observation: Dog-eared page 115. </marc21:subfield>
            </marc21:datafield>
            <marc21:datafield ind1=" " ind2="0" tag="650">
                <marc21:subfield code="a">Communism.</marc21:subfield>
            </marc21:datafield>
           [etc.]
        </marc21:record>
    </c>
[...]
</ead>

[kerstarno]

Thanks @regineheberlein. We'll have a closer look at the example - hopefully in context with other examples that community members might post.

[ewg118]

I think that interoperability is going to be an issue here, especially if you allow an external XML namespace directly within the <c>. In order to allow this, the entire <c> component needs to have its schema requirements relaxed completely to the point that nothing is prohibited. You might as well remove the XSD validation altogether. I think that people are free to do whatever they want in the privacy of their own databases. You can insert MARC directly in a <c> and update your XSLT (or whatever you use to transform XML) so that the titles, dates, etc. are extracted and serialized into HTML or RDF or whatever. But when it comes to aggregating collections across institutions, this isn't going to be workable because you can't assume a large-scale aggregator is going to invest the time and effort and handle every possible data model that has been namespaced into an EAD component.

I really suggest either following the <relation> model above, even if it seems semantically imperfect and then implement in software a solution that will parse out necessary bits of information from your various metadata schemas to automatically populate the <did>. This might not be the easiest solution for you, but it is vital if you want your archival collection to be accessible to the larger archival community.

[markcarlsonuw]

I agree with Ethan. This is especially problematic if your metadata is replacing EAD tags with non-EAD ones; for example, you use Dublin Core <dc:title> in place of <unittitle>. For an external system to understand that, it would need to know how to map every namespace tag to EAD which is impossible not only because it doesn't know how, but because there isn't going to be an equivalent, hence like you said earlier why you end up with "stringy" metadata. Even if there was a one-to-one match like in the case of <dc:title>, this isn't always going to be the case and many times it's going to be a many-to-one scenario. I like the idea of being able to point to the source metadata, especially when you've had to remove granularity, but I think it needs to be a link or in parallel and not a replacement for EAD tags.

[regineheberlein]

EAD already allows this element elsewhere though, so the interoperability question is not new.

[ewg118]

To me, the issue here is figuring out a solution for populating the did with fundamentally required metadata from your namespaced-in complex metadata schemas. Changing the c or did to allow literally any XML element directly for the use-case of one institution will have tremendously negative consequences for data normalization and aggregation across the broader community. I understand the need to prevent duplicative efforts in entering MARC/VRA Core/NUDS metadata and did or c elements, but this strikes me as a problem ameliorated by software, not extension of the EAD3 XSD schema.

A possible workable solution is to extend the odd for objectxmlwrap and standardize a particular attribute that will disambiguate random uses of odd with a very specific usage for capturing complex metadata. If this is documented as an "official" way to encode complex metadata from other schemas, then it becomes a de facto standard model without creating substantial conflicts by relaxing validation on the c and did.

[ewg118]

To add, let's consider this very common scenario:

You're an archivist at a historical society with a small collection of several hundred finding aids. You don't have the resources to run a content management system, so all of your finding aids are created in oXygen. The EAD3 committee changes the XSD to accommodate your use case, allowing all elements from any namespace in the c or did.

When hand editing a finding aid that references the URL for the XSD file on the LC server, there's no longer any autosuggest for elements or attributes in c. There are no red lines that tell you a required element is missing or that it is misspelled. The safeguards of dynamic validation based on on the EAD XSD have been removed. This is repeated at hundreds or thousands of institutions across the globe, just on day 1 after the change has been made.

[markcarlsonuw]

I shudder at the thought... 😄

[doncat]

A new voice in this exchange. I'm a Princeton colleague of Regine's. I support her proposal, because it enables the widest possible range of resource description options. Archival descriptions should not be limited to elements inherited from old-style finding aids. To be most effective and most widely applicable, EAD should have the flexibility to call on other descriptive and encoding practices.
This isn't specifically a plea for "bibliographic" item descriptions to be wrapped in EAD elements for some exceptional case. Rather, I see it as a step on the way to a fuller realization of the re-thinking embodied in RiC. The computing demands are not insignificant but they should not block this evolution.

[fordmadox]

I don't have time to come up with an encoding example just now, but just a quick note to say that I really like Ethan's suggestion to use odd in this case and to keep did as it is.

did is very low barrier, with just one child element being required; and heck, you could add an empty element if so inclined, or even just duplicate the holding repository name here if it was totally undesirable to map something like a title or identifier.

Also, although I have not thought about this too much, if odd, source, and the relation elements were opened so that they permitted any elements in namespaces other than EAD, then perhaps we could do away with objectxmlwrap, which seems unnecessary to me as I've not seen it used in any other XML schemas. Additionally, since odd is repeatable whereas objectxmlwrap is not, you could even embed different descriptions from different standards if you ever chose to do so.

Regardless, I think it's important to allow this in EAD, and if we follow how other schemas open up their schemas, then it would just be a matter of determining where to do that.

[regineheberlein]

I very much like the idea of making namespaces available on elements directly, without the wrapper. I’m still unconvinced about shunting this information into odd, since what I have in mind isn’t “other” descriptive data but THE canonical metadata. Putting it in odd is a way forward to be sure, but not ideal. Another idea to address the interoperability concerns might be to use elements from other namespaces directly in c but leverage the @encodinganalog. The logic could be along the lines of “in the absence of an ead-namespaced element, require at least one @encodinganalog”. The requirement could be further tightened by limiting the value of the attribute. Regine Heberlein Library IT Data Analyst 609-258-6156 heberlei@princeton.edu

[kerstarno]

Quick thank you again to everyone for your contributions and for keeping up the conversation.

@regineheberlein - to be clear about your thought re @encodinganalog, would you imagine this to play out as follows:

<c encodinganalog="NUDS">
  <did>
     <unitid>1</unitid>
     <unittitle>Title of the record</unittitle>
     <nuds:someElementFromNUDS>[metadata that cannot be encoded properly or in all detail in EAD, but is pertinent to the record in question]</nuds:someElementFrom NUDS>
  </did>
</c>

(Not saying, that this should be the intended encoding moving forward, as I am trying to keep myself out of the conversation for now, only trying to understand what's meant and how it could be encoded :-) )

[regineheberlein]

Thanks for checking in @kerstarno !

What I meant is a little different, and a bit of a wild idea / wishful thinking because it obviously would get in the way of validation: the use of @encodinganalog on elements from other namespaces. (Where @encodinganalog doesn't exist.) I fully understand the idea may not be workable in this form, but perhaps it inspires a productive idea in someone else.

I'm basically looking for an elegant way to provide a hook on other-namespace elements to map to the corresponding EAD element, rather than the other way around.

An example of my wishful thinking:

<marc21:datafield ind1="0" ind2="0" tag="245" encodinganalog="ead:unittitle">
  <marc21:subfield code="a">Post-ality :</marc21:subfield >
  <marc21:subfield code="b">Marxism and postmodernism /</marc21:subfield>
  <marc21:subfield code="c">edited by Masʻud Zavarzadeh, Teresa L. Ebert, Donald Morton.
  </marc21:subfield>
</marc21:datafield>      

[regineheberlein]

Unfortunately, I haven't had the time to look into the discussions around the first introduction of objectxmlwrap, where I assume the issue (and difficulties) of parsing elements from other namespaces must have been extensively discussed, perhaps revisiting those might spark further ideas?

[markcarlsonuw]

How do you imagine handling the display of this data from other namespaces? Even if you can figure out how to handle this structurally, it's another thing to be able to handle the end user display so that it displays in any meaningful way, especially if you plan to substitute the new namespace code for EAD. You would need a stylesheet that could handle how to display code from multiple namespaces. I think it's doable but puts a heavy "tech debt" on aggregators to be able to handle it. That's why offering a minimal number of EAD elements while still being able to include more granular code might be the best approach.

[alexduryee]

I'm against this change on a couple of merits:

1. From a systems standpoint, this would be impossible to support - any access system would need to be able to support an arbitrary number of metadata elements. For example, a system designed for taking in, parsing, and displaying <unittitle> strings would now need to parse and render subfields (MARC), <titleInfo> subelements (MODS), plain <title> strings (DC), et al - to say nothing of all of the other standards/fields out there.

2. From a standards standpoint, this effectively turns EAD into a structural standard instead of a descriptive one. By permitting arbitrary XML in place of the <did>, EAD essentially becomes an XML standard for hierarchical description with some recommended fields, instead of one for encoding archival description. Coupled with the fact that multiple descriptive standards could be used across different components(!), I'm not comfortable with this proposal.

As a counter-case - we recently processed a mixed collection of bibliographic materials and archival manuscripts. The bibliographic material received MARC records in our catalog (e.g. https://catalog.nypl.org/record=b22017073) as well as contextual components in the finding aid (http://archives.nypl.org/brg/25777#c1567695). I don't feel that the finding aid would have benefited from bringing e.g. just the 563 note in via objectxmlwrap (or the entire MARC record) versus mapping it to the coarser physdesc - both the bibliographic and archival descriptions do their respective jobs in their respective systems, even though the mappings between them aren't precise.

[kerstarno]

Dear all,

thanks very much to @regineheberlein for bringing this suggestion to the attention of the EAD team within TS-EAS. And thanks very much to everyone else for your comments, feedback and additional thoughts.

EAD team within TS-EAS has talked about this once more during the team meeting on 3 March, trying to take into account everything that has been said in the comments above. We have furthermore been in contact with colleagues from SNAC and Kalliope, where the inclusion of "non-EAS" encodings might be an aspect of the aggregation of information from a broad variety of sources. However, while SNAC has made use of <objectxmlwrap> in its early stages, it does not use the element anymore; Kalliope never made use of it, but prefers to link to existing pieces of information in other metadata formats rather than to include and encode these in the EAS directly.

Based on all of this, EAD team within TS-EAS has decided to not move forward with this suggestion in order to uphold interoperability when using EAD as an exchange and communication format as well as for using EAD in the context of aggregation activities, which follows the arguments brought up in most comments. We would hereby also like to emphasise that EAD is an archival description standard, not a "wrapping" standard that could contain "anything".

To accommodate what the intial use case is looking to do, we would want to strongly recommend the use of the existing solution with <relations> as mentioned in a previous comment (see #517 (comment)).

Thanks very much again to everyone for your input.