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

https://twitter.com/kendall/status/491597407067844608
"as long as the mapping is sound and there’s a real user base for the 
syntax. ShEx fails on that account."

https://twitter.com/gcarothers/statuses/491596541103071232
"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.

Holger

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