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 14:42:46 -0400
Message-ID: <53EBB1A6.6080400@dbooth.org>
To: public-rdf-shapes@w3.org
I think so.  I just wanted to be up front that it may be a little 
different use case than most have been considering.  I think it's very 
important, but I also think it may fall outside of what most of the WG 
wants to focus on, which is why I suggested that it be an OPTIONAL 
deliverable that could be done if there turned out to be sufficient 
initiative in the WG.

David

On 08/13/2014 12:24 PM, Karen Coyle wrote:
> I can never remember where the draft charter is, but as I recall it does
> not specify boundaries for "RDF validation", nor does it list validation
> types. So wouldn't this just be another type of validation that the
> group could consider, without it being named in the charter?
>
> kc
>
> On 8/13/14, 8:45 AM, David Booth wrote:
>> Hi Peter,
>>
>> Here is my main use case for RDF canonicalization.
>>
>> The RDF Pipeline Framework http://rdfpipeline.org/ allows any kind of
>> data to be manipulated in a data production pipeline -- not just RDF.
>> The Framework has regression tests that, when run, are used to validate
>> the correctness of the output of each node in a pipeline.  A test passes
>> if the actual node output exactly matches the expected node output,
>> *after* filtering out ignorable differences.  (For example, differences
>> in dates and times are typically treated as ignorable -- they don't
>> cause a test to fail.)  Since a generic comparison tool is used (because
>> the pipeline is permitted to carry *any* kind of data), data
>> serialization must be predictable and canonical.  This works great for
>> all kinds of data *except* RDF.
>>
>> If a canonical form of RDF were defined, then the exact same tools that
>> are used to compare other kinds of data for differences could also be
>> used for comparing RDF.
>>
>> I consider this a major deficiency in RDF that really needs to be
>> corrected.  Any significant software effort uses regression tests to
>> validate changes.  But comparing two documents is currently complicated
>> and difficult with RDF data.  RDF canonicalization would make it as easy
>> as it is for every other data representation.
>>
>> I realize that this is a slightly different -- and more stringent --
>> notion of RDF validation than just looking at the general shape of the
>> data, because it requires that the data not only has the expected shape,
>> but also contains the expected *values*.  Canonicalization would solve
>> this problem.
>>
>> Given this motivation, would you be okay with RDF canonicalization being
>> included as an OPTIONAL deliverable in the charter?
>>
>> Thanks,
>> David
>>
>> On 08/13/2014 01:11 AM, Peter F. Patel-Schneider wrote:
>>> I'm still not getting this at all.
>>>
>>> How does canonicalization help me determine that I got the RDF data that
>>> I expected (exact or otherwise)?  For example, how does canonicalization
>>> help me determine that I got some RDF data that tells me the phone
>>> numbers of my friends?
>>>
>>> I just can't come up with a use case at all related to RDF data
>>> validation where canonicalization is relevant, except for signing RDF
>>> graphs, and that can just as easily be done at the surface syntax level,
>>> and signing is quite tangential to the WG's purpose, I think.
>>>
>>> peter
>>>
>>>
>>> On 08/12/2014 09:17 PM, David Booth wrote:
>>>> 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 18:43:19 UTC

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