Re: prospective charter for a shapes validation WG

Data producers need to check that the data they publish is valid with regards to their standards (for example their documentation). 

But I agree on the fact that data consumers "see" the data differently from the data producers. and considering the shape definition as a contract between both poorly represent the fact that concerns are different on both sides.

Envoyé de mon iPhone

Le 10 juil. 2014 à 15:07, Sandro Hawke <sandro@w3.org> a écrit :

> On 07/10/2014 08:32 AM, Peter F. Patel-Schneider wrote:
>> I find part of Sandro's motivation rather dangerous.  I do not think that providers of RDF should be in the business of tailoring the shape of their output for eventual consumption.  It is the business of consumers to decide whether the RDF that they encounter is suitable for their purposes.
> 
> Very interesting.  That sounds like a business ignoring what customers want or a speaker never thinking about what the audience might want to hear.   Can you explain this a bit more?
> 
>> That said, there are reasons to have a mechanism for checking and possibly modifying RDF graphs.  This mechanism could be helpful in determining whether a particular RDF graph carries sufficient information to be useful for a particular consumer.
> 
> +1
> 
>       -- Sandro
> 
>> peter
>> 
>> 
>> 
>> From: Sandro Hawke <sandro@w3.org>
>> Date: Fri, 27 Jun 2014 17:46:14 -0400
>> Message-ID: <53ADE626.9010708@w3.org>
>> To: Eric Prud'hommeaux <eric@w3.org>, public-rdf-shapes@w3.org
>> CC: Arnaud Le Hors <lehors@us.ibm.com>
>> 
>> On 06/27/2014 03:50 PM, Eric Prud'hommeaux wrote:
>> > The Shape Expressions 1.0 Submission has just been acknowledged by
>> > W3C, which gives us the opportunity to use the syntax and semantics
>> > from it, as well as the RDF graph defined by Resource Shapes, as the
>> > basis for a charter for an RDF Data Shapes Working Group. Please note
>> > that this is just a draft charter and does not indicate that the W3C
>> > membership endorses this work. The name "RDF Data Shapes" comes from
>> > comments on the Resource Shapes and Shape Expressions that the title
>> > implied and RDF description of "shapes" vs. the topology of RDF graphs.
>> >
>> > As a community, we can help develop this charter to have a clear scope
>> > and deliverables, as well as look for support from developers and
>> > users to help the W3C Membership guage the importance of such work. I'm
>> > also hoping that Sandro Hawk will provide a more extensive use case for
>> > motivation for this work for consideration in the charter (or in a
>> > Use Cases and Requirements document).
>> 
>> What Eric's referring to here is my reaction to the charter.   I thought
>> it was still pretty abstract for anyone not already steeped in RDF data
>> validation.    My sense is it would be helpful to include a motivating
>> story.    So I wrote one.   Eric's not convinced it's useful, so we're
>> asking for more broad feedback. Specifically, do you (a) agree with the
>> text below, and (b) think it would help some people by being in the
>> charter.
>> 
>> I'm not personally invested in the text or whether it's in the charter,
>> but I do happen to think this use case is completely critical.  At this
>> point, people seem to be converging on JSON Schema as Best Practice for
>> Integration.   Understandable, but I'd like to give them Shapes as a
>> more extensible, linkable, semantically-precise alternative.
>> 
>> This text would go into the charter between "1. Introduction" and "2.
>> Scope":
>> 
>> 
>>    <h2>Motivation<h2>
>> 
>>    One motivation for this work is Application Integration, where
>>    different software components, potentially maintained by different
>>    organizations, need to function together smoothly.  As a everyday
>>    example, imagine an international company with a dozen divisions,
>>    each providing a feed of their Human Resources data to authorized
>>    users.  Different divisions might use different software to produce
>>    their feeds, and there might be many distinct applications which
>>    consume the data, ranging from an employee phone book to a
>>    hiring-compliance monitoring system.
>> 
>>    While systems like this are built and maintained around the world
>>    today, their complexity often becomes a problem.  Not only are the
>>    systems expensive and sometimes unpleasant to maintain, but changing
>>    data fields and adding new applications can grow to be practically
>>    impossible.    RDF Data Shapes may be able to help manage the
>>    complexity, greatly reducing the cost and hassle, by separating
>>    components while still allowing them to work together.
>> 
>>    Specifically, in this example, an RDF Data Shapes Language would allow:
>> 
>>       * Developers of each data-consuming application could define the
>>    Shapes their software needs to find in each feed, in order to work
>>    properly, with optional elements it can use to work better
>>       * When these developers want to modify their software, they can
>>    define new Shapes they require
>>       * Management can offer guidance in the relative priorities of
>>    outputing particular Shapes, based on the application(s) that use
>>    them. There might be target goals and deadlines.
>>       * Developers of data-providing systems can read the Shape
>>    definitions (and possibly related RDF Vocabulary definitions) to
>>    learn what they need to provide
>>       * Data providers can also validate their data against the
>>    definitions, to see if they are producing the right information. (Of
>>    course, this doesn't ensure the data is correct, just that it's the
>>    right <i>shape</i>.)
>>       * Data consumers can validate incoming data against the expected
>>    shapes, to make sure they are getting the kind of data they were
>>    expecting.  This can be done manually from time to time, or
>>    automatically on all data.   This kind of validation is particularly
>>    important if producers and consumers keep updating their software to
>>    use new Shapes to meet changing requirements.
>>       * Intermediate systems can, in some cases, be written to convert
>>    data written to match one shape into data which matches a different
>>    shape.
>> 
>>    In all cases, the <i>semantics</i> of the data are determined by RDF
>>    and the vocabularies specified by the Shape, so if the Shapes match,
>>    the systems can reasonably be expected to interoperate correctly.
>> 
>>    While RDF Data Shapes are expected to be have immediate everyday
>>    utility, as illustrated above, they have even wider potential
>>    applicability, ranging in scale.  At the large end, RDF Data Shapes
>>    might be used by loosely-knit communities, where data is provided by
>>    organizations which are not under any central authority, such as
>>    charities and researchers around the world concerned with
>>    quality-of-life measures.  At the small end, RDF Data Shapes might
>>    be used within a mobile application environment to provide
>>    interoperability among independent sensor modules and tools for
>>    analyzing and acting on sensor results.  The common thread is that
>>    RDF Data Shapes allow a loose coupling, where independently
>>    maintained elements of an overall system can reliably and
>>    comfortably interoperate.
>> 
>> 
>> So, feedback welcome, on this and the charter in general.
>> 
>>        -- Sandro
> 
>

Received on Thursday, 10 July 2014 13:40:25 UTC