Rename command issue

[hrshdhgd]

Background: ENVO is using ontobot-change-agent which in turn uses kgcl-java to automate changes in the resource file.

An issue was opened in the ENVO repo which triggered the ontobot workflow and in the workflow I noticed an error:

2024-03-06 17:16:36,716 ERROR org.incenp.obofoundry.kgcl.robot.ApplyCommand - KGCL apply error: Label "tropical grassland" not found on <http://purl.obolibrary.org/obo/ENVO_01001806>

The term and URI do exist in ENVO [Ctrl+f : (tropical grassland)] points to:

# Class: <http://purl.obolibrary.org/obo/ENVO_01001806> (tropical grassland)

Any thoughts ?

[hrshdhgd]

• I just noticed the workflow uses v0.2.0 and the latest is 0.3.2.
  • The error still persists even after the update.

[gouttegd]

This is working as expected. ENVO:01001806 does have a tropical grassland label, but the label has an English language tag:

AnnotationAssertion(rdfs:label ENVO:01001806 "tropical grassland"@en)

KGCL-Java does take the language tag into account when trying to find the existing label, so it is perfectly expected and normal that it does not find "tropical grassland"@en when it is looking for "tropical grassland".

The command should have been

rename ENVO:01001806 from "tropical grassland"@en to "tropical grassland ecosystem"@en

[hrshdhgd]

The @en may not be a good way of doing this. It is tagging a GitHub user (example) with that username. Also, in the absence of language , shouldn't it default to English?

[cmungall]

First, let's acknowledge that ENVO is inconsistent here, with 50% of labels having this tag, and 50% not. For other annotations, it's more skewed towards not having the label.

Let's also acknowledge that KGCL is under-specified here, I made an issue here INCATools/kgcl#60

[gouttegd]

The @en may not be a good way of doing this. It is tagging a GitHub user (example) with that username.

Well, that’s the way specified in the KGCL grammar. Chosen for similarity with the OWL functional syntax, I suppose.

Also, in the absence of language , shouldn't it default to English?

The problem is that a term may very well have both a label without a language tag and label(s) with an explicit language tag. In particular, I’ve seen cases like this:

AnnotationAssertion(rdfs:label EX:0001 "the label")
AnnotationAssertion(rdfs:label EX:0001 "the label"@en)

where both the English label and the “language-neutral” label are the same string.

Now let’s suppose that I want to specifically edit the language-neutral label. Right now, I can do rename EX:0001 from "the label" to "the neutral label", and this will work.

If we decide to interpret the absence of a language tag as an English language tag by default, then I no longer have a way to specifically edit the language-neutral label.

[hrshdhgd]

hmm .. makes sense.

[gouttegd]

@hrshdhgd Let’s keep the discussion on the new issue in the general KGCL tracker, whatever we decide should apply to all KGCL implementations and not just KGCL-Java. My bad for replying here earlier.

[gouttegd]

“Relaxed” matching of language tags, as discussed in INCATools/kgcl#60, is now implemented in KGCL-Java.

When looking for an existing value:

• if the NodeChange’s old_language field has an explicit value: we only search for a value with that exact language;
• otherwise, if the NodeChange’s old_language field is not set:
  • if the NodeChange’s new_language is set, we search for a value with either the same language tag as the new_language, or a value with no language tag at all;
  • otherwise, if new_language is not set, we search for any matching literal value regardless of the language tag;
  • unless the old_datatype field is explicitly set to xsd:string, in which case we specifically search only for a value with no language tag at all.