Curie generation for vocab identifiers sometimes uses incorrect/non-existent prefix for v4.15+

[jamiefeiss]

Currently an issue with the GA dev instance, e.g. - https://ga.dev.kurrawong.ai/catalogs/catalogue:ga-vocabs/collections/gavoc:associationtype
for Prez v4.20.0. Also tested locally for future versions up to latest, including config loaded remotely, locally, or no endpoint config, and the issue persists.

Confirmed working in v4.9.3.

Other instances such as the IDN instance don't have this issue however (also v4.20.0), e.g. - https://data.idnau.org/catalogs/pid:refdata-catalogue/collections/vocab:cat-roles

The identifier used for the UI to construct the /top-concepts URL to request concepts seems to be incorrectly generated, e.g. "ns1:associationtype" rather than "gavoc:associationtype". The correct curie is in other places in the data however. This leads to concept links generated from this identifier to be incorrect, so concepts links do not resolve.

The vocab source data is here (all vocabs have the same issue) - https://github.com/GeoscienceAustralia/ga-vocabs/blob/develop/vocabularies/AssociationType.ttl

Endpoint config is below, but the issue exists even with no config:

@prefix schema: <https://schema.org/> .
@prefix ont: <https://prez.dev/ont/> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix sh: <http://www.w3.org/ns/shacl#> .
@prefix skos: <http://www.w3.org/2004/02/skos/core#> .

<https://prez.dev/systemGraph> {

  <catalogs> a ont:DynamicEndpoint, ont:ListingEndpoint ;
      rdfs:label "Catalogs" ;
      ont:apiPath "/catalogs" ;
      ont:relevantShapes <level1> .

  <catalog> a ont:DynamicEndpoint, ont:ObjectEndpoint ;
      rdfs:label "Catalog" ;
      ont:apiPath "/catalogs/{catalogId}" ;
      ont:relevantShapes <level1> .

  <collections> a ont:DynamicEndpoint, ont:ListingEndpoint ;
      rdfs:label "Collections" ;
      ont:apiPath "/catalogs/{catalogId}/collections" ;
      ont:relevantShapes <level2> .

  <collection> a ont:DynamicEndpoint, ont:ObjectEndpoint ;
      rdfs:label "Collection" ;
      ont:apiPath "/catalogs/{catalogId}/collections/{collectionId}" ;
      ont:relevantShapes <level2> .

  <items> a ont:DynamicEndpoint, ont:ListingEndpoint ;
      rdfs:label "Items" ;
      ont:apiPath "/catalogs/{catalogId}/collections/{collectionId}/items" ;
      ont:relevantShapes <level3> .

  <item> a ont:DynamicEndpoint, ont:ObjectEndpoint ;
      rdfs:label "Item" ;
      ont:apiPath "/catalogs/{catalogId}/collections/{collectionId}/items/{itemId}" ;
      ont:relevantShapes <level3> .

  <level1> a sh:NodeShape ;
      sh:targetClass schema:DataCatalog ;
      ont:hierarchyLevel 1 .

  <level2> a sh:NodeShape ;
      sh:property
        [
          sh:class schema:DataCatalog ;
          sh:path [ sh:inversePath schema:hasPart ]
        ] ;
      sh:targetClass skos:ConceptScheme ;
      ont:hierarchyLevel 2 .

  <level3> a sh:NodeShape ;
      sh:property
        [
          sh:class skos:ConceptScheme ;
          sh:path skos:inScheme
        ],
        [
          sh:class schema:DataCatalog ;
          sh:path (
            skos:inScheme
            [ sh:inversePath schema:hasPart ]
          )
        ] ;
      sh:targetClass skos:Concept ;
      ont:hierarchyLevel 3 .

}

[jamiefeiss]

From further testing locally, this seems to be a data issue to do with identifiers in the data which causes issues with curie generation.

The GA vocab I was testing with had a schema:identifier in the data whereas an IDN vocab did not.

Despite clearing Fuseki and running tbox cache purge, previously generated curies seemed to persist, which continued to cause the issue. Only from starting from a fresh Fuseki/prez compose stack did the curies generate as expected.