- From: Holger Knublauch <holger@topquadrant.com>
- Date: Mon, 19 Oct 2015 10:15:49 +1000
- To: public-data-shapes-wg@w3.org
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