Re: Extending SPIN with meta-templates

On 11/11/14 4:04 AM, Holger Knublauch wrote:
> 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 I find English more readable than Chinese, and that puts me in a 
minority on this globe ;-).

We all read most easily the languages, natural or formal, that we know 
best. I think we need to find some other criteria for deciding. My 
preference would be to do some rigorous testing of capabilities using a 
test suite made up of a judicial sampling of use cases. This testing 
should include simple cases as well as complex cases. My presumption is 
that we can all learn the technology that performs best, just as we have 
learned the ones we are using today.

kc

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

-- 
Karen Coyle
kcoyle@kcoyle.net http://kcoyle.net
m: 1-510-435-8234
skype: kcoylenet/+1-510-984-3600

Received on Tuesday, 11 November 2014 19:59:34 UTC