I’ve been surprised to find that GeoNetwork matches keywords to their thesaurus entry using the skos:prefLabel rather than the identifier by which I mean the rdf:about of the rdf:Description of rdf:type skos:Concept
This has given me problems when my users want to change the way a concept is visually presented (its skos:prefLabel) - I have to ‘rewire’ the whole GeoNetwork catalogue to the “new keyword”.
Perhaps it’s not implemented this way because thesauri from different places (INSPIRE, GEMET, …) seem to structure their SKOS differently, and the GeoNetwork developers are trying to be flexible.
Happy to do that - now to see if anyone else does show an interest!
I’ll try to tag the two developers who have related posts in that forum; I know both Francois & Byron.
I’m not very familiar with the way GeoNetwork finds matching keywords in a thesaurus but I guess we could look for an identifier first and then use the prefLabel field as a fallback, thus not breaking anything.
Another thing that could be a low hanging fruit is to index alternative labels alongside the preferred one, so that (to use an example given in one of the links) both searching for “cat” and “felis catius” would yeild the exact same results.
I don’t have a case for (or experience of) altLabels - there are people on the linked posts who do.
One thing I would say thought is that it is a (strong) SKOS recommendation that the prefLabel is unique (within a language & concept scheme). There is no such recommendation on altLabels (or hidden labels).
I’m not sure if I’m understanding the problem, but in the metadata editor you can choose the encoding of the keyword, by default is text, but you can change it to Anchor (in Geonetwork 4.4 I think Anchor is the default)
I can’t see that this is related to the problem. We do already encode the keywords as gmx:Anchor
My issue is that GeoNetwork seems to build its indexes using the skos:prefLabel for each thesaurus concept. Example, when I loaded a new version of a thesaurus where a concept had changed from:
<rdf:Description rdf:about="http://os.uk/vocabularies/theme/asu">
<rdf:type rdf:resource="http://www.w3.org/2004/02/skos/core#Concept"/>
<skos:prefLabel xml:lang="en">Administrative And Statistical Units Theme</skos:prefLabel>
to
<rdf:Description rdf:about="http://os.uk/vocabularies/theme/asu">
<rdf:type rdf:resource="http://www.w3.org/2004/02/skos/core#Concept"/>
<skos:prefLabel xml:lang="en">Administrative and Statistical Units Theme</skos:prefLabel>
...
A record encoded
<gmd:keyword>
<gmx:Anchor xlink:href="http://os.uk/vocabularies/theme/asu">Administrative And Statistical Units Theme</gmx:Anchor>
</gmd:keyword>
No longer appears in the faceted search for “Administrative and Social Units Theme”. My support tech suggested I bulk change the keywords to have the lower case “and” (as in the new version of the concept) and that solved the issue - but in my opinion is a work around of an underlying problem.
