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

Re: summarizing proposed changes to charter

From: David Booth <david@dbooth.org>
Date: Wed, 13 Aug 2014 00:17:29 -0400
Message-ID: <53EAE6D9.2030309@dbooth.org>
To: "Peter F. Patel-Schneider" <pfpschneider@gmail.com>, Eric Prud'hommeaux <eric@w3.org>, public-rdf-shapes@w3.org
CC: Arnaud Le Hors <lehors@us.ibm.com>
I think "canonicalization" would be a clearer term, as in:

   "OPTIONAL - A Recommendation for canonical serialization
    of RDF graphs and RDF datasets."

The purpose of this (to me) is to be able to validate that I got the 
*exact* RDF data that I expected -- not merely the right classes and 
predicates and such.  Would you be okay with including this in the charter?

Thanks,
David

On 08/12/2014 10:00 PM, Peter F. Patel-Schneider wrote:
> I'm still not exactly sure just what normalization means in this context
> or what relationship it has to RDF validation.
>
> peter
>
>
> On 08/12/2014 06:55 PM, David Booth wrote:
>> +1 for all except one item.
>>
>> I'd like to make one last ditch attempt to include graph normalization
>> as an
>> OPTIONAL deliverable.  I expect the WG to treat it as low priority,
>> and would
>> only anticipate a normalization document being produced if someone
>> takes the
>> personal initiative to draft it.  I do not see any significant harm in
>> including it in the charter on that basis, but I do see a benefit,
>> because if
>> the WG did somehow get to it then it would damn nice to have, so that
>> we could
>> finally validate RDF data by having a standard way to compare two RDF
>> documents for equality, like we can routinely do with every other data
>> representation.
>>
>> Peter, would that be okay with you, to include graph normalization as
>> OPTIONAL
>> that way?
>>
>> Thanks,
>> David
>>
>> On 08/12/2014 08:55 PM, Eric Prud'hommeaux wrote:
>>> 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.
>>>
>>> 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.)
>>>
>>>
>>> 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.
>>>
>>>
>>> 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.
>>>
>>
>
>
>
>
Received on Wednesday, 13 August 2014 04:17:58 UTC

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