Assertion Description (or Assertion Control)

[SJagodzinski]

Documentation of assertion required

Creator of issue

1. Daniel Pitti
2. SNAC
3. @dpitti

The issue relates to

• EAC-CPF schema issue
• EAC-CPF Tag Library issue
• EAD schema issue
• EAD Tag Library issue
• Schema issue
• Tag Library issue
• Suggestions for all schemas
• Suggestions for all Tag Libraries
• Other

Wanted change/feature

For all properties or relations in EAC-CPF describing the entity (that is, not the control elements, nor the higher level description elements), accommodate the following "meta" documentation as a package of information that is repeatable:

1. Agent making the assertion with respect to the property or relation of the CPF entity (for example: nameEntry, existDates, cpfRelation, ...).
2. Date of the assertion or revision of the assertion.
3. Citation of the source that constitutes or provides the evidence for the assertion. Citation should accommodate both traditional citation of "offline" source/evidence, or Web accessible (a URL).
4. Evidence found in the source. Text.
5. Rules used in formulating the assertion.
6. Note for anything deemed important but not otherwise provided.

Context

Such documentation of each assertion is being accommodated in SNAC, and at this time, it cannot be communicated via EAC-CPF.

The same meta-documentation will also be a feature of ICA EGAD RiC.

[karinbredenberg]

This will be a lot of added information to each element and I guess they all would be optional attributes. Is it only intended for high level elements or for all levels? If endorsed it should be reflected in EAD also.

[dpitti]

The source citation and evidence found in the cited source are currently in control and should remain there. This is a request to accommodate the listed items of data for each assertion of an attribute or characteristic of the described entity, or assertion of a relation between the described entity and another described entity.

There are at least three rationales for this. First, there is a growing consensus in the archival community that archival description represents a particular perspective and understanding, and the role of the archivist in description needs to be documented. Second, description (each and every assertion) should be first and foremost based on evidence, and that the person evaluating the evidence and making the assertion should be documented. It is sound scholarly methodology. Finally, there is interest in scholars in using EAC-CPF (digital humanists engaged in documentary editing, documenting social networks, prosopography), though the current lack of being able to establish each assertion based on cited evidence is an impediment to such use.

Optional. Though recommended. Indeed, it is a lot of data, though there are implementation methods that can ameliorate the economy of providing the data.

[MicheleCombs]

Interesting. I assume an "assertion" is something where documented facts conflict (e.g., two different birthdates for a person), or something that is subjective (e.g., I say Adams was a war hero, you say he was a terrorist). If so, then I can definitely see the value of this.

However I'm not sure I understand item 5. What is meant by "Rules used in formulating the assertion" ?

[MicheleCombs]

Re Karin's point about EAD: only logical use for this in EAD would be bioghist, I think. All other areas of EAD are based on the material being described, so these proposed additional attributes wouldn't be necessary, right?

[dpitti]

When we describe we make assertions about the entity being described. Whether any given assertion is contested or not is a different matter.

When we describe, we do so based on descriptive rules, such as DACS or RDA. What rules we are using is context for understanding the nature of the description, of how the archivist describing gets from observed evidence to the formulation of the assertion. I think this might be clear if you think of controlled name entities. A name is found "in the wild." In an item of correspondence, a birth certificate, .... The name found in the historical record is the evidence. For example, "Daniel V. Pitti." Also found is my birthdate, September 23 1952 (I am now 65 years of age, thank you). The archivists then applies rule in formulating a name entry, and let us say the rules are RAD. The name entry based on the found evidence, is transformed into "Pitti, Daniel V., 1952-"

[dpitti]

It would be just as logical in EAD as in EAC-CPF. It is all description based on evidence, all assertions. The material being described provides the bulk of the evidence if at times not all of the evidence.

…

On Nov 3, 2017, at 9:35 AM, MicheleCombs ***@***.***> wrote: Re Karin's point about EAD: only logical use for this in EAD would be bioghist, I think. All other areas of EAD are based on the material being described, so these proposed additional attributes wouldn't be necessary, right? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[dpitti]

Just to clarify, RAD should have been RDA. SNAC is following RDA for formulation of name entries.

[SJagodzinski]

@dpitti: Can you provide an example for the packages you described above?

Not, sure about this, but I think, a similiar request was implemented in EAG by adding an attribute @source (type: anyURI). The attribute might refer to //control/sources/source with a full description of the source.

[dpitti]

Source, that is, a citation of where the evidence resides, is just one piece. A very important one, but needs to be augmented with additional information on providing the found data, when the assertion is made, by whom, and what rules were used in formulating the assertion. I can dig up examples for you, but I will have to do that later as I am in a rush at the moment. Daniel

…

On Nov 6, 2017, at 8:13 AM, SJagodzinski ***@***.***> wrote: @dpitti: Can you provide an example for the packages you described above? Not, sure about this, but I think, a similiar request was implemented in EAG by adding an attribute @source (type: anyURI). The attribute might refer to //control/sources/source with a full description of the source. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[alexduryee]

I'm in agreement re: citation/evidence metadata in EAC. I'm unsure how I feel about including assertion-level evidence in EAD; evidence regarding names seem like the ought to be in a corresponding authority record, and external sources used for narrative description can be cited via existing elements.

[wisserk]

Alex makes an interesting point about where the evidence should reside. Since EAC-CPF is ostensibly modeled to convey ISAAR(CPF) data it makes absolute sense in that context.

I do think there could be legitimate reasons to also include it in EAD in particular places, although the growing consensus that Daniel refers to at the start of this issue in the description of resources really resides on the decisions that archivists are making (e.g., Light and Hyry's call for a colophon) rather than evidence to be supported by an assertion.

[dpitti]

I happen to drop in on this thread. I am not sure exactly what the second paragraph means: I do think there could be legitimate reasons to also include it in EAD in particular places, although the growing consensus that Daniel refers to at the start of this issue in the description of resources really resides on the decisions that archivists are making (e.g., Light and Hyry's call for a colophon) rather than evidence to be supported by an assertion.

What does "really resides on the decisions archivists are making" mean? And can you provide me with a citation for the "Light and Hyry's call for a colophon."

With respect to assertion level data (assertion of a characteristic or assertion of a relation (e.g. of a CPF entity with an EAD description), it would indeed constitute a lot of information, though, as a practical matter, it is quite feasible to implement making global citations of sources of evidence with a representation of evidence found, and then merely referencing the relevant source or sources when asserting some characteristic of the entity being described, or when making a relation between two entities. This we have done in SNAC.

With respect to rules, well, a simple example. If I am describing, let us say, the person named "Robert Horatio George Minty," I find "Col. Robert Horatio George Minty" "was born Dec. 4, 1831 in County Mayo, Ireland" in a source (Bitter, Rand K. 2006. Minty and his cavalry: a history of the Saber Brigade and its commander. Michigan: The Author.). That would be the person's name. But ... I apply rules (RDA) in formulating the nameEntry: Minty, Robert Horatio George, 1831-. The RDA rules provided the specifications for transforming the evidence into "Minty, Robert Horatio George, 1831-"

[wisserk]

The article I was referring to is: Michelle Light and Tom Hyry, "Colophons and Annotations: New Directions for the Finding Aid" American Archivist, 65 (Fall/Winter 2002), pp. 216-230. In it they suggest that as archivists work with collections they document their decisions and encapsulate those decisions along with relevant information about the archivist in a colophon. They do acknowledge that there are already places within existing archival description structures to includes this information (e.g., ) so I believe the suggestion is more about practice than creating encoding systems to accommodate the data. And they do not suggest a formalized structure for the data.

I'm not clear on the finer points you are making with the Minty example; the alphanumeric string selected to represent a nameEntry is based on the rules, but it does not contradict the source material (and I assume would be based on that source). Perhaps I am just not seeing it; can you parse out the example a little more?

[dpitti]

Thanks for the reference. I think colophon is an interesting metaphor. Most certainly the person or persons processing a body of records are a part of the context and not merely the providers of the context. That is one facet of the rationale for the above propose. Identifying the Agent responsible for making an assertion. Citing the evidence. Citing the rules used in interpreting and formulating the assertion. And a note to (the annotation in the above article?) accommodate any additional factors involved in the asserting that are important context.

I would point out that the above proposal is merely seeking to have the a way to communicate such "meta" information in EAC-CPF (and I would extend it to EAD, as well), not to make it obligatory. As a matter of past practice, providing such information has typically only been done at the "top level," that is, to cover all of the description of a given entity, whether it is a CPF entity, or a record entity, such as a fonds, that is, all of the assertions of characteristics or relations.

While it is not part of the current discussion, I think documenting the description needs to be possible and encouraged for multiple levels of context. Holding repositories, in fact, ought to provide a history of policies and current policies with respect to holdings. For government archives, such policies are largely mandated, but for research repositories ... there are specific collecting policies. While such policies in the past favored "white men," current policies are definitely moving in the direction of being more representative. Good. But, one way or the other, such needs to be documented. Also, and I think that perhaps in SNAC we will move in this direction: all SNAC editors (agents) would also have SNAC descriptions, providing biographical information, education, affiliations, .... and anyone wanting to know who is responsible for a a description, or some portion of a description, would be able "to get to know" the editor.

Now, back to the Minty example. No the data in the nameEntry would not contradict the data found in a source of evident. The nameEntry is simply "made up out of thin air." It is based on evidence. Or should be!! The rules inform the agent employing the rules how to formulate the found data. While a nameEntry is based on found data (two different datum in the Minty example), but it is not literary the found data. RDA would tell you to invert a personal name, where to put the comma, how to formulate the forename or forenames, how to formulated the life date or dates, and so on. And so, if Bob did the formulating of Mint's nameEntry, then we will know when Bob did the formulating, what evidence he used, and what rules he used to transform the evidence into the nameEntry.

[gerhardmueller]

Hope, I got this right, but this issue is related to data provenance. The SNAC case is a good example. We have already similar discussions in context of machine-based cataloging. There is a data provenance standard from the W3C: https://www.w3.org/TR/2013/NOTE-prov-overview-20130430/.
Data provenance is a complex issue especially with regard to a precise definition of use cases, data modelling, and data exchange/reuse of data. I thus recommend to discuss this issue on Friday. It might be necessary to postpone this topic. Maybe, aspects of this topic could be part of the task of the related standards team (Regine). I have at least a feeling that this issue must have an influence on the design of EAD and EAC-CPF.

[cannedit]

My two cents, but - as always - maybe too practical ;-):

So this is mainly about accountability for conclusions in metadata based on bits and pieces of metadata from different sources, so pretty much like footnotes in a book or article; then let's use <descriptiveNote/> for this and maybe only expand the use of this element a bit more (allow it in more other elements)?

And/or align it with the EAD3 follow-up on <note/>: <controlnote/>, <didnote/>, (<descriptivenote/>) and <footnote/>?

[SJagodzinski]

This request was discussed for revision and is solved with a new element and a range of new attributes. Follow the discussion with our topic papers and see the following related issues:

<citedRange> #162
@conventionDeclarationReference #174
@sourceReference #172
@maintenanceEventReference #173
@unit #255

The solution will be explained in our Best Practise Guide.