catalogs listing query bug

[lalewis1]

Issue

browsing /catalogs shows no results.

expected behaviour

a list of catalogs is returned.

suspected cause

the main query generated by

prez/prez/services/listings.py

Line 100 in 4ce71b7

main_query = PrezQueryConstructor(

seems to have lost a reference to dcat:Resource after PR #265

the code for the listings_function function and PrezQueryConstructor class don't seem to have been changed so probably it is a profile thing.

question

is this the intended behaviour now? or is this a bug

note

see below screengrab for old vs new query as captured in the debugger

[recalcitrantsupplant]

There was an ongoing discussion here #235

However.. I have some changes to define custom endpoints I'll push soon.

What's the full set of your Classes / relations between them?

Something like this?

{
          "name": "Catalog Record",
          "hierarchy": [
            {
              "rdfClass": "http://www.w3.org/ns/dcat#Catalog",
              "className": "Catalog",
              "hierarchyLevel": 1
            },
            {
              "rdfClass": "http://www.w3.org/ns/dcat#Dataset",
              "className": "Dataset",
              "hierarchyLevel": 2
            },
            {
              "rdfClass": "http://www.w3.org/ns/dcat#Resource",
              "className": "Resource",
              "hierarchyLevel": 3
            }
          ],
          "relations": [
            {
              "levelFrom": 1,
              "levelTo": 2,
              "direction": "outbound",
              "rdfPredicate": "http://purl.org/dc/terms/hasPart"
            },
            {
              "levelFrom": 2,
              "levelTo": 3,
              "direction": "outbound",
              "rdfPredicate": "http://purl.org/dc/terms/hasPart"
            }
          ]
        }

any others? vocab routes?

[lalewis1]

yeah I have some vocab with just two levels

skos:Concept -- skos:inScheme --> skos:ConceptScheme

and the catalog record heirarchy is just

dcat:Catalog -- dcterms:hasPart --> dcat:Resource

[recalcitrantsupplant]

Could you confirm if it's still an issue when defining your own custom endpoints now #274 has been merged

[lalewis1]

well it is still an issue in the sense that it does not show catalogs that only have dcat:Resources in them by default.
it works after defining a custom endpoint and I guess that is OK if that is the behaviour that we want.

would it be a problem to add dcat:Resource to the default endpoint nodeshape properties?

[recalcitrantsupplant]

Ah, I had in fact added it back to the default endpoints too
I'll add a test now

ex:shape-R0-HL3-2 a sh:NodeShape ;
    sh:property [ sh:class dcat:Dataset ;
            sh:path [ sh:inversePath dcterms:hasPart ] ],
        [ sh:class dcat:Catalog ;
            sh:path ( [ sh:inversePath dcterms:hasPart ] [ sh:inversePath dcterms:hasPart ] ) ] ;
    sh:targetClass dcat:Resource ;
    ont:hierarchyLevel 3 .

[lalewis1]

doesn't that only allow

dcat:Catalog --dcterms:hasPart--> dcat:Dataset --dcterms:hasPart--> dcat:Resource

but I am suggesting to allow

dcat:Catalog --dcterms:hasPart--> dcat:Resource

[recalcitrantsupplant]

Apologies yes the former there

@nicholascar what is the preferred Prez default for "CatPrez" - is it to have the three tier Catalog/Dataset/Resource or the Catalog/Resource . Whichever we choose, we can support the other via configurable endpoints, just need to decide what we want the default to be.

[nicholascar]

Catalog/Resource

It's simpler and also it's the OGC Records API equivalent which is the "top-level" style catalogue