Re: A Modest Proposal

One may also argue why do we start with something as complex as 
sh:valueShape as our first example in the Introduction? I guess many 
people will struggle with the concept of recursive shape evaluation 
here, so why complicate the matter? sh:valueShape is just one feature 
among many others. I suggest we switch to an example with just a single 
class and shape in it.

Holger


On 10/17/2015 11:56, Irene Polikoff wrote:
> 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 Monday, 19 October 2015 00:16:30 UTC