Re: Proposed change to the charter, section 4. Deliverables, Recommendation Track

On 8/3/2014 23:28, Dimitris Kontokostas wrote:
> Dear Holger,
>
> I am not experienced in W3C procedures and didn't phrase it correctly 
> so I'll try it again.
>
> I think what you suggested is rushing into something without all the 
> options on the table.
> (disclaimer: I would be in favor of a Shapes-like / SPIN-like / CWA 
> OWL option)

So which other options are on the table? I am trying to help create an 
actionable charter, and believe it would be best to have a list of 
candidates explicitly enumerated. I believe (OSLC) Shapes and ShEx are 
comparable. SPIN sits on a different meta-level but can be complementary 
to both. OWL is yet another topic and its closed world semantics should 
have been standardized in 2004.

> Since the announcement of ShEx, almost everybody rushed into rejecting 
> ShEx as it is not appropriate for validation and proposed their 
> existing options.
> For me Shapes contains many semantics that many people in this list 
> (including TopQuadrad) rejected already, yet I see now you proposing 
> Shapes as an option.

I am proposing Shapes with a syntax that can be represented in SPIN. 
This is slightly different from the proposed Shapes and ShEx in that I 
do believe that constraints should be attached to classes, not be 
stand-alone objects. Also, Shapes cover just a small fraction of 
real-world use cases, so when I say "Shapes" here I really mean any 
library of reusable SPIN templates for frequently needed constraint 
definitions.

>
> What I suggested was taking one step back and see all the options in 
> action.
> - Not everyone is expert in all technologies so a general overview is 
> needed before defining the requirements
> - The issue example that everyone uses is wear-off and not very helpful
> - This list is full of disperse example snippets
>
> Using PROV as a use case has many advantages
> - We can compare options in the exact same context
> - There are many real-world datasets that can be used as validation input
> - All efforts will be coordinated from now on and (hopefully) comments 
> will target actual use cases
> - As I said, PROV constraints have some moderate complexity
> - The work done here will also benefit the prov community
>
> An expert of each validation language could easily transform all 
> constraints very fast (less than a day) and we could use a website 
> (even purl.org/net/rdf-validation 
> <http://purl.org/net/rdf-validation>) where we post validation 
> snippets for each constraint.
> Thus, with a couple of days work max in total, all the discussions 
> will be more constructive.
>
> Please correct me if I am completely wrong or completely off-topic here.

It's a valid view point, and you can see that you are right because some 
people who represent less expressive standards already try to prevent 
this exercise so that we cannot call their bluff. As Paul stated on 
Twitter, this list becomes better entertainment than Game of Thrones.

Sigh.

Holger