Re: AW: SHACL Rules?

On 18/12/2015 6:40 PM, Arnaud Le Hors wrote:
> People are free to collaborate on whatever they want obviously but to 
> publish anything as coming from the WG, even as a WG Note, requires 
> agreement from the WG. This would therefore require people to review 
> the document and approve publication which would have some cost, 
> although clearly less for a Note than if it were part of a spec on the 
> REC track.
>
> I have to admit not to be keen on adding anything to our plate at this 
> point and while some people are interested I didn't get the feeling 
> that this was true for everybody.

This nails down a major problem that I see in the W3C process. 
*Everybody* must agree. A single person can derail basically everything, 
as long as he or she doesn't upset the chair. As it happens, I am 
feeling very negative about any Abstract Syntax. Others will find 
reasons to vote against adding rules. Does this mean that we shouldn't 
explore and eventually publish any of these deliverables, as long as 
they are optional? Some people may see a lot of value in an Abstract 
Syntax (e.g. for conceptual clarity). Others may have experienced 
practical use cases for rules and wouldn't want to miss this unique 
opportunity. Who can tell that one is more right than the other, from 
their own little shells? No individual is smart enough to make these 
decisions, yet the process assumes and even promotes this.

I am sure this topic has been discussed countless times. I am sure some 
people will compare the W3C process with open source projects, that 
sometimes also produce useful (de-facto) standards. Their difference is 
that the latter put more emphasis on evolution and external feedback, 
rather than giving all power to individuals.

Holger


> If you think the situation is different we could ask again. An 
> alternative is for you to create a Community Group. CGs are very light 
> weight structures that would give you a space to work on this. See 
> https://www.w3.org/community/groups/
>
> I'd be happy to give you more info on CGs if you'd like.
> --
> Arnaud  Le Hors - Senior Technical Staff Member, Open Web Technologies 
> - IBM Software Group
>
>
> Simon Steyskal <simon.steyskal@wu.ac.at> wrote on 12/18/2015 05:35:46 AM:
>
> > From: Simon Steyskal <simon.steyskal@wu.ac.at>
> > To: Holger Knublauch <holger@topquadrant.com>, 
> public-data-shapes-wg@w3.org
> > Date: 12/18/2015 05:35 AM
> > Subject: AW: SHACL Rules?
> >
> > +1
> >
> > I would love to work on this.
> >
> > simon
> >
> >
> > -------- Ursprüngliche Nachricht --------
> > Von: Holger Knublauch <holger@topquadrant.com>
> > Datum: 18.12.2015 14:31 (GMT+01:00)
> > An: public-data-shapes-wg@w3.org
> > Betreff: SHACL Rules?
> >
> > I have a process question. During the meeting it turned out that at
> > least three WG members were interested in a SHACL extension to 
> represent
> > rules. I believe this is a low hanging fruit, similar to SPIN rules. 
> For
> > example
> >
> > ex:MyShape
> >      a sh:Shape ;
> >      sh:scopeClass ex:Person ;
> >      shr:rule [
> >          sh:sparql """
> >              CONSTRUCT {
> >                  ?this ex:age ?age .
> >              }
> >              WHERE {
> >                  ?this ex:birthYear ?birthYear .
> >                  BIND (ex:currentYear() - ?birthYear AS ?age)
> >              } """
> >      ] .
> >
> > SHACL already provides all key building blocks, even the concept of
> > SPARQL binding and scoping.
> >
> > I understand the concern that this is potentially outside of the
> > charter, and that we don't want to spend precious WG resources on this.
> > However, assuming that the interested parties create a separate
> > deliverable on this "in their spare time", is there any format in which
> > we could publish this (as a note) within the umbrella of the Shapes WG?
> > The WG is also discussing Abstract Syntax and Compact Syntax documents
> > that appear complementary and optional for implementers.
> >
> > (To keep it simple we could in the first pass exclude any inter-rule
> > dependencies, i.e. not even do fixpoint iteration. We use this a lot 
> for
> > data transformations/mapping, where a single pass is sufficient.)
> >
> > Thanks,
> > Holger
> >
>