Use SHACL for `IriTemplate` mappings
tpluscode opened this issue · 3 comments
Oh, what about IriTemplate
mappings. Maybe they could also be described with a Shape?
The entire mappings could easily be swapped with a Shape, provided that individual PropertyShapes
have an additional variable name which use use currently.
Here's an idea for changing EXAMPLE 19 from the spec
{
"@context": "http://www.w3.org/ns/hydra/context.jsonld",
"@type": "IriTemplate",
"template": "http://api.example.com/issues{?q}",
"variableRepresentation": "BasicRepresentation",
- "mapping": [
- {
- "@type": "IriTemplateMapping",
+ "mapping": {
+ "@type": "sh:NodeShape",
+ "sh:property": [
"variable": "q",
- "property": "hydra:freetextQuery",
- "required": true
- }
- ]
+ "sh:path": "hydra:freetextQuery",
+ "sh:minCount": 1
+ ]
+ }
}
Little has to change conceptually.
hydra:IriTemplateMapping -> sh:PropertyShape
hydra:variable
used withsh:PropertyShape
hydra:property -> sh:path
hydra:required -> sh:minCount
Of course, some limitations could be imposed for practical reasons:
- only single level of shapes
- no property paths
Originally posted by @tpluscode in #214 (comment)
Let's keep the discussion separate for SHACL for hydra:expects
as opposed to hydra:mapping
Alternative solution proposed by @alien-mcl would be to keep the IriTemplateMapping
and simply link the template to a shape which is an alternative description of the same graph.
{
"@context": "http://www.w3.org/ns/hydra/context.jsonld",
"@type": "IriTemplate",
"template": "http://api.example.com/issues{?q}",
"variableRepresentation": "BasicRepresentation",
"hashi:shape": "ex:IssueSearchShape",
"mapping": { /* ... */ }
}
A client which understands SHACL extensions would find the hashi:shape
link and use that as the description of user input.
By keeping the Hydra Core mapping
property other clients could use that as a fallback and still produce a conforming template
I think that's an elegant solution. 👌