Re: speeding up the working group

I believe that one of the things slowing us down is that there was a 
"knowledge gap" between the creation of the requirements and the writing 
of the spec/coding of SHACL. As a group, we did not move from the 
requirements to the definition of SHACL. (which is why I am interested 
in doing a reality check between SHACL and the requirements)

Many decisions were made that were not discussed with the group. A small 
but obvious example is the one that I brought up about mincount and 
maxcount. The requirement states:

4.2.1 R5.2: Property Min/Max Cardinality

The stated values for a property may be limited by minimum/maximum 
cardinality, with typical patterns being [0..1], [1..1], [0..*] and [1..*].

However, the group was never involved in the discussion about 
implementation of this feature and the difference between the SHACL 
implementation decision and what was stated in the requirement was not 
brought before the group. Had this been discussed when it came up during 
the creation of the spec, we quite possibly could have dispensed with it 
with an email discussion. As it is, the reality of the implementation 
(that maximum cardinality "*" is not included in SHACL) came up almost 
by accident, and looking at it this late in the game is much more 
disruptive than it would have been had it been noted at the time.

The problem is that we are doing the awkward task of reverse-engineering 
the spec to understand if it meets the requirements, rather than working 
from the requirements to the spec.

kc

On 10/8/15 6:43 PM, Holger Knublauch wrote:
> On 10/2/2015 23:10, Peter F. Patel-Schneider wrote:
>> In my view the best way to speed up the working group would be to have
>> more
>> work on implementations of SHACL.  For the working group to finish
>> successfully, there should be multiple interoperating implementations of
>> SHACL.  Having these implementations underway now will not only make
>> the later
>> phases of the W3C process go faster, but will also provide valuable
>> information to the working group on various aspects of SHACL.  If these
>> implementations are done by major vendors of RDF tools, then that is
>> even better.
>>
>> So, if anyone wants the working group to come up with a W3C
>> recommendation
>> more quickly, I think that they should be reaching out to RDF tool
>> vendors to
>> convince them to put more resources into the working group and
>> particularly
>> into implementing SHACL.
>
> I fully agree and look forward to exchanging implementation experience
> with other groups.
>
> I would like to use this opportunity to also explain why I am sometimes
> "impatient" and frustrated with the speed of the WG. I believe it is
> beneficial for the WG to have an active implementer (TQ) who is
> motivated to closely track the evolution of the standard. I am thus able
> to provide additional input that we would otherwise not have, and I can
> confirm or criticize assumptions and the design.
>
> Tracking the specification however also means that it is sometimes
> complex to keep multiple "branches" of the spec, the software and the
> Turtle file alive and synchronized. There is quite a bit of extra cost
> involved in not being able to progress on the changes proposed in
> ISSUE-95 and ISSUE-98. Especially the latter seems to be
> uncontroversial, and several people have spoken out in support of it,
> yet it is hanging around unresolved for over three weeks now and we
> didn't even have a straw poll on it.
>
> There is a need to balance the formal processes (issue tracker etc) with
> the practical reality of building things and getting work done.
>
> Holger
>
>
>

-- 
Karen Coyle
kcoyle@kcoyle.net http://kcoyle.net
m: 1-510-435-8234
skype: kcoylenet/+1-510-984-3600

Received on Tuesday, 20 October 2015 17:44:44 UTC