Re: prospective charter for a shapes validation WG

I answer "Yes" to both questions:

a) I agree with the text and in fact I have been proposed to solve a
similar use case using RDF Data Shapes. In general RDF Data Shapes can help
to integrate data portals which produce data that is not necessarily the
same but can have the same shape, or compatible shapes.

b) I also think the use case could help some people to participate in the
charter. In my opinion, any step that can be done to explain and motivate
RDF Data Shapes is important.

I found one typo in the last paragraph: "are expected to <be> have... "



On Fri, Jun 27, 2014 at 11:46 PM, Sandro Hawke <sandro@w3.org> wrote:

>  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/
>
>
>


-- 
Saludos, Labra