Re: A Modest Proposal

Oh, I have plenty of suggestions on how to simplify SHACL. I would start 
by dropping the concept of "Shape", which is almost equivalent to 
"Class" and therefore can be merged into what already exists. Then I 
would delete the concept of "scopes", which in the majority of cases is 
scopeClass anyway. Finally I would delete QCRs, closed shapes and many 
other features that are barely needed in my personal experience. I would 
leave them all to 3rd party template libraries instead.

If we want to create a language that is easy to understand and 
incrementally adopt by existing semantic web users then the design above 
should have been used.

Templates are not the big obstacle - as Karen states some people 
struggle much earlier. Indeed templates keep the whole language design 
consistent. There is no way TQ is going to accept dropping templates 
without also reopening basically every single decision that we approved 
as a compromise in exchange.

Holger


On 10/17/15 3: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
>

Received on Friday, 16 October 2015 23:22:17 UTC