Re: Extending SPIN with meta-templates

On 11/7/14, 9:15 AM, Holger Knublauch wrote:
> 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.

Thinking more about this, I can see that such a context-sensitive 
constraint could be a genuine improvement to SPIN. Assuming that in the 
example above, the template spl:RequiredPropertyConstraint would have 
the following body:

ASK {
     FILTER NOT EXISTS { ?this ?property ?any }
}

If used within a spin:ContextSensitiveConstraint, it would be executed as

ASK {
     ?root :assignedTo ?this .
     FILTER NOT EXISTS { ?this ?property ?any }
}

This would not require any complex changes to the SPIN execution engine, 
but can already be solved with a simple pre-processor that rewrites the 
constraints. As Eric states, the benefit is that people can make of 
high-level constraint templates for additional use cases, without having 
to fall back to SPARQL. It even has similarities with the context idea 
from the Google paper.

So I'd be all in favor of adding this, and hope this brings our 
approaches closer to a common grounding. Details would need to be worked 
out, e.g. I guess we should also allow inverse property paths, possibly 
even more general path expressions, and a context could probably also 
point to multiple child templates, essentially grouping them together.

Eric: I would like to know how many of your (clinical?) use cases such a 
solution would cover. Do you have specific examples other than the issue 
tracker toy example? Which cases could not be represented with this 
mechanism, and do you see similar patterns to represent those while 
staying within the simple execution logic of SPIN?

Thanks,
Holger

Received on Saturday, 8 November 2014 04:08:09 UTC