See also: IRC log
<Dimitris> *are we using webex?*
<Arnaud> no, just zakim
<scribe> scribe: simonstey
<Arnaud> PROPOSED: Approve minutes of the 28 May Telecon: http://www.w3.org/2015/05/28-shapes-minutes.html
<pfps> minutes look OK
RESOLUTION: Approve minutes of the 28 May Telecon: http://www.w3.org/2015/05/28-shapes-minutes.html
Arnaud: next meeting june 11th
ericP: I set up a webex meeting
Arnaud: when do we have to switch to webex?
ericP: we can start using it whenever we want
... we got a meeting number, password etc.
Arnaud: I'm in favour of switching to webex but keep zakim as backup
... there are some limitations/advantages to webex, I think we can switch to webex for the next meeting
ericP: whoever joins first becomes "presenter" in webex
Arnaud: those who use voip may experience better sound quality when using webex and you see who speaks
... unfortunately people have to directly tell zakim that they have joined the call
<ericP> next meeting:
<ericP> https://mit.webex.com/mit/j.php?MTID=m941b5e6540d345fcb389bc371ae7d2fc
<ericP> Meeting number: 640 811 616
<ericP> Meeting password: shapes
<ericP> US Toll Number:+1-617-324-0000
<ericP> Mobile Auto Dial:+1-617-324-0000,,,640811616#
Arnaud: we'll only use webex for the call and still use IRC
... webex info will be on the webpage
<Zakim> pfps, you wanted to ask when tracker is going to get back on track and to
Arnaud: one open action
pfps: when is tracker going be back on track?
Arnaud: no news, but sysguys are already informed
pfps: problem appears to be evident at least since may 21st
hknublau: I've updated the draft (regarding the open issue)
... I didnt coordinate with arthur who is also a coeditor/responsible of the issue
Arnaud: we have a bunch of raised issues which we get back to later
Arnaud: two new stories
... S45 https://www.w3.org/2014/data-shapes/wiki/User_Stories#S45:_Linked_Data_Update_via_HTTP_GET_and_PUT
<ericP> +1
Arnaud: are you ready to approve it? are there any questions?
<Arnaud> PROPOSED: Approve S45: Linked Data Update via HTTP GET and PUT https://www.w3.org/2014/data-shapes/wiki/User_Stories#S45:_Linked_Data_Update_via_HTTP_GET_and_PUT
+1
<ericP> +1
<kcoyle> +1
<Dimitris> -0.5 fine with the idea don;t like sh:hasShape suggestion
pfps: I still dont know what arthur is asking for
... either he is asking for something that is already available or not.. I'm not sure
<hsolbrig> +1
Arnaud: I don't see that as a problem
<Labra> +1
<michel> +1
<TallTed> +1
pfps: as long as user stories are something that is related to stuff the WG is doing, I'm fine
<pfps> +1 assuming that all that a user story is is something related to what the working group is doing, not something all of whose aspects are in scope
RESOLUTION: Approve S45: Linked Data Update via HTTP GET and PUT https://www.w3.org/2014/data-shapes/wiki/User_Stories#S45:_Linked_Data_Update_via_HTTP_GET_and_PUT
Arnaud: S46 https://www.w3.org/2014/data-shapes/wiki/User_Stories#S46:_Software_regression_testing_with_SHACL
<Arnaud> PROPOSED: Approve S46: Software regression testing with SHACL https://www.w3.org/2014/data-shapes/wiki/User_Stories#S46:_Software_regression_testing_with_SHACL
<ericP> +1
<hknublau> +1
<hsolbrig> +1
<kcoyle> +1
<Dimitris> +1
<Labra> +1
<pfps> +1
+1
TallTed: it seems out of scope
<pfps> +1 under the same assumptions, not that SHACL is supposed to be storing the results of validation and checking them later
TallTed: we are talking about defining a shape but what you are doing with the shape is up to you
Dimitris: I want to be able to track how the shape validation developed over time
<TallTed> +1
pfps: sure this has a SHACL component in it but also some stuff that SHACL won't handle
... +1 under the assumption that SHACL won't be responsible for storing the validation results into a db, etc.
RESOLUTION: Approve S46: Software regression testing with SHACL https://www.w3.org/2014/data-shapes/wiki/User_Stories#S46:_Software_regression_testing_with_SHACL
Arnaud: eric added another story
https://www.w3.org/2014/data-shapes/wiki/User_Stories#S47:_Clinical_data_constraints
<Arnaud> PROPOSED: Approve S47: Clinical data constraints https://www.w3.org/2014/data-shapes/wiki/User_Stories#S47:_Clinical_data_constraints
ericP: is about existing clinical systems that have multi-occuring constraints
pfps: maybe eric should add some sentence to emphasize the required features
<pfps> +1 especially as property constraints that don't "exhaust" the property are a reasonable thing
TallTed: the story isn't worded as story, so it needs some reworking
... if it's mockup data prefixes are useless, if it's live data we need some prefixes to get a better understanding
<kcoyle> Ted:could you write that as a comment on the story?
<TallTed> +1 modulo turning it into a story here, and putting the technicalities into the Requirements doc
<ericP> +1
Arnaud: editors will restructure/rephrase the story or may ask you (ted) to rephrase it
<hsolbrig> +1
+1
<hknublau> +1
<Labra> +1
<kcoyle> +1
<Dimitris> +1
Arnaud: ted's point is valid and I will note it in the resolution
RESOLUTION: Approve S47: Clinical data constraints (modulo turning it into a story and putting the technicalities into requirements in the UC&R doc) https://www.w3.org/2014/data-shapes/wiki/User_Stories#S47:_Clinical_data_constraints
<pfps> S48 seems a bit premature
<Arnaud> https://www.w3.org/2014/data-shapes/wiki/User_Stories#S48:_Capturing_precise_business_practices
ericP: S48 captures the point that we sometimes also want to capture business processes
Arnaud: we will postpone S48 to next week
Arnaud: I want to talk about the raised issues
... there are a lot of them and I don't know how much time we should spend on this
... I also want to talk about the way forward (i.e. how we continue working on the spec)
<pfps> open it
<TallTed> +1
RESOLUTION: open ISSUE-51
Arnaud: no objections opening issue-51
<Arnaud> reopen ISSUE-51
<trackbot> Re-opened ISSUE-51.
Arnaud: some of the issues jose raised last week are too abstract, but eric helped to rephrase/edit them
... shall we open them all together or one by one?
pfps: I'm not against opening them but I'm afraid there are some incorrent assumptions in them
... there is no rule by rule algorithm in SHACL
ericP: I call them rules and you call them individual rules
pfps: property constraints want to consume everything for the property
... there is nothing in the highlevel language that handles multi-occurence as you prefer it but maybe the extension can handle it
Arnaud: let us not get to much into technical details here
pfps: you can perfectly write SPARQL that handles that
... (multi-occur.)
<pfps> how about s/core/rdf-encoded/
ericP: I need some way to say "I dont want to have to use sparql to express it" and I think "core" fits well
Labra: I think it's an issue to decide whether or not something has to use an extension mechanism (like SPARQL) to express it or not
<ericP> @pfps: "This is at odds with the "greedy" alogorithm defining the semantics of the SHACL high-level language (core)."?
Labra: I think multi-occurence has to be part of the core language
<pfps> ISSUE-57 says that ShEx has cardinalities over multiple properties, which I don't remember being the case
Arnaud: I would be happy to open all the raised issues at once
<Arnaud> PROPOSED: Open ISSUE-52, ISSUE-53, ISSUE-57-65
<hknublau> +1
<hsolbrig> +1
<Labra> +1
<Dimitris> +1
<kcoyle> +1
<pfps> some of the issues are rather silly, as they talk about things that already have a determination, but that doesn't mean that I'm against opening them
<pfps> +1
+1
RESOLUTION: Open ISSUE-52, ISSUE-53, ISSUE-57-65
<ericP> +1
Arnaud: peter agreed to co-edit the spec (or fragments of it)
... he mentione that the foundation of the spec is split into bits and pieces and he emphasized that we/people may want to have a seperate & concise document that defines SHACL
<hknublau> +q
<ericP> +1 to seperate semantics
hknublau: we have already a file that contains all the detailed information in a sense -> shacl.ttl
<pfps> I don't think that an RDF document is adequate for defining the syntax of anything.
hknublau: but some information isn't captured there, the current document is only compromise
... as a way forward I would suggest to look into the introduction
... and try to find an agreement on the terminology
Arnaud: the sooner we nail down a terminology, we don't have this type of miscommunication while moving forward
... peter wanted to introduce a formal definition in maybe a seperate document
pfps: I'm not saying (in this discussion) that the split into core/extension is wrong but I'm talking about taking out the formal underpinnings of SHACL
... so if someone wants to precisely wants to know something about the formal underpinnings of SHACL he/she could look at a specific section as supposed to have it shattered across the whole document as it is now
... right now we have two definitions of a lot of things (e.g. english definition & sparql translation)
hknublau: the whole document is normative..
... putting the definitions at the end may be redundant
<pfps> I'm not saying that there needs to be more normative stuff. I would prefer less, actually.
pfps: has already complained that he was not able to find specific information in the document
<pfps> I'm willing to put together a table of contents and outline.
Arnaud: peter may propose how this fragment describing the formal definition could/should look like
<pfps> ACTION: pfps to write outline of semantics document fragment [recorded in http://www.w3.org/2015/06/04-shapes-minutes.html#action01]
<trackbot> Created ACTION-27 - Write outline of semantics document fragment [on Peter Patel-Schneider - due 2015-06-11].
Arnaud: ISSUE-65 http://www.w3.org/2014/data-shapes/track/issues/65
... peter's proposal clearly defines the different concepts and we should leverage from that
<Arnaud> https://lists.w3.org/Archives/Public/public-data-shapes-wg/2015Jun/0014.html
pfps: one terminological issue is "what is a shape?"
... in some proposals shapes can have sets of constraints
... e.g. scope: Person, constraint: must have a name, shape: a person must have a name
... but maybe we also need unscoped shapes
<hknublau> +q
<TallTed> "every *representation of* a person gotta have a name" is (might be) a shape def; "every person gotta have a name" is (might be) a class def.
pfps: then we may also need two types of constraints -> the first one will take a focus node where the second one doesn't
constraints without focus nodes are global constraints in holger's proposal aren't they?
hknublau: I agree defining shapes as a scope+constraint+(maybe filters)
<pfps> In my view there are two kinds of constraints, those that run over nodes in a graph and those that don't
<pfps> I think that these two need to be kept separate because they look and act very different.
hknublau: I dont't see how our approaches differ, I suppose that if we have a flexible scoping mechanism people won't have to use global constraints very often
pfps: graphs we get by http put/get are anonymous so the main graph won't have a URI
TallTed: either way, the system has to interact with the graph.. regardless of it being directly referenceable by a name or any other way
(peter&ted are arguing about naming/phrasing issues)
hknublau: we may have to force an invention that a uri has to be created by the system if it's not provided
pfps: we have to disinguish whether a node is supposed to be in the graph or not
Arnaud: I don't know how to make progress on this, any suggestions?
hknublau: we could start with the introduction
... I think we are not fast enough
<pfps> In my opinion, working on particular (aspects of) issues results in slow progress. I think that it is better to work on proposals that embody solutions to a related group of issues.
Arnaud: we have a glossary so maybe we should put definitions there.. but it's up to you
<Arnaud> trackbot, end meeting