Re: summarizing proposed changes to charter

Ok then, I take your word on this issue ;)

While I still don't understand why the (abstract) syntax and semantics 
document is helpful or required, I believe there is sufficient consensus 
now that we should move on quickly, so +1 to the proposed changes.

It would be good to see the latest version online soon.

Thanks
Holger


On 8/14/2014 5:56, Arnaud Le Hors wrote:
> Hi Holger,
>
> The fact that extensibility is explicitly listed as a design goal in 
> the scope section [scope] should be enough to assure you that this is 
> something the WG is expected to deliver on. If the WG didn't, it would 
> fail to deliver on the goals set by its charter.
>
> [scope] http://www.w3.org/2014/data-shapes/charter#scope
>
> Furthermore, the workshop clearly showed strong support for some 
> extensibility mechanism so I don't see why you'd think there is a risk 
> the WG will then decide to ignore that.
>
> I've asked Eric to see if he could add a mention of extensibility to 
> the deliverables to address your concern but quite frankly you could 
> say the same should be done about every other goals listed in the 
> scope section. Yet, it's simply not practical. As I said before, there 
> is only so much we can say in the list of deliverables. That list 
> doesn't stand on its own, it is to be taken along with everything else 
> in the charter.
>
> Regards.
> --
> Arnaud  Le Hors - Senior Technical Staff Member, Open Web Standards - 
> IBM Software Group
>
>
> Holger Knublauch <holger@topquadrant.com> wrote on 08/12/2014 08:26:12 PM:
>
> > From: Holger Knublauch <holger@topquadrant.com>
> > To: public-rdf-shapes@w3.org
> > Date: 08/12/2014 08:28 PM
> > Subject: Re: summarizing proposed changes to charter
> >
> > Hi Arnaud,
> >
> > sorry but there is one fundamental issue here. Chapter 3 clearly
> > states that Extensibility is a design goal, but none of the
> > deliverables mentions this. On the recommendation track there is
> > only a vocabulary for "these shapes" and those Shapes are basically
> > the other items from the Scope section, aka the "hard-coded"
> > Resource Shapes such as ranges and cardinalities. Then there is a
> > Not Recommendation Track item for "Relationship to SPARQL" which is
> > not talking about extensibility either.
> >
> > So where is extensibility covered? If it is not covered, how sure
> > can we be that the WG will implement the Scope? What happens if
> > people who happen to sit in the WG decide that extensibility is just
> > a nice-to-have (even though it has been clearly identified as a
> > requirement in the discussions so far)?
> >
> > Thanks,
> > Holger
> >
> >
> >
> >
> > On 8/13/2014 13:10, Arnaud Le Hors wrote:
> > Hi Holger,
> >
> > It may seem unfair indeed that your proposal wasn't directly
> > addressed in Eric's email. However, I hope you will recognize that
> > there is a clear overlap between the different proposals and there
> > is only so much we can do to accommodate the different suggestions.
> >
> > Under pressure from about everybody the charter has been
> > significantly watered down and made completely technology neutral.
> > As a result the WG has now a lot of room to decide exactly what spec
> > to produce and based on what technology.
> >
> > As noted before this is both a gift and a curse because it means we
> > will have a lot of work to do to define a clear direction but, at
> > this point, as others have pointed out, I think the most productive
> > thing to do is to launch the WG.
> >
> > I do think your interpretation of what charters imply is a bit on
> > the conservative side. My experience is that when WGs agree they
> > have a lot of leeway with regard to their charter. So, I wouldn't
> > fret too much about the details of the charter.
> >
> > Regards.
> > --
> > Arnaud  Le Hors - Senior Technical Staff Member, Open Web Standards
> > - IBM Software Group
> >
> >
> >
> >
> > From:        Holger Knublauch <holger@topquadrant.com>
> > To:        public-rdf-shapes@w3.org
> > Date:        08/12/2014 06:33 PM
> > Subject:        Re: summarizing proposed changes to charter
> >
> >
> >
> > Hi Eric,
> >
> > this is a good initiative. I do wonder though why my own proposal which
> > is best summarized at
> >
> > http://lists.w3.org/Archives/Public/public-rdf-shapes/2014Aug/0088.html
> >
> > is not being discussed? If you are suggesting to follow the 
> splitting of
> > the deliverable suggested by Peter, then why not also discuss the
> > splitting that I proposed?
> >
> > Alternatively, let's assume that the WG will redefine the deliverables
> > anyway once it has agreed on which base technology to start with. In
> > that case, we only need a single vague deliverable outline for now. But
> > even then the current prose
> >
> > "An RDF vocabulary, such as Resource Shapes 2.0, for expressing these
> > shapes in RDF triples, so they can be stored, queried, analyzed, and
> > manipulated with normal RDF tools."
> >
> > does not work because it only highlights Resource Shapes 2.0 and also
> > does not say anything about the extension mechanism and fallback to
> > something like SPARQL that was identified in section 3. These are not
> > "shapes" but meta-shapes and my suggestion was to clarify this into two
> > deliverables. Only defining hard-coded Shapes is not an acceptable
> > outcome of this WG. It would work for me if the above sentence is
> > extended to explicitly mention this extension mechanism, so my
> > compromise proposal is:
> >
> >     An RDF vocabulary for expressing structural constraints (aka
> > Shapes) together with
> >     a definition of their formal semantics that explains how shapes are
> > evaluated against
> >     RDF graphs. Also an extension mechanism that enables the definition
> > of new Shapes
> >     and to fall back to a richer language to express more complex
> > constraints.
> >
> > The part "for expressing these shapes in RDF triples etc" from the
> > original proposal can be deleted because it is a consequence of being
> > based on RDF.
> >
> > I also want to note that the deliverable "Relationship to SPARQL" 
> should
> > have a similar sentence like the OWL deliverable underneath it, to make
> > it unnecessary if SPARQL is already used for the first deliverable.
> >
> > On 8/13/2014 10:55, Eric Prud'hommeaux wrote:
> > > separate semantics:
> > >
> > >    "Peter F. Patel-Schneider" <pfpschneider@gmail.com> - Message-ID:
> > <53E2AFBD.9050102@gmail.com>
> > >      A syntax and semantics for shapes specifying how to construct
> > shape expressions and how shape expressions are evaluated against 
> RDF graphs.
> > >    "Dam, Jesse van" <jesse.vandam@wur.nl> - Message-ID:
> > <63CF398D7F09744BA51193F17F5252AB1FD60B24@SCOMP0936.wurnet.nl>
> > >      defining the the (direct) semantics meaning of shapes and
> > defining the associated validation process.
> > >
> > >    opposition: Holger Knublauch
> > >
> > >    proposed resolution: include, noting that if SPARQL is judged
> > to be useful for the semantics, there's nothing preventing us from 
> using it.
> >
> > I am not happy with that, and I believe my proposal above covers it 
> more
> > pragmatically. I am very much against making this more complicating 
> than
> > it needs to be by introducing extra layers of "formal" specifications.
> > Just use SPARQL and it becomes both formally specified and immediately
> > executable.
> >
> > The other topics below are fine for me.
> >
> > Holger
> >
> >
> > >
> > >
> > > make graph normalization optional or use-case specific:
> > >
> > >    "Peter F. Patel-Schneider" <pfpschneider@gmail.com> - Message-ID:
> > <53E2AFBD.9050102@gmail.com>
> > >      3 OPTIONAL A specification of how shape verification
> > interacts with inference.
> > >    Jeremy J Carroll <jjc@syapse.com> - Message-Id:
> > <D954B744-05CD-4E5C-8FC2-C08A9A99BA9F@syapse.com>
> > >      the WG will consider whether it is necessary, practical or
> > desireable to normalize a graph...
> > >      A graph normalization method, suitable for  the use cases
> > determined by the group....
> > >    David Booth <david@dbooth.org> - Message-ID: <53E28D07.
> > 9000804@dbooth.org>
> > >      OPTIONAL - A Recommendation for normalization/
> > canonicalization of RDF graphs and RDF datasets that are serialized
> > in N-Triples and N-Quads. opposition - don't do it at all:
> > >    "Peter F. Patel-Schneider" <pfpschneider@gmail.com> - Message-ID:
> > <53E3A4CB.4040200@gmail.com>
> > >      the WG should not be working on this.
> > >
> > >    proposed resolution: withdrawn, to go to new light-weight,
> > focused WG, removing this text:
> > >    [[
> > >    The WG MAY produce a Recommendation for graph normalization.
> > >    ]]
> > >
> > >
> > > mandatory human-facing language:
> > >
> > >    "Dam, Jesse van" <jesse.vandam@wur.nl> - Message-ID:
> > <63CF398D7F09744BA51193F17F5252AB1FD60B24@SCOMP0936.wurnet.nl>
> > >      ShExC mandatory, but potentially as a Note.
> > >    David Booth <david@dbooth.org> - Message-ID: <53E28D07.
> > 9000804@dbooth.org>
> > >      In Section 4 (Deliverables), change "OPTIONAL - Compact,
> > human-readable syntax" to "Compact, human-readable syntax", i.e.,
> > make it required.
> > >    Jeremy J Carroll <jjc@syapse.com> - Message-Id: <54AA894F-
> > F4B4-4877-8806-EB85FB5A42E5@syapse.com>
> > >
> > >    opposition - make it OPTIONAL
> > >    "Peter F. Patel-Schneider" <pfpschneider@gmail.com> - Message-ID:
> > <53E2AFBD.9050102@gmail.com>
> > >      OPTIONAL A compact, human-readable syntax for expressing shapes.
> > >
> > >    proposed resolution: keep as OPTIONAL, not mentioning ShExC,
> > but clarifying that it's different from the RDF syntax.
> > >
> > >
> > > report formats:
> > >    Dimitris Kontokostas <kontokostas@informatik.uni-leipzig.de>
> > >      provide flexible validation execution plans that range from:
> > >        Success / fail
> > >        Success / fail per constraint
> > >        Fails with error counts
> > >        Individual resources that fail per constraint
> > >        And enriched failed resources with annotations
> > >
> > >    proposed resolution: no change, noting that no one seconded
> > this proposal.
> > >
> > >
> > > test suite/validator:
> > >
> > >    Dimitris Kontokostas <kontokostas@informatik.uni-leipzig.de>
> > >      Validation results are very important for the progress of
> > this WG and should be a standalone deliverable.
> > >    David Booth <david@dbooth.org> - Message-ID: <53E28D07.
> > 9000804@dbooth.org>
> > >      Test Suite, to help ensure interoperability and correct
> > implementation. The group will chose the location of this
> > deliverable, such as a git repository.
> > >
> > >    proposed resolution: leave from charter as WGs usually choose
> > to do this anyways and it has no impact on IP commitments.
> > >
> >
> >