EHRI / ehri-frontend

The EHRI project's portal interface.
https://portal.ehri-project.eu
European Union Public License 1.2
14 stars 9 forks source link

Access points not displayed as links #618

Open michalfrankl opened 9 years ago

michalfrankl commented 9 years ago

In the portal interface, where a unit has multiple descriptions (in different languagues, typically), the access points are listed in all languages, but only displayed as links in one language. This can be very confusing.

This can be seen especially on the JMP Terezín data for which descriptions were imported in three languages. The links are just fine in Czech:

https://portal.ehri-project.eu/units/cz-002279-collection_jmp_shoah_t-2-a-10k_327-041-document_jmp_shoah_t_2_a_10k_327_041_004#desc-ces

... but are missing in English and German versions.

Is this an issue with the portal code or with the import?

mikesname commented 9 years ago

I suspect this is an import issue, but also an unfortunate consequence of our overly-complicated multi-description / access point / link model. Every description has its own set of access points, which are basically just dumb labels. They're only hyperlinked if an actual link object exists, with the two items as targets and the access point as a "body". These link objects were created on import, and I would guess only for one description.

I gather actually creating these links at import time was itself very complex, and the portal cannot just infer the access points on two different descriptions refer to the same thing because 1) descriptions are not always just straight translations (see YV), and 2) when they are translations the dumb labels in the source data might be in different languages.

There are some janky heuristics we could potentially employ, but, as ever, that risks making things more confusing.

It's ripe for a rethink frankly.

michalfrankl commented 9 years ago

Thanks - I suspected that this is in the first place an import issue. I'm not sure if the process of creation of links at the import time was so complicated since the provided EAD files contained clear and unique identifiers of the linked items. In my view, there was no reason to create the links for one imported EAD and not for the others.

So I guess this should go back to Linda... Or would the heuristics you mention be easier if we limit it to the JMP Terezín collection where we positively know that the descriptions in different languages always have the same set of access points?

mikesname commented 8 years ago

Note to self: possible fix for material in a single repository when access points on multilingual descriptions have the same text (and therefore should share the same link):

MATCH (parent:DocumentaryUnit)-[:heldBy]->(repo:Repository),
   (doc:DocumentaryUnit)-[:childOf*]->(parent),
   (desc1)-[:describes]->(doc),
   (desc2)-[:describes]->(doc),
   (desc1)-[:relatesTo]->(ap1:AccessPoint),
   (desc2)-[:relatesTo]->(ap2:AccessPoint),
   (ap2)<-[:hasLinkBody]-(link:Link)
WHERE ap1.name = ap2.name 
  AND desc1 <> desc2 
  AND repo.__id = "cz-002279"
MERGE (link)-[r:hasLinkBody]->(ap1)
RETURN ap1, r

Need to ensure that doesn't have any extra, unexpected side-effects.