BetaMasaheft / Documentation

Die Schriftkultur des christlichen Äthiopiens: Eine multimediale Forschungsumgebung
3 stars 3 forks source link

Visualization of skos:broadMatch relations in work records #1900

Open DariaElagina opened 2 years ago

DariaElagina commented 2 years ago

Dear @PietroLiuzzo ,

I think that the skos:broadMatch relations are not visualized correctly on the app. Here is the example: https://betamasaheft.eu/works/LIT1340EnochE/main or https://betamasaheft.eu/works/LIT1239Chroni/main In the text edition, there is no visualization either. It would be nice to have it and to have the links to the external resources visible. Hope this is easy to solve!

All best and many thanks in advance,

Daria

PietroLiuzzo commented 2 years ago

This needs to be fixed in the expand.xql script, which does not deal properly with the URLs. No, it is not easy to solve. And also finding out where the issue is is not "easy". Two little bits of help would have been for example formatting links correctly in your issue (see my edit) and, for example, providing a screenshot of the area of the web view in question. I will see what I can do.

PietroLiuzzo commented 2 years ago

I have introduced two fixes for this two instances where the value of @passive is actually a shortened BM URI. I have checked a couple of other work record with this named relation but could not further check.

DariaElagina commented 2 years ago

Thank you, Pietro. A short question still: the app visualizes the list of BM URIs under "The following textual units have a relation to this textual unit" (see the picture), where actually the external URIs would be expected. skosBroadMatch I have checked, and the coding seems to be correct according to the GL: https://betamasaheft.eu/Guidelines/?id=work-teiHeader Examples 10 and 11. I understand that there is no time to solve this, but the question is: is the problem in visualization or in the GL? If the problem is in the GL, we have to fix it, and if in the visualization, I think it should be considered to be fixed in future. @thea-m @eu-genia @DenisNosnitsin1970

eu-genia commented 2 years ago

Dear Daria, I tried to reverse but I believe the external links are not shown anyway. There was however one error in the encoding comparing to Example 12: you had betmas:LIT1340EnochE:1.1 where betmas:LIT1340EnochE.1.1 is expected, I have replaced it throughout (so at least the internal links work now). Did it work in the earlier release? Note that Pietro does not receive notifications for issues. If this is very important you may try to ask him directly, otherwise you will have to wait.

eu-genia commented 2 years ago

as a test, I added a reverse relation in LIT1239Chroni, so there are both directions, and one can see image

the second empty line being the external uri if it is encoded as passive

DariaElagina commented 2 years ago

Thank you, Zhenia! This is not urgent, especially if this is just an issue of visualization and we can still follow the encoding proposed in the GL (meaning that the external link is encoded as active), otherwise, it might be problematic (for me). Honestly, I am not sure about the visualization in the previous release, but since I had a look and there was nothing striking, probably, it was fine. It is not urgent, as I said, but if it might be reported within the next "package" of issues, I would be very grateful!

PietroLiuzzo commented 2 years ago

I have focused on the relation table, where the list of links is given in full rather than on the main view, which I think @eu-genia already sorted out.

The cause of the problem was IMHO a replacement pattern not matching dots and hyphens. checked with https://regexr.com/ expand.xql leaves this betmas: prefixed CURLs untouched (line 165) and the link, at least in the table are produced by the function apprest:decideLink(). This does not use, for reasons I cannot recall, the injected prefixDef which is found in the expanded file, but imports prefixDef from the Github repository. the pattern to be matched: LIT1340EnochE.1.6-9 current regex pattern: ([a-zA-Z0-9]+) This is called by BetMasWeb/modules/item.xqm which is called by BetMasWeb/restviews/items.xqm proposed regex pattern: ([a-zA-Z0-9\.\-]+) I have changed this in the file imported by apprest.xql. Next time the module is loaded, instead of <a target="_blank" href="https://betamasaheft.eu/LIT1340EnochE.https://betamasaheft.eu/1.https://betamasaheft.eu/6-https://betamasaheft.eu/9"></a> apprest.xql will replace correctly <a target="_blank" href="https://betamasaheft.eu/LIT1340EnochE.1.6-9"></a>.

The content of those links is produced byexptit.xql invoked by apprest.xql in the function apprest:decideRelation() and many other places. This function never supported these pointers. I have added in BetMasWeb/modules/exptit.xql the following condition, to try and gently skip them by printing the main title instead. This should work when with next restart (exptit is imported by many modules) so I am not testing it, and moving to another issue instead.

else if (not(starts-with($id, 'http')) and matches($id, '(A-Za-z0-9\.\-)')) then 
(:    in e.g. LIT1340EnochE.1.6-9 will remove .1 and .6-9 :)
    let $mainid := replace($id, '(\.[A-Za-z0-9\-]+)', '') return
    $exptit:col/id($mainid)//t:title[@type = 'full']/text()

If this does not work, the same logic can be moved one step upwards to the apprest:decideRelation() function

You may additionally consider also the following:

eu-genia commented 2 years ago

The problem here if I recall correctly is that the link pointed to should not be to our record but to the external URL

eu-genia commented 2 years ago

i.e. the link should be from LIT1340EnochE.1.6-9 to https://corpuscoranicum.de/kontexte/index/sure/2/vers/102/intertext/769

PietroLiuzzo commented 2 years ago

For that problem, all you need to do is fix the encoding.

eu-genia commented 2 years ago

the encoding is according to the guidelines as far as we can see https://betamasaheft.eu/Guidelines/?id=work-teiHeader

switching active and passive does not solve the problem

eu-genia commented 3 months ago

The text/address of the link should be made visible. At the moment, links are rendered in html as <a href="https://betamasaheft.eu/LIT1340EnochE#t4aramaic">Aramaic Version of Enoch</a> for Bm entries and as <a href="https://pemm.princeton.edu/stories/1005" passive="https://pemm.princeton.edu/stories/1005"></a> making the latter invisible

eu-genia commented 3 months ago

fixed by adding a condition for external links in item.xqm <a href="{$p}" >{if (contains($p, 'betamasaheft')) then exptit:printTitle($p) else string($p)}</a> instead of simply <a href="{$p}" >{exptit:printTitle($p)}</a> which naturally did not work for external links

eu-genia commented 3 months ago

@DariaElagina if you invert activeand passive, with passivebeing the links, the links will be printed as in https://betamasaheft.eu/works/LIT6994MMDZGrotto/main

Please let me know if there was something else not visualized properly

eu-genia commented 3 months ago

https://betamasaheft.eu/works/LIT1239Chroni/main looks ok