W3C

RDF Data Shapes Working Group Teleconference

30 Nov 2016

Agenda

See also: IRC log

Attendees

Present
simonstey, hknublau, Dimitris, Arnaud, kcoyle, pano, marqh, TallTed
Regrets
ericP, Jose
Chair
Arnaud
Scribe
pano

Contents


<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

Admin

<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

Highlight of last edits

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

ISSUE 213: Finding Shapes

<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

ISSUE-198: rdf:langString

<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

ISSUE-201: node target

<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

ISSUE-205: Validation report

<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?

ISSUE-207: Parameters

<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

ISSUE-210: Expected type

<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

The use of must

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

Next release of the spec

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

Summary of Action Items

Summary of Resolutions

  1. Approve minutes of the 23 Nov 2016 Telecon: http://www.w3.org/2016/11/23-shapes-minutes.html
  2. Close ISSUE-213 as duplicate of ISSUE-209
  3. 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
  4. Close ISSUE-201 as addressed: https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Nov/0079.html
  5. 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
  6. 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
  7. 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
  8. 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)
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.143 (CVS log)
$Date: 2016/12/15 10:22:18 $