Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Indexing 'label_property' is not working as aspected #474

Closed
rombaum opened this issue Aug 16, 2023 · 3 comments
Closed

Indexing 'label_property' is not working as aspected #474

rombaum opened this issue Aug 16, 2023 · 3 comments
Assignees

Comments

@rombaum
Copy link

rombaum commented Aug 16, 2023

I finally found the time to play around with your ols4 version. I also converted our old .yaml config files to JSON via:

cat old-config.yaml | yq eval -j - > ./new-config.json

I afterwards indexed everything to my local machine. The indexing process worked so far smooth and fine. I afterwards starts to check some loaded ontologies at the frontend. In one case I spotted as a result that the parsing of the preferred label has changed. In OLS3 the label_property was a single value in quotation marks. OLS4 is expecting an array/collection. Similar to the hierarchical_property and synonym_property. I could live with this change but I think it is maybe not meaningful due to the fact that a owl:class could have to different properties for labels. In this case it could be that the value of the first label property could be overwritten from the second label property.

There are two simple ways to continue.

  1. The first one would be to change the code in the LabelAnnotator class.

https://github.com/EBISPOT/ols4/blob/d9f2391a8fbcedb68888cb48458fd466eeddd646/dataload/rdf2json/src/main/java/uk/ac/ebi/rdf2json/annotators/LabelAnnotator.java#L12C1-L26C10

  1. Update the config files to the new structure. For example at the moment the following line is ignored via the indexing.
    "label_property": "http://www.w3.org/2004/02/skos/core#prefLabel",

Here are some nice images to describe the issue.

term view GUI
fig.1 term view GUI with unwished labels
excerpt from the owl file
fig.2 excerpt from the corresponding owl file
excerpt from a json config file which doesn't work
fig.3 excerpt from a json config file which doesn't work
excerpt from a json config file with corrected structure
fig.4 excerpt from a json config file with corrected structure

@henrietteharmse
Copy link
Collaborator

@rombaum Thank you for logging this. Can you please provide a minimal complete ontology with config illustrating the problem?

@rombaum
Copy link
Author

rombaum commented Aug 21, 2023

@henrietteharmse to prepare such a ontology file I played a little bit with namespaces. First I just tried:

http://xmpl.org/xmpl/

but had the issue does it never works. I changed it afterwards to:

http://exmpl.org/xmpl/

and I had the same behavior as described in the first post of this ticket #474 (comment) . Which means that I see the user defined pref label.

I than checked if the list is maybe ordered and tried:

http://zxmpl.org/xmpl/ and http://ympl.org/xmpl/

I than tried http://sxmpl.org/xmpl/ because the 's' is directly behind the 'r' in http://www.w3.org/2000/01/rdf-schema# and there the specific pref label is also working correctly.

However I put everything into a .zip.file. In this zip file are two config files and an small ontology file. The config file with the user defined pref label is named use-user-defined-pref-label.json . The config file where the user defined pref label is ignored is called ignore-user-defined-pref-label.json. You have to change the path of ontology_purl in the config files.

@henrietteharmse henrietteharmse self-assigned this Aug 30, 2023
henrietteharmse added a commit that referenced this issue Nov 13, 2023
…ue rather than array. No code change for now.
henrietteharmse added a commit that referenced this issue Nov 13, 2023
#474 examples (1)with array of 2 labels and (2) label with string val…
@henrietteharmse
Copy link
Collaborator

I agree with you that for a specific term where 2 label_properties apply it is not ideal and most likely unintentional. However, having multiple label_properties for an ontology I think is indeed a valid use case. Often ontologies are created using different vocabularies and ontologies. I.e. Schema.org uses rdfs:label, while SKOS uses skos:prefLabel, and some OBO ontologies use obo:IAO_0000118. Thus, for now we will leave the label property as an array.

I have added your examples for future reference under ./testcases/iri_labels. I have amended the example to specify 2 label_properties that are used in the ontology.

Thank you for raising the issue and the examples. It has been very helpful.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants