12:58:52 <RRSAgent> RRSAgent has joined #shapes
12:58:52 <RRSAgent> logging to http://www.w3.org/2016/11/30-shapes-irc
12:58:54 <trackbot> RRSAgent, make logs rdf-data-shapes
12:58:54 <Zakim> Zakim has joined #shapes
12:58:56 <trackbot> Zakim, this will be SHAPES
12:58:56 <Zakim> ok, trackbot
12:58:57 <trackbot> Meeting: RDF Data Shapes Working Group Teleconference
12:58:58 <trackbot> Date: 30 November 2016
12:59:36 <Dimitris> Dimitris has joined #shapes
12:59:55 <pano> pano has joined #shapes
13:00:12 <hknublau> hknublau has joined #shapes
13:00:31 <Arnaud> agenda: https://www.w3.org/2014/data-shapes/wiki/Meetings:Telecon2016.11.30
13:00:36 <Arnaud> chair: Arnaud
<Arnaud> regrets: ericP, Jose
13:00:49 <simonstey> present+
13:02:17 <Arnaud> very slowly for me
13:02:31 <simonstey> but no audio right?
13:02:36 <pano> can't connect to audio yet
13:02:39 <Arnaud> hmm
13:02:43 <Dimitris> I got a message that cannot connect to audio until host connects
13:02:48 <pano> same
13:02:51 <simonstey> I guess eric has to fix that
13:02:54 <Arnaud> shoot
13:03:02 <Arnaud> and eric is on a plane
13:03:08 <Arnaud> let me see if I have the way in
13:05:50 <Dimitris> it works now
13:06:44 <TallTed> TallTed has joined #shapes
13:06:58 <hknublau> present+
13:07:04 <Dimitris> present+
13:07:06 <Arnaud> present+
13:07:13 <kcoyle> present+
13:07:15 <pano> present+
13:07:21 <marqh> marqh has joined #shapes
13:07:25 <marqh> present+
13:08:17 <pano> Scribe: pano
13:08:46 <pano> topic: Admin
13:08:32 <Arnaud> PROPOSED: Approve minutes of the 23 Nov 2016 Telecon: http://www.w3.org/2016/11/23-shapes-minutes.html
13:08:52 <hknublau> +1
13:08:59 <Arnaud> RESOLVED: Approve minutes of the 23 Nov 2016 Telecon: http://www.w3.org/2016/11/23-shapes-minutes.html
13:09:01 <TallTed> present+
13:09:48 <pano> Arnaud: Eric and I are not available next week, unfortunately
13:10:50 <pano> ... default is skip next week, if someone wants to have an informal meeting next week you can speak up
13:11:28 <pano> hknublau: Can the group make any resolutions
13:11:45 <simonstey> +1
13:12:13 <hknublau> I think we should try to have the meeting next week.
13:12:19 <hknublau> Time is very short now.
13:12:22 <pano> Arnaud: if there is consensus: yes
13:13:09 <pano> ... we can postpone those issues for which there is no consensus
13:13:47 <pano> topic: Highlight of last edits
13:14:51 <pano> hknublau: [discusses his summary]
13:15:10 <kcoyle> q+
13:16:34 <Arnaud> ack kcoyle
13:17:15 <pano> Karen: I made a number of comments, some of them have been responded to, some haven't.
13:17:38 <pano> kcoyle: I made a number of comments, some of them have been responded to, some haven't.
13:17:59 <Dimitris> https://github.com/w3c/data-shapes/commits/gh-pages has message icons
13:18:11 <Dimitris> for the commits that have comments
13:18:25 <pano> Arnaud: work them out as much as possible, and bring those that you don't agree on to the WG
13:19:12 <kcoyle> q+
13:19:38 <kcoyle> one more raised issue: issue-214 [Editorial] Read through for "must" and "may"
13:19:38 <pano> ... Thanks to Holger for reviving the Proposals wiki page
13:20:14 <Arnaud> ack kcoyle
13:20:23 <pano> ... it would be good if people cast (informal) votes on the wiki page
13:20:30 <AxelPolleres> AxelPolleres has joined #shapes
13:21:50 <pano> topic: ISSUE 213: Finding Shapes
13:22:26 <Arnaud> Issue-213
13:22:26 <trackbot> Issue-213 -- Finding shapes -- open
13:22:26 <trackbot> http://www.w3.org/2014/data-shapes/track/issues/213
13:22:26 <pano> Arnaud: this is a duplicate of ISSUE-209
13:22:31 <simonstey> issue-209
13:22:31 <trackbot> issue-209 -- What is a shape -- open
13:22:31 <trackbot> http://www.w3.org/2014/data-shapes/track/issues/209
13:22:43 <simonstey> https://www.w3.org/2014/data-shapes/wiki/Proposals#ISSUE-213:_Finding_shapes
13:22:45 <Dimitris> actually it is duplicate to https://www.w3.org/2014/data-shapes/track/issues/190
13:24:18 <pano> Dimitris: it is actually a duplicate of 190
13:25:14 <pano> kcoyle: I don't think they are the same. I don't think finding shapes is the same as defining shapes.
13:25:42 <Arnaud> issue-190
13:25:42 <trackbot> issue-190 -- Identifying the shapes in a SHACL Full shapes graph -- closed
13:25:42 <trackbot> http://www.w3.org/2014/data-shapes/track/issues/190
13:26:29 <pano> simonstey: i think 209 related to 190, but not necessarily to 213
13:27:35 <pano> Arnaud: it seems to fall back to the question of "What is a shape?"
13:28:41 <pano> ... 190 was closed because of sh:hasShape, but that doesn't answer 209, 213
13:29:30 <pano> ... we'll postpone the resolution, and give the editors the opportunity to clarify the difference between these issues.
13:29:52 <pano> hknublau: we've already done this. 190 has nothing to do with this
13:29:59 <Arnaud> PROPOSAL: Close ISSUE-213 as duplicate of ISSUE-209
13:30:03 <hknublau> +1
13:30:06 <Dimitris> +1
13:30:15 <simonstey> 0
13:31:02 <pano> kcoyle: i'm still not convinced that these are the same thing.
13:31:27 <pano> +1
13:31:37 <kcoyle> 0 if we check with Peter
13:31:51 <pano> ... we should inform Peter of this decision
13:33:12 <pano> TallTed: may be worth noting to raisers of issues that raised issues should be formatted as an issue
13:34:22 <TallTed> +0
13:34:27 <Arnaud> RESOLVED: Close ISSUE-213 as duplicate of ISSUE-209
13:34:42 <pano> topic: ISSUE-198: rdf:langString
13:34:54 <Arnaud> PROPOSAL: Close ISSUE-198 as addressed by https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Nov/0083.html and https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Nov/0094.html
13:36:25 <kcoyle> 17.4.2.6 lang  simple literal  LANG (literal ltrl) Returns the language tag of ltrl, if it has one. It returns "" if ltrl has no language tag. Note that the RDF data model does not include literals with an empty language tag.
13:37:16 <Dimitris> see recent reply: https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Nov/0174.html
13:37:28 <hknublau> q+
13:37:31 <hknublau> https://www.w3.org/TR/rdf11-concepts/#section-Graph-Literal
13:37:35 <Arnaud> ack hknublau
13:37:48 <pano> kcoyle: in the terminology it says that the term datatype is used in de same way as the RDF spec. Yet we also refer to the term datatype as per the Sparql spec. I think we should remove the datatype reference from the terminology section. for lang we need to say specifically what definition we use.
13:38:27 <Dimitris> q+
13:38:40 <pano> hknublau: I think that the definitions are conistent as can be seen in https://www.w3.org/TR/rdf11-concepts/#section-Graph-Literal
13:39:22 <Arnaud> ack Dimitris
13:39:44 <Dimitris> https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Nov/0174.html
13:41:17 <pano> Dimitris: the datatype function of sparql covers our need
13:41:35 <Arnaud> https://github.com/w3c/data-shapes/commit/94e68840b9d11e6ce0abdc79e296b607f8c024be
13:42:57 <Arnaud> PROPOSAL: Close ISSUE-198 as addressed by https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Nov/0083.html and https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Nov/0094.html, changing "implies" to "means" in the reference to rdf:langString
13:43:03 <hknublau> +1
13:43:05 <simonstey> +1
13:43:06 <Dimitris> +1
13:43:08 <pano> +1
13:43:50 <TallTed> +1
13:43:51 <kcoyle> +1
13:43:59 <Arnaud> RESOLVED: Close ISSUE-198 as addressed by https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Nov/0083.html and https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Nov/0094.html, changing "implies" to "means" in the reference to rdf:langString
13:44:18 <pano> topic: ISSUE-201: node target
13:44:22 <Arnaud> PROPOSAL: Close ISSUE-201 as addressed: https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Nov/0079.html
13:44:50 <simonstey> +1
13:45:17 <pano> hknublau: this was largely editorial
13:45:44 <Dimitris> +1
13:45:45 <TallTed> +1
13:45:47 <hknublau> +1
13:45:50 <pano> ... it improves the precision
13:45:56 <pano> +1
13:46:10 <kcoyle> +1
13:46:21 <Arnaud> RESOLVED: Close ISSUE-201 as addressed: https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Nov/0079.html
13:46:37 <pano> topic: ISSUE-205: Validation report
13:48:16 <Arnaud> PROPOSAL: Close ISSUE-205 as already addressed by the recent introduction of sh:ValidationReport and the corresponding edits by Dimitris
13:48:51 <hknublau> +1
13:49:01 <kcoyle> - .5
13:49:10 <simonstey> http://w3c.github.io/data-shapes/shacl/#validation-report
13:49:29 <simonstey> issue-205
13:49:29 <trackbot> issue-205 -- Section 1.4 - graph is the result of validation -- open
13:49:29 <trackbot> http://www.w3.org/2014/data-shapes/track/issues/205
13:49:47 <Dimitris> the diff
13:49:49 <Dimitris> https://github.com/w3c/data-shapes/commit/1b38515bd5a3a3c6829bd9765e0df2878a871314
13:50:43 <Dimitris> q+
13:50:52 <Arnaud> ack Dimitris
13:50:53 <pano> kcoyle: not sure that this addresses Peter's issue
13:52:31 <pano> Dimitris: first a valid data graph would lead to an empty graph as the result of validation, now we require a graph containing a sh:ValidationReport as the result.
13:53:08 <pano> s/first/before
13:54:43 <TallTed> q+
13:54:54 <Arnaud> ack TallTed
13:56:02 <pano> TallTed: we could explicitly state that the sh:ValidationReport is the minimum that is required
13:57:03 <pano> Arnaud: Peter asks "how do you use sh:name?"
13:57:36 <pano> hknublau: I don't see the role of sh:name in this case.
13:59:03 <Arnaud> PROPOSAL: Close ISSUE-205 as addressed by the recent introduction of sh:ValidationReport and the corresponding edits by Dimitris https://github.com/w3c/data-shapes/commit/1b38515bd5a3a3c6829bd9765e0df2878a871314 adding that this is the minimum requirement and other information can be added to the report
13:59:14 <hknublau> +1
13:59:15 <TallTed> +1
13:59:16 <Dimitris> +1
13:59:20 <kcoyle> +1
13:59:23 <pano> +1
13:59:26 <simonstey> +1
13:59:46 <Arnaud> RESOLVED: Close ISSUE-205 as addressed by the recent introduction of sh:ValidationReport and the corresponding edits by Dimitris https://github.com/w3c/data-shapes/commit/1b38515bd5a3a3c6829bd9765e0df2878a871314 adding that this is the minimum requirement and other information can be added to the report
13:59:58 <hknublau> Dimitris could you handle that one?
14:00:12 <pano> topic: ISSUE-207: Parameters
14:00:43 <simonstey> issue-207
14:00:43 <trackbot> issue-207 -- Parameter descriptions for constraint components -- open
14:00:43 <trackbot> http://www.w3.org/2014/data-shapes/track/issues/207
14:00:56 <pano> Dimitris: the problem here was loose terminology
14:02:08 <kcoyle> q+
14:02:14 <Arnaud> ack kcoyle
14:02:36 <pano> Arnaud: I'm missing a pointer to the section that fixes this in the proposal
14:03:39 <simonstey> +q
14:03:40 <pano> kcoyle: This is an example where I think that uppercase "MUST" should be used.
14:03:48 <Arnaud> ack simonstey
14:04:19 <pano> ... in the blue `TEXTUAL DEFINITION` boxes
14:06:28 <pano> simonstey: in section 4.5.2. in the `TEXTUAL DEFINITION` box, the first must should be rewritten as a defining statement such as "The values of sh:maxLength are literals"
14:06:37 <Dimitris> q+
14:07:07 <Dimitris> q-
14:07:12 <TallTed> "The values of … <strike>must be</strike> *are* …. A validation result MUST <strike>must</strike> be produced"
14:09:14 <pano> Arnaud: back to issue-207, I was asking for a pointer to the changes that resolve this issue.
14:09:43 <Arnaud> PROPOSAL: Close ISSUE-207 as addressed in the latest editor's draft as explained in https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Nov/0115.html
14:09:49 <hknublau> +1
14:09:51 <kcoyle> +1
14:09:54 <Dimitris> +1
14:09:59 <simonstey> +1
14:10:14 <TallTed> +1
14:12:39 <pano> +1
14:12:43 <Arnaud> RESOLVED: Close ISSUE-207 as addressed in the latest editor's draft as explained in https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Nov/0115.html
14:13:01 <pano> topic: ISSUE-210: Expected type
14:13:18 <simonstey> issue-210
14:13:18 <trackbot> issue-210 -- value types and expected types -- open
14:13:18 <trackbot> http://www.w3.org/2014/data-shapes/track/issues/210
14:14:48 <simonstey> +q
14:14:54 <Arnaud> ack simonstey
14:15:55 <pano> hknublau: This is similar to the last one. The rewording resolves the issue. The stated example clearly becomes invalid.
14:17:53 <pano> ... the sentence about value type, which is the source of the issue, has been removed.
14:18:02 <simonstey> +q
14:18:49 <simonstey> -q
14:19:25 <simonstey> +q
14:19:31 <Arnaud> ack simonstey
14:20:41 <hknublau> q+
14:20:46 <Arnaud> ack hknublau
14:21:30 <pano> TallTed: We still need some rewording here. [must -> are] as discussed earlier.
14:22:14 <simonstey> +q
14:22:27 <pano> hknublau: we could solve this in the conformance section of the spec
14:23:09 <kcoyle> yes, that's what we said
14:23:24 <simonstey> q-
14:24:39 <pano> ... [discussion on lowercase must vs is/are for user input and uppercase MUST for engine behavior]
14:25:40 <pano> TallTed: we should look at how other people have solved this, not try to reinvent language to describe this
14:25:54 <hknublau> q+
14:26:18 <simonstey> q+
14:26:46 <Arnaud> ack hknublau
14:27:29 <kcoyle> q+
14:27:43 <Arnaud> ack simonstey
14:29:20 <Arnaud> PROPOSED: Close ISSUE-210, as addressed in the latest editor's draft, where the definitions of expected types have been updated and explicitly exclude the troublesome values
14:29:32 <pano> simonstey: in Peter's example the citation of "Expected type" is now obsolete. This has been improved and in my opinion this resolves the issue.
14:30:19 <hknublau> +1
14:30:30 <Arnaud> ack kcoyle
14:30:46 <simonstey> +1
14:31:41 <pano> kcoyle: so far in the spec we don't talk about how we validate the shapes graph itself. We should be careful about doing this here, without doing this throughout the document.
14:31:47 <kcoyle> +1
14:31:56 <pano> +1
14:34:04 <pano> Arnaud: we keep running into this issue. I think the standard should define what the format is, and what the processer does based on that. Not what the user must provide.
14:34:05 <TallTed> +1
14:34:31 <pano> ... maybe we need to formally decide as a group how we handle this once and for all.
14:34:40 <Dimitris> +1
14:34:46 <marqh> +1
14:34:55 <Arnaud> RESOLVED: Close ISSUE-210, as addressed in the latest editor's draft, where the definitions of expected types have been updated and explicitly exclude the troublesome values
14:35:22 <TallTed> q+
14:35:22 <simonstey> +q
14:35:48 <Arnaud> ack TallTed
14:35:57 <Arnaud> ack simonstey
14:36:24 <pano> topic: The use of must
14:37:20 <kcoyle> q+
14:38:01 <Arnaud> ack kcoyle
14:38:31 <pano> simonstey: I think it's valuable to describe in the spec what must happen on certain input, for e.g. on the values of sh:minCount. This to achieve consistency of engine behavior
14:38:58 <TallTed> q+
14:39:08 <Arnaud> ack TallTed
14:39:41 <pano> kcoyle: this raises an issue for me, in the spec we define a vocabulary and we define the behavior of an engine with rules, but so far we haven't talked about the rules of the vocabulary.
14:40:15 <kcoyle> q+
14:40:27 <pano> TallTed: in RDF terms we're then talking about the ontology of SHACL and constructs like domain and range will cover many of these issues
14:40:29 <kcoyle> q-
14:41:24 <simonstey> +q
14:41:24 <marqh> q+
14:41:33 <pano> ... but the proper, consistent use of rfc2119 key words should still be applied
14:41:34 <Arnaud> ack simonstey
14:42:22 <kcoyle> q+
14:42:33 <Arnaud> ack marqh
14:42:52 <pano> simonstey: "are" is of course not as restrictive as must, but I was wondering if formalizing some of this would help
14:43:05 <simonstey> https://tools.ietf.org/html/rfc2119
14:43:40 <simonstey> 1. MUST   This word, or the terms "REQUIRED" or "SHALL", mean that the    definition is an absolute requirement of the specification.
14:44:04 <Arnaud> ack kcoyle
14:44:11 <pano> marqh: I was wondering if SHALL an option instead of MUST, but after looking at rfc2119 it seems they are interchangeable
14:44:15 <simonstey> Guidance in the use of these Imperatives     Imperatives of the type defined in this memo must be used with care    and sparingly.  In particular, they MUST only be used where it is    actually required for interoperation or to limit behavior which has    potential for causing harm (e.g., limiting retransmisssions)  For    example, they must not be used to try to impose a particular method    on implementors where the method is not required for    int[CUT]
14:45:18 <TallTed> +1 to separate ontological definition, from its effects during conformance check a/k/a validation
14:45:31 <pano> kcoyle: I think these 'TEXTUAL DEFINITION' sentences are doing two things: 1. defining the type of the input, and 2. defining the behavior of the engine.
14:45:41 <pano> ... I think we should split these
14:46:45 <pano> ... we could use the way the sparql and rdf specs use a column that states the `type`
14:48:32 <simonstey> +1 to what arnaud said
14:49:29 <simonstey> I can do that
14:49:40 <pano> Arnaud: This is a problem that other specs have also faced. As hknublau and simonstey stated before we can add a part in a general section to address this.
14:51:13 <pano> Dimitris: I agree with this.
14:52:32 <AxelPolleres> AxelPolleres has joined #shapes
14:53:20 <Arnaud> PROPOSED: reserve the use of MUST to requirements on the processor, use "is" or "are" to describe the language, and add a section on expectated input graphs and treatment of errors (or not)
14:53:32 <Arnaud> s/expectated/expected/
14:53:39 <simonstey> +1
14:54:01 <Dimitris> +1
14:54:14 <TallTed> "if parameters don't conform to defined DOMAIN/RANGE, the shape is ill-formed, and results of its use (in validation or UI or...) are indeterminate..."
14:54:23 <hknublau> 0
14:54:25 <kcoyle> +1
14:54:26 <TallTed> +1
14:54:33 <pano> +1
14:54:50 <Arnaud> RESOLVED: reserve the use of MUST to requirements on the processor, use "is" or "are" to describe the language, and add a section on expectated input graphs and treatment of errors (or not)
14:55:13 <Dimitris> I can do that
14:55:21 <hknublau> q+
14:55:30 <Arnaud> ack hknublau
14:55:56 <pano> topic: Next release of the spec
14:56:40 <pano> hknublau: is it possible to release an update of the spec?
14:56:53 <simonstey> q+
14:57:21 <pano> ... doing it now, we could say that this is the last draft and give people the chance to make comments over the holidays
14:57:46 <pano> Arnaud: I think we should aim to publish before the holidays
14:57:50 <Arnaud> ack simonstey
14:57:51 <Dimitris> q+
14:58:42 <Arnaud> ack Dimitris
14:59:18 <pano> simonstey: In another WG Phil Archer mentioned that there is a blackout period, but this probably isn't a problem for us.
15:05:41 <Arnaud> ack Dimitris
15:12:03 <Arnaud> trackbot, end meeting
15:12:03 <trackbot> Zakim, list attendees
15:12:03 <Zakim> As of this point the attendees have been simonstey, hknublau, Dimitris, Arnaud, kcoyle, pano, marqh, TallTed
15:12:11 <trackbot> RRSAgent, please draft minutes
15:12:11 <RRSAgent> I have made the request to generate http://www.w3.org/2016/11/30-shapes-minutes.html trackbot
15:12:12 <trackbot> RRSAgent, bye
15:12:12 <RRSAgent> I see no action items