Re: Extending SPIN with meta-templates

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?

If you need more opinions, see for example
"as long as the mapping is sound and there’s a real user base for the 
syntax. ShEx fails on that account."
"Allow me to gaze in horror at ShEx. Clearly what Linked Data needs is 
more standards with limited implementations."

as well as numerous emails from the old mailing list.

> The ShExC above is trivially compiled to SPARQL so nesting doesn't 
> impose complexity constraints.
> The example above for a constraint (patients in the positive outcome 
> report) is typical; imposing an arbitrary depth limit will just 
> confuse users.
> > 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.
> Why would the user interface be easier or harder to use if it's 
> getting integrity constraints on 2, 3, or 10 levels of nested 
> constraints? If you mean the creator of the constraint, they'll only 
> have a harder time if the shapes syntax imposes some arbitrary limit.

I have no idea how a graphical editor for such complex constraints would 
look like.

> > 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.
> I agree with the goal of simplicity. I think that if you experiment 
> with this a bit, you'll get to really like it and find that it 
> simplifies things for your users.

Sorry but I see no evidence for that claim. I find SPARQL far more 
readable than ShExC and I am not alone with that opinion. And if you 
prefer an object model instead of a textual syntax, the SPIN RDF Syntax 
can help and has true coverage of the SPARQL spec, not just an arbitrary 
sub-set like ShExC does.


Received on Tuesday, 11 November 2014 12:07:28 UTC