Re: summarizing proposed changes to charter

* Holger Knublauch <holger@topquadrant.com> [2014-08-13 11:31+1000]
> 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?

Yep, quite right; I failed to include them in my summary. Sorry I
missed them. Thanks for tailoring your proposal.


> 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.

I think you want the charter to prescribe some characteristics of the
extension mechanism. I appreciate the desire for direction, but
caution that this would in effect exclude other possible designs like
grammatical extensions (as occurred in SPARQL 1.1) or the MUST/MAY
UNDERSTAND (e.g. SOAP) model. I believe the current charter permits
your design without prescribing it. What do others think?


> 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.
> >
> 
> 

-- 
-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.

Received on Wednesday, 13 August 2014 12:08:55 UTC