SHACL: Shapes discovery

[tpluscode]

I have found it useful to be able to easily find Node Shapes for a given class. There are a handful of scenarios.

In one, an operation expects a class which is described by multiple shapes.

<operation> hydra:expects schema:Person .

A client could generate a form UI from shapes targeting the given class.

GET /shapes?targetClass=https://schema.org/Person

Secondly, an application itself can render resources views from shape descriptions. These could be served from the same collection filtered differently or a different one

GET /shapes?applicableToClass=https://schema.org/Person

The difference here is the filter property. In the validation case, the strong sh:targetClass property would be used. In a less strict scenario dash:applicableToClass could be used to find shapes which do not otherwise trigger validation.

The collection template could be similar to that below

[] 
  a hydra:IriTemplate ;
  hydra:template "/shapes{?targetClass,applicableToClass}" ;
  hydra:mapping [
    hydra:variable "targetClass" ;
    hydra:property sh:targetClass ;
  ] , [
    hydra:variable "targetClass" ;
    hydra:property dash:applicableToClass ;
  ] ;
.

[alien-mcl]

What is an extension regarding pure hydra in this scenario? From hydra point of view it's a standard Iri template. Indeed she sh:targetClass and dash:applicableToClass should be understood by the client to effectively use it, but this can be advertised with extension predicate provided in the ApiDocumentation

[tpluscode]

Not sure if I understood the question.

The missing piece would be the actual link from the documentation to the shapes collection. Not enough to just add the hydra:extension IMO

# or maybe subPropertyOf hydra:search ?
hashi:shapes rdfs:subPropertyOf hydra:collection .

<api>
  a hydra:ApiDocumentation ;
  hashi:shapes [
    # the search template as above
  ] .

The actual document would describe what a clients/server should or must do with this property, ie. define some best practices about interpreting the template variables as used above, etc.

[alien-mcl]

You could use strongly typed collections - this way there is no need to introduce new predicates - client could discover a collection of shapes with pure hydra.

[tpluscode]

Would strongly typed collections provide filtering? A server could add "non-standard" variable/property maps to the template to give client who understand a more flexible query mechanism to get the exact shapes they need

[tpluscode]

Well ok, I think I see who we can put 2 and 2 together.

</api/ShapesCollection>
  a hydra:Class ;
  rdfs:subClassOf hydra:Collection ;
  hydra:memberAssertion [
    hydra:property rdf:type ; hydra:object sh:NodeShape ;
  ] ;
  hydra:search [
    # as above
  ] .

</api> hydra:collection </shapes> .
</shapes> a </api/ShapesCollection> .

This way the extension would only need to describe that compliant clients look for a hydra:collection value with appropriately typed collection type and what they can expect from the search template.

The only downside is that look for hydra:Collection with certain member assertion is slightly more verbose that look for hashi:shapes predicate but I certainly buy the argument that using Core terms would at least partially work for basic clients 👍