OpenAtlas

Thanks for the quick reply.
I have just seen that in the UI the external reference is seen from the file page: https://thanados.openatlas.eu/entity/234690#tab-reference
but the reference page does not show the file: https://thanados.openatlas.eu/entity/237492#tab-file

We took a look at it at the developer meeting yesterday. If we understood correctly, the issue is only between file and reference and could be solved with inverting the link direction.
If you (Stefan) could be so kind to confirm this, we would change it in the application and write an SQL update for existing data.
In case we missed the point, we should discuss it further.

And I will also take a look at the missing entries at the reference detail view mentioned in your last comment.

Yes, I can confirm. Basically there are two different cases: 1. The file/document is a depiction of a certain entity: E.g. The "self portrait of Vincent van Gogh" P67 - refers to - "Actor Vincent van Gogh". The other case would be that the file/document is referred to by "another document". E.g. The document "Gesammelte Werke von Vincent van Gogh - Exhibition Catalog" - refers to - "self portrait of Vincent van Gogh" on page 31, (this works well in OpenAtlas) - but - if the document is an external reference, it does not. E.g. "Wikimedia Commons Url for self portrait of Vincent van Gogh" refers to "self portrait of Vincent van Gogh (file in OA Database)" does not work properly, (it is inversed)

I took a closer look at the implementation and have to say, it's definitely a good catch by you, Stefan.
E.g. when at the file detail view in the reference tab depending on if you link to an existing bibliography it's linked in another direction than if you create (and link) a new one. So definitely a bug which we should fix.

• Bibliography, Edition, Reference Systems (e.g Wikidata, GeoNames) are always used as domain
• Files are always used as domain except when in combination with Bibliography, Edition
• External references are always used as domain except when in combination with a file

This should cover all combinations but please take you time to think it through (I might have missed something) and others are welcomed to participate as well.
If we fail to define a basic strategy e.g. sometimes a file and an external reference should be linked with refers to in one direction, and sometimes in the other, this will get a much longer discussion.
Anyway, you raised good points and we should discuss it through before making changes.

I did some testing, following SQL returns all P67 combinations with OpenAtlas classes for domain/range with counts:

SELECT DISTINCT
    count(l.property_code),
    d.openatlas_class_name AS domain,
    l.property_code,
    r.openatlas_class_name AS range
FROM model.link l
JOIN model.entity d ON l.domain_id = d.id
JOIN model.entity r ON l.range_id = r.id
WHERE l.property_code = 'P67'
GROUP BY l.property_code, d.openatlas_class_name, r.openatlas_class_name
ORDER BY domain, range

• red ones are invalid for the rules defined before. There are a few but it looks good so far.
• I also found one file/file link which we should look at separately
• Don't take my word for granted and check for yourself, it's a little mind boggling when staring too long at this ;)
• I will try to check other projects next week as well

Alexander Watzinger wrote in #note-5:

I took a closer look at the implementation and have to say, it's definitely a good catch by you, Stefan.
E.g. when at the file detail view in the reference tab depending on if you link to an existing bibliography it's linked in another direction than if you create (and link) a new one. So definitely a bug which we should fix.

I can fix the code and also write an update SQL to fix existing entries but before that I wanted to make sure we get it right, otherwise this could turn really messy.
So my question is, can we define a basic link strategy for refers to, "always used as" refers to combinations with all other entities as well (actor, event, place, ...) e.g.:

• Bibliography, Edition, Reference Systems (e.g Wikidata, GeoNames) are always used as domain
• Files are always used as domain except when in combination with Bibliography, Edition
• External references are always used as domain except when in combination with a file

This should cover all combinations but please take you time to think it through (I might have missed something) and others are welcomed to participate as well.
If we fail to define a basic strategy e.g. sometimes a file and an external reference should be linked with refers to in one direction, and sometimes in the other, this will get a much longer discussion.
Anyway, you raised good points and we should discuss it through before making changes.

I think it is even easier. all References as well as Reference Systems should be domain: Reference (Bibliography, Editon, External reference) "P67 - refers to" "whatever entity"

Files can be domain and range depending on a simple decision: is the file showing a certain entity? -> Yes: File "P67 refers to" "certain entity" So all tabs/classes entities in the file view (except for the reference ones) should be linked like described above.
Other case:
Is the file from a certain source-entity? -> Yes: Source entity (Bibliography, External Reference) "P67 refers to" "that one file".

Hope this helps,
best, Stefan

Thank you for your feedback. After discussing it with Bernhard we refined the rules:

• Bibliography, edition, external reference, reference systems (e.g Wikidata, GeoNames) are always used as domain
• Files are always used as domain except when in combination with above

Just a few notes (mostly for myself).

The issue is less dramatic than assumed. The problem occurs only when being in a file detail view and adding (and linking) a new reference via the "+" buttons.
When adding a reference via the "link" functions it works as expected. When using the "+" function in other views than files it also works as expected.

• Rewrite the "+" function (/insert/<class_>/<int:origin_id>) to behave differently when coming from a file and creating a reference.
• Write an SQL update that fixes existing P67 links to references which may have the wrong direction caused by this bug (file should be the range).