Are we running out of time? (was: shapes-ISSUE-113 (SHACL and user interfaces): [SHACL Spec])

Hi Arnaud,

I find your last sentence very alarming. It sounds like you are willing 
to delete already approved requirements and even rewrite the original 
charter because we may run out of time. Your previous suggestion was a 
"compromise might be to define a small set of such features packaged 
together as an optional feature, if there is such a set we could agree 
on". If the recent evidence is anything to go by, then we will not be 
able agree on these features. Likewise, almost every proposal on the 
wiki page has a -1 from someone.

So what is next: "Sorry, we ran out of time and someone voted -1, so 
let's delete templates, functions and other random stuff". I am very 
worried that the outcome of this WG will be a useless language.

Could we please create task forces to push key issues forward and then 
present worked out proposals. One such task force could work on the UI 
stuff. Another task force could look into the Turtle file and template 
metamodel. Another topic could be the proper definition of recursion. 
Some of these topics require more bandwidth than group emails and weekly 
meetings provide.

If we are starting to run out of time, then I think we need to change 
the process. I would also like to hear how you imagine the remaining 
time line of the WG, i.e. when are which deliverables planned?

Thanks
Holger


On 11/13/15 1:39 PM, Arnaud Le Hors wrote:
> Holger,
> Sorry, but I disagree with your interpretation of the situation.
>
> First, saying that there is no cost to adding annotations is simply 
> false. It takes time to agree to every single one of them. Someone has 
> to propose it, others have to read and understand what they mean. We 
> discuss them, argue, etc.
>
> Then unless they are optional, it adds to the implementation burden. 
> It will take time to develop tests for them (and we already said we 
> aren't even sure how we would do that), time to gather implementation 
> reports, etc.
>
> This is hardly free.
>
> While I certainly agree with you that it is part of our charter, this 
> clearly hasn't been much of our focus to date and, given the amount of 
> time it is taking to address the validation use case which nobody is 
> interested in, I think it is reasonable for us to postpone if not give 
> up entirely on the UI stuff. I'm happy to explain that to W3M if need be.
> --
> Arnaud  Le Hors - Senior Technical Staff Member, Open Web Technologies 
> - IBM Software Group
>
>
> Holger Knublauch <holger@topquadrant.com> wrote on 11/12/2015 06:23:20 PM:
>
> > From: Holger Knublauch <holger@topquadrant.com>
> > To: public-data-shapes-wg@w3.org
> > Date: 11/12/2015 06:24 PM
> > Subject: Re: shapes-ISSUE-113 (SHACL and user interfaces): [SHACL Spec]
> >
> > On 11/13/2015 7:23, RDF Data Shapes Working Group Issue Tracker wrote:
> > > shapes-ISSUE-113 (SHACL and user interfaces):  [SHACL Spec]
> > >
> > > http://www.w3.org/2014/data-shapes/track/issues/113
> > >
> > > Raised by: Peter Patel-Schneider
> > > On product: SHACL Spec
> > >
> > > The WG charter includes the goal of "Human and machine
> > interpretation of shapes to [...] develop user interfaces."
> > >
> > > SHACL includes shapes and constraints.  Most constraints are
> > expected to be property or inverse property constraints.
> > >
> > > These SHACL features provide a backbone for the development of
> > user interfaces related to shapes.   UI tools can, for example, use
> > property and inverse property constraints to determine which
> > properties should be part of an input form to create data that
> > conforms to a shape.  Because shapes and contstraints are nodes in
> > RDF graphs they can have extra information associated with them that
> > can be exploited by user interface tools.
> > >
> > >
> > > PROPOSAL:  As the RDF Data Shapes working group does not have
> > sufficient expertise to create a good set of features for UI
> > creation it should stop at providing this backbone and let those who
> > build user interfaces design the information needed for connecting
> > SHACL shapes and constraints to UI tools.   To conform with this
> > sentiment, sh:defaultValue will be removed from the SHACL vocabulary.
> >
> > The assumption "As the RDF Data Shapes WG does not have sufficient
> > expertise..." is incorrect. Furthermore, default values are an approved
> > requirement. I'll vote -1 for this proposal and propose to close this
> > ticket without action.
> >
> > Peter, you have made it clear many times that you don't think the
> > Charter should have included UI features. But that decision was made
> > long ago, so I encourage you to accept other people's view points. I
> > have also seen features that I personally don't like and would 
> prefer to
> > not have to work on. However, if there is little or no cost involved,
> > then this didn't cause me to block others from getting those features.
> > In other words: If you don't need the UI features, just ignore them.
> > Being destructive about them is only poisoning the working climate in
> > the WG.
> >
> > Holger
> >
> >
>