Re: Pragmatic Proposal for the Structure of the SHACL Spec

Holger,

I understand that this division of content is not what you have been
advocating. I disagree that specs are only for implementers. I
frequently consult the SPARQL spec when I am writing queries, but I
have never implemented a SPARQL engine. Who among has implemented a
SPARQL engine? Specs are normative and precise. Primers focus on
progressive disclosure and are pedagogical.

Part 1 is not a primer. It covers the part of SHACL that most users of
SHACL need to understand (approximately the same level of material
covered by OSLC Shapes). That part of SHACL can be used without
requiring any knowledge of SPARQL. That part of SHACL could be
implemented in other technologies.

Part 2 defines the extension mechanism and uses SPARQL to define the
precise meaning of constraints expressible in Part 1. Only people who
understand SPARQL would benefit from reading it.

Part 3 defines the semantics more abstractly and precisely defines the
aspects of Part 2 that cannot be expressed directly in SPARQL, e.g.
the higher level control structures. In theory, an implementer who did
not understand SPARQL would be able to understand SHACL by reading
Part 3.

We definitely need a primer for Part 1. We probably need a primer for
some of Part 2. The audience for Part 3 is beyond the need for
primers.

-- Arthur

On Wed, Mar 18, 2015 at 6:43 PM, Holger Knublauch
<holger@topquadrant.com> wrote:
> 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 Thursday, 19 March 2015 02:54:34 UTC