<TallTed> trackbot, start meeting

<trackbot> Meeting: RDF Data Shapes Working Group Teleconference

<trackbot> Date: 25 January 2017

<TallTed> scribenick: dallemang

<ipolikoff> present

<TallTed> PROPOSED: Approve minutes of the 18 Jan 2017 Telecon: https://www.w3.org/2017/01/18-shapes-minutes.html

<hknublau> +1

<ipolikoff> +1

RESOLUTION: Approve minutes of the 18 Jan 2017 Telecon: https://www.w3.org/2017/01/18-shapes-minutes.html

TallTed: We will have another call next week, same time/channel

<TallTed> ISSUE-219: Should we add a one-of-a-list-of-shapes operator

<trackbot> Notes added to ISSUE-219 Should we add a one-of-a-list-of-shapes operator.

<TallTed> ISSUE-219: Should we add a one-of-a-list-of-shapes operator

<trackbot> Notes added to ISSUE-219 Should we add a one-of-a-list-of-shapes operator.

<TallTed> issue-219?

<trackbot> issue-219 -- Should we add a one-of-a-list-of-shapes operator -- raised

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

simonstey: Why didn't we follow up on this, when we realized that XOR wasn't doing the job we needed?
... was it lack of use cases?

ipolikoff: I don't know, but Eric brought up a use case recently
... either a combination of first/last or full name
... she has been talking to Allotrop (consortium of pharmas) They have been devleoping shapes for medical instruments
... OneOf is all over their shapes.
... she doesn't know if it is really essential or could be replaced with something else

TallTed: Is that one or more, or one and only?

ipolikoff: one and only

TallTed: one and only is XOR, so this is already covered

<TallTed> PROPOSAL: Open ISSUE-219

TallTed: This is not the right meeting for this discussion

<hknublau> +1

<TallTed> +1

<simonstey> +1

<Dimitris> +1

<pano> +1

RESOLUTION: Open ISSUE-219

0

Working Draft

TallTed: We will put in a draft now, publish current version as nominal working draft

.,. we're faking a "last call"

<ipolikoff> I thought CR1 was "last call"

simonstey: We aren't faking the last call, we're simulating it

Dimitris: there have been a lot of changes in the past two weeks

<TallTed> PROPOSAL: Publish current working draft as (final) public working draft.

<simonstey> +1

<hknublau> +1

<ipolikoff> +1

=1

+1

<Dimitris> 0

<TallTed> +1

<pano> +1

RESOLUTION: Publish current working draft as (final) public working draft

ISSUE-218: Move annotations

<TallTed> issue-218?

<trackbot> issue-218 -- Should we move SPARQL Annotations mechanism into the WG Note? -- open

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

holger: in most drafts, we had a chapter about how to inject annotations into SPARQL results
... standalone and not important, he proposes putting it into the note with advanced SPARQL
... to reduce complexity

Dimitris:

<TallTed> PROPOSAL: close issue-218, by moving SPARQL Annotations mechanism into the WG Note

<simonstey> +1

<hknublau> +1

<Dimitris> +1

<ipolikoff> +1

<TallTed> +1

0

<pano> +1

RESOLUTION: close issue-218, by moving SPARQL Annotations mechanism into the WG Note

ISSUE-93: engine/language

<TallTed> issue-93?

<trackbot> issue-93 -- SHACL engine vs. SHACL instance requirements -- open

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

<TallTed> https://www.w3.org/2014/data-shapes/wiki/Proposals#ISSUE-93:_engine_.2F_language

<simonstey> issue-214

<trackbot> issue-214 -- [Editorial] Read through for "must" and "may" -- closed

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

TallTed: thinks that the resolution is to close it as taken care of by conformance 1.3 work

<simonstey> http://w3c.github.io/data-shapes/shacl/#conformance

<TallTed> PROPOSAL: Close ISSUE-93 as handled by section 1.3 (Conformance)

<simonstey> +1

<hknublau> +1

simonstey: there's a "to do" in 1.3 Compliance, which we need to get rid of

TallTed: Is that separate, or part of this issue?

<pano> +1

+1

<Dimitris> +1

<ipolikoff> +1

<TallTed> +1

RESOLUTION: Close ISSUE-93 as handled by section 1.3 (Conformance)

hknublau: will take out the to do comment, since for CR we don't need test case links

simonstey: isn't test case needed for conformance?

hknublau: we don't have tests, only work in progress.

TallTed: We can have a pointer to our work in progress.

simonstey: The LDP has test suites listed up front, but not in conformance
... therefore, we can get rid of this in 1.3, and put in test suites in the final iteration

TallTed: We will remove the reference to test suites from section 1.3

ISSUE-111: charter issues

<TallTed> issue-111?

<trackbot> issue-111 -- How should the working group address the issues called out in the WG charter? -- open

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

<TallTed> https://www.w3.org/2014/data-shapes/wiki/Proposals#ISSUE-111:_charter_issues

ipolikoff: "In current intro to SHACL, we don't sufficiently tie to charter. " Proposal is to add language to spec to put in this link.

<simonstey> +q

ipolikoff: question: Is it customary or necessary for spec to have close tie explanation for its ocnnection to the charter?

TallTed: No, this isn't common, the spec doesn't usually say anything itself.

ipolikoff: in that case, she suggests closing

<hknublau> I checked a few other specs, none of them have such a reference.

simonstey: is it necessary, or is it clever to do it? To avoid future comments. So even if it is not necessary, simonstey things it would be better to close the issue with the explanation that ipolikoff summarized in the proposal page
... so that e.g. Peter will see why, and what the connection is.

<TallTed> PROPOSAL: close issue-111 without putting any Charter-validation in the spec, as this is neither customary nor required by W3 process, but with notation in closing that "the SHACL spec meets all three of the issues listed in the RDF Data Shapes working group charter"

<ipolikoff> +1

+1

<simonstey> +1

<TallTed> +1

<pano> +1

<Dimitris> +1

<hknublau> +1

RESOLUTION: close issue-111 without putting any Charter-validation in the spec, as this is neither customary nor required by W3 process, but with notation in closing that "the SHACL spec meets all three of the issues listed in the RDF Data Shapes working group charter"

ISSUE-211: Eliminate property constraints

<TallTed> https://www.w3.org/2014/data-shapes/wiki/Proposals#ISSUE-211:_Eliminate_property_constraints

<TallTed> issue-211?

<trackbot> issue-211 -- Eliminate property constraints -- open

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

<TallTed> PROPOSAL: close issue-211 as essentially solved, with Dimitris putting remaining fragmentary concern in a fresh issue

hknublau: hoping that we will close all issues by the end of this meeting, to give positive progress report to W3C mgmt

<hknublau> +1

<Dimitris> +1

+1

<pano> +1

<simonstey> +1

<TallTed> +1

RESOLUTION: close issue-211 as essentially solved, with Dimitris putting remaining fragmentary concern in a fresh issue

<ipolikoff> +1

ISSUE-215: literal parameters

<TallTed> issue-215?

<TallTed> https://www.w3.org/2014/data-shapes/wiki/Proposals#ISSUE-215:_parameters_with_a_value_type_that_is_a_datatype

<trackbot> issue-215 -- parameters with a value type that is a datatype -- open

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

ipolikoff: 215 is no longer relevant, because there was an issue with Expected Type, the wording could have inferred that a literal is something else
... ipolikoff put a proposal together to change the language, however,
... the spec has changed, so that sentence is no longer there, since ExpectedType is no longer there
... this raises a new topic, related to expected type
... current spec, a shape is an IRI or blank in the shapes graph. Another proposal (Dimitris and Peter) said that it had to have expected type of Shape

<TallTed> PROPOSAL: close issue-215 as resolved by other changes to date; "expected type" no longer occurs in the spec

ipolikoff: not about this issue, this issue can be closed

<hknublau> +1

ipolikoff: but this resolution brings up a new topic

<pano> 2.1

https://w3c.github.io/data-shapes/shacl/#shapes

hknublau: e.g., we have a formal rule that says that cardinality must be an integer, if we violate this, then outcome is undefined

TallTed: mincount is in 4.2.1

hknublau: separate syntax and semantics,

Dimitris: What happens if mincount is not an integer? If hknublau says it is disallowed, then the issue is no longer releant

TallTed: original concern is about expected type, but the example is mincount, now we say that it isn't an expected type, but now it is this type

<ipolikoff> sec 4

<ipolikoff> Shapes that violate any of the syntax rules enumerated in those parameter tables are ill-formed.

TallTed: Is there a place to say what happens if something is a type, but the graph violates that

<simonstey> http://w3c.github.io/data-shapes/shacl/#syntax-rules

https://w3c.github.io/data-shapes/shacl/#ill-formed-shape-graphs

TallTed: Any objections to change may/should in 3.4.2?

hknublau: no, because shapes graph and data graph could be the same

<simonstey> 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.

hknublau: it is impractical to insist on this

TallTed: "should" allows the processor not to do something in some situation
... "should" is guidance to non-sophisticated folks, to indicate that if they don't know better then they should do it.

hknublau: Doesn't "UNDEFINED" do this?
... it isn't realistic to expect an implementation to do all those tests.

TallTed: isn't so sure about "UNDEFINED", but is pretty sure about this SHOULD produce a failure

hknublau: what if there is a bad shape in the graph, but it isn't being used? Does it make sense for there to be an error?

dallemang: actually, yes, such an error is welcome

hknublau: we can change MAY/SHOULD, but not change UNDEFINED

<TallTed> ack

simonstey: RECOMMENDED is what SHOULD means, so he is in favor of change to SHOULD

<TallTed> PROPOSED: change the MAY in "3.4.2 Handling of Ill-formed Shapes Graphs -- If the shapes graph contains ill-formed nodes, then the result of the validation process is undefined. A SHACL processor MAY produce a failure in this case." to SHOULD

<ipolikoff> +1

<simonstey> +1

<Dimitris> +1

<pano> +1

<TallTed> +1

+1

<hknublau> +1

RESOLUTION: change the MAY in "3.4.2 Handling of Ill-formed Shapes Graphs -- If the shapes graph contains ill-formed nodes, then the result of the validation process is undefined. A SHACL processor MAY produce a failure in this case." to SHOULD

<Dimitris> scribenick: dimitris

<TallTed> PROPOSAL: close issue-215 as resolved by other changes to date; "expected type" no longer occurs in the spec

<hknublau> +1

+q

<TallTed> PROPOSAL: close issue-215 as resolved by other changes to date; "expected type" no longer occurs in the spec, and explicit syntax rules have been added

<ipolikoff> +1

<hknublau> +1

Dimitris: expected type is removed from the spec why?

hknublau: no longer needed, only needed for the shapes definition
... we never needed it anyway

<ipolikoff> I read thoroughly through Dimitris draft and expected type only used there for defining the shape

Dimitris: we need to review the spec

<simonstey> +1

<TallTed> +1

<pano> +1

0 (cannot tell in the light of the definition changes)

<dallemang> +1

RESOLUTION: close issue-215 as resolved by other changes to date; "expected type" no longer occurs in the spec, and explicit syntax rules have been added

hknublau: discuss about XOR?

issue-219

<TallTed> issue-219?

<trackbot> issue-219 -- Should we add a one-of-a-list-of-shapes operator -- open

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

hknublau: we've seen use cases that require this

<simonstey> https://en.wikipedia.org/wiki/Exclusive_or

<simonstey> More generally, XOR is true only when an odd number of inputs are true. A chain of XORs—a XOR b XOR c XOR d (and so on)—is true whenever an odd number of the inputs are true and is false whenever an even number of inputs are true.

TallTed: do not understand the odd number of matches
... xor is odd number of true values

dallemang: ... explaining xor definition ...
... official definition is counter intuitive

TallTed: sh:xor can be as "exclusive or" or "one and only one of this list"

simonstey: why not sh:oneOf

dallemang: oneOf is a term in OWL

TallTed: why not add a disclaimer for xor?

dallemang: I can write the disclaimer

<simonstey> +1

TallTed: suggest to try with sh:xor

<TallTed> PROPOSAL: close issue-219, adding sh:xor, meaning one-and-only-one-of, wording carefully to avoid confusions and to align with sh:or (meaning at-least-one-of)

<dallemang> +1

<hknublau> +1

<TallTed> +1

<pano> +1

+1

<ipolikoff> +1

RESOLUTION: close issue-219, adding sh:xor, meaning one-and-only-one-of, wording carefully to avoid confusions and to align with sh:or (meaning at-least-one-of)

hknublau: what are the next steps?
... how much time for feedback once we publish?

TallTed: do not have a definitive answer

ipolikoff: publish and let's see

dallemang: are we talking abut the definition of shapes?

TallTed: once you are ready send a mail for review

<dallemang> https://en.wikipedia.org/wiki/Exclusive_or 'Some may contend that any binary or other n-ary exclusive "or" is true if and only if it has an odd number of true inputs '

TallTed: maintain weekly calls in case something comes up

shape definition in 2.1

dallemang: definition is problematic
... "A shape is an IRI or blank node in the shapes graph." is far too general

<ipolikoff> dallemang: far too general

dallemang: and counter intuitive

hknublau: was trying to come up with a minimum definition
... it only makes sense in validation
... it doesn't matter anywhere else
... a shape can be validated only if it has a target
... two ways to call the engine, using targets, explicitely or with reference
... can be defined but not needed

<simonstey> +q

hknublau: only matters to implementers
... we can enumerate informative rules

dallemang: I find this satisfying, because I want to be able to find all shapes

<simonstey> sh:or A SHACL list of shapes to validate the value nodes against. The value of each sh:or is a SHACL list. Each member of such list must be a well-formed shape.

simonstey: [explaining example above]
... could I just put any IRI?

hknublau: should I put ill-formed there?

simonstey: kind of works but since everything is a shape any blank can be ill-formed

ipolikoff: is it a problem

simonstey: what is a well-formed shape for values in e.g. sh:or

TallTed: if it has shacl attributes is has to conform, if not it doesn't

simonstey: then we need to define what is an ill-formed shape

<ipolikoff> for example

<ipolikoff> The values of sh:qualifiedValueShape must be well-formed shapes.

<ipolikoff> becomes

hknublau: "it must be a shape but not ill-formed"?

<ipolikoff> The values of sh:qualifiedValueShape must be a shape that is not ill-formed.

simonstey: define what well-formed / ill-formed shape is

TallTed: we have many references to ill-formed graph but not for ill-formed shapes

http://w3c.github.io/data-shapes/shacl/#node-shapes

Dimitris: we need to be explicit, this is too loose

hknublau: the definition does not brake anything

Dimitris: this list has to be normative

TallTed: it depends on the use case

is sh:IRI as shape

?

simonstey: can we say something about node shape? it is too general
... state it explicitly in every occurrence?

hknublau: Add it once, it is a big overhead

<TallTed> ADJOURNED

<hknublau> trackbot, end meeting

This is scribe.perl Revision: 1.148  of Date: 2016/10/11 12:55:14  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/compliance/conformance 1.3/
Succeeded: s/13/1.3/
Succeeded: s/c eto/ce to/
Succeeded: s/Accepted/Expected/
Succeeded: s/exclusive or or one and only one of this list/"exclusive or" or "one and only one of this list"/
Succeeded: s/bi-weekly/weekly/
Found ScribeNick: dallemang
Found ScribeNick: dimitris
Inferring Scribes: dallemang, dimitris
Scribes: dallemang, dimitris
ScribeNicks: dallemang, dimitris
Default Present: hknublau, Nicky_, simonstey, dallemang, TallTed, Dimitris, pano, ipolikoff
Present: hknublau Nicky_ simonstey dallemang TallTed Dimitris pano ipolikoff
Found Date: 25 Jan 2017
Guessing minutes URL: http://www.w3.org/2017/01/25-shapes-minutes.html
People with action items: