Re: Extending SPIN with meta-templates

* Holger Knublauch <holger@topquadrant.com> [2014-11-08 14:07+1000]
> 
> 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?

If I understand it correctly, this will take care of at least one
level of conttextual constraints, potentially more. This is quite
important to most of my use cases. Can it handle multiple levels of
constraints <http://w3.org/brief/NDEz>:

Data:
  <P>
    core:cureIndication [
      core:hasIntervention :KidneyTransplant ;
      core:hasOutcomeAssessment [
        core:hasResultValue :ImprovedToNormal
      ]
    ] .

ShExC Schema:
  :PatientShape {
    core:cureIndication {
      core:hasIntervention (:KidneyTransplant :HeartTransplant),
      core:hasOutcomeAssessment {
        core:hasResultValue (:ImprovedToNormal)
      }+
    }
  }

OWL/ICV Schema:
  :TransplantProcedure owl:oneOf (:KidneyTransplant :HeartTransplant) .
  xplant:PatientShape
    rdfs:subClassOf [
      owl:onProperty core:cureIndication ;
      owl:allValuesFrom xplant:GraftSurvivalAssessment
    ] .
  xplant:GraftSurvivalAssessment 
    rdfs:subClassOf [
      owl:intersectionOf (
        [ owl:onProperty core:hasIntervention ;
          owl:value :TransplantProcedure ]
        [ owl:onProperty core:hasOutcomeAssessment ;
          owl:allValuesFrom [
            owl:intersectionOf (
              core:FunctionOutcomeAssessment 
              [ owl:onProperty core:hasResultValue ;
                owl:hasValue :ImprovedToNormal ]
            )
          ]
        ]
      )
    ] .
    

> Thanks,
> Holger
> 
> 

-- 
-ericP

office: +1.617.599.3509
mobile: +33.6.80.80.35.59

(eric@w3.org)
Feel free to forward this message to any list for any purpose other than
email address distribution.

There are subtle nuances encoded in font variation and clever layout
which can only be seen by printing this message on high-clay paper.

Received on Monday, 10 November 2014 23:34:54 UTC