Re: prospective charter for a shapes validation WG

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

>
> prospective charter: http://www.w3.org/2014/rds/charter
> Resource Shapes: http://www.w3.org/Submission/shapes/
> ShEx primer: http://www.w3.org/Submission/shex-primer/
> ShEx definition: http://www.w3.org/Submission/shex-defn/
>