Re: Pragmatic Proposal for the Structure of the SHACL Spec

Arnauld,

For several reasons the code analogy is not a relevant argument in the
context of our discussion. For example, code modules that depend on each
other usually import each other or are jointly part of a compile/build
process that flags incompatibilities. There are common interfaces and
contracts defined for code that must work together and so on. In short,
there are whole methodologies and corresponding tooling to ensure that code
modularity works. 

Yes, I am pointing to the problem of different people working independently
without reaching consensus on key issues. This is the real issue and the
main way it is related to the number  documents is that having separate
documents better enables such mode of working.

At the same time, I am not clear what problem is being solved by having
multiple separate documents.

Irene

From:  Arnaud Le Hors <lehors@us.ibm.com>
Date:  Thursday, March 19, 2015 at 8:05 PM
To:  Irene Polikoff <irene@topquadrant.com>
Cc:  <kcoyle@kcoyle.net>, <public-data-shapes-wg@w3.org>
Subject:  Re: Pragmatic Proposal for the Structure of the SHACL Spec

Irene, the possible problem you're pointing out has to do with having
different people work independently rather than having multiple documents.
The same would be true if we had one document with various sections
independently edited by different people.

As far as I know, nobody has suggested having different people work
independently, whether on the same document or not. If this is a major
concern we could mitigate it by having the same people edit the different
documents.

Quite frankly I find this whole argument a bit silly. Does anybody keep all
their code in a single file just to keep it consistent? And there are plenty
of examples of specifications that depend on one another,  without having
been put all into the same document (thankfully).  RDF 1.1 and its 7+
related specs is one of those.
--
Arnaud  Le Hors - Senior Technical Staff Member, Open Web Technologies - IBM
Software Group


Irene Polikoff <irene@topquadrant.com> wrote on 03/19/2015 04:05:08 PM:

> From: Irene Polikoff <irene@topquadrant.com>
> To: <kcoyle@kcoyle.net>, <public-data-shapes-wg@w3.org>
> Date: 03/19/2015 04:06 PM
> Subject: Re: Pragmatic Proposal for the Structure of the SHACL Spec
> 
> Karen,
> 
> I agree that coordination is important. Having one document forces
> multiple editors to work together with some coordination, to come to
> consensus where they can, clearly identify other things as issues and work
> on producing a document that is coherent in its content even if it has a
> number of clearly marked open switches.
> 
> I am concerned that in the presence of different viewpoints, separating a
> document that should be coherent into multiple independent document
> sections written by different people would actually remove the need to do
> any coordination. As a result, we will end up with sections that don¹t
> work together.
> 
> Irene
> 
> On 3/19/15, 5:30 PM, "Karen Coyle" <kcoyle@kcoyle.net> wrote:
> 
> >
> >
> >On 3/19/15 1:46 PM, Holger Knublauch wrote:
> >
> >> The argument about implementation support is not strong enough. As
> >> stated TopQuadrant will provide an open source implementation of the
> >> full spec that is tracking the progress as soon as we decide to go to
> >> FPWD state. In the IRC log, Dimitris has also announced that he will
> >> work on another implementation. Finally, while I cannot speak for them,
> >> we have at least one SPARQL database vendor in our group (I am not sure
> >> what happened to Arthur Keen, I don't see him on the list anymore). This
> >> sounds like at least 3 implementations from within the group already,
> >> and we still have 1.5 years to go.
> >>
> >> Holger
> >
> >I don't think it matters greatly how many documents we end up with, but
> >it might be convenient to work independently on sections, which could
> >later be published as a single document. It would certainly be easier to
> >focus a review on smaller segments than on a whole document. I realize
> >that requires some coordination, but the same coordination is also
> >needed in a large document with more than one person working on it.
> >
> >kc
> >
> >>
> >>
> >>> --
> >>> 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
> >>> > >>
> >>> > >
> >>> >
> >>
> >
> >-- 
> >Karen Coyle
> >kcoyle@kcoyle.net http://kcoyle.net <http://kcoyle.net/>
> >m: 1-510-435-8234
> >skype: kcoylenet/+1-510-984-3600
> >
> 
> 
>