Re: summarizing proposed changes to charter

Thanks Eric.

For those who might be looking for it, here is the link to the proposed 
charter:
http://www.w3.org/2014/data-shapes/charter

Just make sure your AC rep supports it when it comes up for review!

Thanks all for a difficult but fruitful discussion. I look forward to the 
WG getting started and meeting you at TPAC.
--
Arnaud  Le Hors - Senior Technical Staff Member, Open Web Standards - IBM 
Software Group


"Eric Prud'hommeaux" <eric@w3.org> wrote on 08/15/2014 11:08:36 AM:

> From: "Eric Prud'hommeaux" <eric@w3.org>
> To: public-rdf-shapes@w3.org
> Cc: Arnaud Le Hors/Cupertino/IBM@IBMUS
> Date: 08/15/2014 11:08 AM
> Subject: Re: summarizing proposed changes to charter
> 
> * Eric Prud'hommeaux <eric@w3.org> [2014-08-12 20:55-0400]
> > Hi all, we can have a face-to-face at the W3C Technical Plenary in
> > November if we can quickly endorse a good-enough charter.  As it
> > stands now, it isn't clear that the group will be able to reach
> > consensus within the Working Group, let alone get through the member
> > review without objection.
> 
> Many thanks to everyone! I think this will get us to AC review in time
> for a F2F at the Technical Plenary.
> 
> 
> > Please review the proposals that I've culled from the list.  I
> > encournage compromise on all our parts and we'll have to suppress the
> > desire to wordsmith. (Given the 3-month evaluation period,
> > wordsmithing won't change much anyways.)
> 
> For posterity's sake, below is an accounting of how these were
> implemented in the charter:
> 
> 
> > 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.
> 
> +        <li><p><b>Semantics</b>, possibly defined as SPARQL 
> operations, specifying how shapes are evaluated against RDF 
graphs.</p></li>
> 
> 
> > 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.
> >   ]]
> 
> -      <p>The WG <strong>MAY</strong> produce a Recommendation for 
> <strong>graph normalization</strong>.</p>
> 
> 
> > 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.
> 
> ~        <li><p><strong>OPTIONAL</strong> - <b>Compact, human-
> readable, non-RDF syntax</b> for expressing constraints on RDF graph
> patterns (aka shapes), suitable for the use cases determined by the 
> group.</p></li>
> -   This syntax might be a variation of an existing standard, such 
> as templates for SPARQL, or something new, such as ShExC.
> 
> 
> > 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 
thisproposal.
> 
> no change
> 
> 
> > 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.
> 
> no change
> 
> 
> I also added ", with some extensibility mechanism for complex use 
> cases." to the first deliverable. I presume this is non-controversial.
> 
> 
> > -- 
> > -ericP
> > 
> > office: +1.617.599.3509
> > mobile: +33.6.80.80.35.59
> > 
> > (eric@w3.org)
> > Feel free to forward this message to any list for any purpose other 
than
> > email address distribution.
> > 
> > There are subtle nuances encoded in font variation and clever layout
> > which can only be seen by printing this message on high-clay paper.
> 
> -- 
> -ericP
> 
> office: +1.617.599.3509
> mobile: +33.6.80.80.35.59
> 
> (eric@w3.org)
> Feel free to forward this message to any list for any purpose other than
> email address distribution.
> 
> There are subtle nuances encoded in font variation and clever layout
> which can only be seen by printing this message on high-clay paper.
>