Correct <unitTitle> content model

Submitted on Tuesday, April 30, 2013 - 6:46am Submitted values are:

Name: Kerstin Arnold Affiliation: APEx project (Archives Portal Europe) Does this represent an official comment from your affiliated group? Yes Comment: The following represents a common comment of the APEx project responsible for
the continued development of the Archives Portal Europe, especially to the
Work Package (WP) 4 on standards and guidelines, and the "EAD" and "Authority
data" expert groups of the French Association of Standardization (AFNOR) on
the alpha release.

<lb/>, <emph> and <ref> as well as indexing elements (with the @normal
attribute) should be kept within <unitTitle> and the @normal attribute of <unitTitle> should be removed. The content model of <unittitle> is much poorer than it was in the DTD EAD
In EAD 2002, <unittitle> could contain #PCDATA, as well as several elements (abbr, archref, bibref,
bibseries, corpname, date, edition, emph, expan, extptr, extref, famname, function, genreform, geogname, imprint, lb,
linkgrp, name, number, occupation, persname, ptr, ref, subject, title, unitdate). In the Alpha version of the
schema, this element can only contain textual information and the elements <emph>, <lb/>, <ref> and <title>. The decision consisting in removing mixed content only prevailed for
<unitTitle>. At the same time, the <p> element of <scopeContent> or <biogHist> and in fact in any element where it
occurs (relatedMaterial, separatedMaterial, and so on), includes rich content. It does not seem
consistent. It is now impossible to index within <unitTitle>. So, information may be
lost, indexing may be decontextualised. The schema seems to favour the use of <controlaccess>, thereby
differentiating content and indexing. While in France and other European countries, best practices and guidelines
encourage the use of indexing within <unitTitle>, the schema questions this encoding flexibility. Some
institutions (such as the National Overseas Archives) or some collaborative projects (such as the "Calames" gateway of
the Higher Education Bibliographic Agency) built their information system on indexing within <unitTitle>. The @normal attribute was made available to qualify <unitTitle>. Why? should be kept within `<unitTitle>` and @normal should be removed from `<unitTitle>`.</li> </ul> <p>The results of this submission may be viewed at: <a rel="noreferrer nofollow" target="_blank" href="http://www2.archivists.org/node/17190/submission/13137">http://www2.archivists.org/node/17190/submission/13137</a></p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/rockivist"><img src="https://avatars.githubusercontent.com/u/1456132?v=4" />rockivist</a> commented <strong> 11 years ago</strong> </div> <div class="markdown-body"> <p>From @florenceclavaud and Michael Fox: </p> <p>Hi Michael and all,</p> <p>Le 30/04/2013 20:45, Michael Fox a écrit :</p> <blockquote> <p>This posting boils down, as I understand it, to an argument that indexing should be allowed from any of three locations: within unitTitle, within description text such as biogHist and scopecontent, and within controlAccess.</p> </blockquote> <p>Yes, that is what both the APEx project and French community of archivists suggest.</p> <blockquote> <p>Is it envisioned that the archivist would use only one of these or potentially all three in a given archival tradition?</p> </blockquote> <p>Yes. In France several archival institutions and projects use all three ; using indexing elements (i.e.persname, geogname, famname and so on in the EAD 2002 DTD) directly in unittitle or scopecontent, or bioghist when useful, is teached and shown as a good practice. Doing this, when possible, is considered to produce a lighter and more 'fluid' result (specially when you display it) ; indexing in context, when you read the text, gives you some information about the role and position of every entity or term you index.</p> <blockquote> <p><code><title></code> exists within <code><unitTitle></code> because the title assigned to the materials might include the title of a published work.</p> </blockquote> <p>Yes. And the title (formal title or concise supplied title, as ISAD(G) standard says) may also contain the name of a person or corporate body, a geographical name, a record type (I mean what may be indexed using genreform), a topic, etc (or a date, but the date encoding problem has been discussed elsewhere ; I would say that the problem is the same). It may be the same for scopeContent etc. The problem is that at present the new EAD model allows to use persname or geogname and so on within scopeContent (which can contain <code><p></code>), not within unitTitle.</p> <p>What I would like to stress here is that :</p> <ul> <li>once the new EAD model is released, if in 'my' institution or for 'my' project, for some reasons that can of course be strong and legitimate, particularly because the information system is based upon a powerful relational database that does not allow to index directly in a paragraph of text, I will easily write an application profile or subset of the EAD model, which will remove those subelements, say from unitTitle and scopeContent. The EAD instances that this institution or project will create will be valid against the new EAD model.</li> <li>if I consider better to index directly "in the text", not with external controlAccess elements when possible (which can also be seen as a legitimate reason), and if the technical architecture beyond uses for example a file system or an XML database to store the EAD instances, then I will be glad to use an EAD model that allows that, without being compelled to extend it.</li> </ul> <p>Finally, each of these EAD instances of different kinds can be indexed and one will be able to search them through lists of persons, geographical or published works, etc. And of course through any plain text index you want to build.</p> <p>I think the new model should give the archivists this kind of freedom.</p> <p>Best,</p> <p>Florence</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/rockivist"><img src="https://avatars.githubusercontent.com/u/1456132?v=4" />rockivist</a> commented <strong> 11 years ago</strong> </div> <div class="markdown-body"> <p>Closed. Addressed by #230 </p> </div> </div> <div class="page-bar-simple"> </div> <div class="footer"> <ul class="body"> <li>© <script> document.write(new Date().getFullYear()) </script> Githubissues.</li> <li>Githubissues is a development platform for aggregating issues.</li> </ul> </div> <script src="https://cdn.jsdelivr.net/npm/jquery@3.5.1/dist/jquery.min.js"></script> <script src="/githubissues/assets/js.js"></script> <script src="/githubissues/assets/markdown.js"></script> <script src="https://cdn.jsdelivr.net/gh/highlightjs/cdn-release@11.4.0/build/highlight.min.js"></script> <script src="https://cdn.jsdelivr.net/gh/highlightjs/cdn-release@11.4.0/build/languages/go.min.js"></script> <script> hljs.highlightAll(); </script> </body> </html>

SAA-SDT / EAD3

Correct <unitTitle> content model #184