Re: Pragmatic Proposal for the Structure of the SHACL Spec

Hi Arthur,

I think your message is mixing up Primer and Spec material. The Spec is 
meant for implementers. Others can read Primers, examples, mailing 
lists, stack overflow etc. For now the WG should focus on the Spec.

Having said this, I believe my current draft addresses your separation 
of Part 1 (sections 2-6) and Part 2 (sections 7 onwards) already. I do 
not see how to separate your Part 3 from Part 2 - as soon as you talk 
about templates and sh:sparql, you also need to have a precise 
definition of how these are implemented. This is covered by the 
Operations section of my draft.

Holger


On 3/19/2015 8:29, Arthur Ryman 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 Wednesday, 18 March 2015 22:52:16 UTC