CWKB numbers not being deleted

[rla2118]

Residual CWKB numbers are not being deleted from the XML whenever an attempt is made to save a new number.

[paregorios]

This sounds like a problem with the editor to me. Is that your impression @rla2118 @jcowey @Edelweiss? I've added the "editor" label based on that assumption.

[Edelweiss]

In DCLP EpiDoc there is no specific xpath reserved for CWKB numbers (such as a TEI:idno).

The representation of CWKB numbers within EpiDoc is a URL inside a @ref attribute:

<author ref="http://cwkb.org/author/id/1234/rdf http://data.perseus.org/catalog/urn:cts:greekLit:tlg2345 http://data.perseus.org/catalog/urn:cts:latinLit:phi7654 http://catalog.perseus.org/catalog/urn:cts:latinLit:stoa6789"/>

If you want to get rid of a CWKB number, you also have to remove the corresponding link.

If you don’t remove the URL, the editor will (for your convenience) restore the CWKB number from the given URL the next time you call up that file for display in the editor mask.

(The same goes for TLG, Stoa and PHI numbers)

We could change that behaviour so that the editor will delete any URL if there is an empty string in the corresponding number field. But beware: If we use this logic, the users will have to provide a CWKB number whenever they want to save a link to CWKB. If they only provide a link and leave the corresponding number field blank, the link will be deleted. Let’s call that alternative (I).

Further alternatives could be:

(II) Make the editor delete links automatically once the number in the corresponding text field is erased (and of course the other way around, i.e. when a link is deleted, the corrsponding number will disappear). Perhaps a message box could inform the users about the repercussions of their actions. This would be the client side version of alternative (I).

(III) Hide the links (as suggested during one of our hands-on workshops here in Heidelberg). It’s actually very much like alternative (I), but the users won’t see that there are any links unless they view the xml. This might, however, make them think that they need to provide the links themselves. SoSOL can, of course, remove dupliactes, but the users might wonder why the data they enter is not being displayed in the editor mask. The entry field would look like this:

(IV) Get rid of the numbers at the top altogether to have the editor reflect the underlying xml as accurately as possible. It would look like this:

I would opt for alternatives (II) or (IV) or leave it as it is, as these are the alternatives with either the least suprise or the least chances of accidental data loss.

[paregorios]

I will ask the users here at the workshop in NYC today which approach they would prefer.

[Edelweiss]

Cool!

[paregorios]

Users here would prefer not to see the URLs at all. Further, they recommend an interface that would look like this:

[Edelweiss]

a few example tei:author/@ref that we currently have in the system:

• http://catalog.perseus.org/catalog/urn:cts:greekLit:tlg2643
• http://cwkb.org/author/id/97/rdf
• http://data.perseus.org/catalog/urn:cts:arabicLit:0150MuqatilIbnSulayman
• http://data.perseus.org/catalog/urn:cts:greekLit:tlg0001
• http://data.perseus.org/catalog/urn:cts:latinLit:phi0013
• http://data.perseus.org/catalog/urn:cts:latinLit:stoa0007
• http://data.perseus.org/catalog/urn:cts:latinLit:stoa0108a

[Edelweiss]

examples for tei:title/@ref

• http://catalog.perseus.org/catalog/urn:cts:greekLit:tlg0006.tlg015
• http://cwkb.org/work/id/2032/rdf
• http://www.trismegistos.org/authorwork/25

[paregorios]

@Edelweiss where should we look to test this? cc @jcowey

[paregorios]

per discussion with @jcowey @Edelweiss @m-k-r this morning, Heidelberg to provide links to committed code discussed above

[Edelweiss]

This can be tested on litpap.info. Testing was meant to ensure that the new interface didn’t break the underlying logic that is responsible for loading from and saving to EpiDoc.

As this was lower priority the desiderata were not fully implemented.

Yet to be done:

• authority list based on CWKB’s rdfs
• »autocomplete« for author (TLG, CWKB, Stoa and Phi numbers [perhaps language as well?!])
• drop down for work titles
• »autocomplete« for works (TLG, CWKB, Stoa and TM numbers [perhaps language as well?!])
• get rid of drop down box for language selection?!

[Edelweiss]

• https://github.com/DCLP/sosol/commit/1abd59790710c7a612f4d2a780e7695a8db367e3
• https://github.com/DCLP/sosol/commit/b8b30402a7260f5b4eb5a71a19eebff15f151181
• https://github.com/DCLP/sosol/commit/9a28bbd4ed60289a9b6d87a26eb6b5717bb537bc
• https://github.com/DCLP/sosol/commit/29dd690e585b87700bc1adde0214dc3336c2a13b
• https://github.com/DCLP/sosol/commit/a21fd526cab1d95c05adb97989e601315fd18650
• https://github.com/DCLP/sosol/commit/534e2801dc8754768df66fb2813292564f612ff1
• https://github.com/DCLP/sosol/commit/1078296b3958315dbd5b21fea22b3e3f5dc2cfa3
• https://github.com/DCLP/sosol/commit/2f441fe24835202441912b01902162f7727d2368
• https://github.com/DCLP/sosol/commit/cf2bae44f007ae6e5417d6909c3f9f03700ca4dc
• https://github.com/DCLP/sosol/commit/166ba7eacaadd2225dda7628ddc34869d8aa8157
• https://github.com/DCLP/sosol/commit/f7eebfd12014a24233294e6ed7794f12ba6efc1c

I listed only the relevant commits. There are also a few other commits that are related to the same editor component but are not part of the resolution of this issue. Regarding the commits mentioned above in an isolated container may cause some quirks, though, such as wrong captions for digital identifiers.

[Edelweiss]

The part of this ticket that concerns the new user interface lives on in #331