- From: David Booth <david@dbooth.org>
- Date: Wed, 13 Aug 2014 14:42:46 -0400
- 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