See also: IRC log
<ipolikof> scribenick: dallemang
ipolikof: Approve minutes
<ipolikof> PROPOSED: Approve minutes of the 01 Mar 2017 Telecon: https://www.w3.org/2017/03/01-shapes-minutes.html
<ipolikof> +1
<hknublau> +1
dallemang: is it important to change minutes for dallemang being present
<pano> +1
sandro: not importat to change, since dallemang shows up in ballots
RESOLUTION: Approve minutes of the 01 Mar 2017 Telecon: https://www.w3.org/2017/03/01-shapes-minutes.html
+1
ipolikof: agenda: disposal of
isssues. No open issues
... Introduces pfps as special guest
... pfps will explain his objections
<ipolikof> https://www.w3.org/2014/data-shapes/wiki/FO-1:Removing_features_from_node_shapes
pfps: We can do this foromulaic, or to do something good. Which will we do?
TallTed: We are all trying to achieve something successful, with best results
pfps: he can discuss the three formal objections, vs. general problems he sees with working group operation. pfps thinks that the latter is more productive
ipolikof: wants to go through the
objections to understand them.
... and pfps objections were described on a tight deadline
pfps: starting with
https://www.w3.org/2014/data-shapes/wiki/FO-1:Removing_features_from_node_shapes
... removal removes expressive power, further complicates
language,
... lost expressive power threatens future-proofing
ipolikof: to clarify: Loss of expressive power has to do with future possibliity of subject becoming literals?
pfps: Not sure that this is true
ipolikof: was pfps member of that
rdf working group? yes, he was. Did he raise objection to that?
No, that group was chartered for minor changes.
... can you talk about machine generated shapes?
pfps: eg., transform DL into shapes. There is already a commercial system that does something like this. This could use a SHACL engine to run this.
<sandro> (stardog icv)
pfps: Stardog is the commercial
system
... some DLs allow a /self/ role (Stardog doesn't), so /self/
role restrictions turn into node shapes.
ipolikof: can you send us some OWL constructs that cause this issue?
pfps: "at least 2 self Person"
ipolikof: Have you seen this in
practice? (asking about pfps
... have you seen this in practice?
pfps: Yes, at least one widely, OpenCyc in OWL that uses necessarily empty concepts as part of OWL trnaslation
sandro: unconfirmed suspicion is that the loss of power has to do with use of generalized RDF. pfps confirms that he believes this to be the case
<ipolikof> https://www.w3.org/2014/data-shapes/wiki/FO-2:Disjoint_siblings
ipolikof: Next one https://www.w3.org/2014/data-shapes/wiki/FO-2:Disjoint_siblings
pfps: hasn't had enogh time to
look at latest edit
... earliest time to look at it is March 20
<ipolikof> https://www.w3.org/2014/data-shapes/wiki/FO-3:No_requirement_to_reject_graphs_with_invalid_shapes
<sandro> (week of March 20)
move on to https://www.w3.org/2014/data-shapes/wiki/FO-3:No_requirement_to_reject_graphs_with_invalid_shapes
pfps: this page misses the major
point
... The issues is that it is possibe to build a SHACL graph in
such a way that users don't know how they interact with others.
There is no way to know if your grpah is valid or not.
... Rules for validity are difficult - so it is difficult to
know if the graph is valid
... implementations are free to do as they please with invalid
graphs. With no indication back to the user.
... this is fatal to interoperability
... "Usrs of conforming SHACL implementations will have no way
to know if their graphs will be processed the same way in other
implementations"
... this is because even for valid grpahs, they don't know if
they are valid
<sandro> dalleman: This issue sounds clear and valid, but I thought we dealt with this 2-3 weeks ago. Did that get reflected in draft?
dallemang: Didn't we talk about this two or three weeks ago?
pfps: the change was to allow
implemetnations to signal whether it is valid?
... key problem is "allow" - so it might now
sandro: finds this compelling, and of course, we'll stick to valid graphs, but for users, there will be mistakes
pfps: even with expert users we'll have these mistakes
ipolikof: what is the amount of work we'll need to make it happen?
pfps: a one-word change will be
sufficient, i.e., allow -> require
... WG has to write tests so that the implementation can do
this
sandro: invalid shapes definition and tests will be needed
TallTed: Recalls this as a requirement for a linter, akin to the ones we see for RDF and OWL, none of which are required by a SPARQL engine. But Validator is there (instead of the engine)
sandro: HTML5 fixed this by defining repair behaviors (HTML5 had a problem like this)
TallTed: Does this really work on all HTML5 failure mode?
sandro: No, just that this is viewed as an error, and was addressed this way
ipolikof: we have worried that this raises the bar for implementation. Is that unreasonably high?
sandro: maybe a middle ground? The implemetnation is only required to reject the errors that SHACL itself can check (e.g., a shape for SHACL)?
ipolikof: for Core, many things could be checked by SHACL itself (with a SHACL Shape for SHACL)
sandro: presumably this bar is pretty low
pfps: the code to do the check
isn't much, he's done it, two pages of code
... also, it is possilbe to check all of CORE easily, except
sh:pattern be legal SPARQL , and recursive for paths and
shapes, but can be checked with an extension to core that only
takes a small implementation change.
... that is, bar is low
... has sent comments to this effect to the group (can we find
these in our archives?)
dallemang: I think there might be a proposal we could do from this to resolve it.
ipolikof: this is an info gathering call
sandro: There is more going on
here than just allow -> require. There will have to be some
sort of mode, etc.
... strict vs loose for instance
pfps: that was pfps'
proposal
... strict checking is cheap, do ti all the time, but a loose
mode is permissible.
ipolikof: move on to other topics from pfps
pfps: structurat topics. He has
sent into to group that hasn't received responses
... many comments have only received non-technical
responses
... it is the WG's job to respond to comments.
TallTed: WG's job is to wokr, there are lots of kinds of work
ipolikof: regarding pfps' email
about implemnting syntax check
... isn't "thank you for the info" appropriat?
pfps: for this, yes
TallTed: WG is doing its best to keep up with comments, If we aren't keeping up, we need to go to W3C mgmt, who has asked for issues to be triaged
pfps: this is a lot of work for pfps to figure out whether changes to the doc have really addressed a comment.
sandro: can github help us manage this?
pfps: Probably not
... this seems like more burden on the commenter
... sometimes a comments become an issue, and the issue is
closed, but he doesn't necessarilly know how it was closed so
that he can evaluate if it was responsive
sandro: github model keeps a trail for this
ipolikof: this isn't about
checking the WG process, but really about the issues and
comments on SHACL spec as it is now.
... do we need to track all the back issues, or review the spec
as it stands today?
sandro: process from other groups - if an issue was closed, we only raise it again if there is something new
<sandro> PROPOSED: In the transition request, we'll be clear that the door is open during CR for any issues that were previously reported and handled in a way which was not fully reported back to the commenter
pfps: treating the doc as new and looking for issues again is difficult for reviewers, and risks dropping issues through the cracks
<TallTed> +1
<sandro> +1
RESOLUTION: In the transition request, we'll be clear that the door is open during CR for any issues that were previously reported and handled in a way which was not fully reported back to the commenter
<sandro> pfps: Or in status of document
+1
<pano> +1
pfps: pre-binding has been and
continues to be a problem, is it well-behaved?
... it isn't his job to convince anyone that it works, since
pfps isn't a pre-binding advocate.
ipolikof: Andy Seaborne is not on the call today, who could respond to this.
TallTed: This is an early release, and the process is iterative
ipolikof: Andy is a recognized expert in SPARQL
pfps: reluctantly agrees
... we need someone who can review Andy's work
sandro: there's an academic idea
of "peer review" - e.g.,, three reviewers for any item.
... this process is less than that.
pfps: pre-binding has had many
iterations, and required shouting from pfps to get any
attention at all.
... pre-binding history: SHACL wanted pre-binding, and said
"use SPARQL", but the SPARQL spec didn't have details of the
meaning, so we couldn't find out what it means.
ipolikof: if this objection were raised for SPARQL, would it have made it to CR?
pfps: there is no implementation of SPARQL
ipolikof: but it is successful and there are many implementations
pfps: here are probably ways to
fix it up, and Andy could do that.
... what will we do if a problem is found?
ipolikof: personal opinion, if
SHACL reaches the success level of SPARQL, she's happy, hope
for even more success
... that would address industry needs. Maybe not perfect.
pfps: WG can move ahead with this
unknown
... Another topic. Validation Reports
... made an earlier objection, and sees that the pendulum has
swung the other way
... it will be possible to produce validation reports that vary
from the expectation.
... suspects that there are issues, but he hasn't had time to
find it.
... WG could deicde to wait for pfps , which won't be for a few
weeks
sandro: checking against the test suite will reveal problems
pfps: assuming that test suite can check it, which is hard
ipolikof: test suite will include validation report
<sandro> If the test suite compares validation reports, this problem should be addressed
pfps: if writing the tests reveals the issue, then we make a new CR at that level
sandro: has the WG resolved that the test suite should include validation reports ?
ipolikof: No formal resolution. OPTIONAL things might not be in
hknublau: test harness checks output graph isomorphism between output and expectation
pfps: not sure that graph
isomorphis is correct test
... we have to include "we will check validation reports as
part of the test"
sandro: are you asking for something beyond standard requirement, that if two people implement to the spec, then they can interoperate?
ipolikof: W3C director has a lower bar - need a test suite, needs to be reasonable, might not be comprehensive
<sandro> sandro: Every normative statement in the spec should result in 1+ tests
pfps: every normative statement
should have something backing it up
... end of major things, he's concerned with syntax
... current syntax is mystifying
... disjoint shapes is worrisome
... theres still a lot of work to be done, and this is nobody's
day job.
ipolikof: misalignment between
pfps' expectation and WG process, and even W3C process
... time is up. to sandro is there any urgent process
issue/
sandro: internationalization email
ipolikof: i think that was good
<TallTed> 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, Dimitris, ipolikof, dallemang, pano, sandro, TallTed, Nicky Present: hknublau Dimitris ipolikof dallemang pano sandro TallTed Nicky Found ScribeNick: dallemang Inferring Scribes: dallemang WARNING: No "Topic:" lines found. Found Date: 08 Mar 2017 Guessing minutes URL: http://www.w3.org/2017/03/08-shapes-minutes.html People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option. WARNING: No "Topic: ..." lines found! Resulting HTML may have an empty (invalid) <ol>...</ol>. Explanation: "Topic: ..." lines are used to indicate the start of new discussion topics or agenda items, such as: <dbooth> Topic: Review of Amy's report[End of scribe.perl diagnostic output]