blakearchive / archive

GNU General Public License v2.0
5 stars 7 forks source link

in letters, object links aren't being formed properly #422

Open ba001 opened 7 years ago

ba001 commented 7 years ago

http://www.blakearchive.org/blake/work/letters

see in Related Items, Object 3, "Thomas Haley," for example. the link for it is:

http://www.blakearchive.org/bb467.1.comeng.03

ba001 commented 7 years ago

the xml for the above example below. all the object links need to be formed.

the first one points to a work outside of letters, though: http://www.blakearchive.org/blake/copy/bb467.1?descId=bb467.1.comeng.01

and the others point to objects in virtual group letters.

<relationship>William Hayley, *An Essay on Sculpture*
            <br/>
            <link ptr="bb467.1.comeng.03" type="object">Object 3, &quot;Thomas Hayley&quot;</link>
            <br/>
            William Blake, etching and engraving, 1800 
            <br/>
            Collection of Robert N. Essick

            <br/>
            Altadena, California
            <br/>
            <br/>
            in letter of: 
            <br/>
            1 April 1800 
            <link ptr="lt1april1800.1.ltr.01" type="object">(Object 1, lines 1-5)</link>
            <br/>
            6 May 1800 
            <link ptr="lt6may1800.1.ltr.02" type="object">(Object 2, lines
                4-7)</link></relationship>
ba001 commented 7 years ago

related issue, which might be the same actually. for an entry in cpd.info.xml:

<relationship>
<link type="compare" ptr="mhh.c" objnum="B4">*The Marriage of Heaven and Hell*, Plates 4</link> and 
<link type="compare" ptr="mhh.c" objnum="B24">24</link><br/> Relief etchings, 1790.  Bentley 98, Plates 4 and 24.
</relationship>

the output is:

The Marriage of Heaven and Hell, Plates 4 and Relief etchings, 1790. Bentley 98, Plates 4 and 24.

that second \<link>, for 24, is not getting rendered

nathan-rice commented 7 years ago

This issue is exacerbated by that nasty hybrid xml that is doing double duty as presentation and data.

Honestly the best way to fix this is to have one link per relationship. The alternative involves changing the structure of that part of the json data, which means rewriting all the code that touches it. Additionally, you will go from having nicely hyperlinked titles to smaller, less accessible hyperlinks below the titles, which is a useability loss in my opinion.

The code around related works is spaghetti, and I'd really like to simplify it if possible, not make it worse.

ba001 commented 7 years ago

yes, we're dealing with old XML and old ways of thinking about it. but we do have to deal with it. @joeafletch these links are necessary, aren't they? if something is in the Archive and is mentioned in the Related Works, the mention should be linked, right?

nathan-rice commented 7 years ago

I'm not saying we don't display those relationship links, just that we treat them as their own relationship (which they really are).

ba001 commented 7 years ago

ok, i see, just explode them into more 'relationships'. let's see what the editors think. i think they'll go for it.

ba001 commented 7 years ago

although, this might be a problem for the letters, where related works are works mentioned in multiple letters, which are the things needed to be linked

http://www.blakearchive.org/work/letters

joeafletch commented 7 years ago

I'm seeing other problems with this display, which you can compare to how this list looked on the old site here.

Yes, the links should function for works that are in the Archive, in order to be consistent with all other Related Works lists--so that link to object 3 in Hayley's Essay on Sculpture should go to that work/object. We also stripped the links to the specified objects within the Letters themselves--these were there on the old site, but now they're not. In that Hayley example from Mike, there is now no (object 1, lines 1-5) link after 1 April 1800 in that entry. We decided we could live without that. BUT: sometimes those parenthetical links are still there, and they are confusingly getting placed at the top of some entries for works that aren't in the Archive. See the entry directly above the one Mike mentions, for the frontispiece to Euler's Elements of Algebra. We don't have that work in the Archive, and that "(object 2, line 7)" is not a link to the Euler work, but to the letter of 4 May 1804 (but it isn't functioning anyway, and just takes one to the homepage)--and again, such links have been stripped in all other instances.

nathan-rice commented 7 years ago

Regarding the letters, not a problem, the example page you listed has one work (the thing linked to) with multiple referents. That would still be a single link tag per relationship. You would just have multiple source entries.

ba001 commented 7 years ago

hmm, i'm not following. if we break out the links into more relationships, we won't have the letters under the work. they would be their own entries. basically, it needs to look exactly like the old site, as @joeafletch pointed out

nathan-rice commented 7 years ago

No, remember I'm proposing one link per relationship. let me give you an example:

<relationship> <link>Print, plate 4</link> <source>First letter</source> <source>Second letter</source> </relationship>

ba001 commented 7 years ago

ok, i see. so add an element 'source' which will contain a link? should the link go in an attribute?

ba001 commented 7 years ago

like this?

<source link=...>first letter, object 1</source>

nathan-rice commented 7 years ago

Treat sources like another link tag of which there may be multiple? That would work I think.

When you go back to modify the info files you will want to remove the <br> tags and make sure there is no text not wrapped by a link or source. If you find text that doesn't fit in a link or source it could go in a <note> or we could come up with a new tag for it.