Re: Pragmatic Proposal for the Structure of the SHACL Spec

I have to differ on the point that the organization of our documents is up 
to the editors. This is very much a WG decision and there is actually very 
practical consequences that we need to consider and may influence how we 
want to organize our documents.

One of them is that to become a Recommendation a specification needs to 
successfully go through Candidate Recommendation and gather enough 
implementation support (what exactly "enough" means is to be defined by 
the WG but it's a least 2 implementations). If everything is in one 
document, we need to get that  whole document to get enough implementation 
support to become a Recommendation. If we split the document in smaller 
pieces, various pieces might move along at a different pace.

For instance, we might be able to get the higher level set that doesn't 
require support for SPARQL extensions as a REC sooner.

This is also something to consider when thinking about the dependencies 
between the different layers. With the bottom up approach, if we end up 
with the higher level having a normative reference to the lower level it 
won't be able to get to REC until the lower level is. This is also true if 
the higher level is defined as a "profile" (i.e., a specification that 
defines a subset of a full spec) of the main spec.
--
Arnaud  Le Hors - Senior Technical Staff Member, Open Web Technologies - 
IBM Software Group


Arthur Ryman <arthur.ryman@gmail.com> wrote on 03/19/2015 09:15:39 AM:

> From: Arthur Ryman <arthur.ryman@gmail.com>
> To: Richard Cyganiak <richard@cyganiak.de>
> Cc: "public-data-shapes-wg@w3.org" <public-data-shapes-wg@w3.org>
> Date: 03/19/2015 09:16 AM
> Subject: Re: Pragmatic Proposal for the Structure of the SHACL Spec
> 
> Richard,
> 
> I am fine with these parts being in one document if that in fact
> simplifies maintenance. That decision should be delegated to the
> editors. However, I think we could stabilize Part 1 soon, publish it,
> show a heartbeat, and get some feedback.
> 
> I hope we don't have warring editors. Putting a stake in the ground by
> publishing Part 1 might improve our shared understanding of SHACL.
> 
> -- Arthur
> 
> On Thu, Mar 19, 2015 at 8:02 AM, Richard Cyganiak <richard@cyganiak.de> 
wrote:
> > Arthur,
> >
> > I agree with your analysis regarding different audiences. I am 
> sympathetic to the notion that there should be three parts.
> >
> > However, I disagree with your conclusion that there should be 
> three documents.
> >
> > Keeping multiple documents in sync is a significant burden on a 
> working group. It makes sense if the documents describe loosely 
> coupled components of an overall framework, but that is not the case
> here; your proposed split would leave material related to a single 
> language feature often distributed over three different documents 
> (and perhaps maintained by three warring editors).
> >
> > I don’t see why a single specification cannot adequately address 
> the needs of different target audiences.
> >
> > The SPARQL 1.1 spec is an example of a specification that delivers
> a primer, a thorough language reference, precise semantics, and 
> guidance for implementers in a single document.
> >
> > Best,
> > Richard
> >
> >
> >
> >> On 18 Mar 2015, at 22:29, Arthur Ryman <arthur.ryman@gmail.com> 
wrote:
> >>
> >> At present we are witnessing a burst of creative activity. It is 
great
> >> to see such energy in a WG. However, the result is that we have too
> >> many specs and I doubt that most members can give all these documents
> >> adequate review. We need to focus our resources on fewer specs.
> >>
> >> There has also been extended discussion on the role of SPARQL, on
> >> profiles of SHACL, and on who the target audience is. I'd like to
> >> propose a pragmatic structure that will enable us to package the
> >> material in a way that will address our audiences, enable us to 
divide
> >> the work better, and create a sequence of deliverables.
> >>
> >> I propose three levels of content. I'll refer to these as Parts 1, 2,
> >> and 3 in order to defer word-smithing of the titles.
> >>
> >> 1. SHACL Part 1. The audience is people who want to use a simple,
> >> high-level language that can express common constraints. This 
document
> >> should use precise, natural language to describe the semantics of
> >> those common constraints that can be expressed using the high-level
> >> vocabulary of SHACL. It should also include simple examples to
> >> illustrate concepts. It should be readable by people who do not know
> >> SPARQL. It should not refer to SPARQL. It should not define formal
> >> semantics. It should be possible for this part of SHACL to be readily
> >> implemented in SPARQL or Javascript. We therefore need to limit the
> >> expressive power of this part of SHACL.
> >>
> >> 2. SHACL Part 2. The audience is people who want to write custom
> >> constraints using an executable language. This part defines the
> >> template/macro mechanism. It also provides normative SPARQL
> >> implementations of the high-level SHACL language introduced in Part 
1.
> >> This part should not contain other formal specifications. The SPARQL
> >> implementations can be regarded as executable formal specifications.
> >>
> >> 3. SHACL Part 3. The audience is people who want to implement SHACL.
> >> This part should contain a formal specification. We can defer the
> >> choice of formalism. If we have multiple candidates and willing
> >> authors, let's do a bake-off.
> >>
> >> -- Arthur
> >>
> >
>