Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Dummy headers in DCLP #81

Open
samosafuz opened this issue Jul 23, 2020 · 6 comments
Open

Dummy headers in DCLP #81

samosafuz opened this issue Jul 23, 2020 · 6 comments

Comments

@samosafuz
Copy link
Member

In the event of reprint or reedition, the DDB generally employs dummy headers in the xml to redirect, the logic being that a user may be familiar with a previous identifier and that it is therefore preferable to preserve rather than delete. A good example is

https://github.com/papyri/idp.data/blob/master/DDB_EpiDoc_XML/p.louvre/p.louvre.1/p.louvre.1.4.xml#L55-L59

    <head n="11853" xml:lang="en">
    <date>AD -166</date>
    <placeName>Soknopaiou Nesos</placeName>
    <ref n="bgu;1;1|bgu;1;337|chr.wilck;;92" type="reprint-from">Chrest.Wilck. 92, BGU 1 337 (col 1 only), BGU 1 1 (col 2 only)</ref>
    </head>

It appears as follows in PN:

Screen Shot 2020-07-23 at 2 01 08 PM

Such dummy headers are typically found in the final destination file (as type="reprint-from"). In the xml of any previous files, by contrast, one normally finds a more general xml comment noting the destination file. A good example is

https://github.com/papyri/idp.data/blob/master/DDB_EpiDoc_XML/bgu/bgu.1/bgu.1.15.xml#L65

    <lb n="1"/><note xml:lang="en">BGU 1,15,1 reprinted in WChr 393</note>

It appears as follows in PN:

Screen Shot 2020-07-23 at 1 58 41 PM

Dummy headers of the former sort do not yet appear to be possible in DCLP. At present, two texts have been migrated from DDB to DCLP (and since DCLP and HGV share 508 entries, many more await migration--potentially hundreds):

http://papyri.info/ddbdp/o.mich;1;656
http://papyri.info/ddbdp/p.mich;7;456

In both cases, the DDB text has been migrated and replaced by the same xml comment used in the aforementioned example of BGU 1 15.

In both cases, however, there is a problem in the DCLP. Although the xml contains the dummy header indicating type="reprint-from", it is not displaying in PN.

https://github.com/papyri/idp.data/blob/master/DCLP/65/64004.xml#L122-L126

    <head n="64004" xml:lang="en">
       <date>IIIspc</date>
       <placeName>Karanis</placeName>
       <ref n="o.mich;1;656" type="reprint-from">O.Mich. 1 656</ref>
    </head>

Screen Shot 2020-07-23 at 2 13 33 PM

https://github.com/papyri/idp.data/blob/master/DCLP/64/63275.xml#L116-L120

    <head xml:lang="en">
       <date>I/II spc</date>
       <placeName>?</placeName>
       <ref type="reprint-from">C.Pap.Lat. 231</ref>
    </head>

Screen Shot 2020-07-23 at 2 14 04 PM

This eventuality was probably not foreseen when DCLP was created, but it would helpful to allow for the same kind of correspondence between DCLP to DDB that one finds within the DDB itself. This should probably take place as part of a larger conversation about the best way to manage the interaction between the two datasets.
hcayless added a commit that referenced this issue Nov 15, 2021
@hcayless
Fix for #81.
2ef04a6 
Also attempting to improve error reporting for broken links.
@hcayless
Copy link
Member

hcayless commented Dec 1, 2021

This now works, but I'm not 100% happy with it. We don't actually have a convention for dummy headers in this circumstance, and so it's not going to display perfectly until we do. My suggestion is to allow a prefix for the link in the dummy header, so P.Mich 7, 456 would have:

<ref type="reprint-in" target="dclp:63275">DCLP 63275</ref>

or something like that. A ddbdp: prefix should be made to work too. What's happening now is that the links are made, but it's not clear which is the primary record, because there's no reprint from/in information. If this sounds like a reasonable convention, I can put it in place.

@samosafuz
Copy link
Member Author

I think the ddbdp: and dclp: prefixes will address the problem nicely. It's certainly a more elegant (and machine-readable) solution than relying on <note xml:lang="en">Text transferred from DDbDP to DCLP</note> to indicate the linkage.

I note that <ref type="reprint-in"> or <ref type="reprint-from"> will now employ @target instead of @n , as it did previously within the DDB records. Will that require a universal change to existing records, or will the old DDB-specific system for dummy headers function in parallel with the new DDB/DCLP method?

@hcayless
Copy link
Member

hcayless commented Dec 2, 2021

@target was possibly an error on my part. It is the usual way these things work, but I don't know that we need to embark on a wholesale conversion of @n to @target. It's something we could (and possibly should) do, but I wouldn't consider it high priority.

@jcowey
Copy link
Member

jcowey commented Dec 2, 2021

Stick to what we have at present with @n. Change to @target definitely not high priority at present, I would say, speaking pragmatically.

@samosafuz
Copy link
Member Author

I recently returned to this issue, and have used 64004 as a test case: the reprint-from dummy header in the DCLP file works fine; the reprint-in header in the DDB file is still waiting for the aforementioned convention (with ddbdp: and dclp: prefixes) to be put in place. That would be nice to have working.

A related issue (which may need to be its own ticket) involves how PN indexes by dclp-hybrid <idno>. Given the structure of DCLP, with a single file of text/metadata per TM number, there will only ever be a one file for a given papyrus. The current system of dummy headers works great in DDB for republished pieces, where the previous publication's file can be preserved while pointing to the new one, but that won't be possible in DCLP. There, rather, it sometimes happens that you get two partial editions (62867 is a good example), for which dummy headers of the reprint-in and reprint-from variety won't be accurate. In the case of 62867, for example, we find two dclp-hybrid indos (<idno type="dclp-hybrid">p.oxy;57;3879</idno> and <idno type="dclp-hybrid">psi;16;1584</idno>) reflecting the two publications of the papyrus, but note how the indexer only catches the first, P.Oxy. 3879:
Screen Shot 2022-10-09 at 2 33 27 PM

The second hybrid idno, for PSI 1584, is not indexed:
Screen Shot 2022-10-09 at 2 33 52 PM

It would be nice to have the indexer loop over these dclp-hybrid idnos to capture them all: users who are more comfortable browsing by series/volume instead of TM number can find themselves frustrated. James and I had previously discussed whether it might be worth having a new <idno type="deprecated"> (vel sim.) for cases such as these, but I wonder whether simply tweaking the indexer would be a more elegant solution. Is it in fact simple (or possible at all)?

@jcowey
Copy link
Member

jcowey commented Jan 9, 2023

With new treatment of stubs / bibliographic edition, this will be solved.

@samosafuz samosafuz mentioned this issue Apr 30, 2024
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@hcayless @jcowey @samosafuz