Re: prospective charter for a shapes validation WG

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.

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.

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 12:32:39 UTC