Containing Relationships in SPEAR header

[dlschwartz]

In order to exploit composite URIs for browsing in SPEAR, I've added seriesStmt to the SPEAR header. See https://github.com/srophe/srophe-app-data/blob/dev/data/spear/tei/SPEAR_John_Ephesus_Lives_794.xml#L41. I've also added an equivalent statement into the sourceDesc for works that are not part of a series: https://github.com/srophe/srophe-app-data/blob/dev/data/spear/tei/Chronicle_of_Edessa.xml#L38.

This was a little tricky since elsewhere in our data we can simply use seriesStmt in fileDesc. In SPEAR, this has to appear inside sourceDesc since the SPEAR file itself is not part of a series but rather the work from which the prosopographical data is derived comes from a series of works.

A couple of issues arise:

1) I needed to include in sourceDesc both the parent and the child in order for it to make sense as a sourceDesc. This is more data than @wsalesky asked for but I trust that isn't a problem for her.

2) It does produce a result that isn't very human readable without a lot of hassle (i.e. convoluted TEI or significant customization). That doesn't exactly bother me but I thought I should ask if that concerns @davidamichelson.

After I get your feedback I'll add this sourceDesc to all of the Lives of John of Ephesus. Before we can use composite URIs for the letters, we'll need to mint those URIs.

[wsalesky]

@dlschwartz This approach makes sense to me.

[dlschwartz]

@wsalesky So, now that I've added seriesStmt to the files, I've been in touch with Nathan and he's corrected me on something. These are not composite URIs and, therefore, should not use seriesStmt. Rather these works are in a containing relationship with one another. We do this elsewhere with a relation element (https://github.com/srophe/srophe-app-data/blob/dev/data/works/tei/10510.xml#L248) and I think we should maintain consistency on this point. I am going to redo the TEI to put a relation element into the sourceDesc for SPEAR. Let me know if you anticipate any problems with this approach.

`

This is a born digital prosopography containing data derived from John of Ephesus, History of the Convent of John Urtaya, in The Lives of the Eastern Saints.

        </sourceDesc>`

[dlschwartz]

Just to be clear, the URI of the containing work would be the attribute value of the passive attribute. And, perhaps this is easier to look at here: https://github.com/srophe/srophe-app-data/blob/dev/data/spear/tei/SPEAR_John_Ephesus_Lives_10510.xml#L39.

[dlschwartz]

One more thought here. I'm not sure what other uses we might have for the sourceDesc. I can't think of any. Can anyone think of a reason why it might be a problem that we have one structure for a sourceDesc that expresses a containing relationship :https://github.com/srophe/srophe-app-data/blob/dev/data/spear/tei/SPEAR_John_Ephesus_Lives_10510.xml#L39, and another structure for a sourceDesc that does not: https://github.com/srophe/srophe-app-data/blob/dev/data/spear/tei/Chronicle_of_Edessa.xml#L38. @davidamichelson, thoughts?

[wsalesky]

I can't think of any issues with using the sourceDesc, code wise.

On Fri, Feb 2, 2018 at 3:07 PM, Daniel Schwartz notifications@github.com wrote:

One more thought here. I'm not sure what other uses we might have for the sourceDesc. I can't think of any. Can anyone think of a reason why it might be a problem that we have one structure for a sourceDesc that expresses a containing relationship :https://github.com/srophe/ srophe-app-data/blob/dev/data/spear/tei/SPEAR_JohnEphesus Lives_10510.xml#L39, and another structure for a sourceDesc that does not: https://github.com/srophe/srophe-app-data/blob/dev/data/ spear/tei/Chronicle_of_Edessa.xml#L38. @davidamichelson https://github.com/davidamichelson, thoughts?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/srophe/srophe-app-data/issues/730#issuecomment-362692754, or mute the thread https://github.com/notifications/unsubscribe-auth/ABHTToUz1mhHHxzHLY04JclHCqJLEbdPks5tQ2sUgaJpZM4RxTW8 .

[dlschwartz]

@wsalesky I added a title element with ref to the work URI in the sourceDesc. For the time being I've left the listRelations in sourceDesc. As we discussed, it would be great to use the work URI in conjunction with the RDF from the works data to visualize the containing relationship in SPEAR. That would allow me to remove listRelation from sourceDesc. If we can't do that, it will be fine. But removing it would be nice. Thanks. Here's a link to the commit https://github.com/srophe/srophe-app-data/commit/1908cd0158f4d06227f8162ada65a86d0a695772

[dlschwartz]

@wsalesky I just realized a problem. We don't currently have work records for the individual letters of Severus contained in SPEAR. The URIs are reserved in a spreadsheet but we currently have no records that contain a reference to a containing work. As such, that data will not be in our RDF from the work record until we create work records. Argh.

[wsalesky]

That could be a problem. Let me work my way through the issues, saving this one to later. There is still plenty to work on!

[dlschwartz]

@wsalesky I've been in touch with Nathan. He has a spreadsheet already set up for batch processing of works records. Much of the basic data was already collected in the process of reserving the URIs for the individual letters and now we have URIs/records for the containing works. I should be able to produce draft records for dev by Monday. I trust that the RDF from those records is easily acquired. Let me know if I'm wrong. I don't think this will be the problem I originally thought it would.

[wsalesky]

Great! I'm really behind on multiple projects this week due to snow days and delays, so I may not get to this before Monday anyway. Let me know when they are up.

[wsalesky]

@dlschwartz I think this can be closed?