See also: IRC log
<Arnaud> trackbot, start meeting
<hknublau> scribenick: hknublau
We should try to look at some of the big tickets in this meeting.
<Arnaud> PROPOSED: Approve minutes of the 9 Nov 2016 Telecon: http://www.w3.org/2016/11/09-shapes-minutes.html
<simonstey> +1
RESOLUTION: Approve minutes of the 9 Nov 2016 Telecon: http://www.w3.org/2016/11/09-shapes-minutes.html
Arnaud: Next week regular meeting again.
... depending on progress today, we should schedule more longer meetings in the coming weeks
Arnaud: CR status is the big goal; test suite; user-friendly syntax
Arnaud: Next publication could be CR, although this sounds bold
... Key is to claim we have closed all our issues and had wide review.
... there should not be a wide delta between previous draft; for this reason we want to republish another draft before CR
... Test suite is required, because CR is also a call for implementations
... We don't need a complete test suite but we do need framework, so that spec can point for test suite
... and tests can evolve over time.
... On public comments: since there is no more Last Call it is less clear when we are required to follow a formal response process
... however, we should do our best to respond
<simonstey> https://www.w3.org/2015/Process-20150901/#doc-reviews
Arnaud: also to document that we do have feedback, although technically there is no requirement to respond to all of them.
... of course we don't need to agree on the comments
<ericP> hknublau: how about if we have a way for the WG to check diffs
simonstey: I agree, I think we need such a mechanism.
<Dimitris> I also agree
<Zakim> ericP, you wanted to propose a little mechanism behind hknublau's proposal
simonstey: so that we close public email threads that ask for WG support.
ericP: The editors could also provide pointers to the most interesting changes.
+q
hknublau: everyone should review the changes on a weekly basis
Arnaud: reasonable to put this on the agenda each week.
... any disagreements?
... I want to encourage Karen to raise formal issues on the comments
kcoyle: I can do that.
<Dimitris> I can
ericP: Hint: Ask commenters to prioritize issues
Arnaud: We are running out of runway, technically until June 1st 2017
... there is minimum amount of time that we need to grant reviewers and implementers
... we need to be "done" by end of Feb/March.
... and holiday season doesn't help.
... will be very hard to get an extension. If we were in CR and have implementers, we could reasonably ask for extension.
Arnaud: We have the framework from last year, we have ShEx tests that could be converted, and Holger's test suite
ericP: Status on ShEx tests
... Updated tests for changes to sh:datatype
... Big issue, converting from ShEx to SHACL. Depends on partition topic.
... and we requested changes to stem.
... We don't have target-based tests, use parameters directly.
hknublau: we do have a test format, which is integrated with TopBraid, but let's just continue with the format that we defined next year.
Arnaud: Initially "anyone" can add tests and later they will be stabilized and approved.
<simonstey> https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Nov/0039.html
<Zakim> ericP, you wanted to say that in SPARQL, folks would upload contradictory tests and the WG would mark one (hopefully) "approved"
ericP: In SPARQL WG, people submitted contradicting tests to clarify semantics.
<simonstey> +1
<Dimitris> +1
hknublau: Old tests should be discarded, but we keep the format
Arnaud: Which format to use?
ericP: We have manifest files, Holger's format doesn't use/need them.
... manifest provides metadata such as what kind of test we have
... manifest may be compatible with what we have in ShEx
hknublau: TQ's format can also represent metadata, but I don't want to start controversies on the details of the format.
Arnaud: Eric should stabilize the test format and then have Eric and Holger to contribute their (converted) tests.
<ericP> ACTION: ericP to review test suite and compare with shex tesst suite [recorded in http://www.w3.org/2016/11/16-shapes-irc]
<trackbot> Created ACTION-47 - Review test suite and compare with shex tesst suite [on Eric Prud'hommeaux - due 2016-11-23].
<kcoyle> scribenick: kcoyle
Arnaud: background: would possibly use ShEx as basis for compact user-friendly syntax
... partitions key to alignment of shex and shacl
ericP: Yes, alignment is possible & a good idea
... looking at where "or" allowed in shacl
... Jose is working on translate from shex to shacl; this means there is a test suite for the two
<ericP> shex spec
ericP: would like to publish shex spec as FPWD, get it out there for review
Arnaud: Technically there is a version as a starting point, but was not an editor's draft
... so should be offered to group to review
hknublau: eric described features needed for shacl to create compatibility; but shex needs to cover all aspects of shacl core
Arnaud: may not have a mandate to cover all aspects
ericP: shex says that targets are separate from shex;
... not clear if target* of shacl is needed
... thre is a feature in shex that allows you to have unique keys, e.g. for literal with only one language code
... suggest publish was exists, then add to make compatible
Arnaud: proposal is to make shex a working draft
<Arnaud> PROPOSED: accept ShEx as an Editor's draft
Dimitris: making it a draft is a good idea; but have to align them or it will be difficult for users, esp. conjunction/disjunction
Arnaud: yes, probably need to add a section explaining the document
Dimitris: what is there must be consistent, even if some features are missing
ericP: and, or, unary are all the same; n-ary target constraints and repeated groups will need to be translated well
Arnaud: alignment will either extend shacl or reduce compact syntax
+1
<simonstey> +1
<ericP> +1
<Dimitris> +1
<TallTed> +1
<Arnaud> PROPOSED: accept ShEx as an Editor's draft
hknublau: this is compact syntax, not shex itself?
<ericP> ShEx Spec
hknublau: publishing this draft would just be confusing
<hknublau> -1
ericP: shex exists and is being used in practice
... will we uncloak within this group, or separately?
TallTed: this is a not uncommon kind of end-run that you (eric) have done before
... inappropriate to make this w3c without going through process
... should follow how json-ld was brought in; more work needs to be done
Arnaud: it's not like we haven't known about shex all along; maybe should have been brought sooner
... not sure what the 'right process' is - put it in realm of working group and give the group a chance to work on it
TallTed: this is not being presented as: this is for your consideration; my understanding is that shex does not fit
... not in the charter
Arnaud: Holger says there is too much in this document, so what should be removed?
... process is that spec needs to be brought into working group as an editor's draft
ericP: we tried to do this within the group
Arnaud: it would be a shame if shex were standardized outside of w3c; we were trying to accommodate both views
... analogous to relax ng within xml - so now there are both, which isn't a bad thing, but w3c lost having the relax ng spec
hknublau: We decided 1.5 yrs ago that we are not using shex. all we need to do is describe a compact syntax
ericP: should shex go someplace else?
hknublau: yes
Arnaud: This is not making shex a competitor to shacl;
TallTed: in the context of this working group, there is nothing in here that references shacl - so how do they align? or are they separate?
<ericP> ShEx-to-SHACL
Arnaud: that is the work that needs to take place; the abstract syntax (kcoyle and ericp) and the shex to shacl
... we don't want the two to be in isolation from each other; now they are separate and shex is not visible as a wg product
... this mainly format/style. note that we have worked to align them, e.g. with partition
marqh: question: is it a fair comment that shex is a partial implementation?
ericP: there is a large intersection; if we put in partition then shex is a nearly complete intersection with shacl
... the big difference is the extension mechanism
... also stems in value sets
marqh: if wg is developing standard for shapes, is it reasonable to publish a relationship between shex and shacl, with shacl being the standard?
ericP: i... think.... so.... um
... if the semantics are all captured in ... nope, unsure
Arnaud: my mental model is the other way around; you can implement shacl with shex
<scribe> ... done through abstract syntax
UNKNOWN_SPEAKER: what matters is if mapping works
... if we don't want the layering, then it isn't clear what we're doing
hknublau: if shex is an implementation of shacl, (but not vice versa) - then all we need is the compact syntax
TallTed: with that flavoring, if shex can be described as an alternative - as a different user-friendly language
... but with shacl as the primary point, then that allays many of my fears
... right now it looks too independent
ericP: shacl has evolved a lot; it began as a set of spin-like rules. It has become more of an 'how things work' document
... shex has a lot to offer to shacl
<ericP> kcoyle: i've not seen a side-by-side comparison of ShEx and SHACL.
<ericP> ... without seeing that, i don't know whether ShEx is a human-friendly representation of SHACL
<ericP> ... until we see that, it's hard to have a real opinion
<ericP> ... could we be presented with something that shows how it interacts with SHACL
Arnaud: with sympathy for eric - we can't ask him to do too much
... leave it at this for today and give people a chance to look at documentation
... eric to send message to group
***break for 5***
back
<Dimitris> scribenick: Dimitris
<Arnaud> PROPOSED: open ISSUE-195 and ISSUE-196
hknublau: (about issue 195) is just to update rdfs:comments, maybe even drop them and keep only labels
<hknublau> +1
<ericP> +1
+1
<simonstey> +1
<kcoyle> +1
<pano> +1
RESOLUTION: open ISSUE-195 and ISSUE-196
<TallTed> +1
<Labra> +1
<simonstey> issue-196
<trackbot> issue-196 -- Should we delete filter shapes? -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/196
Arnaud: there is a very concrete proposal from Holger to delete filter shapes, let's discuss this idea now
... that would indeed simplify the model after all the discussions we had
... does any other wants or uses filter shapes or have problems with dropping them?
<ericP> +q to dropping filter shapes
<ericP> +1 to dropping filter shapes
hknublau: filters are just syntactic sugar for an OR / NOT, it is only a convenience feature but a very expensive one
+1 from me as well
arnaud: what is sh:disabled?
hknublau: it disables some shapes. It can be for reusing other shapes but disabling / deactivating some constraints
... means that all focus nodes will be valid
<simonstey> +q
simonstey: currently, how would removing filter shapes change the language?
hknublau: currently you cannot deactivate a constraint
simonstey: not sure if this should be part of SHACL or implementation specific
hknublau: not interoperable
kcoyle: spec does not specify processing to say how one can turn things off
hknublau: we define what validation is, I only propose a minor change
kcoyle: I am lacking the motivation for that feature
<hknublau> +q to say that you can achieve this via a custom target
tallted: does not see a motivation for eliminating filters
<simonstey> +q
Dimitris: filters are useful but we are out of time
<Zakim> hknublau, you wanted to say that you can achieve this via a custom target
Dimitris: sh:ignore can be useful for testing shapes
hknublau: custom targets are far more efficient for selecting specific nodes
<hknublau> straw poll?
<Arnaud> STRAWPOLL: Delete filter shape and instead, add a boolean flag sh:disabled which (if true) means that a shape or constraint is ignored.
<hknublau> +1
+1
<Labra> +1 for deleting filter shape, 0 for the boolean flag
<kcoyle> ted, the graphic has been removed
<kcoyle> +1 delete filter, 0 for flag
<Arnaud> PROPOSED: Close ISSUE-196, deleting filter shape and instead, adding a boolean flag sh:disabled which (if true) means that a shape or constraint is ignored (i.e., any node is considered conforming/valid).
simonstey: we need to define how sh:ignored is defined in referenced shapes (sh:shape, sh:or, ...)
<hknublau> +1
<TallTed> +0.7
<pano> +1
+1
<kcoyle> +.5
<simonstey> +0.5
<Labra> 0
<ericP> +1 filter, 0 for flag
<Labra> my 0 was for the flag..., +1 for deleting filterShape
RESOLUTION: Close ISSUE-196, deleting filter shape and instead, adding a boolean flag sh:disabled which (if true) means that a shape or constraint is ignored (i.e., any node is considered conforming/valid).
<simonstey> issue-185
<trackbot> issue-185 -- Processing order for filters and constraints -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/185
<simonstey> issue-192
<trackbot> issue-192 -- Should filter shapes be of type sh:Shape? if not, then what? -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/192
<Arnaud> PROPOSED: Close ISSUE-185 and ISSUE-192 as now irrelevant
<simonstey> +1
+1
<hknublau> +1
<TallTed> +1
<ericP> +1
<Labra> +1
<kcoyle> +1
RESOLUTION: Close ISSUE-185 and ISSUE-192 as now irrelevant
<simonstey> issue-92
<trackbot> issue-92 -- Should repeated properties be interpreted as additive or conjunctive? -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/92
<hknublau> Makes little sense to discuss now, and the proposal is incomplete
arnaud: based on the previous discussion let's see what's the status here
... Arthur started this and Eric continue working on this
ericP: I am working on the partition proposal, no updates yet
... will nee to see about different ORs in the spec
<TallTed> issue-180
<trackbot> issue-180 -- Should IRI paths always be interpreted as predicates? -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/180
hknublau: That's a detail about the path syntax
... there were various complications in the design when a node is an IRI, it could be property or e.g. an inverse path etc
... the suggestion is that all nested paths must be blank nodes otherwise it will be treated as a property
kcoyle: I'd like to hear from ShEx if this affects them
ericP: it doesn't
<Arnaud> PROPOSED: Close ISSUE-180, accepting Holger's proposed changes (in the issue description)
<hknublau> Proposal is basically all IRI paths are counted as PredicatePaths, i.e. all complex paths such as inverse paths must be blank nodes.
<hknublau> +1
+1
<kcoyle> 0
<Labra> 0
<simonstey> +1
<TallTed> +0
RESOLUTION: Close ISSUE-180, accepting Holger's proposed changes (in the issue description)
<hknublau> Proposal for ISSUE-186 is in https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Oct/0040.html
<Labra> * I am leaving for 20 mins
kcoyle: I agree to close them (98% sure these are all)
<TallTed> +1
<Arnaud> PROPOSED: Close ISSUE-186, adding new properties as proposed by Holger in https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Oct/0040.html
+1
<kcoyle> +1
<hknublau> +1 (and if someone finds other duplicates, let's treat them in the same way)
<simonstey> +1
<ericP> 0
RESOLUTION: Close ISSUE-186, adding new properties as proposed by Holger in https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Oct/0040.html
<ericP> issue-189
<trackbot> issue-189 -- Clarify validation report trigger in section 3 -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/189
<hknublau> Voting really early, +1
<TallTed> +1 with sh:conforms
<Arnaud> PROPOSED: Close ISSUE-189, adopting Dimitris and Karen's proposal: https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Nov/0051.html
<ericP> +1
<hknublau> +1
<kcoyle> +1
+1
<simonstey> +1
<TallTed> +1
RESOLUTION: Close ISSUE-189, adopting Dimitris and Karen's proposal: https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Nov/0051.html
<Arnaud> issue-188
<trackbot> issue-188 -- "Validation" needs to be defined -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/188
kcoyle: validations was used for the process and the result.
<TallTed> https://github.com/kcoyle/data-shapes/commit/bb301ef1b942a0773c45f7cb4c30b7ff9726db3a
kcoyle: two solutions: use successfully validates or conforms
<hknublau> +1 to conforms
<TallTed> +1 conforms
+1 to conforms as well
have to leave apologies can someone scribe?
<simonstey> scribenick: simonstey
simonstey: also +1 to conforms
<kcoyle> simonstey: valid and conforms are two different things
Arnaud: people seem to be happy with conform
<kcoyle> PROPOSED: replace instances of "validates" meaning "is true" with a version of the verb "conforms"
+1
Arnaud: we can iterate over this if necessary
<hknublau> +1
TallTed: shouldn't we change validation report to conformance report?
... might be an overkill though
kcoyle: it would require a lot of changes to the spec
Arnaud: maybe we should mention somewhere that if something is found to be valid it means it is conformant (or alike)
<kcoyle> +1
<Arnaud> PROPOSED: Close ISSUE-188, replace instances of "validates" meaning "is true" with a version of the verb "conforms"
<hknublau> +1
<kcoyle> +1
<TallTed> +1
<ericP> +1
kcoyle: when I raised that issue I wanted to address the fact that validation was used differently throughout the spec
+1
RESOLUTION: Close ISSUE-188, replace instances of "validates" meaning "is true" with a version of the verb "conforms"
hknublau: kcoyle, you started a branch working on that.. is it ready to be merged to master?
kcoyle: not quite ready yet
... it's "conforms to"
<Arnaud> issue-68
<trackbot> issue-68 -- pre-binding not defined in SHACL spec -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/68
Arnaud: meanwhile there was an email from peter discussing prebinding; mentioning we could get rid of it alltogether
hknublau: it wasn't about getting rid of prebinding
... sparql queries would have to return a value that is then compared
... andy is working on a proposal
Arnaud: could you elaborate on why you and Dimitris think peters proposal isn't optimal?
hknublau: [explains issues]; holger will follow up
Arnaud: any other open issues we want to discuss?
hknublau: maybe we want to consider closing issue-176
<Arnaud> issue-176
<trackbot> issue-176 -- Should SHACL include a (simple) rules feature -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/176
<Arnaud> PROPOSED: Close ISSUE-176 due to lack of time
hknublau: and leave it up for future groups to follow up on that
<Arnaud> PROPOSED: Close ISSUE-176 due to lack of time and out of scope
-0
<hknublau> 0
<kcoyle> +1
<ericP> +1
<TallTed> +0 postponed to SHACL 1.1 a/k/a 2.0 or whatever...
<TallTed> or perhaps "can be handled via extension mechanism..."
<hknublau> +1
<hknublau> +q
Arnaud: one thing we can do is making a wiki page listing all the features that didn't make it in to the spec
... but may be included in the future
hknublau: shouldn't we "reserve" certain keywords? e.g., sh.rule (other languages do that)
ericP: the one who owns the ns document also owns those properties
RESOLUTION: Close ISSUE-176 due to lack of time and out of scope
Arnaud: I would be more comfortable if we would already know that we are going to work on something like SHACL 2.0
issue-187
<trackbot> issue-187 -- sh:severity and sh:message are not defined as shapes graph properties -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/187
kcoyle: it's about not being able to set severity/message in the shapes graph
hknublau: I'm not really sure.. maybe this issue was already resolved earlier
... it was resolved after issue-178
<Arnaud> PROPOSED: Close ISSUE-187, as resolved as part of ISSUE-178
issue-178
<trackbot> issue-178 -- Should sh:message be permitted at constraints, too? -- closed
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/178
<hknublau> +1
<kcoyle> +1
+1
<TallTed> +1
<ericP> +1
RESOLUTION: Close ISSUE-187, as resolved as part of ISSUE-178
Arnaud: anything else we can tackle now?
issue-194
<trackbot> issue-194 -- stems in value sets -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/194
ericP: motivation was that value sets are tedious to enumerate
... value sets have either values, a stem, or an exclusion of stems (?)
... at some time we added sh:stem to SHACL
<hknublau> +q
ericP: but sh:stem doesn't reflect the intended meaning of stems
... as used in shex (?)
hknublau: afaik, it's syntactic sugar and doesn't add additional expressivity
... my proposal would be to put that into the mapping of the compact syntax
kcoyle: I'm doing my usual call for examples
ericP:
<Zakim> ericP, you wanted to propose removing the Stem Parameter
<ericP> https://w3c.github.io/data-shapes/shacl-abstract-syntax/shex-to-shacl#h-object-values
kcoyle: what makes those stems?
ericP: [explaining the examples]
<hknublau> +1 to deleting sh:stem
kcoyle: what would it look like as a value set value?
Arnaud: two proposals on the table
... removing sh:stem and adding it to value sets
... just removing sh:stem
ericP: right now you could not put a sh:stem inside a sh:in
Arnaud: I don't want us to get rid of stuff if there are use cases depending on it
<Arnaud> https://www.w3.org/2016/04/07-shapes-minutes.html#resolution02
<Arnaud> https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Mar/0311.html
[explaining that sh:or&sh:pattern would need to be used if sh:stem was to be removed]
ericP: my second proposal matches the one from the email but with "s/values/in/"
hknublau: I actually didn't understand the proposal back then
... as I understand it now
... and I agree that the spec doesn't match the resolution we made back then
TallTed: there is more to the email thread -> more discussions
<kcoyle> https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Mar/0315.html where I ask about "or"
Arnaud: we have to look into the change history of the spec
... we may leave this issue for now
... and holger tries to figure out what happend
hknublau: it's a complex feature, we may want to consider the resolution we made wrt. it
Arnaud: I think we should have a similar meeting soon
hknublau: why not next week?
<kcoyle> ok by me
Arnaud: we could extend next meeting to two hours?
... half an hour earlier?
hknublau: maybe we should make that a permanent thing
<Arnaud> PROPOSED: make calls 2h, starting at 8am Eastern
+1
<hknublau> +1
<TallTed> +0.5
<kcoyle> +1
<Dimitris> +1
RESOLUTION: make calls 2h, starting at 8am Eastern
<Arnaud> trackbot, end meeting