W3C home > Mailing lists > Public > public-rdf-shapes@w3.org > August 2014

Re: Moving forward

From: Holger Knublauch <holger@topquadrant.com>
Date: Thu, 07 Aug 2014 09:48:50 +1000
Message-ID: <53E2BEE2.8050508@topquadrant.com>
To: public-rdf-shapes@w3.org
Hi Arnaud,

thank you for stepping in so that the process can take the next hurdle.

I would like to propose changes to the deliverable section that try to 
address some issues raised by others. I believe the first deliverable 
needs to be split into two. Currently it reads

1) An RDF vocabulary, such as Resource Shapes 2.0, for expressing these 
shapes in RDF triples, so they can be stored, queried, analyzed, and 
manipulated with normal RDF tools.

This doesn't get the meta-levels right, because the Shapes need to be 
based on *something*. Furthermore it is unclear how the extensibility 
(fall-back to SPARQL) is reflected here. And mentioning Resource Shapes 
as the only named technology is clearly not "fair".

I suggest to change this to

1) An RDF vocabulary and semantics (i.e. instructions on how to evaluate 
the vocabulary) to represent constraints, and resulting constraint 
violations, for RDF graphs and ontologies. This vocabulary must include 
a mechanism to represent higher level vocabularies that can be stored, 
queried, analyzed and manipulated with normal RDF tools. Candidate 
starting points are OWL, ShEx and SPIN.

2) An RDF vocabulary implementing a library of high level constraints 
for the most common use cases (as identified by the requirements). 
Candidate starting points are OWL, Resource Shapes, ShEx and various 
SPIN template libraries.

The "Candidate starting point" sentences could be dropped.

The first deliverable is basically the meta-language for the shapes and 
defines the mechanisms in which Shapes are exchanged and evaluated. My 
OSLC Shapes implementation in SPIN shows one way of solving this 
stacking. We need to keep in mind that whatever specific Shapes are 
identified now will not be the final answer, so an extension mechanism 
is crucial. At the same time, the 2) deliverable can be used stand-alone 
by people who are not familiar with advanced topics such as SPARQL, so 
it should also be a separate deliverable. Deliverable 1) does not depend 
on 2), so it should be kept separate.

Holger



On 8/7/14, 2:31 AM, Arnaud Le Hors wrote:
> Hi all,
>
> As chair-to-be of the proposed WG I've been working with the W3C Team 
> on trying to find a way forward that would be acceptable by all.
>
> The normative change proposed to the charter [draft charter] which was 
> to start with use cases and requirements instead of assuming Resource 
> Shapes as a starting point was made weeks ago. The Team has actually 
> made the charter technology neutral with regard to all of the various 
> candidates out there and has now made the compact human-readable 
> syntax an optional deliverable and added a reference to Dublin Core 
> Application Profiles. I haven't seen any other proposal that seems to 
> have general support.
>
> [draft charter] http://www.w3.org/2014/data-shapes/charter
>
> So at this point, I think we're better off going with the proposed 
> charter, launch the WG, and direct our efforts towards writing up the 
> use cases, requirements, and exploring what the best solution might be 
> objectively.
>
> There is definitely a risk that the WG will struggle to find a 
> direction with such an open ended charter but at the same time I think 
> it will be more productive to have a discussion within the framework 
> of a WG than the way it's happening now on this mailing list.
>
> I can say that I've worked with Arthur Ryman so that IBM would support 
> this even though this isn't what he wanted (FYI Arthur and I are from 
> different groups within IBM). Standards are made of compromises, so I 
> hope you will all do the same.
>
> I look forward to working with you all.
> Thank you.
> --
> Arnaud  Le Hors - Senior Technical Staff Member, Open Web Standards - 
> IBM Software Group
Received on Wednesday, 6 August 2014 23:49:24 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:02:40 UTC