See also: IRC log
<ericP> scribenick: ericP
marqh: happy to scribe
... how do i do so?
... happy to marqh
<scribe> scribenick: marqh
<ericP> : Approve minutes of the 2 Nov 2016 Telecon: http://www.w3.org/2016/11/02-shapes-minutes
<ericP> PROPOSED: Approve minutes of the 2 Nov 2016 Telecon: http://www.w3.org/2016/11/02-shapes-minutes
ericP: first topic, approve previous minutes
<ericP> PROPOSED: Approve minutes of the 2 Nov 2016 Telecon: http://www.w3.org/2016/11/02-shapes-minutes
ericP: exciting bits: end of minutes
<Labra> ** I will leave in 10 mins and be back after another 20mins
ericP: opened issue 193 targets can be defined
<scribe> ... closed issue 191, about valueTypes et al.
<simonstey> +1
<ericP> +1
<Labra> +1
<hknublau> +1
RESOLUTION: Approve minutes of the 2 Nov 2016 Telecon: http://www.w3.org/2016/11/02-shapes-minutes
<ericP> PROPOSED: Change time of regular weekly call to 8:30am US Eastern
<ericP> +1
<hknublau> +1
ericP: quorum is marginal, but best we can do
<simonstey> +1
<Labra> 0
RESOLUTION: Change time of regular weekly call to 8:30am US Eastern
+1
<ericP> PROPOSED: Virtual F2F scheduled on 16 Nov 08:00-12:00 EST
<ericP> doodle poll
<hknublau> +1
<ericP> +1
ericP: virtual face to face meeting proposal
<simonstey> +1
<Labra> 0
RESOLUTION: Virtual F2F scheduled on 16 Nov 08:00-12:00 EST
<ericP> issue-194
<trackbot> issue-194 -- stems in value sets -- raised
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/194
ericP: when we had a discussion of what we call stems in sheks, we weren't specific about how they are used.
... any value set is an enumeration of a long or
... this can include URIs that a certain substring, and excluding other substrings
... this is about URIs starting with a substring only
<ericP> PROPOSED: Open ISSUE-194
<ericP> +1
<simonstey> +1
<Labra> +1
<hknublau> +1
ericP: the proposal is to raise ISSUE-194 to address this
+1
RESOLUTION: Open ISSUE-194
<trackbot> issue-183 -- Eliminating the term "Undefined" -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/183
ericP: this came for dimitris, but he is not here
<trackbot> issue-184 -- Property paths and value nodes -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/184
ericP: we may leave this issue unresolved
hknublau: i can pick this up. In have avoided the term and teh change is now dealt with. the issue can be closed, in my view
... the background is about the term 'undefined'
... what terms to return a node or nothing
... closest in SPARQL is a SPARQL error
... so I have just used this
ericP: I understand, i would like dimitris to agree to closure
hknublau: dimitirs may just be late, let's defer in case he arrives
ericP: agreed
... lets move to issue-191
<trackbot> ISSUE-191 -- Should the value types of parameters be constraints -- closed
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/191
hknublau: this issue is already closed, resolved last week
<trackbot> ISSUE-140 -- SHACL needs to support validation of individual nodes -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/140
ericP: one way to look at this is that a this can be handled with distinct mechanism
... the spec can describe no shape pairs
... i have made a proposal
... one approach i would propose is to move the section on how we sift through graphs and compose node shape pairs
... then have a seperate operation that mkaes it clear it is done one
... once
hknublau: it sounds like we need a compromise here. sheks are not fond of targets, in my view targets are useful
<Labra> ** I have to leave now...be back in 20 mins...
hknublau: why don't we meet in th3e middle, have some targets in examples and some without targets
... look under focesNodes. this describes how focusNodes can be determined
... I woudl like input from sheks on
... it is also possible to pass a node into a processor by some means
... a sentence to put in here to mention this explicitly would be useful
... add som examples with no target, with text to clarify node origins
... this could be a good compromise
ericP: i am content with that
... it does make it harder to separate the 2 processes, but that may not be a problem
<ericP> PROPOSED: resolve issue-140 by having half of the examples include target* and the other half not.
<ericP> +.5
TallTed: that puts significant weight on having examples of both kinds in each case
<hknublau> +0.5
ericP: can readers extrapolate and understand
<simonstey> +q
some examples in one formulation and some in the other, we set it up so that is how it is implemented
simonstey: to support what TallTed has said, some example with or without target, people will read into this
... so examples consistency is helpful
... some statements saying 'target omitted in this example' will get missed by readers
<TallTed> maybe include a comment-line next to each target triple, saying "that triple is optional"
Dimitris: we can have examples with targets, then ones showing how targets may be ommitted in some cases
ericP: could have targets in a seperate block, illustrating that it provides functionality
Dimitris: this is a differnet type o fvalidation
... just need to show how to omit them in specific csaes
ericP: having targets in there is problematic for useability
... inherent cost of having things written into the shape graph or data graph
... inherent cost of having things written into the shape graph or data graph
... making the shape graph predestined for some data
<hknublau> strongly disagree, except for sh:targetNode
ericP: my goal is to show how to add that, but you don't have to have a target for validation
<simonstey> +q
<TallTed> or a comment line saying "targets could be set here, as ..."
Dimitris: having both ways, showing targets can be ignored is useful
<hknublau> different CSS would be ok
ericP: duplicating all the examples is one way, could get busy
... could have a section showing the alternative approach
<simonstey> +q
TallTed: consistent style as a link
hknublau: i like this approach
simonstey: can do some fancy javascript to enable switching things on and off in examples
ericP: editorial question; i suspect flat styling is sensible
<ericP> PROPOSED: close issue-140 by adding some consistent style and a link to say that target* is not needed for invocations by API
<hknublau> +1
<simonstey> +1
<Dimitris> +1
<ericP> +1
<TallTed> +1
hknublau: do you want to include text into bullet 9.1
ericP: i'll come up with something for this
RESOLUTION: close issue-140 by adding some consistent style and a link to say that target* is not needed for invocations by API
<trackbot> ISSUE-183 -- Eliminating the term "Undefined" -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/183
<hknublau> (bullet 2.1 Focus Nodes)
<ericP> holger's edits addressing issue-183
Dimitris: this is an old one
hknublau: this is about sparql functions which return nothing
... term is SPARQL error, i have used 'undefined' not an official term
Dimitris: happy to close this
<ericP> PROPOSED: Close ISSUE-183, accepting the edits made by the editors to eliminate the term undefined which alters the definition of the sh:hasShape SPARQL function
<hknublau> +1
<ericP> +0
+1
<simonstey> +1
<Dimitris> +1
<TallTed> +1
RESOLUTION: Close ISSUE-183, accepting the edits made by the editors to eliminate the term undefined which alters the definition of the sh:hasShape SPARQL function
<trackbot> ISSUE-184 -- Property paths and value nodes -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/184
Dimitris: use sparql definitions for property paths
... when on property paths don't take duplicate nodes
... issues including cardinality
... proposal is to work with sets
hknublau: this is already implemented in the spec
... the question is whether people are against this change
<ericP> PROPOSED: Close ISSUE-184, agreeing that on property constraints with sh:path the value nodes are a set with no duplicate value nodes.
<hknublau> +1
<Dimitris> +1
+1
<ericP> +1
<TallTed> +1
<simonstey> +1
RESOLUTION: Close ISSUE-184, agreeing that on property constraints with sh:path the value nodes are a set with no duplicate value nodes.
<trackbot> ISSUE-185 -- Processing order for filters and constraints -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/185
Dimitris: after some of peter's comments, introduced ordering, proposl: there is an ordering
<simonstey> +1
<simonstey> +q
simonstey: are there any implication that arbitray order allows you to do, rather than this strict order
... is there something you can't do
... is there minimal implication
Dimitris: can make single query for whole constraint, can choose to operate on fewer nodes
... when a failure occurs, not easy to define what happens
simonstey: if validation fails, based on node not to be included, but filter not applied yet?
... if first step fails, then could end up with different results
ericP: ambiguous
Dimitris: might not complete result back when failure occurs
simonstey: if filter wants only to check constraint on 'male' persons
... now, do you do filtering afterwards?
... failure might not occur if filtering done first
hknublau: i think this can be avoided if we always evaluate both: enforce this rule
... in this case, these are not returned as failures
... even if there is a failure, it woudl not propagate up
simonstey: do we need to consider a crashdue to the failure
hknublau: i don't think so
ericP: this is a form of negation and failure; sometimes you need to avoid ssituation where you can infer p and not p
... Proposal: SHACL does not force whether filters or constraints are evaluated first for validating a node against a shape.
<ericP> PROPOSED: Close ISSUE-185, agreeing that SHACL does not define whether filters or constraints are evaluated first when validating a node against a shape, but both must be evaluated
simonstey: if constraint is evaluated before filter, both must be evaluated
<simonstey> +1
<hknublau> +0.5
<Dimitris> +1
<ericP> 0
<Labra> 0
<ericP> marqh: re readability: should we just say "but all must be evaluated"?
TallTed: as i recall, the point on filters was to eliminate from constraint validation things which may be problematic
simonstey: maybe not to include focus nodes, it may be useful
... may want to filter out certain nodes
TallTed: may have a million zeros and six ones, why invest time on things which don't matter
hknublau: similar with sh:and and sh:or
... every filter is an and or an or, can be turned around
TallTed: if can't hint at order, every job may last for ever
<ericP> marqh: i feel like we don't need to mention ordering in the standard. it's defined either way
TallTed: then they are not filters, they are constraints
simonstey: if validation of the filter fails, are you returning any results
... if constraint fails, you woudl return a validation results
TallTed: i see not value in not saying: this is teh order that this should be dealt in
marqh: interested in the reason to maintain the felixibilty nod not have order
<simonstey> +q
Dimitris: have and and or where order does not matter, this is consistent
hknublau: unfortunately, had long discussion with karen, on what is considerd a focusNode. we agreed that a focusNode is a node which passes all teh filters
... target - filters are focusNodes
... need order that things are defined
TallTed: filter should be evaluated before constraints by the spec
... i believe hinting is a good thing, ordering helps
... harder in RDF world to have ordering, but having a class of things to deal with
simonstey: and and or are completely different things. ordering with regard to constraints is needed
... checking the filter afterwards is not good
... if either of the ands fail, you could do a lot of work not required
Dimitris: two and statements, order matters. engine evaluates
simonstey: if you have an and and 2 shapes, if one fails, can return faster result
... with filter and constraint, if constraint first, fails, then filter passes, return result, if ordered differently, diferent results returned
Dimitris: i am not sure, i think the same thing happens
<ericP> marqh: it sounds to me like we should change the issue-185 proposal "SHACL *does* not care about order" to "SHACL *does* care about the order"
marqh in favour of changing ISSUE-185 to propose that filters are evaluated before constraints
Dimitris: i mind, but i am willing to consider
simonstey: i think that Dimitris has a valid point why cases are not that different. in both cases if you evaluate wrong side first, then the very last would fail, the outcome is the same; i get this
... unless a strong reason exists for flexibilty, it is useful to require that filters are evaluated first
... could make statement that it doesn't matter to the result, but the filters shall be evaluated first
TallTed: this is a useful detail for the reader
... if shape2 does not pass filter, then the work is trivially satisfied
Dimitris: if we have order, we cannot model the shape as sh:and and sh:or
... if there is no ordering, then we can model teh filter like an sh:or
TallTed: the point of filter is to say don't evaluate
... we had a graphic showing that the filter pre-processess before constraints
... is filter about results or about focusNodes?
ericP: it is about removing results that would otherwise fail
... i think this is about result reporting: take 5 errors and return zero
TallTed: then it should be about results filtering; it should be moved to the results section
... int that case, it would be not be about choosing focusNodes
ericP: has the effect of filtering out results
TallTed: question is what is being applied to
... if about trimming results, it comes at a different point, doing a different job
ericP: not only about trimming results
TallTed: it is a focusNode trimmer
ericP: in C pragmas are written in as par tof the compiler
... Dimitris raised the point that it would be nice to let the system be smart
marqh: i am quite taken with the point that oreder should be enforced; i don't think the counter argument is strong
ericP: Dimitris point is a good one, where the filter is very complex and may fail a lot
<Dimitris> this is more ordering
TallTed: do we need 2 types of filter
ericP: pre and post constrasin
marqh: i'm not convinced 2 filter are needed
simonstey: or and not are not intended to be used as filter
ericP: how can a test be set up to test the order of processing
TallTed: can write long test
... can make a test with a div0
<ericP> marqh: if you have an impl, you can test pieces, even if it's not an end-to-end integration test
<ericP> ericP: so write it in English, not in standard test case format
Dimitris: can provide a new definition int he spe to close this issue
... definition of validation
<Dimitris> A node validates against a shape if and only if either it does not validate against some filter of the shape or none of the constraints in the shape produce a validation result or a failure for the node.
ericP: who will write a proposal for change
<ericP> ACTION: marqh to propose changes to the definition of validation to close issue-185 [recorded in http://www.w3.org/2016/11/09-shapes-minutes.html#action01]
<trackbot> Created ACTION-46 - Propose changes to the definition of validation to close issue-185 [on Mark Hedley - due 2016-11-16].
Dimitris: it's fine, i'm done
<ericP> trackbot, end meeting