Enhancement: add matchedNotation field to search results for notation matches

[fvogel]

Summary

When searchByNotation is enabled, the search query's VALUES clause includes (skos:notation 5 '') as a property with priority 5, but the $labelpriority BIND block in GenericSparql.php has no corresponding BIND for priorities 5/6. Similarly, transformConceptSearchResult() has no handler for notation-only matches.

While the notation field itself still appears in results (populated by a separate OPTIONAL { ?s skos:notation ?notation } clause), there is no way for API consumers to know that a concept was matched because of its notation — unlike matchedPrefLabel, altLabel, and hiddenLabel, which indicate the reason for a match.

Current behavior

curl 'http://localhost:9090/rest/v1/test/search?query=A.1&lang=en'

{
    "uri": "http://example.org/test/cat",
    "prefLabel": "Cat",
    "notation": "A.1",
    "vocab": "test"
}

The result shows notation but there is no indication this concept was found via its notation.

Proposed behavior

{
    "uri": "http://example.org/test/cat",
    "prefLabel": "Cat",
    "notation": "A.1",
    "matchedNotation": "A.1",
    "vocab": "test"
}

The new matchedNotation field (parallel to matchedPrefLabel) tells the consumer this concept was matched by its notation.

Root Cause

In src/model/sparql/GenericSparql.php, the labelpriority BIND section covers priorities 1/2 (prefLabel), 3/4 (altLabel), and 7/8 (hiddenLabel) but skips 5/6 (notation):

BIND(IF((?pri = "1" || ?pri = "2") && ?match != ?label, ?match, ?unbound) as ?plabel)
BIND(IF((?pri = "3" || ?pri = "4"), ?match, ?unbound) as ?alabel)
-- priority 5/6 (notation): MISSING
BIND(IF((?pri = "7" || ?pri = "8"), ?match, ?unbound) as ?hlabel)

And transformConceptSearchResult() has no branch for notation matches.

Proposed Fix

1. Add BIND(IF((?pri = "5" || ?pri = "6"), ?match, ?unbound) as ?nlabel) and include ?nlabel in SELECT/GROUP BY
2. Add handler: $hit['matchedNotation'] = $row->nlabel->getValue()

This creates a matchedNotation field parallel to the existing matchedPrefLabel, giving consumers explicit match-type information.

Test vocabulary

ex:cat a skos:Concept ;
    skos:prefLabel "Cat"@en ;
    skos:notation "A.1" .

ex:siamese a skos:Concept ;
    skos:prefLabel "Siamese cat"@en ;
    skos:notation "A.1.1" .

Config: searchByNotation true, sparqlDialect "JenaText".

Environment

• Skosmos 3.1 (also present in v2.18-maintenance)
• Fuseki 5.4.0 with Jena Text / Lucene

[fvogel]

Disclaimer: I'm a new Skosmos user, currently building a vocabulary and ontology around the Kunming-Montreal Global Biodiversity Framework (KMGBF). These issues surfaced while testing the tool for my own project. I may have missed a design reason for the current behaviour — perhaps the notation priority was intentionally left unhandled. Happy to be corrected if so!