Open tpluscode opened 3 years ago
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
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.
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.
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
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 :+1:
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.A client could generate a form UI from shapes targeting the given class.
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
The difference here is the filter property. In the validation case, the strong
sh:targetClass
property would be used. In a less strict scenariodash:applicableToClass
could be used to find shapes which do not otherwise trigger validation.The collection template could be similar to that below