Re: Extending SPIN with meta-templates

* 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.


> 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.

Kendal obviously has an interest in selling ICV, of which there is one
implementation that no one's seen. Contrast that with five open-source
implementations of ShEx:
a W3C Submission (definition and primer) with five submitters:
hudreds of tests:
and rigorous theoretical analysis:


> >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.

I imagine it's practical to consider two groups:

  application UI: hand-designed for a particular process. Uses shapes
  to test the input data against constraints, e.g. a clinician
  entering a patient record as a positive outcome to a clinical trial.

  generic UI: machine-generated from a schema. Uses shapes to generate
  the interface, drive the generation of pick-lists or tab-completions,
  and validate the entered data.

While both of these could take advantage of a machine-readable
expression of contextual constraints, I think you're speaking of the
former.


> >> 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.

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.


> 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 Tuesday, 11 November 2014 18:36:24 UTC