W3C home > Mailing lists > Public > public-rdf-shapes@w3.org > August 2014

Suggested charter changes

From: David Booth <david@dbooth.org>
Date: Wed, 06 Aug 2014 16:16:07 -0400
Message-ID: <53E28D07.9000804@dbooth.org>
To: public-rdf-shapes@w3.org
On 08/06/2014 02:52 PM, Arnaud Le Hors wrote:
> The only pratical way forward I see
> is for everyone to focus on the exact wording of the charter and to
> propose specific changes. . . .

Regarding the draft charter:
http://www.w3.org/2014/data-shapes/charter

SUGGESTED SUBSTANTIVE CHANGES:

1. In Section 4 (Deliverables), change:
[[
   5. Test Suite and/or Validator: to help ensure interoperability
   and correct implementation. The group will chose the form of
   this deliverable, such as a git repository.
]]
to:
[[
   5. Test Suite, to help ensure interoperability and correct
   implementation. The group will chose the location of this
   deliverable, such as a git repository.

    6. (OPTIONAL) Reference Validator: a reference implementation
   that may be used for non-production purposes to test validation
   rules against test data.
]]

REASON: A test suite is essential; a reference validator would be nice 
but is not essential.  Also, the previous word was completely unclear 
able what was meant by "Validator".

2. Change "The WG MAY produce a Recommendation for graph normalization." 
to something like: "OPTIONAL - A Recommendation for 
normalization/canonicalization of RDF graphs and RDF datasets that are 
serialized in N-Triples and N-Quads."

REASON: Canonicalization needs to be relative to a serialization in 
order to be most useful.  Otherwise "canonicalized" RDF may be 
serialized in multiple ways, and still could not be usefully compared 
for regression testing or other purposes.

3. In Section 4 (Deliverables), change "OPTIONAL - Compact, 
human-readable syntax" to "Compact, human-readable syntax", i.e., make 
it required.

REASON: I think a compact, readable syntax is important.  Writing 
validation rules in RDF would be simpler than writing them in SPARQL, 
but still much more tedious than having a concise, compact syntax for 
expressing them.


SUGGESTED EDITORIAL CHANGES:

4. s/The group will chose/The group will choose/

5. For consistency, in Section 4, changed "The WG MAY produce a 
Recommendation for graph normalization." to "OPTIONAL - A Recommendation 
for graph normalization." and make it a third numbered item under 
"Recommendation Track:".

6. s/Not Recommendation Track/Other Deliverables/
(So that they don't sound like they are "not recommended".)

7. Number the deliverables sequentially, without restarting the count, 
so that there is only one deliverable #1, etc. -- not two.

8. Delete "These Use Cases and Requirements are to be documented in a 
Working Group Note within 3-6 months after the start of the group.", 
because this is already covered by the combination of the Deliverables 
section and the Schedule section.

Thanks,
David
Received on Wednesday, 6 August 2014 20:16:36 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:02:40 UTC