See also: IRC log
<scribe> scribenick: TallTed
<Arnaud> PROPOSED: Approve minutes of the 17 March 2016 Telecon: http://www.w3.org/2016/03/17-shapes-minutes.html
RESOLUTION: Approve minutes of the 17 March 2016 Telecon: http://www.w3.org/2016/03/17-shapes-minutes.html
pfps: I don't think face- nor meeting-time is the bottleneck at the moment
... gaps in the design/spec need to be filled
... which needs external inputs and/or increased attention from some quarters
hknublau: what are the dramatic holes at the moment?
pfps: prebinding and hasShapes
Arnaud: there's been recent email traffic on prebinding
hknublau: hasShape has not been updated because we're still working on recursion, which resolution has significant impact there
[ back-and-forth about F2F impact/utility ]
hknublau: what is current timeline?
Arnaud: we are chartered until June 2017, so there should be plenty of time, even though we have not kept up with original forecast schedule
pfps: another implementation, especially one that includes the extension mechanism, would help a lot in boosting confidence
simonstey: I'm doing a fair amount of work with hknublau's draft API. do we need to re-implement that to be counted as multiple implmentations?
<Dimitris> I am planning to implement the spec
TallTed: I do expect that OpenLink will implement SHACL including extension mechanism. timing is indeterminate, but we do try to do such within CR->PR window.
<Arnaud> PROPOSED: Open ISSUE-138 Property constraints as lists, ISSUE-139 Universal applicability, ISSUE-140 Individual validation, ISSUE-141 Mixed ranges
<hknublau> +1
+1
<Dimitris> +1
<kcoyle> +1
<simonstey> +1
<pfps> I think that it would be very much better if OpenLink did an implementation before CR. This gives the WG much needed confidence that the design is workable.
<pfps> +1
RESOLUTION: Open ISSUE-138 Property constraints as lists, ISSUE-139 Universal applicability, ISSUE-140 Individual validation, ISSUE-141 Mixed ranges
<pfps> It would also be very helpful if OpenLink can contribute to the design of hasShape and pre-binding.
ISSUE-128?
<trackbot> ISSUE-128 -- sh:defaultValueType is rdfs:range -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/128
<Arnaud> PROPOSED: Close ISSUE-128, without action.
hknublau's email -- https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Mar/0252.html
pfps: as far as I can tell, defaultValueType is trying to mirror part of RDFS, so we don't have to put class links on some shapes, in order to support a particular version of the metamodel
... this seems to be a special purpose crutch to enable metamodel validation, and of no use elsewhere
<Arnaud> PROPOSED: Close ISSUE-128, without action.
<pfps> -1
<hknublau> +1
<simonstey> -0.5
<kcoyle> -.5
<Dimitris> 0
<jamsden> 0
+0.5
<Arnaud> PROPOSED: Close ISSUE-128, dropping sh:defaultValueType
<hknublau> -1
<pfps> +1
<kcoyle> 0
<Dimitris> 0
<simonstey> .5
<kcoyle> +q
kcoyle: I believe we've decided definitively that SHACL includes no inferencing. that makes me wonder how using rdfs:range could help us here.
hknublau: this is about pre-validation inferencing on the shapes graph
... the difference is that rdfs:range effectively always adds a type triple, while sh:defaultValueType only applies if there is no other type triple
<simonstey> sh:property [ a sh:PropertyConstraint; sh:predicate ex:property; sh:minCount 1 ] vs. sh:property [sh:predicate ex:property; sh:minCount 1 ]
simonstey: this seems to be just a bit of shorthand sugar, allowing some explicit statements to be left out
Dimitris: I think we need to finalize the metamodel before we'll know whether this is useful or not
Arnaud: do we break anything if we drop sh:defaultValueType?
hknublau: no
TallTed: what about marking it Feature At Risk?
... after this discussion, I revise my votes above to +1, -1
kcoyle: I wonder if we're not talking so much about the standard, as implementation variance
Arnaud: anyone else adjusting votes?
RESOLUTION: Close ISSUE-128, without action.
background https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Mar/0255.html
Dimitris: we have two considerations -- metamodel simplification, and syntax simplification. making one simpler tends to make the other more complex. do we simplify life for "engine user" or for "engine writer"?
pfps: the current design with mixed up PropertyConstraints and property paths is broken. there is some patch in consideration, but it's not clear whether that resolves the whole break.
Arnaud: in the course of this, Property Paths were raised again, and appear to be more broadly acceptable and implementable
<pfps> I don't see that closing this the other way is a possibility today.
Dimitris: ShEx people are likely to have objections here, so if we reopen, shouldn't reclose without them
<simonstey> if the extension mechanism will be dropped, we need those paths
hknublau: I wonder whether we now have solutions to a problem that doesn't really exist or isn't that important
... would probably want this to be in extension mechanism, not core
<hknublau> Yes, we could postpone it.
<Arnaud> PROPOSED: Reopen ISSUE-41, based on Peter's email https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Mar/0290.html
<simonstey> +1
<pfps> +0.5 as I find them very useful in my implementation
+1
<kcoyle> 0
<hknublau> -0
<Dimitris> +0
RESOLUTION: Reopen ISSUE-41, based on Peter's email https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Mar/0290.html
ISSUE-130?
<trackbot> ISSUE-130 -- SHACL should not assume that the data graph is in an RDF dataset -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/130
<Zakim> pfps, you wanted to say that the current draft does not depend on datasets
<Arnaud> PROPOSED: Close ISSUE-130, as is - the latest draft doesn't require/assume a dataset
<pfps> +1
+1
<Dimitris> +1
<kcoyle> +1
<jamsden> +1
<simonstey> +1
<hknublau> 0
RESOLUTION: Close ISSUE-130, as is - the latest draft doesn't require/assume a dataset
adjourned!
<Arnaud> trackbot, end meeting