See also: IRC log
<Arnaud> very slowly for me
<simonstey> but no audio right?
can't connect to audio yet
<Arnaud> hmm
<Dimitris> I got a message that cannot connect to audio until host connects
same
<simonstey> I guess eric has to fix that
<Arnaud> shoot
<Arnaud> and eric is on a plane
<Arnaud> let me see if I have the way in
<Dimitris> it works now
<scribe> Scribe: pano
<Arnaud> PROPOSED: Approve minutes of the 23 Nov 2016 Telecon: http://www.w3.org/2016/11/23-shapes-minutes.html
<hknublau> +1
RESOLUTION: Approve minutes of the 23 Nov 2016 Telecon: http://www.w3.org/2016/11/23-shapes-minutes.html
Arnaud: Eric and I are not available next week, unfortunately
... default is skip next week, if someone wants to have an informal meeting next week you can speak up
hknublau: Can the group make any resolutions
<simonstey> +1
<hknublau> I think we should try to have the meeting next week.
<hknublau> Time is very short now.
Arnaud: if there is consensus: yes
... we can postpone those issues for which there is no consensus
hknublau: [discusses his summary]
Karen: I made a number of comments, some of them have been responded to, some haven't.
kcoyle: I made a number of comments, some of them have been responded to, some haven't.
<Dimitris> https://github.com/w3c/data-shapes/commits/gh-pages has message icons
<Dimitris> for the commits that have comments
Arnaud: work them out as much as possible, and bring those that you don't agree on to the WG
<kcoyle> one more raised issue: issue-214 [Editorial] Read through for "must" and "may"
Arnaud: Thanks to Holger for reviving the Proposals wiki page
... it would be good if people cast (informal) votes on the wiki page
<Arnaud> Issue-213
<trackbot> Issue-213 -- Finding shapes -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/213
Arnaud: this is a duplicate of ISSUE-209
<simonstey> issue-209
<trackbot> issue-209 -- What is a shape -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/209
<simonstey> https://www.w3.org/2014/data-shapes/wiki/Proposals#ISSUE-213:_Finding_shapes
<Dimitris> actually it is duplicate to https://www.w3.org/2014/data-shapes/track/issues/190
Dimitris: it is actually a duplicate of 190
kcoyle: I don't think they are the same. I don't think finding shapes is the same as defining shapes.
<Arnaud> issue-190
<trackbot> issue-190 -- Identifying the shapes in a SHACL Full shapes graph -- closed
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/190
simonstey: i think 209 related to 190, but not necessarily to 213
Arnaud: it seems to fall back to the question of "What is a shape?"
... 190 was closed because of sh:hasShape, but that doesn't answer 209, 213
... we'll postpone the resolution, and give the editors the opportunity to clarify the difference between these issues.
hknublau: we've already done this. 190 has nothing to do with this
<Arnaud> PROPOSAL: Close ISSUE-213 as duplicate of ISSUE-209
<hknublau> +1
<Dimitris> +1
<simonstey> 0
kcoyle: i'm still not convinced that these are the same thing.
+1
<kcoyle> 0 if we check with Peter
scribe: we should inform Peter of this decision
TallTed: may be worth noting to raisers of issues that raised issues should be formatted as an issue
<TallTed> +0
RESOLUTION: Close ISSUE-213 as duplicate of ISSUE-209
<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
<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.
<Dimitris> see recent reply: https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Nov/0174.html
<hknublau> https://www.w3.org/TR/rdf11-concepts/#section-Graph-Literal
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.
hknublau: I think that the definitions are conistent as can be seen in https://www.w3.org/TR/rdf11-concepts/#section-Graph-Literal
<Dimitris> https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Nov/0174.html
Dimitris: the datatype function of sparql covers our need
<Arnaud> https://github.com/w3c/data-shapes/commit/94e68840b9d11e6ce0abdc79e296b607f8c024be
<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
<hknublau> +1
<simonstey> +1
<Dimitris> +1
+1
<TallTed> +1
<kcoyle> +1
RESOLUTION: 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
<Arnaud> PROPOSAL: Close ISSUE-201 as addressed: https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Nov/0079.html
<simonstey> +1
hknublau: this was largely editorial
<Dimitris> +1
<TallTed> +1
<hknublau> +1
hknublau: it improves the precision
+1
<kcoyle> +1
RESOLUTION: Close ISSUE-201 as addressed: https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Nov/0079.html
<Arnaud> PROPOSAL: Close ISSUE-205 as already addressed by the recent introduction of sh:ValidationReport and the corresponding edits by Dimitris
<hknublau> +1
<kcoyle> - .5
<simonstey> http://w3c.github.io/data-shapes/shacl/#validation-report
<simonstey> issue-205
<trackbot> issue-205 -- Section 1.4 - graph is the result of validation -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/205
<Dimitris> the diff
<Dimitris> https://github.com/w3c/data-shapes/commit/1b38515bd5a3a3c6829bd9765e0df2878a871314
kcoyle: not sure that this addresses Peter's issue
Dimitris: before 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.
TallTed: we could explicitly state that the sh:ValidationReport is the minimum that is required
Arnaud: Peter asks "how do you use sh:name?"
hknublau: I don't see the role of sh:name in this case.
<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
<hknublau> +1
<TallTed> +1
<Dimitris> +1
<kcoyle> +1
+1
<simonstey> +1
RESOLUTION: 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
<hknublau> Dimitris could you handle that one?
<simonstey> issue-207
<trackbot> issue-207 -- Parameter descriptions for constraint components -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/207
Dimitris: the problem here was loose terminology
Arnaud: I'm missing a pointer to the section that fixes this in the proposal
<simonstey> +q
kcoyle: This is an example where I think that uppercase "MUST" should be used.
... in the blue `TEXTUAL DEFINITION` boxes
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"
<TallTed> "The values of … <strike>must be</strike> *are* …. A validation result MUST <strike>must</strike> be produced"
Arnaud: back to issue-207, I was asking for a pointer to the changes that resolve this issue.
<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
<hknublau> +1
<kcoyle> +1
<Dimitris> +1
<simonstey> +1
<TallTed> +1
+1
RESOLUTION: 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
<simonstey> issue-210
<trackbot> issue-210 -- value types and expected types -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/210
<simonstey> +q
hknublau: This is similar to the last one. The rewording resolves the issue. The stated example clearly becomes invalid.
... the sentence about value type, which is the source of the issue, has been removed.
<simonstey> +q
<simonstey> -q
<simonstey> +q
TallTed: We still need some rewording here. [must -> are] as discussed earlier.
<simonstey> +q
hknublau: we could solve this in the conformance section of the spec
<kcoyle> yes, that's what we said
hknublau: [discussion on lowercase must vs is/are for user input and uppercase MUST for engine behavior]
TallTed: we should look at how other people have solved this, not try to reinvent language to describe this
<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
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.
<hknublau> +1
<simonstey> +1
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.
<kcoyle> +1
+1
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.
<TallTed> +1
Arnaud: maybe we need to formally decide as a group how we handle this once and for all.
<Dimitris> +1
<marqh> +1
RESOLUTION: 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
<simonstey> +q
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
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.
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
<simonstey> +q
TallTed: but the proper, consistent use of rfc2119 key words should still be applied
simonstey: "are" is of course not as restrictive as must, but I was wondering if formalizing some of this would help
<simonstey> https://tools.ietf.org/html/rfc2119
<simonstey> 1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the definition is an absolute requirement of the specification.
marqh: I was wondering if SHALL an option instead of MUST, but after looking at rfc2119 it seems they are interchangeable
<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]
<TallTed> +1 to separate ontological definition, from its effects during conformance check a/k/a validation
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.
... I think we should split these
... we could use the way the sparql and rdf specs use a column that states the `type`
<simonstey> +1 to what arnaud said
<simonstey> I can do that
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.
Dimitris: I agree with this.
<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 expected input graphs and treatment of errors (or not)
<simonstey> +1
<Dimitris> +1
<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..."
<hknublau> 0
<kcoyle> +1
<TallTed> +1
+1
RESOLUTION: 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)
<Dimitris> I can do that
hknublau: is it possible to release an update of the spec?
... doing it now, we could say that this is the last draft and give people the chance to make comments over the holidays
Arnaud: I think we should aim to publish before the holidays
simonstey: In another WG Phil Archer mentioned that there is a blackout period, but this probably isn't a problem for us.
<Arnaud> trackbot, end meeting