Extending SPIN with meta-templates (was: Can Shapes always be Classes?)

On 11/7/2014 0:20, Eric Prud'hommeaux wrote:
> Try the exercise of validating this data:
>    _:IssueA :submittedBy _:Bob ; :assignedTo  _:Bob .
> against this schema:
>    OWL:
>      Class: x:NewIssueShape
>        SubClassOf:
>          :submittedBy some x:SubmitterShape,
>          :assignedTo some x:AssigneeShape
>    ShExC:
>      x:NewIssueShape {
>        :submittedBy @x:SubmitterShape,
>        :assignedTo @x:AssigneeShape
>      }
>
> In OWL, Resource Shapes, ShExC (DC Application Profiles, …), the
> validator is testing _:Bob against two shapes, one for submitters
> and one for assignees. In SPIN, one would have to first infer that
>    _:Bob a x:SubmitterShape, x:AssigneeShape .
> via e.g. some OWL RL inference in order to trigger the associated
> SPIN constraints.

As stated elsewhere, there is no need to introduce extra types here and 
the constraint can be attached to :Issue directly.

I believe if people really insist on it, SPIN could be extended with 
syntactic sugar: a specific template that applies another template "one 
hop away". For example, the following should work

:Issue
     spin:constraint [
         a spin:ContextSensitiveConstraint ;
         spin:context :assignedTo ;
         spin:childConstraint [     // This gets executed for the Assignees
             a spl:RequiredPropertyConstraint ;
             spl:property foaf:mbox
         ]
     ]

where spin:ContextSensitiveConstraint would be a meta-template that 
executes another template with different bindings of ?this. It would 
require an extension to the (currently simple) execution engine. So we 
have a trade-off between keeping the language simple and the usability 
for those specific scenarios. But I see no technical reason why SPIN 
couldn't be extended for this. In the end we need to agree how important 
those use cases are.

Holger

Received on Thursday, 6 November 2014 23:18:11 UTC