- From: Holger Knublauch <holger@topquadrant.com>
- Date: Tue, 11 Nov 2014 10:11:30 +1000
- To: public-data-shapes-wg@w3.org
On 11/11/14, 9:34 AM, Eric Prud'hommeaux wrote:
>
> 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.
Good, we may be getting somewhere!
> 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 ]
> )
> ]
> ]
> )
> ] .
The draft of the SPIN extension would only cover one level of context.
While I am sure further levels could be added, I believe that if we go
down this route then we are rather re-inventing a light-weight version
of SPARQL, and I wonder where this ceases to make sense. Even the OWL
example above looks already too complex (and similar to how the SPIN RDF
triple notation would look like). At some stage these object models stop
being useful, and we could just as well open up to any SPARQL.
If our main goal is to create a high-level syntax that uses objects
instead of SPARQL strings, then we have various alternatives such as
using something similar ShExC as one possible input notation, which then
gets compiled into SPIN/SPARQL for execution.
I can imagine one use case of the high-level "object" notation may be
graphical editors for constraints. Such graphical editors would
typically be hard-coded against certain patterns. For things like
dependencies that are two levels deep, I believe those tools quickly
become too complicated.
Where to draw the line? Hard to say without seeing more real-world use
cases where simple one-step-contexts are not sufficient yet falling back
to SPARQL is not acceptable. I believe that space may be very small and
I'd rather keep the language and engine simple before expecting too much
from an adoption standpoint.
HTH
Holger
Received on Tuesday, 11 November 2014 00:12:08 UTC