HydraCG/Specifications

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 with sh:PropertyShape
  • hydra:property -> sh:path
  • hydra:required -> sh:minCount

Of course, some limitations could be imposed for practical reasons:

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. 👌