Require data on resources and resource relations

[deternitydx]

From Adrienne:

Since I wanted to double-check our minimum required field list (we came up with it in February . . .)
for related resource records, they are:

• Document type
• Title
• Role

The URI is recommended if available but isn't required (since not everything will have one). 

[deternitydx]

Document type, title, and URI are stored in the Resource Cache (and independent of a Constellation) and should be verified when creating a new Resource item.

Role is part of the Constellation and determines how the identity is connected with the resource: this should be verified when saving a Constellation.

[wnmartin]

Adrienne, Hello. I believe we will want to indicate that the URI for the Resource is STRONGLY encouraged, however, we recognize that not all resrources have URIs.

The Role on the connection from the Identity Constellation to the Resource (established while editing the Identity Constellation record) should be required.

Cheers, Worthy

P.S. The connection from the Identity Constellation to the Resource also has "Relation Entry" and "Descriptive Note" fields. "Descriptiove Note" is optional, however, "Relation Entry" is used in the public display (see the "bubble" above it in the first attached image) of the Identity Constellation, so should be required.

[wnmartin]

Adrienne and Robbie, Hello. I realized that I added "wnm testing" after snapping the first image. The second image shows that Resource in the Identity Constellation public view.

Cheers, Worthy

[dpitti]

I worry here about terminology confusion. Document type What is this? Is it the type of thing at the end of the URL? If so, then this would be equivalent to the attribute role in EAC-CPF. See below. Title Is this the same as the relationEntry? Role Is this the same as attribute role?

And then there is arcrole, which in other terms, is the property, the nature of the arc, e.g. creatorOf

There is a builtin redundancy in EAC-CPF in that the attribute relationType incorporated the rather limited vocabulary of ISAAR, whereas the xlink attribute arcrole provided the possibility of extending the vocabulary. We did not use attribute relationType in assembling the EAC-CPF, but instead used attribute arcrole. Some attribute relationType may have come in via the ANF EAC-CPF, and if so, we want to fix these, that is, convert to arcrole.

All of this is likely to lead to a lot of confusion, as I think most people think in terms of relationType and not arcrole. We want to think in terms of the latter, and with a vocabulary of our own.

Before we do anything here, we need to make sure we are all on the same page. There are a lot of implications to not getting this right.

[deternitydx]

@dpitti I think I can clear up some of your confusion, since what was in the resourceRelation in EAC-CPF has been split in two so that we can keep track of the resources themselves apart from an identity's relationship to the resource.

Document Type (as shown on the edit page) and Title are part of the resource itself. The former is either "ArchivalResource" or "BibliographicResource."

The relationEntry and role (arcrole) are part of the identity's relation. The Role is how they are connected (creatorOf, referencedIn) and the relationEntry is this identity's name for the resource. A while back, I had tried to display the resource's actual title in the HRT list of related resources, but when there were lists of "Papers, 1800" without more context, you had asked me to change it back.

[dpitti]

Document type = EAC-CPF attribute xlink:role (yes, specific to the resource and not the relation) creatorOf, referencedIn = values used in EAC-CPF xlink:arcrole (specific to the relation).

We might want to revisit using name of creator + title in place of relationEntry. Yes, titles alone frequently are too generic to be meaningful with out the name of the creator of the collection. Ideally: name + title + date

[deternitydx]

Unfortunately we don't have the date from the resources in the database. We have title, abstract, extent, URL, and holding repository. We don't have one specific creator listed for each either, although we can get every IC listed as "creator of" the resource. So, there will need to be work if we want to automate that display to replace relationEntry.

[dpitti]

No date. There is suppose to be a date. It is fundamental. I am sure it is the specifications for when we normalized the resource descriptions.

[deternitydx]

@dpitti It was not in the specs, unfortunately. See https://github.com/snac-cooperative/technical-docs/blob/master/Specifications/Resource%20Relation.md. Since this is just a cache of what to find at the other end of a URL, how much do we want to hunt down?. We added title, abstract, extent, and repository from the inset EAD in the EAC-CPF records. Looking at example EAC-CPF, it doesn't look like the date was captured in the inset objectXMLWrap mods/did records. Therefore, it may be difficult to find the dates.

[dpitti]

That is most unfortunate. Strangely I specified including the from , but specified including it in the title. So that is why it is there. And not a separate item of data.

Checking the XSLT, the entirety of each in the was brought in. And so , whether it is directly in or embedded in , will be in the EAC-CPF. Or should be. I double checked and this would appear to be what I did. (Whether Tim altered this after I gave him the code, I do not know).

As for the MARC, Tom wrote the extraction for this based on specifications I gave him. I suspect I can track down the specifications. At any rate, the MARD field 260 $c will have dates. (Though I suspect that some folks may have put the dates in the titles of the MARC: subfields f and g on 245 field.

At any rate, it is very disappointing that the date is not there, and I clearly did not pay sufficient attention. I suspect we could, again, go back to the sources, and retrieve this data, though I would need to carefully examine the sources (EAC-CPF derived from EAD), and MARC.

[deternitydx]

We had an offline discussion that resolved the date issue, but it wasn't documented here. The dates are kept in the title of the resources in the cache, which I think was deemed sufficient.

[deternitydx]

Adding a new to-do item based on feedback from Jerry:

• [ ] We should pre-fill the Relation Entry text from the resource when the user adds it from the web ui. It should still be editable, but it can be pre-populated

[dpitti]

Though I will not advocate retrospectively massaging the data, I do think that "date" should be added as a field in the cached descriptive data, for future use. While both MARC21 and EAD may treat the date as part of the title, it is also the case that many archives will treat title and date as separate. For collection description, the data is typically given as a range, called the "inclusive date," that is, the earliest date of the aggregated records, and the latest date of the aggregated records, as a range. Sometimes archivists also give the "bulk date" along with the "inclusive date." It is a way of saying the records span this date range, but the bulk of them are in this range. Thus there is always the possibility of these two types of date ranges, and of course, a single date for individual items. Let's discuss this at some point.

[deternitydx]

Assigning @glassjoseph since he's working on the redesigned Resource interface. Date is being added there, but I also added "data refinement" since we want to use a script to choose the Display Name for each Resource. (I've written most of that script)

[dpitti]

Let's revisit this given the complete reworking of the resource description. I think, in fact, we have specified what is required. And also have come with warnings for information that may not be required (only because not available in some cases), but desired. In library standards speak, the latter are "required if available," versus required, and optional though recommended.

[deternitydx]

This should be included in the Resource editing functionality by @glassjoseph now on dev.