Revise relationships model and related elements

[rockivist]

Submitted on Tuesday, April 30, 2013 - 5:23am Submitted values are:

Name: Sibille Claire Affiliation: French Association of Standardization, French archival
institutions and libraries Does this represent an official comment from your affiliated group? Yes

1.3. Relation element and other older ones

Relationships model should be revised (it is a key element for the Beta
version).

If elements like <relatedMaterial>, <separatedMaterial>, <repository>,
<origination>, <otherFindAid> are kept (which seems good to us as they can be
seen as specialized relationship elements), their content model should be
reviewed so that it should be (at least optionnally) as close as possible to
the content model of the new <relation> element. Last year, Florence Clavaud
sent a proposal on these old elements on the list of TS-EAD (3rd August
2012).

[MinnesotaFox]

The whole relations concept, taken from CPF, does not translate well into EAD for a host of theoretical and practical reasons.

Since we lack a concrete model for how relationships work in the context of the the description of archival records as opposed to the context of providing information about corporate, personal and family,entities, I suggest that the adoption of the proposed model at this point is premature, unworkable, and likely to create problems from which future archivists will have to extricate us.

I believe that it was Florence who pointed that there likely to be many other types of relationships that we have not already identified.

When we do this, we will want to do it right, fully, and on a principled basis.

[MicheleCombs]

Other than <origination>, I too have had a good deal of difficulty applying the relationships model to archival description, particularly with things like <repository> and <otherfindaid>. The fact that a collection is housed in Building A, or that there is also an Excel spreadsheet listing of it, does not, to my mind, create a "relationship" between the collection and the building, or the collection and the Excel file. Perhaps it's a philosophical question ("What do we mean by 'relationship'?") but even given the most generous definition, such "relationships" as these would at best be temporary and incidental, with no connection to the actual archival content.

[anarchivist]

I disagree with @MicheleCombs here.

<repository> is not about what building the material is in, but rather the organization which maintains and/or provides access to the materials described.

<otherfindaid> is not just about Excel spreadsheets, but any number of alternate representations or supplemental sources of descriptive information, not the least of which are guides that have been published as monographs.

[MicheleCombs]

Fair enough, but my point still stands: those things are incidental to the archival material. The collection might just as easily be housed in some other repository, or it might just as easily have some other type of description. And if it were or it did, nothing about that archival material would change. There is no intrinsic connection, certainly not in the way there is, for example, between a collection and its creator.

In EAC-CPF, one would (presumably) encode only substantive relationships, not incidental ones. For example, if you were doing a record for John Smith, would you add a <cpfRelation> for every single person he ever met? No, you'd only put in the ones that were significant, that (presumably) affected John Smith himself somehow. How would you decide if they were significant? If they were supported by the material in John Smith's papers (wherever they are), or perhaps by other reliable sources about John Smith.

Likewise, one could argue that in terms of archival description, the substantive relationships are those that pertain to the archival material itself (e.g., who created it, who added to it, who's mentioned in it), not where you have to go to look at it or what third party wrote something about it.

But again, I suppose it all comes down to your definition of "relationship" :)

[svassallo]

I'm not so comfortable with the idea that an ISDIAH relationship isn't significant or doesn't pertain to the archival material :-)

[MinnesotaFox]

Michele,

Actually, is where my philosophical/theoretical problems with relations begins.

is defined as the core, fundamental information about a body of records. Origination is one of those elements. But, according to the relationships model, we place that key information elsewhere in but only if there is some external object to which it has a relation such as an authority record. But what if we have two creators, one who is well known and for whom there is extensive external information, and the other who does not. Does one creator go in origination and the other in relation? What happens when one has a record with an statement in and then discovers an authority file record? Move the entry in the record? Some will argue that it doesn't matter where we put the data; that's for the computer to work out. But that argument cuts both ways. Let's assume for the moment that some creators are in and some in in a with a @role of createdby. If machine-processing can pull the names of creators from these two different locations and combine them for online display, then it surely can retrieve them both from a single location in and determine which entries have an expressed relationship requiring a link. What is the business case for change? The only one I've heard has been an unspecified claim of easier machine processing? What machine processing? As I have said before, relations are probably coming our way but we have neither a principled model to work from nor a community that has been prepared for and accepting of the larger relationship model. There is lot of theoretical work and evangelizing to be done first. Relations are a whole lot more complex in the description of records than they are in authority records. The library community worked through FRBR for a long time, building community understanding and support before Bibliographic Framework appeared. I do not think it politically or practically wise for us to take shortcuts here by implementing the relations model now. Michael On Thu, Jun 20, 2013 at 9:24 AM, MicheleCombs notifications@github.comwrote: > Other than , I too have had a good deal of difficulty > applying the relationships model to archival description, particularly with > things like '' and `'. The fact that a collection is housed in Building A, > or that there is also an Excel spreadsheet listing of it, does not, to my > mind, create a "relationship" between the collection and the building, or > the collection and the Excel file. Perhaps it's a philosophical question > ("What do we mean by 'relationship'?") but even given the most generous > definition, such "relationships" as these would at best be temporary and > incidental, with no connection to the actual archival content. > > — > Reply to this email directly or view it on GitHubhttps://github.com/SAA-SDT/EAD-Revision/issues/197#issuecomment-19755986 > . ## Michael Fox

[MinnesotaFox]

This is in response to the communication on the list from Florence Clavaud regarding relationships. If we already have a model for relationships why has ICA formed a committee that is charged with developing such a model over the next four years? The truth is that the set of relationships related to a description of archival materials will prove to be much more complex that that for CPF entities. There are three sets of relationships at least: external associations to the body of records as a whole, relationships to individual elements of description, and the internal relationships of the individual elements of description to the description as a whole. It wasn't too long ago that some committee members were urging that elements be renamed to better address this last set of relationships. I think that we need both a model that has been fully vetted and tested in relation to the description of records and not just CPF entities and we need to build a case for its adoption by the community. We are a long way from either. Don't get me wrong; I believe that the modeling and incorporation of relationships into description will certainly be in our future. But dropping a half-cooked implementation on the community is not the way to gain converts. Even now, at the eleven hour in the revision process we don't even have agreement as to what is in relations and what is out and whether the relationship is expressed within the element or wraps it. Michael

[florenceclavaud]

Hi Michael,

If we see the problem like you do, the problem seems huge. My thoughts only concern the relationships between the archival units that are described in an EAD finding aid and anything else that is distinct, that should not be described in the finding aid, or may be not described within it, as today some projects use the EAD instances only to describe archives, not their context.

Relationships between individual elements of description to the description as a whole are already well expressed in an EAD (or EAD 2013) instance, through the hierarchy of levels of description, and through the inheritance of information from the higher levels to the lower ones (this is a key concept of ISAD(G) standard, and of the EAD 2002 DTD).

So, let's go back to the relationship question as it is being thought of and discussed here for a long time. The alpha EA 2013 schema already includes a element. Do you mean we should not maintain this element in the EAD 2013 schema ?? I think we should. There obviously is a need that we have to take into account. In the Google Drive folder, I am sure that several instances use this element (at least so does the one I have loaded, for our rather important research project we need such an element). In the EAC-CPF schema, there already several relation elements, and they are needed and used, see for instance SNAC project.

Second, what I am saying is that , , , , maybe , , give information on things that are distinct from the archival units, and that they should be considered as a kind or relation. I cannot imagine that noone here agrees with me. If so, why not trying to think about these elements as sharing some properties and features ? It seems to be a good basis for modelling. And again, of course there will be a lot of archivists who will not need to create links to external resources when using these elements - so their attributes, or even some of their subelements, could be set as optional.

Of course we need to build an archival ontology so that our concepts be more accurate, our information systems stronger, our data really present in the Linked data network. But we already have experience, and some description standards, where some concepts are defined (repository, other finding aid, related material, origination, etc.), some relationships too. Are we not able to model these relationships now? I think we can do this. And that if we do not do this, more and more projects will soon build specific schemas instead of sharing the same one. When the ICA/EGAD will start creating an ontology, I think that there will be much more problems, more difficult questions to answer. Creating a generic element, and trying to create a more accurate, powerful and consistent model for the archival elements mentioned above, is not a half-cooked implementation, if well done.

Any reactions ?

Florence Clavaud Ecole nationale des chartes (Paris, France)

[MinnesotaFox]

Obviously we see this differently. I believe that should be removed from EAD 2013. There are two fundamental problems.

1. We do not have a working model now. There are various ideas floating about as to what to include and exclude and how to do the encoding but no consensus. There simply is not enough time left to have a meaningful discussion with so many other issues pressing us.
2. As you point out, there will be problems if some precede with models that end up different from the ICA ontology. We ought not to contribute to that confusion.

Michael

[florenceclavaud]

1. We do not have a working model now. There are various ideas floating about as to what to include and exclude and how to do the encoding but no consensus.

Few people only have already told what they think about this.

There simply is not enough time left to have a meaningful discussion with so many other issues pressing us.

It is just a question of defining priorities. Like in any other roadmap.

2.

As you point out, there will be problems if some precede with models
that end up different from the ICA ontology. We ought not to
contribute to that confusion.

I did not say that at all, you say that. I am focussing on our schema problem. The SAA has decided to create a new schema. It is too late to say that we will wait for the ontology and build the schema after it. I say that if we do not include a 'relationship solution' in EAD 2013, more and more projects will customize EAD 2013 in order to include it in their own specific model, or even will not use EAD 2013 : do we want that ? I also say that I do think that we are able to model this.

Florence