trackbot, start meeting

<trackbot> Meeting: RDF Data Shapes Working Group Teleconference

<trackbot> Date: 18 January 2017

<scribe> scribenick: hknublau

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

+1

<Nicky> +1

<dallemang> 0

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

PROPOSAL: Open ISSUE-218

+1

<ipolikoff> PROPOSAL: Open ISSUE-218

<ipolikoff> +1

<TallTed> +1

<Nicky> +1

RESOLUTION: Open ISSUE-218

<dallemang> Where do we see the draft that Holger is talking about?

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

<ipolikoff> PROPOSAL: Close ISSUE-203 as addressed by https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Nov/0112.html

hknublau: Summary of new edits: better structure, separation of syntax and semantic rules, new metamodel and terminology changes

+1

<TallTed> +1

<Nicky> obsolete +!

<Nicky> +1

<dallemang> +1

RESOLUTION: Close ISSUE-203 as addressed by https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Nov/0112.html and obsolete

ISSUE-68

<ipolikoff> PROPOSAL: Close ISSUE-68 defining pre-binding using eval(D(G), Replace(PrjMap(X), μ)) as described in https://w3c.github.io/sparql-exists/docs/sparql-exists.html

AndyS: Issue is how to set variables in SPARQL queries.

<dallemang> +q

AndyS: EXISTS uses something similar. EXISTS is a FILTER function that checks whether the sub-query using the values from the outside has solutions.
... Issues were reported regarding EXISTS (HK: and a CG was created in response).
... Proposal consists of three parts (as written down in the linked document)

dallemang: How would it differ from VALUES?

AndyS: VALUES is just a block of data. It's close to Peter's proposal.
... that proposal works for less cases, because values are injected into the top level only.
... my approach supports nested features such as UNIONs, close to replacement.

<ipolikoff> PROPOSAL: Close ISSUE-68 defining pre-binding using eval(D(G), Replace(PrjMap(X), μ)) as described in https://w3c.github.io/sparql-exists/docs/sparql-exists.html

+1

<TallTed> +1

<dallemang> +1

<AndyS> +1

<ipolikoff> 0

<pano> 0

<Nicky> 0

RESOLUTION: Close ISSUE-68 defining pre-binding using eval(D(G), Replace(PrjMap(X), μ)) as described in https://w3c.github.io/sparql-exists/docs/sparql-exists.html

ISSUE-170

I have deleted all uses of EXISTS, so this can be closed.

<TallTed> issue-170?

<trackbot> issue-170 -- SPARQL specifies a different reading for exists and blank nodes than needed for SHACL -- open

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

* cheers

<ipolikoff> PROPOSAL: Close ISSUE-170 since EXISTS has been removed, see https://lists.w3.org/Archives/Public/public-data-shapes-wg/2017Jan/0021.html

+1

<ipolikoff> +1

<dallemang> +1

<TallTed> +1

<pano> +1

<Nicky> +1

RESOLUTION: Close ISSUE-170 since EXISTS has been removed, see https://lists.w3.org/Archives/Public/public-data-shapes-wg/2017Jan/0021.html

<ipolikoff> PROPOSAL: Close ISSUE-204 as addressed by https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Nov/0113.html and a number of subsequent edits that make the issue obsolete

<dallemang> +1

+1

<ipolikoff> +1

<Nicky> Obsolete +1

RESOLUTION: Close ISSUE-204 as addressed by https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Nov/0113.html and a number of subsequent edits that make the issue obsolete

<pano> +1

<TallTed> +1

<ipolikoff> Discuss ISSUE-181

ipolikoff: This was brought up by Jose. Proposal there that slightly changes the language.
... implementers would have the option to stop

dallemang: This struck me as the right thing to do when I read the doc.

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

<ipolikoff> PROPOSAL: Close ISSUE-181 adopting proposal 2 in the wiki - engines must be able to return all results

<dallemang> +1

<Nicky> +1

<pano> +1

<ipolikoff> +1

<AndyS> +1

+1

<TallTed> +1

RESOLUTION: Close ISSUE-181 adopting proposal 2 in the wiki - engines must be able to return all results

ISSUE-217

<TallTed> issue-217

<trackbot> issue-217 -- Further clean up of paths versus predicate -- open

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

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

Advantages of 1a: Potentially easier to understand for end users Easier to query in cases where we are only interested in property declarations: { ?node sh:predicate ?predicate } versus { ?node sh:path ?path . FILTER isIRI(?path) } Better suitable for sh:Parameter declarations (which do not accept paths) - sh:Parameter is a subclass of sh:PropertyShape. This syntax has been in production for a long time. All examples, tools, tests and tutorials will co[CUT]

<dallemang> +q

Advantages of 1b: Potentially cleaner because properties are just a special kind of path Easier to ask "is this node a property constraint?": FILTER EXISTS { ?node sh:path ?any } versus FILTER EXISTS { ?node sh:path|sh:predicate ?any }

dallemang: Anecdote from provo, it had two ways of doing something.
... Some people thought this made the structure annoyingly verbose because you always had to distinguish between the complex structure or the simple structure.
... They always wanted the more powerful structure.

TallTed: Easier to understand leaves both predicate and path, which may be more confusing.
... My preference would be to go with sh:path

ipolikoff: 1b is delete sh:predicate altogether.

dallemang: leaning towards 1b
... danger of misunderstanding is contained.

<ipolikoff> STRAWPOLL: proposal 1a vs proposal 1b

1a) 0.5 1b) -0.5

<dallemang> 1a) -1 1b) +1

<TallTed> 1a: -1 1b: +1

<AndyS> (1a) 0 ; (1b) -0.5

<Nicky> 1a) 0 1b) 1+

<pano> 1a) 0.5 1b) 0

<ipolikoff> PROPOSAL: Close ISSUE-217 using proposal 1b

<TallTed> +1

0

<pano> 0

<ipolikoff> 0

<Nicky> +1

RESOLUTION: Close ISSUE-217 using proposal 1b

<ipolikoff> topic ISSUE-94

<TallTed> issue-94?

<trackbot> issue-94 -- Should RDF syntax requirements be separated from SHACL semantics -- open

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

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

<ipolikoff> PROPOSAL: Close ISSUE-94 as obsolete

+1

<pano> +1

<dallemang> +1

<Nicky> +1

<TallTed> +1

<ipolikoff> +1

RESOLUTION: Close ISSUE-94 as obsolete

<ipolikoff> Discuss ISSUE-92

ipolikoff: It's a piece of work to finish, there seems to be nobody who is passionate about this issue
... Some use cases would have to be addressed via SPARQL instead of the Core.
... Proposal is to close it by deleting sh:partition

We could theoretically add a flag on the shape, to make each QCR disjoint.

<TallTed> issue-92?

<trackbot> issue-92 -- Should repeated properties be interpreted as additive or conjunctive? -- open

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

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

ipolikoff: We could put such a flag in (we would cover more use cases), and remove it if it introduces problems in CRs
... I have no strong opinion and believe the partition the scenario isn't very important.

dallemang: I would vote for the path of least resistence.
... I don't feel passionate about this either way, i.e. deleting sh:partition is fine.

<ipolikoff> PROPOSAL: Close ISSUE-92 by adding a flag that will make QCRs disjoined

<ipolikoff> PROPOSAL: Close ISSUE-92 by adding a flag that will make QCRs disjoined and deleting sh:partition

+1

<TallTed> +1

<TallTed> dallemang: +1

<ipolikoff> +1

<pano> +1

<Nicky> +1

RESOLUTION: Close ISSUE-92 by adding a flag that will make QCRs disjoined and deleting sh:partition

ISSUE-202: Remove pre-binding from core

<TallTed> issue-202?

<trackbot> issue-202 -- Suggestion to remove pre-binding from core -- open

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

<TallTed> https://www.w3.org/2014/data-shapes/wiki/Proposals#ISSUE-202:_Remove_pre-binding_from_core

hknublau: I think this can be closed because it's handled by edits.

<ipolikoff> PROPOSAL: Close ISSUE-202 as obsoleted by edit

<TallTed> +1

<pano> +1

<ipolikoff> +1

+1

RESOLUTION: Close ISSUE-202 as obsoleted by edit

<Nicky> +1

<ipolikoff> topic ISSUE-208

<TallTed> issue-208?

<trackbot> issue-208 -- $this in aggregations -- open

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

<TallTed> https://www.w3.org/2014/data-shapes/wiki/Proposals#ISSUE-208:_.24this

<ipolikoff> PROPOSAL: Close ISSUE-208 as addressed by https://lists.w3.org/Archives/Public/public-rdf-shapes/2016Nov/0027.html

+1

<Nicky> +1

<ipolikoff> PROPOSAL: Close ISSUE-208 as addressed by https://lists.w3.org/Archives/Public/public-rdf-shapes/2016Nov/0027.html - made obsolete

<ipolikoff> +1

<TallTed> +1

<pano> +1

RESOLUTION: Close ISSUE-208 as addressed by https://lists.w3.org/Archives/Public/public-rdf-shapes/2016Nov/0027.html - made obsolete

ipolikoff: For next meeting we should look at current draft to decide whether it can be the final public working draft.
... everyone please review the draft.

<TallTed> trackbot: end meeting