W3C

RDF Data Shapes Working Group Teleconference

30 Jun 2016

Agenda

See also: IRC log

Attendees

Present
simonstey, ericP, hsolbrig, AndyS, Dimitris, kcoyle, TallTed, jamsden, pfps
Regrets
Arnaud, markq, hknublau
Chair
ericP
Scribe
AndyS, hsolbrig

Contents


<AndyS> Hello

<AndyS> I'll scribe

<AndyS> scribenick: AndyS

<pfps> OK - the punishment for bad scribing is expulsion from the group, right?

Admin

<ericP> Approve minutes of the 23 June 2016 Telecon: http://www.w3.org/2016/06/23-shapes-minutes.html

<pfps> minutes looked fine to me

+1

<ericP> PROPOSED: Approve minutes of the 23 June 2016 Telecon: http://www.w3.org/2016/06/23-shapes-minutes.html

RESOLUTION: Approve minutes of the 23 June 2016 Telecon: http://www.w3.org/2016/06/23-shapes-minutes.html

Disposal of raised issues

pfps: 171 and 172 are more like glitches
... 170 is the SPARQL issues.
... as my leaving present to you all.

EricP: thanks to pfps for his contributions on the working group.
... quite a lot of discussion

<TallTed> +1 open all three...

<ericP> PROPOSED: raise issue-170

EricP: any objections to raising 170?

<pfps> s/raise/open/?

<ericP> PROPOSED: open issue-170

<pfps> +3, distributed evenly

<Dimitris> +1

<hsolbrig> +1

<simonstey> +1

<TallTed> +1

<kcoyle> +1

RESOLUTION: open issue-170

<jamsden> +1

<hsolbrig> ... pfps: 171 and 172 are glitches bordering on editorial

<ericP> scribenick: hsolbrig

<simonstey> issue-171

<trackbot> issue-171 -- sh:classIn SPARQL definition incorrect -- raised

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

<simonstey> issue-172

<trackbot> issue-172 -- the sh:nodeKind SPARQL definition is unnecessarily complex -- raised

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

<ericP> PROPOSED: open issue-171, issue-172

<pfps> +1

<Dimitris> +1

<kcoyle> +1

<jamsden> +1

<simonstey> +1

<TallTed> +1

+1

RESOLUTION: open issue-171, issue-172

ISSUE-41: property paths

<simonstey> issue-41

<trackbot> issue-41 -- Using property paths to refer to values/types? -- open

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

simonstey: issue raised more than a year ago. About including property paths...
... issue was resolved back then as "nice feature" but could be done through native sparql
... issue was revived and Holger made a proposal that was similar to original.

Couldn't hear Dimitris' response

Dimitris: Idea was accomodidate Simon's issue
... remove reverse property constraint and use sh:predicate for forward predicate or list based path

<AndyS> scribenick: AndyS

Dimitris: only simple paths e.g. inverse

EricP: not * and + what about "/"

Dimitris: it's a list so each element is a path step

EricP: SPARQL is all ways to satisfy the path

<simonstey> -q

<pfps> the question is whether there is, in effect, a DISTINCT in the query

<ericP> PROPOSED: change PropertyConstraint and InversePropertyConstraint to one type of Constraint with either a predicate (which implies arcs-out) or a path. The path does not include * or + and cardinalities on the resulting node value set are satisfied by combination of cardinalities on the steps.

pfps: This is a new kind of thing - (noises)

<pfps> is this something new? before all that counted was the number of values, now this appears to be counting paths of course, the two where (roughly) the same before.

hsolbrig: how does inverse realised in this design?

<Dimitris> sh:path ( sh:invesre ex:p)

hsolbrig: how is inverse predicate realised in this design?

<Dimitris> I do not remember the exact syntax Holger proposed but is similar to the above

EricP: we have a fixed series of steps inc reverse path

<simonstey> https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Jun/0134.html

<Dimitris> sh:path ( ex:p1 [sh:invesre ex:p2] ex:p3)

SPARQL -- ex:p1/^ex:p2/ex:p3

<ericP> sh:path ( ex:p1 ex:p2b ex:p3 ) . ex:p2b sh:inverse ex:p2 .

EricP: In my example - I put in an IRI for the bnode.

Dimitris: deals to be sorted out
... can also have nested paths with nested () which are bnodes in the grap.

EricP: ready to vote?

<Dimitris> +1

<simonstey> I made a proposal a year ago https://lists.w3.org/Archives/Public/public-data-shapes-wg/2015Jul/0070.html (but it's not using lists and is a bit verbose though)

EricP: this proposal unblocks progress on syntax.

<ericP> PROPOSED: change PropertyConstraint and InversePropertyConstraint to one type of Constraint with either a predicate (which implies arcs-out) or a path. The path does not include * or + and cardinalities on the resulting node value set are satisfied by combination of cardinalities on the steps. Exact syntax (e.g. nested paths, behavior of bnodes) to be resolved.

simonstey: pointer in minutes is good.

<simonstey> +1

<pfps> 0

<Dimitris> +1

<hsolbrig> +0

<kcoyle> 0

<jamsden> +0

<TallTed> +1

EricP: advice to editors - tentative support

RESOLUTION: change PropertyConstraint and InversePropertyConstraint to one type of Constraint with either a predicate (which implies arcs-out) or a path. The path does not include * or + and cardinalities on the resulting node value set are satisfied by combination of cardinalities on the steps. Exact syntax (e.g. nested paths, behavior of bnodes) to be resolved.

ISSUE-52: abstract syntax

EricP: email -- https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Jun/0159.html on shex/shacl syntax
... was up to date until the path resolution above

pfps: Didn't see a need for an abstract syntax.

jamsden: What is the purpose here?

EricP: Purpose is to have a terse semantics and relate a shex parse tree to shacl (for the overlap)
... e.g. SPARQL does abstract syntax to algebra
... this is a "shapes algebra" equivalent

jamsden: it creates redundancy in defn terms
... how does it affect the reSpec?

EricP: This is not huge. Little or no automation needed.
... not a machine readable tool

jamsden: suggest non-normative appendix?

simonstey: xtext in Eclipse useful? Auto generate parsers from this.

EricP: Purpose today is to highlight its existence.

ISSUE-139: Universal applicability

<simonstey> issue-139

<trackbot> issue-139 -- Can all constraint properties be applied in all scenarios? -- open

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

pfps: worry is that language is complex, many restrictions and rules, so maybe make any constraint anywhere - there has been push back.
... everything is a constraint.
... interacts with path

<ericP> NC, PC, IPC table

pfps: see table in sec 4 ... quite complicated ... so let anything happen
... alternative is to remove the SHACL rules in the table and allow all possible uses even if they do not have much usefulness.

"Generalised RDF"

pfps: in some places e.g. can't have literals in some places in RDF - we are charged to future proof SHACL so may change. And some tripestores allow it.

<Dimitris> all this are now solved with the new path syntax

<Dimitris> there is no longer a distinction between PC & IPC

pfps: effect of my proposal is to put check marks everywhere.

Dimitris: only NC and paths now
... table will by modified / removed.

<pfps> so far, this is not about performance - that's a separate issue

TallTed: some strictly silliness is useful to check for silly data.

<Zakim> ericP, you wanted to describe the 3 apparent classes of Property

TallTed: it is a valid validation

pfps: sounds reasonable

ISSUE-133: syntax

<simonstey> issue-133

<trackbot> issue-133 -- syntax simplification and regularization -- open

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

pfps: some of this has already been resolved.
... ducks example
... shape or constraint : striped syntax leads to a constraint just to keep two shapes apart.
... we can have just constraints

EricP: shex - just triple constraints

<ericP> I heard that as "ConApe" as in "ConstrationShape"

pfps: constraint or shape in any place

<pfps> This is recapping a long discussion of quite some time ago.

Ptr to email?

Dimitris: closer to pfps's syntax now - diff is that he works on sets
... node constraints else quite similar.

(detailed discussion)

pfps: things on sets can't be in NCs

ISSUE-150: nested severities

<Dimitris> https://www.w3.org/2014/data-shapes/track/issues/150

Dimitris: not intuitive how it would work.
... link to info or violations
... an area for discussion to get to a proposal.
... sh:Warning with sh:Violation and also sh:Info inside

pfps: issues with composition of shapes

EricP: preprocessing step for nested constraints/violations?

pfps: handles level at runtime to pass highest priority
... separately how do the messages come out?

Dimitris: I proposed treat everything as an error

<pfps> my problem with violation levels is that a shape that produces only informational results can't be used inside another shape

<pfps> Dimitris's proposal would at least change the validation reports that are emitted, so it is not just editorial

Dimitris: can make proposal for a resolution

<kcoyle> bye Peter!

EricP: suggest Dimitris writes consolidated proposal

<Dimitris> bye Peter!

<pfps> bye

Farewell to Peter!

<simonstey> bye peter

<ericP> trackbot, end meeting?

Summary of Action Items

Summary of Resolutions

  1. Approve minutes of the 23 June 2016 Telecon: http://www.w3.org/2016/06/23-shapes-minutes.html
  2. open issue-170
  3. open issue-171, issue-172
  4. change PropertyConstraint and InversePropertyConstraint to one type of Constraint with either a predicate (which implies arcs-out) or a path. The path does not include * or + and cardinalities on the resulting node value set are satisfied by combination of cardinalities on the steps. Exact syntax (e.g. nested paths, behavior of bnodes) to be resolved.
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.143 (CVS log)
$Date: 2016/07/13 18:25:36 $