<Jack_> I cannot dial in on audio

Jack_, are you saying webex isn't working, or you're not able to be on the phone right now?

<Jack_> It 'did' let me in, but I heard no one speaking so I hung up and tried again, and now I cannot get to the passcode. I'll try a cell phone.

<scribe> scribe: sandro

<TallTed> scribenick: sandro

<TallTed> PROPOSED: Approve minutes of the 03 May 2017 Telecon: https://www.w3.org/2017/05/03-shapes-minutes.html

<hknublau> +1

<ipolikof> +1

<Jack_> +1

<TallTed> +1

RESOLUTION: Approve minutes of the 03 May 2017 Telecon: https://www.w3.org/2017/05/03-shapes-minutes.html

TallTed: Likely regrets on the 24th

Open Issues: https://github.com/w3c/data-shapes/issues

ipolikof: The Commenter-Not-Satisfied issues are all formal objections, linked

TallTed: Tag for FO?

sandro: not necessary, given the small number overall
... let's close these if-and-when we're settled we don't plan to work on it more

Formal Objections: https://www.w3.org/2014/data-shapes/wiki/Formal_Objection_Status

ipolikof: Do we need prfo0 ?

TallTed: Is saw Peter said he'd withdraw it if we'd consider / vote to accept new ones

ipolikof: But that sounds like what we originally said, doesn't it?

<TallTed> https://lists.w3.org/Archives/Public/public-rdf-shapes/2017May/0019.html

ipolikof: Maybe we should ask him to clarify on this?

TallTed: It was in the minutes. Maybe there's a page we need to update.
... Who wants to followup with Peter

ipolikof: I'll do it

<TallTed> moving on to https://www.w3.org/2014/data-shapes/wiki/PRFO1

ipolikof: Peter labels it 'interoperability'. He wants this mode of checking
... I didn't see any new information since CR objection, except Peter's saying it doesn't check everything, but that's known

TallTed: I think different results from different engines does not conform to my idea of interoperability

ipolikof: "Lack of syntax-checking mode"

<Jack_> that does seem like what he is saying

hknublau: We can continue to say everyone's free to check their shapes graph; this can be tested beforehand by the tool of your choice

TallTed: This is about invalid shapes graph's producing different results.

ipolikof: Right. Shacl-for-shacl checks most of these.

sandro: What is Peter expecting different from the Director?

ipolikof: Sh4sh doesn't check everything

sandro: But the Director understood that perfectly well

ipolikof: I told him that.

sandro: Sounds to me like there's not much more we can do on this

TallTed: Sounds like there's nothing new we can do here

<TallTed> TallTed: I think PRFO1 has already been addressed to Director's satisfaction, even if imperfect

sandro: Possible Peter just raised it again to get it in front of the W3C Advisory Committee again

<TallTed> onward to path syntax - https://www.w3.org/2014/data-shapes/wiki/PRFO2

ipolikof: Peter wrote the original Path rules, oddly

hknublau: I think we've done what we can. Peter gave us two test cases, of edge cases, where things that look like paths are lists. But I think we've taken this as far as we can and need to agree to disagree.

TallTed: So we believe it's handled by the testing

ipolikof: Peter says shapes are too strict because users may want to put in comments, but sh4sh checks this. No evidence of lack of functionality.
... also, one path that users may misinterpret
... but there are tests that prove impls don't misinterpret

sandro: Peter's proposal?

ipolikof: He offered new rules, but it's late in the game, and we don't have experience with the new rules. The current ones have been stable for months.
... the issue seems minor, and the remedy seems risky. It would require new tests...

TallTed: new CR

sandro: Would his new rules require impls to change? If not, probably not new CR

ipolikof: Illformed might not be illformed. Not sure.

TallTed: That makes this seem like a 1.1 or 2.0 feature

sandro: I'm hearing a sense that this isn't terribly important
... We could ask Peter for more compelling use case

<TallTed> PROPOSAL: Lacking a compelling use case, the WG feels that this incremental improvement is suitable for SHACL 1.1/2.0, but is not necessary for SHACL 1.0.

<ipolikof> +1

<hknublau> +1

hknublau: People can put native comments into turtle or xml file

<pano> +1

<simonstey> +1

ipolikof: I could add this to postponed features

hknublau: I think this problem is too small to merit that

<TallTed> +1

RESOLUTION: Lacking a compelling use case, the WG feels that incremental improvement in PRFO2 is suitable for SHACL 1.1/2.0, but is not necessary for SHACL 1.0.

<Jack_> +1

(That resolution is about PRFO2, Property Path Synax objection)

aka https://github.com/w3c/data-shapes/issues/75

<TallTed> PROPOSED: WG feels that PRFO1 was addressed sufficiently in its prior incarnation as CRFO2.

<hknublau> +1

<ipolikof> +1

<Jack_> +1

<simonstey> +1

+1

<TallTed> +1

RESOLUTION: WG feels that PRFO1 was addressed sufficiently in its prior incarnation as CRFO2.

<TallTed> by request, skipping ahead to SHACL definition of pre-binding - https://www.w3.org/2014/data-shapes/wiki/PRFO4

hknublau: The bulk of PRFO4 is that we're painting over the problems
... but this is the best solution we've got so far; Peter's suggestion didn't help

<hknublau> http://w3c.github.io/data-shapes/shacl/#pre-binding

hknublau: He asked one detail yesterday
... this is the current defn in draft
... a couple of syntax rules, then four blue boxes. This was all copied from Andy Seaborne's work for sparql CG.
... When I looked at this, thinking about Peter's comment, I noticed that these two blue boxes can be deleted, as obsolete by last weeks clarification about returning all variables
... but this text was written to handle the case that doesn't happen any more

<simonstey> +q

hknublau: so this should address Peter's most recently found problem
... the defn was only for subselects, but it turned out it would also be allowed to top level select, which was never the intention
... some examples in document do not align with this defn, and he's right, this is a glitch
... because of our copying it from SPARQL
... we can just delete the first two blue boxes, about Variable Remapping
... and the remaining two, replace PrjMap(E) with E
... so this should solve glitch
... it was only for the case where subselect didn't project out all the variables, but now we've said all subselects much return all prebound variables
... SPARQL CG needs this more complex solution, because they can't just exclude syntax like we can

<simonstey> +q

simonstey: In defn values insertion, replace x, I was wondering if this X is the same as in remapping -- or is this a different X? Is it an algebraix expression?

<TallTed> PROPOSED: Address PRFO4 with editorial correction to Appendix A, delete "DEFINITION: Projection Expression Variable Remapping" and "DEFINITION: Variable Remapping" which were only required for sub-selects which did not project all variables, because we already require all variables be projected by such sub-selects. Examples and tests already carry intent, which is then correctly conveyed by remainder of Appendix A.

hknublau: No, it's another one. He's defining a new function, and X is just the formal parameter, an algebra object

<hknublau> +1

<simonstey> +1

<TallTed> +1

<ipolikof> +1

<Nicky> +1

+1 makes sense, at my level of understanding

<pano> +1

<Jack_> +1

<hknublau> https://github.com/w3c/sparql-exists/commits/gh-pages

<simonstey> thx

RESOLUTION: Address PRFO4 with editorial correction to Appendix A, delete "DEFINITION: Projection Expression Variable Remapping" and "DEFINITION: Variable Remapping" which were only required for sub-selects which did not project all variables, because we already require all variables be projected by such sub-selects. Examples and tests already carry intent, which is then correctly conveyed by remainder of Appendix A.

TallTed: We owe thanks to Peter for this improvement

<TallTed> and the last, "SHACL syntax rules make certain shapes ill formed" - https://www.w3.org/2014/data-shapes/wiki/PRFO3

hknublau: Now fixed in http://w3c.github.io/data-shapes/shacl/#pre-binding

PRFO3

ipolikof: He doesn't like syntax restrictions

hknublau: No loss of expressive power, because we have workarounds

<simonstey> +q

ipolikof: and all of this is checked in sh4sh

simonstey: Especially for this case, this is a prime example of where sh:and is useful/required.
... You need to kind of catch with this workaround. A perfect example of why we included sh:and, so you can express something like that. If we allowed multiple minCounts
... and maybe in other scenarios, ...
... I don't feel that this is like that, this is a scenario where you need sh:and. It's a stronger argument, rather than just saying it's a workaround

<TallTed> PROPOSED: Lacking a real-world use case which cannot be addressed by SHACL as currently defined, WG feels that PRFO3 was addressed sufficiently in its prior incarnation as CRFO1.

ipolikof: I agree. The example he provided, xsd:int and xsd:integer, they probably meant *either*, and for that case we have sh:or

<hknublau> +1

<simonstey> +1

<pano> +1

<Nicky> +1

<Jack_> +1

<ipolikof> +1

<TallTed> +1

RESOLUTION: Lacking a real-world use case which cannot be addressed by SHACL as currently defined, WG feels that PRFO3 was addressed sufficiently in its prior incarnation as CRFO1.

Features At Risk

TallTed: Okay to extend meeting? Hearing no objection....
... Given test results, two green for everything, I thing we can keep the At Risks

ipolikof: SHACL-SPARQL with two impls seems okay

TallTed: ToDos?

hknublau: Old thing from Arnaud, given no feedback on this, I'd say we just leave it as it is

<TallTed> https://www.w3.org/TR/shacl/#constraint-components-validators

hknublau: Let's just remove the red sentence

TallTed: Sure, that's editorial

sandro: agreed

<TallTed> TallTed: All Features at Risk have 2 implementations! No more risk!

hknublau: Re lessThan-scope syntax rules (generalized RDF) -- came out of discussion with Tim
... he wanted to keep this more open, and we're okay with that
... It's not possible to write a test case for this, so I'd like to remove the at-risk, keeping the rule

ipolikof: Removing the "At Risk", and keeping the feature.

sandro: Can't be tested because none of platforms supports generalized RDF?

ipolikof: Right

sandro: I'm a fan of generalized RDF, but this seems like a pretty tiny bit.

simonstey: Maybe remove At Risk but add sentence about the future

sandro: Why not remove syntax rules?

hknublau: Suddenly this property will show up on forms, where it's allowed. Impls will have to handle it, even if it can't occur

sandro: But in a non-general RDF system it can't occur, so no need to check it

ipolikof: If you allow people to create just shapes, then you have to do something with them.

hknublau: I don't get how this use case is of interest, a literal having a property of another literal, ....

sandro: Is this because they're constant?

hknublau: that value of lessThan is a property, so if you say in a shape that it has a lessThan relationship to some property, then it means the subject must be less than the value of that property
... the original use case was about startDate alsways before endDate
... which is perfectly fine for Resources
... but does a Literal have a start date

Pano: Maybe in the case where graphs are reified? That's a case where a literal might have a start date?

sandro: Let's go the way hknublau is suggesting, and see if the Director pushed back. None of us cares strongly, but we don't see the motivation.

<TallTed> PROPOSED: remove At Risk on all features

<ipolikof> +1

<Jack_> +1

<TallTed> +1

<simonstey> +1

<pano> +1

+1

<Nicky> +1

<hknublau> +1

RESOLUTION: remove At Risk on all features

Next Steps towards PR

sandro: no need to keep anything in draft for historical, just make it what makes sense to new readers

<TallTed> PROPOSED: submit Transition Request for PR

<ipolikof> +1

+1

<TallTed> +1

<pano> +1

<Jack_> +1

<simonstey> +1

RESOLUTION: submit Transition Request for PR

<Nicky> +1

<hknublau> +1

<hknublau> * even later

sandro: I'll send out transition request and scheduling poll.

<TallTed> barring objection -- ADJOURNED!

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)

Succeeded: s/this incremental improvement/incremental improvement in PRFO2/
Succeeded: s/PROPOSED: Editorial/PROPOSED: Address PRFO4 with editorial/
Succeeded: s/Jack_/Pano/
Present: TallTed Jack_ simonstey_ ipolikof sandro hknublau pano Nicky
Found Scribe: sandro
Found ScribeNick: sandro
Found Date: 10 May 2017
Guessing minutes URL: http://www.w3.org/2017/05/10-shapes-minutes.html
People with action items: