Re: Extending SPIN with meta-templates

On 11/12/2014 4:36, Eric Prud'hommeaux wrote:
> * Holger Knublauch <holger@topquadrant.com> [2014-11-11 22:04+1000]
>> On 11/11/2014 18:25, Eric Prud'hommeaux wrote:
>>> Wouldn't it be easier for users and implementors alike of the if
>>> there were a consistent syntax for representing constraints at any
>>> depth?
>> Yes, and such a syntax already exists and is called SPARQL. Why
>> invent another experimental language for a sub-set of SPARQL?
> I don't know how we ended up back here. I was simply saying that your
> proposal for a single nesting of constraints would have more
> applications and be more intuitive to your users if it weren't
> artificially limited to one level.

Let's try to make this concrete. Your example data was

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

Your corresponding ShExC pattern is:

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

If I understand ShEx correctly, then an equivalent SPARQL query would be:

SELECT ?patient
WHERE {
     ?patient core:cureIndication ?indication .
     ?indication core:hasIntervention ?intervention .
     FILTER (?intervention IN (core:KidneyTransplant, core:HeartTransplant))
     ?indication core:hasOutcomeAssessment/core:hasResultValue 
core:ImprovedToNormal .
}

which leads to the question whether SPARQL is really that bad, and 
whether we therefore need to introduce yet another syntax for a similar 
job, especially if that new syntax then introduces many other 
limitations that are already solved by SPARQL.

Assuming that the SPARQL above is acceptable, then why would introducing 
further metalanguage to SPIN be necessary, and how would that extension 
look like in detail? I can easily see how to extend SPIN with a single 
level of nesting, so that a constraint can be applied to a resource that 
is accessed from the root object via a path expression. For example, see 
the examples at the lower half of

https://www.w3.org/2014/data-shapes/wiki/Schema.org_Constraints

(Having just a single level would just require introducing a single 
property such as spin:thisPath or spin:valuePath, and that can readily 
be reused to construct an error message. If OTOH we supported multiple 
levels, we would need to introduce new nodes that lead to complex bnode 
structures and ugly Turtle/JSON-LD.)

And I can also see how we can still explain this one level to users. I 
would struggle to explain to users why we ended up with another way of 
expressing complex expressions that are already handled (better) by 
general SPARQL, and require complex bnode structures to represent them.

>
> I don't think this is about ShExC. I was using ShExC as a terse way to
> write nested validation constraints but I could write it again in your
> RDF syntax.

FWIW the SPIN RDF syntax of the SELECT above would look like

[ a sp:Select ;
     sp:resultVariables  ( [ sp:varName  "patient" ] ) ;
     sp:where            (
         [
             sp:subject    [ sp:varName  "patient" ] ;
             sp:predicate  core:cureIndication ;
             sp:object     [ sp:varName  "indication" ] ;
         ]
         [
             sp:subject    [ sp:varName  "indication" ] ;
             sp:predicate  core:hasIntervention ;
             sp:object     [ sp:varName  "intervention" ] ;
         ]
         [ a  sp:Filter ;
             sp:expression  [ a sp:in ;
                 sp:arg1  [ sp:varName  "intervention" ] ;
                 sp:arg2  core:KidneyTransplant ;
                 sp:arg3  core:HeartTransplant
             ]
         ]
         [ a sp:TriplePath ;
             sp:subject  [ sp:varName  "indication" ] ;
             sp:object   core:ImprovedToNormal ;
             sp:path     [ a         sp:SeqPath ;
                 sp:path1  core:hasOutcomeAssessment ;
                 sp:path2  core:hasResultValue
             ] ;
         ] )
]

which isn't perfectly readable to humans, but quite processable by tools 
(and covers all of SPARQL, not just some subset). I am quite confident 
that your ShEx RDF syntax would have similar complexity - that's just 
the price of triple-based notations.

Holger

Received on Tuesday, 11 November 2014 23:37:58 UTC