Re: A Modest Proposal

Peter, I'm glad that your proposal is MUCH more modest that Swift's.* I 
heartily agree that SHACL is overly complex from the user point of view. 
To prove this one way or the other, I was hoping to code a set of test 
cases that, should things remain as they are, could be used to 
illustrate SHACL to potential users. The lack of comments that we've 
gotten tells me that folks either are totally uninterested or become so 
once they set eyes on the draft. Examples might help them get a quick 
view. However, I'm not a programmer, and I don't have a way to test my 
tests. So I'm not making the progress I would like. If anyone else is 
interested in this approach, I'll do all of the heavy lifting that I can.

Thanks,
kc

* "I have been assured by a very knowing American of my acquaintance in 
London, that a young healthy Child well Nursed is at a year Old, a most 
delicious, nourishing, and wholesome Food, whether Stewed, Roasted, 
Baked, or Boyled, and I make no doubt that it will equally serve in a 
Fricasie, or Ragoust."

On 10/16/15 10:44 AM, Peter F. Patel-Schneider wrote:
> I was looking at the SHACL document in preparation for making a suggestion
> about what to do about subclassing between templates.  I ended up being most
> struck with how complex SHACL now is.
>
> I found this very strange, as a big reason in my mind for basing SHACL on
> SPARQL was to make SHACL small and easy to understand.  Given that SHACL is
> so complex, what can be done?
>
> I see two approaches:
> 1/ Don't base SHACL on SPARQL.
> 2/ Simplify SHACL.
>
> The first approach admits that a constraint language is in itself so complex
> that it needs its own complete foundation from the ground up.  What the
> result of this approach would be is uncertain, but the syntax and the formal
> underpinnings might be something like ShEx, but with a different set of
> implicit or explicit control constructs
>
> The second approach needs a determination of what to simplify to get to a
> modest SHACL.  It seems to me that a large source of complexity are the
> template mechanisms.  A SHACL specification without templates and related
> notions would, I think, be viable, and quite easy to produce from the
> current document.  This would retain the ability to use native SPARQL as an
> extension mechanism.  This would not prevent SHACL implementors from
> implementing SHACL by means of templates nor in exposing this template
> mechanism to their users.  I think that other simplifications are possible
> and desirable, but removing templates is the biggest reasonable
> simplification.
>
> Of the two approaches, I prefer the second.  (No surprise here!)
>
>
> Peter F. Patel-Schneider
> Nuance Communications
>
>

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

Received on Friday, 16 October 2015 20:04:45 UTC