Re: prospective charter for a shapes validation WG

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:07:56 UTC