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
>>
>

Received on Thursday, 19 March 2015 16:16:10 UTC