RDF Data Shapes Working Group Teleconference

<scribe> scribe: pano

<TallTed> PROPOSED: Approve minutes of the 08 Feb 2017 Telecon: https://www.w3.org/2017/02/08-shapes-minutes.html

<simonstey> +1

<Nicky> +1

<hknublau> +1

+1

RESOLUTION: Approve minutes of the 08 Feb 2017 Telecon: https://www.w3.org/2017/02/08-shapes-minutes.html

<TallTed> next call: Wednesday 2017.02.22

Admin

<TallTed> https://www.w3.org/2014/data-shapes/track/issues/raised

<TallTed> PROPOSED: Open all ISSUE-226, ISSUE-227, ISSUE-228, ISSUE-229, ISSUE-230, ISSUE-231

<hknublau> +1

<simonstey> +1

+1

<Nicky> +1

RESOLUTION: Open all ISSUE-226, ISSUE-227, ISSUE-228, ISSUE-229, ISSUE-230, ISSUE-231

issueless rename of sh:xor

<simonstey> +q

wrong name xor

Simon: What was the problem with only one of?

TallTed: It is a very long label

<hknublau> sh:xone

TallTed: I did some research and found a couple of terms: one and only one, exactly one, or shorter onee, oaoo

Simon: A couple of meetings ago, Dean had explained the differences in interpratation of xor, which leads to discussion. I like holger's proposal. Im less in favor of abbreviations with double letters
... I believe we discussed the response to expected comments to be that we would explain/clarify our interpretation of sh:xor

TallTed: In English exclusive or makes sense, but since we're dealing with stakeholders that intepret exclusive or differently it might be good to reconsider

<TallTed> PROPOSED: change sh:xor to sh:xone, pronounced "ex-one", meaning "exactly one"

<hknublau> +1

<Nicky> +1

+1

<TallTed> +1

<simonstey> +1

RESOLUTION: change sh:xor to sh:xone, pronounced "ex-one", meaning "exactly one"

<TallTed> issue-230?

<trackbot> issue-230 -- Inconsistency in the use of $this and $PATH in sh:sparql vs constraint components -- open

<trackbot> http://www.w3.org/2014/data-shapes/track/issues/230

ISSUE-230

hknublau: this was pointed out by Peter, and correctly so. I have already updated this in the document

<simonstey> sounds good to me

<simonstey> +q

hknublau: since sparql based constraints are applicable to Property Shapes, this needs to be fixed as well by allowing the use of $PATH when sh:sparql is used in property shapes

<hknublau_> My usual crash. Redialling in.

simonstey: do we need to add some sort of disclaimer or note in the spec when we remove something from the language

TallTed: Any implementation of SHACL is at risk currently anyway

<hknublau_> PROPOSAL: Remove the special handling of the result variable ?focusNode in SPARQL constraints. $this will become the sh:focusNode.

<simonstey> +1

<TallTed> +1

<hknublau_> +1

+1

<Nicky> +1

RESOLUTION: Remove the special handling of the result variable ?focusNode in SPARQL constraints. $this will become the sh:focusNode.

<hknublau_> PROPOSAL: Close ISSUE-230 by changing the binding of ?this from the value node to the focus node (section 5.3.1) and allowing the use of $PATH in SPARQL-based constraints.

<simonstey> +1

<hknublau_> +1

<TallTed> +1

<Nicky> +1

+1

RESOLUTION: Close ISSUE-230 by changing the binding of ?this from the value node to the focus node (section 5.3.1) and allowing the use of $PATH in SPARQL-based constraints.

ISSUE-231

hknublau: [explains ISSUE-231]
... the constraint component is the owner of the validators

<hknublau_> PROPOSAL: Change the rule for sh:resultMessage in section 5.3.2 to fall back to sh:message at the constraint component if no other message has been found.

<hknublau_> +1

<TallTed> +1

+1

<Nicky> +1

<simonstey> +1

simonstey: shouldn't it be the other way around with the constraint component and the validator?
... if we phrase it using overridden I would prefer that wording

<TallTed> PROPOSAL: in section 5.3.2, add sh:message to constraint component; that may be over-ridden by a more specific sh:message attached to a specific validator within that constraint component

<simonstey> +1

<hknublau_> +1

<TallTed> +1

+1

<Nicky> +1

RESOLUTION: CLOSE issue-231 by: in section 5.3.2, add sh:message to constraint component; that may be over-ridden by a more specific sh:resultMessage attached to a specific validator within that constraint component

ISSUE-227

hknublau: there seems to be good progress being made in the SPARQL group, but the point being made in comments is that the definition of EXISTS in SPARQL is broken, therefor SPARQL is broken, therefor we cannot make a spec that is built on SPARQL

TallTed: we already state somewhere that we acknowledge that SPARQL has issues.
... and we can acknowledge that more clearly
... this is a legitimate issue with SPARQL, and we can say that we can't solve this. We can acknowledge that this issue is there, and that one has to be aware of this.

<TallTed> PROPOSED: CLOSE issue-227 by adding wording to the effect of: As of this writing, SPARQL EXISTS is imperfectly defined, and implememtations vary; therefore use of EXISTS may have inconsistent results, and should be approached with care.

<simonstey> +1

<Nicky> +1

<hknublau_> +1

+1

<TallTed> +1

RESOLUTION: CLOSE issue-227 by adding wording to the effect of: As of this writing, SPARQL EXISTS is imperfectly defined, and implememtations vary; therefore use of EXISTS may have inconsistent results, and should be approached with care.

simonstey: could we add a link to the current efforts in the SPARQL CG?

<TallTed> ACTION: simonstey to produce a JSON-LD @context draft [recorded in http://www.w3.org/2017/02/15-shapes-minutes.html#action01]

<trackbot> Created ACTION-48 - Produce a json-ld @context draft [on Simon Steyskal - due 2017-02-22].

ISSUE-226

hknublau: this may help in the adoption, if we can make a readable JSON-LD template for shapes

<TallTed> trackbot: end meeting