jamieparkinson
commented
3 years ago Examples of ambiguous graphs
- https://wellcomecollection.org/works/gdze3764/images?id=br8jzfx8 V0014845 is linked to by b15526483 and b15526422 which refer to different sections of the image
- https://wellcomecollection.org/works/ju9sdqws/images?id=nbkcxp6z V0029295 is linked to by b11879440, b11879427, b11879452 and b11879439 which refer to different sections of the image
- https://wellcomecollection.org/works/nx82ybh7/images?id=aw32pqt5 V0007228 is linked to by b11648260, b11649045, and b11649033 where b11649045 and b11649033 appear to be incorrect.
- https://wellcomecollection.org/works/z3d5t6p8/images?id=g7r8yavv V0047493 is linked to by b15821043, b15821018, b15821031, b1582102x and b15821067. All of these refer to sections of the image, but only b15821018 and b15821031 do not have correspoding L-series links to what are effectively crops, so they are ambiguous.
- https://wellcomecollection.org/works/u8bp4xs6/images?id=vdpmyqfv L0055769 (a photograph) and L0055768 (the opaque negative of the photograph) are both linked to by b11767340 and b11767352 - it's unclear to me why both of these exist.
- https://wellcomecollection.org/works/sfwj44hv/images?id=wn34myty V0039805 contains 6 sub-images, each of which has a Sierra record: b11889470, b11889494, b11889433, b11889469, b11889457, b11889445.
- L0015006 is linked to by b11745824, but also by 4 others. Why? b11745885, b11745861, b11745873, b11745903/
- https://wellcomecollection.org/works/sgfs2x3s/images?id=y247vqv9 V0047492 is linked to by b15821006 and b15820968, which have their own L-series images which is fine, but also by b1582097x, b15820981 and b15820956, which refer to different sections of the image.
- L0018774, L0031031 and V0036773 are all linked to by both b11767212 and b11767200.
- https://wellcomecollection.org/works/s4rv5fbm/images?id=y3zf8rn2 V0010523 contains 4 images, which are linked to by b11688245, b11688257, b11688233 and b11688221. Each of these has another Miro image which is a crop of the relevant section, but b11688245 and b11688233 have 2 crops.
- https://wellcomecollection.org/works/tskmm36x/images?id=bpmkmdbt V0033226 contains 20 panels, each of which has a bib that links to it. No crops exist.
- https://wellcomecollection.org/works/en78wcu6/images?id=csvfc6bg V0047495 contains 6 sections, one of which has a crop (b15821146), but another 4 of which have bibs referring to different sections (b15821158, b1582116x, b15821134, b15821183).
alexwlchan
paul-butcher
Context
We have previously assumed that the matcher graphs recorded by the matcher would be relatively simple and predictable - for example, a Sierra work and a METS work, or a Sierra work and several Miro works. However, it turns out that for some works the graphs can be extremely complex:
These complexities most often occur when several Sierra works link to a single Miro work, although we've seen that it can also occur when Sierra works link to each other. I've only explored the Miro case so far.
The problem
The merger has no understanding of graphs and just operates on lists of works (it does not care how they are linked, as this is the job of the matcher). While this works well for most cases, it does not handle the complex graphs: we see non-deterministic behaviour depending on the order in which the merger encounters the works. In the case of high-degree Miro works, this usually manifests as images being linked to the wrong Sierra works and so seeming to disappear.
In some cases, we can identify these cases as errors in the catalogue records (ie incorrect linking). However, in many others, the links are valid representations - see next comment for some examples.
Incomplete solutions
It seems likely that we can automatically break up graphs in the matcher by applying some sort of business logic, but this has turned out to be both difficult and incomplete. Perhaps we can be OK with this, but it needs some more work. Some initial work on this is given below.
Further work on this would probably aim to handle some of these cases automatically, and warn (or even error) on ambiguous cases. It may be that the solution is not to merge the ambiguous cases at all so as to ensure that no information is hidden unexpectedly.