Re: Pragmatic Proposal for the Structure of the SHACL Spec

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
>

Received on Thursday, 19 March 2015 12:03:00 UTC