Open tpluscode opened 4 years ago
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. 👌
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
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: