See also: IRC log
<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
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
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.
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
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:[End of scribe.perl diagnostic output]