Re: A Modest Proposal

I find the discussion on all the different scopes very complex and since
this complexity is presented as the first several sections in the document
they are a major obstacle to anyone trying to understand this for the
first time.


Irene Polikoff






On 10/16/15, 7:21 PM, "Holger Knublauch" <holger@topquadrant.com> wrote:

>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 Saturday, 17 October 2015 01:57:31 UTC