See also: IRC log
+q
<scribe> scribe: simonstey
<Arnaud> PROPOSED: Approve minutes of the 28 July 2016 Telecon: http://www.w3.org/2016/07/28-shapes-minutes.html
RESOLUTION: Approve minutes of the 28 July 2016 Telecon: http://www.w3.org/2016/07/28-shapes-minutes.html
Arnaud: we agreed to wait with the abstract syntax & SHACL drafts
... any updates on where we stand?
Dimitris: hknublau did some work on the draft and I plan to continue tomorrow
... I think in two weeks from now we could have another version of the draft published
hknublau: in my opinion it's still not 100% perfectly readable
... I guess it needs another pass from someone
... was also waiting on some resolutions
issue-92
<trackbot> issue-92 -- Should repeated properties be interpreted as additive or conjunctive? -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/92
Arnaud: regarding sh:partition, I think we should wait for ericP to decide whether we want to keep/remove it
... I'm in favour of dropping it though
Arnaud: unfortunately, none of the proposals clearly sticks out
<Arnaud> https://www.w3.org/2014/data-shapes/wiki/Proposals#ISSUE-175:_rename_scope
<Arnaud> issue-175
<trackbot> issue-175 -- Alternate naming for term for scope / in-scope -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/175
issue-175
<trackbot> issue-175 -- Alternate naming for term for scope / in-scope -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/175
kcoyle: we have to be clear about used terminology
... i.e., "they are in scope" vs. "they are selected"
hknublau: what kcoyle says is correct; the problem was that someone from outside the group was mentioning that "scope" already has another meaning in cs
... my personal fav. for now is "target" instead of "scope"
... i.e., a shape is "targeting" a set of nodes
<pano> +1 for target
<Dimitris> target works for me as well
hknublau: targetnode, targetclass, etc.
<Dimitris> but I would rather targetInstancesOf instead of targetClass
[talking about a variation of "Proposal 5: Use target instead of scope / in-scope (suggested by James Anderson). The existing properties would be renamed to sh:targetNode, sh:targetInstancesOf, sh:targetObjectsOf, sh:targetSubjectsOf"]
Dimitris: I would prefer targetInstancesOf instead of targetClass
simonstey: we have to be very clear on explaining what sh:targetClass means
<Arnaud> PROPOSED: Close ISSUE-175, changing "scope" to "target"
<hknublau> +1
<kcoyle> +1
<pano> +1
+1
<Dimitris> +1
RESOLUTION: Close ISSUE-175, changing "scope" to "target"
issue-169
<trackbot> issue-169 -- Should we rename sh:scopeProperty/InverseProperty -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/169
<Arnaud> PROPOSED: Close ISSUE-169, rename sh:targetProperty to sh:targetSubjectsOf and sh:targetInverseProperty to sh:targetObjectsOf.
hknublau: I raised that issue directly after we decided to kick out inverseproperty
<hknublau> PROPOSED: Close ISSUE-169, rename sh:targetProperty to sh:targetObjects and sh:targetInverseProperty to sh:targetSubjects.
<hknublau> PROPOSED: Close ISSUE-169, rename sh:targetProperty to sh:targetObjectsOf and sh:targetInverseProperty to sh:targetSubjectsOf.
+1
<hknublau> +1
<Dimitris> +1
+q
<pano> +1
sh: scope
<kcoyle> 0
kcoyle: the problem I have is that if you start to concatenate a bunch of subjects together, well it doesn't really work well in english
RESOLUTION: Close ISSUE-169, rename sh:targetProperty to sh:targetObjectsOf and sh:targetInverseProperty to sh:targetSubjectsOf
kcoyle: grammatically correct would be sh:targetedSubjectsOf which makes it even longer
Arnaud: we started talking about that last week
... there are two different dimensions to the problem
... 1.) higher sev. wins over lower sev.
... 2.) what happens with nested sev.?
Dimitris: if a shape has a warning, info, and violation
... only if viol. fails the shape doesn't validate
... if a shape doesn't validate but has a nested shape that would throw a warning that warning isn't actually thrown
<Dimitris> https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Jul/0079.html
hknublau: I would change anything in the spec
... I also don't agree with treating all sev. the same
... an info isn't a violation
Arnaud: it all boils down to what the application actually does with the validation results
+q
simonstey: agree with hknublau
TallTed: there is a difference between "data is not available/wrongly formatted" vs. "data is wrong" hence should have dif. levels of severity
hknublau: we leave it to the engine to signal e.g. a failure to the outside
<TallTed> TallTed: ex, "123456789"^^xsd:int vs "1-234-56-789"^^xsd:string vs (missing) for a phone number
<Arnaud> http://w3c.github.io/data-shapes/shacl/#terminology
Arnaud: I guess we are missing on a sentence explaining the term "failure"
hknublau: I'll fix that
<Arnaud> http://w3c.github.io/data-shapes/shacl/#results-severity
kcoyle: either shacl provides the levels you need or it allows you to define those levels yourself
... I'm not sure how much burden that puts on implementers
<kcoyle> yes, what Simon is saying - can't have it both ways
Dimitris: with my proposed approach it should be easy to add additional sev. levels
hknublau: we used to have a design with an hierarchy
... where you could e.g. subclass a warning and make it an error or alike
... which was rejected by the group and I agrree it isn't optimal
Arnaud: hknublau is saying there isn't any problem vs. Dimitris saying that there is
hknublau: I see no warning with nesting either
Dimitris: it's also about reporting where it can easily become confusing for users
TallTed: it's use case dependend whether you care about nested sev. or not
<Dimitris> I agree for OR as well
<Dimitris> but not for all other nested cases
[ TallTed and hknublau discussing different use cases of nested shapes/severities and respective impact of sev. reporting ]
<Dimitris> this gets problematic even in sh:or because sh:Warning and shInfo does not case a violation
Arnaud: I somehow agree with TallTed here in the sense that we have to allow users to configure those things by themselves
+q
-q
hknublau: the important part is the most outer shape
+q
<Dimitris> I agree with Simon
<Dimitris> this is inline with what I was proposing
<Arnaud> trackbot, end meeting