<scribe> scribe: sandro

ipolikof: Next meeting: same time, same place (next week)

<ipolikof> PROPOSED: Approve minutes of the 12 April 2017 Telecon: https://www.w3.org/2017/04/12-shapes-minutes.html

<hknublau> +1

<ipolikof> +1

<simonstey> +1

<TallTed> +1

+1

RESOLUTION: Approve minutes of the 12 April 2017 Telecon: https://www.w3.org/2017/04/12-shapes-minutes.html

test suite

<ipolikof> See http://w3c.github.io/data-shapes/data-shapes-test-suite/

hknublau: Peter's test case, questions about how to go from here, with more test cases coming in.
... moving target
... prebinding, especially
... This test case of Peter's:

<hknublau> https://github.com/w3c/data-shapes/tree/gh-pages/data-shapes-test-suite/tests/core/validation-reports

hknublau: click on shared-shapes
... go from a node shape to two property shapes
... system will recursively walk into them, and produce validation results for all of them
... two possibilties
... reach the same focus node from two paths
... either report once, or twice, or we dont care
... two variations of this, one from peter, one from me

<simonstey> +1 for producing a result for each of the propertyshapes

ipolikof: so the spec if unclear about whether the results should be 1 or 2?

hknublau: I don't care which it is, and I don't see the spec saying one way or the other

<simonstey> For every validation result that is produced by a validation process (except those mentioned in the context of conformance checking), the SHACL instance of sh:ValidationReport in the results graph has a value for the property sh:result.

ipolikof: Can we say both are valid, to allow more optimization as Peter wants

<simonstey> https://www.w3.org/TR/shacl/#result

TallTed: Seems like the basic results is it failed and the more detailed is where

sandro: Could you have a success with the same ambiguity?

<simonstey> +q

hknublau: no, then there'd be no validation report
... Could have test result allow either, MFresult1 and MGresult2
... or we-don-t-care, ...

dimitris: What does your impl return, hknublau?

hknublau: Currently 2, but I could easily change it to 1 by having it rememer

dimitris: Let's wait and see what the various impls report

simonstey: We had a similar discussion months ago, about the optimization. Where if you have to report all the results, you can't optimize.
... I'm in favor of having all-results-reported. I wouldn't want to rule out impls providing all. Making everyone keep track of all paths seems too much.
... I'm in favor of treating them as independent

ipolikof: Peter wants the impl that reports it once still passes

TallTed: Each failure is identical, these subgraphs, so an efficient reporting engine would combine these as not-distinct. As someone receiving a report, I'm not going to want 400 identical lines.

simonstey: Peter's point is they're not really identical since they are different blank nodes.
... Maybe we can go the easy way and says results must be RDF Grpah Isomorphic after blank node subsitution

ipolikof: I like dimitris's suggestion to see what others report, but can we say both are allowed?

simonstey: If we say both are allowed, we have to figure out how to test that

hknublau: We can have two results, and say either is a pass
... In the spec I have this rule about always-needs-to-produce-new-blank-node, but in this case it's wishywashy, it doesn't say they have to be new

TallTed: So that's an editorial bug

hknublau: You can do your optimizaiton, but you need to have one mode that produces all the results

ipolikof: "Implementations MAY suppress...."

hknublau: I would want to be clear these always need to be new results

TallTed: As I recall this was the intent

simonstey: But Ted's issue about 400 artificial duplicate results

TallTed: no problem, the good tool will do the blank node subsitution and reduce it to one

hknublau: If you have 400 identical results, they're probably actually slightly different, different focus node or something

TallTed: We intended to have one result node for each test. So there's an editorial bug that this one doesn't have that bit of text.
... in optimization of tools and UI, that's value add

ipolikof: I'm hearing proposal to fix editorial bug to make it clear each results needs to be present

<ipolikof> PROPOSAL: Fix the editorial bug to clarify that all results must be produced

sandro: that doesn't neeed a new CR

<hknublau> PROPOSAL: Fix the editorial bug to clarify that all results of sh:property must be fresh validation result nodes, then delete the test case with 1 result only.

<hknublau> +1

<simonstey> +1

<ipolikof> +1

<Nicky> +1

<TallTed> +1

jack_, can you see this?

jack_: +1

RESOLUTION: Fix the editorial bug to clarify that all results of sh:property must be fresh validation result nodes, then delete the test case with 1 result only.

<jack_> hello

New test on prebinding

jack_, I just saw 'hello'

<jack_> I just found the window to type in :-)

hknublau, talked to Andy, and there are some changes, makes one of the test cases invalid

scribe: and Peter may find some nasty corner cases
... this is appendix on Prebinding
... because of SPARQL EXISTS CG, and the change I didn't know about
... sounds like a normative change, making certain shape graphs ill-formed
... unfortunate reality

TallTed: Is there any pushback we can/should do on this change?
... is this change really necessary / permanent

hknublau: They're spec is evolving, whatever we copy is a snapshot

<simonstey> +q

sandro: What's the prognosis for the AT RISK sparql extensdion mechanism?

TallTed: The bar isn't about the math

simonstey: (summarizing)

hknublau: SOme people find corner cases, like embedding minus block

simonstey: Is it only about sparql, or our semantics

hknublau: What's unsatisfactory is being blocked by corner cases

simonstey: I don't want to remove sparql part; a lot of companies that will use shacl want this.
... They'll migrate the constraints they already have in sparql to shacl
... By removing it from normaitve bits, they'd be very unhappy

ipolikof: Is there way for us to make a general sentence, about some things not being defined

hknublau: That would be ideal, if you can find such a sentence

simonstey: We can't test for all possible sparql constraints

<jack_> my company would be, if I am allowed to say so

understood, jack_

hknublau: We could enumerate the features that definitiely work, filter graph patters, etc
... and everything else is undefined and left to future work to define
... that would work for all or almost all our usecases

simonstey: maybe "illformed" is too strong

hknublau: That just means the output is undefined, and it could be allowed in the future

ipoliko: Can we define it precisely

<simonstey> https://www.w3.org/TR/shacl/#ill-formed-shape-graphs

<simonstey> If the shapes graph contains ill-formed nodes, then the result of the validation process is undefined. A SHACL processor SHOULD produce a failure in this case.

sandro: I'll have to check if that would need new CR

ipolikof: I like this solution

TallTed: Relying on another W3C spec makes this hard

simonstey: If one of my 1000 shapes uses minus, this would mean the whole validation process is undefined

<hknublau> PROPOSAL: Add a syntax rule making SPARQL queries ill-formed (or undefined) that use certain features outside of {BGP, FILTER, GRAPH, UNION, etc} excluding difficult cases like VALUES, MINUS.

simonstey: everything SHOULD abort because of an ill-formed shape

<hknublau> +1

simonstey: can we instead slip into the result a label that it's undefined
... We want to point out that using those sparql features in undefined

TallTed: Because SPARQL has issues, we can't say the result

sandro: make this a moving reference to sparql?

hknublau: except prebinding isn't in sparql at all

<ipolikof> PROPOSAL: Add a syntax rule making SPARQL queries that use certain features outside of {BGP, FILTER, GRAPH, UNION, etc} excluding difficult cases like VALUES, MINUS undefined

<hknublau> +1

<ipolikof> PROPOSAL: Add a syntax rule making SPARQL queries that use certain features outside of {BGP, FILTER, GRAPH, UNION, etc} undefined, excluding difficult cases like VALUES, MINUS

sandro: Doesn't that proposal mean it will be informed

TallTed: nope

ipolikof: syntax rule will just say it's undefined

<ipolikof> +1

<simonstey> +1

<hknublau> +1

<jack_> +1

<TallTed> +1

+1

<Nicky> +1

RESOLUTION: Add a syntax rule making SPARQL queries that use certain features outside of {BGP, FILTER, GRAPH, UNION, etc} undefined, excluding difficult cases like VALUES, MINUS

(failed to scribe discussion of new publication)

<scribe> ACTION: sandro send mail to list about plan to cut off new tests May 25 [recorded in http://www.w3.org/2017/04/19-shapes-minutes.html#action01]

<trackbot> Created ACTION-49 - Send mail to list about plan to cut off new tests may 25 [on Sandro Hawke - due 2017-04-26].

<hknublau> https://www.w3.org/TR/shacl/#DatatypeConstraintComponent

definition of sh:datatype

hknublau: Currently says for datatypes supporte by sp 1.1, impl has to do extra test, BUT this datatypes support by sp 1.1 is not very specific. It's theoretically possible someone might find it ambiguous.
... The term "supported" datatytpes in SPARQL doesn't exist
... so we've got an undefined reference

sandro: sure be nice if we can find a list somewhere

<TallTed> https://www.w3.org/TR/sparql11-query/#operandDataTypes

ipolikof: If SPARQL spec is unclear, ours ends up being unclear

hknublau: I'll see if Andy has thoughts

TallTed: I see a list, but it doesn't incudes dates

simonstey: Did OWL2 have a list?

<simonstey> https://www.w3.org/TR/owl2-syntax/#Datatype_Maps

sandro: Ask Andy what SPARQL's thinking on this was, what the intended list of supported sts was

hknublau: Okay to make edit it I find solution

ipolikof: yes
... Okay, adjourn!

<ipolikof> trackbot, end meeting

This is scribe.perl Revision: 1.152  of Date: 2017/02/06 11:04:15  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Default Present: hknublau, sandro, dimitris, simonstey, Nicky, ipolikof, TallTed
Present: hknublau sandro dimitris simonstey Nicky ipolikof TallTed
Found Scribe: sandro
Inferring ScribeNick: sandro
Found Date: 19 Apr 2017
Guessing minutes URL: http://www.w3.org/2017/04/19-shapes-minutes.html
People with action items: mail sandro send