See also: IRC log
<scribe> scribe: simonstey
<hknublau> Webex took forever to start up…
<Arnaud> PROPOSED: Approve minutes of the 7 January Telecon: http://www.w3.org/2016/01/07-shapes-minutes.html
RESOLUTION: Approve minutes of the 7 January Telecon: http://www.w3.org/2016/01/07-shapes-minutes.html
issue-117
<trackbot> issue-117 -- sh:class should not require that its objects be known to be instances of rdfs:Class -- raised
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/117
issue-118
<trackbot> issue-118 -- syntax errors should not be confusable with validation results -- raised
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/118
Arnaud: any questions/concerns?
ericP: I'm not entirely sure what's desired there
... the issue said when it's something a class/shape.. at least that's what I thaught 117 was about
Arnaud: I think that's about the email pfps sent out and not the issue
pfps: there are a bunch of issues.. the document is unclear about what's going on and what should be going on
... 117 is about the syntax
... hknublau's spec. produces syntax errors when I think it should not to
aryman: is it hknublau's implementation that throws an error?
pfps: his implementation throws a violation under some circumstances that seem questionable
aryman: I think it's more accurate to say it's a "ShapeError" on the shapes graph
... it shouldnt be a violation on the data graph
<Arnaud> PROPOSED: Open ISSUE-117 and ISSUE-118
<kcoyle> +1
+1
<Labra> +1
<hknublau> +1
<pfps> +1
<aryman> +1
<TallTed> +1 open both; I suggest rewording ISSUE-118 to something more like "syntax errors are currently confusable with validation results"; ISSUE-117 may need similar reword
RESOLUTION: Open ISSUE-117 and ISSUE-118
aryman: 1st the shapes graph has to be validated and that's different from validating the data graph
<pfps> which issue separates syntax and validation errors?
aryman: the violation report should really just be violations on the data graph; I think there was an issue for this
Arnaud: please add any hints to former issues dealing with similar stuff
<aryman> ISSUE-117 looks related to ISSUE-75
kcoyle: correlations between requirements and SHACL concepts where added
... so for one I'm not sure if all of the UCs where already addressed
... and secondly, I think I stumbled across some interesting candidates for tests
... how shall we proceed?
Arnaud: either by putting a document in the testing space on github or create a wiki page
kcoyle: keeping it in github keeps everything together
<pfps> fine by me
Arnaud: everybody should give the ucr document a read until next week
hknublau: the syntax/facts should be up-to-date
... (inverse) property constraints, ... sections are still kind of seperated
... but I think we could publish it as is
aryman: I think last week we reached closure on issue 49
<pfps> I think that having a week for review is appropriate.
Arnaud: but we haven't it closed yet, right?
aryman: If we close 49 today I would like to have it in the draft before publication
Dimitris: I'm fine with aryman's proposal
issue-23
<trackbot> issue-23 -- Shapes as classes -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/23
Arnaud: hknublau removed shapeclass and rephrased parts of the draft
<kcoyle> link to where in the spec pls?
<Arnaud> http://w3c.github.io/data-shapes/shacl/#scopeClass
<kcoyle> thx
Arnaud: is the current approach of inferencing acceptable for the group? (wrt. section 2.2)
pfps: this wording (I guess) was one of the reasons I sent out my email this morning
... this stuff has to be nailed down so there is no chance to wiggle around
... e.g., what does "prior to validation" exactly mean?
... alot of things can happen "before" validation
aryman: I kind of agree with pfps
... I think it would be clearer if we specify the notion of scope class more precisly
... we haven't been really clear how the shapes graph is constructed
... we had the discussion about scope node
... the seperation between data/shapes graph is kind of application dependend
hknublau: I agree with aryman
... of course, if you also validate the shapes graph, then you will get other/additional results
pfps: we have to be clear about any changes to the shapes graph
... if shapes&data graph are put together, you could construct a shape that looks for scopeclass triples
... if there are no side effects, we can be more relaxed regarding the processing order
Dimitris: what happens if you have "double scopes"?
<pfps> with individual scopes you really need multiple scopes
aryman: yes, scopes are unioned
Dimitris: but union is not consistent with the rest, e.g., constraints are conjunctive
aryman: yes but scoping is different.. if you want to eliminate things, you can use filters
pfps: no scope triples, class scope triples, and there is self scoping
... the first two seem to be well-behaved
... the third one might be problematic
... i.e., when does self-scoping happen?
Arnaud: I would like to give aryman the chance to edit the draft (working in his proposed definition)
<pfps> kicking the can down the road? sure
issue-49
<trackbot> issue-49 -- Distinction between scoped and unscoped shapes -- postponed
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/49
aryman: I think everyone that expressed opinion seem somehow satisfied
<pfps> fine by me
<Arnaud> PROPOSED: Close ISSUE-49, adopting Arthur's and Peter's suggestions https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Jan/0024.html https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Jan/0025.html
+1
<hknublau> +1
<kcoyle> +0 (going on faith)
<pfps> +1
<aryman> +1
<Dimitris> +1
<TallTed> +1
<Labra> 0
<ericP> +0
RESOLUTION: Close ISSUE-49, adopting Arthur's and Peter's suggestions https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Jan/0024.html https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Jan/0025.html
Arnaud: aryman is it possible for you to make the required edits to the draft early so that people can have a look before next meeting?
aryman: I'll aim to have it done by monday
... or the day after
<pfps> It appears to me that 2.2 already conforms with the resolution on filters.
issue-115
<trackbot> issue-115 -- Closeness is an aspect of a Shape, but the current syntax treats it like all other constraints. -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/115
Arnaud: aryman added two option on how we could solve this issue
<pfps> I agree with Arthur that the current syntax is less than ideal
<Arnaud> https://lists.w3.org/Archives/Public/public-data-shapes-wg/2015Dec/0057.html
hknublau: just wanted to add that there's a third option (found in my email)
strawpoll
<pfps> right now it appears that multiple closure constraints are possible on the same shape - how will that work?
<Arnaud> STRAWPOLL: a) sh:close on sh:Shape , b) sh:ClosedShape, c) sh:close on sh:constraint
<hknublau> @pfps someone could also have true and false for sh:close in option 1.
<ericP> a: +1, b: -.9, c: -.5
<TallTed> tangential -- sh:closed better than sh:close... ["closed-ness" (vs "open-ness") more than "close-ness" (which reads like "how nearby") I think... ]
<aryman> a) +1, b) +.5, c) +0
<hknublau> a) -0.9 b) -.5 c) +1
<pfps> a: +1, b: 0, c: -0.5
a)-0.5 b)+0.5 c)+0.9
<Dimitris> a: +1, b:+0, c:-.5
<Labra> a) +1, b) -0.5 c) -0.5
<TallTed> a) +1, b) -0.5 ,c) -0.5
<kcoyle> a) +.5 b) 0 c) -.5
hknublau: the problem is that every constraint (except of this one) uses the same strategy
<pfps> I fail to see any implementation difference between the various options; what I see is a very large difference between closure and the (other) constraints
hknublau: this approach would not have a "trigger property" -> you would have to check for that everytime
... I don't see why this is so different from and/or
TallTed: I think that this is maybe more of an operational than a shape thing
Arnaud: so it should be a parameter to validation then? (agreed to by TallTed)
TallTed: it's definitely a thing that has multiple layers to it
<ericP> Σ: a: 5.1, b: -1.4, c: -1.1
pfps: everything that's currently a constraint is independent, but this doesn't work for "closedness"
... so it's different from any other constraint
aryman: what pfps said
... what we should be striving for is how the language looks to users
... so there are two aspects, (i) implementer's pov (ii) author's/writer's pov, and I think we have to give them both appropriate weight
<kcoyle> THANK YOU ARTHUR!
<Arnaud> PROPOSED: Close ISSUE-115, adopting sh:closed on sh:Shape
<ericP> +1
<aryman> +1
<Labra> +1
<kcoyle> +1
<hknublau> -0.5
<TallTed> +1
0
<pfps> +1
<Dimitris> +1
RESOLUTION: Close ISSUE-115, adopting sh:closed on sh:Shape
Arnaud: pfps asked about the process of adding tests
... ericP, how did we do that for turtle, etc.?
ericP: for turtle it was the editors, for sparql it was me & andy
<Zakim> ericP, you wanted to ask relationship between test-node-as-shape vs. test-graph test formats
ericP: certainly someone who can think of different kinds of permutations etc.
... we already have >600 for shex
pfps: there is def. a tention of having a test harness that tests every fine-grained aspects vs. having one that only tests the most general test cases
[discussion on abilities of a suitable test harness]
<pfps> I propose a process something like: a proposed test that works for the majority of implementations is proposed and if not vetoed become approved, proposed tests where the implementations do not conform need explict discussion
pfps: I think we should encourage people to propose tests
<pfps> quodlibet uses something to vet pushes I'll see if I can find out what they do
<Arnaud> trackbot, end meeting