RDF Data Shapes Working Group Teleconference

preent+ dimitris

<scribe> scribenick: dimitris

Admin

<Arnaud> PROPOSED: Approve minutes of the 16 July Telecon: http://www.w3.org/2015/07/16-shapes-minutes.html

<pfps> minutes look OK to me

arnaud: let's get started, approval of the minutes of the last call

RESOLUTION: Approve minutes of the 16 July Telecon: http://www.w3.org/2015/07/16-shapes-minutes.html

<simonstey> me most likely

Disposal of ISSUE-5: Resource Shape Association

Arnaud: holger pointed out that with resolution 62 we can close issue 5
... and issue 3

<pfps> I am unclear as to how ISSUE-62 covers ISSUE-5

<simonstey> related to that: http://w3c.github.io/data-shapes/shacl/#scopesAndFilters

<Arnaud> issue-62

<trackbot> issue-62 -- Selection or filtering by arbitrary expressions and shapes -- closed

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

pfps: resolution of issue 62 is selection/fitering

<simonstey> +q

simonstey: I think it covers issue 5
... it defines how shapes can be associated with resources

arnaud: does 62 cover all or are there other types of associations?

<pfps> OK, scopes cover ISSUE-5 as far as I am concerned

dimitris: I think issue 5 can be closed but not sure about issue 3

pfps: I am happy to close issue 5

<Arnaud> PROPOSED: Close ISSUE-5 based on resolution of ISSUE-62, per Holger's email https://lists.w3.org/Archives/Public/public-data-shapes-wg/2015Jul/0067.html

<simonstey> +1

+1

<pfps> +1

<TallTed> +1

<BartvanLeeuwen> +1

RESOLUTION: Close ISSUE-5 based on resolution of ISSUE-62, per Holger's email https://lists.w3.org/Archives/Public/public-data-shapes-wg/2015Jul/0067.html

arnaud: let's see issue 3

ISSUE-3: How is a shape associated with a graph?

arnaud: holger also said in email that we could close issue-3 for the same reason

<trackbot> issue-3 -- How is a shape associated with a graph? -- open

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

<pfps> I don't think that the resolution of ISSUE-62 speaks to ISSUE-3 at all

<simonstey> issue-3 is basically about an owl:imports for SHACL

dimitris: issue 3 is about a higher level than shape scopes

arnaud: let's leave issue 3 and move on to issue 65

ISSUE-65: A consistent and cohesive definition of shapes, scopes, and constraints

<trackbot> issue-65 -- A consistent and cohesive definition of shapes, scopes, and constraints -- open

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

arnaud: there was some discussion on this but didn't conclude

<BartvanLeeuwen> https://w3c.github.io/data-shapes/shacl/

BartvanLeeuwen: in the email conversation holger said he updated the draft, is this the location?

arnaud: yes

<pfps> Holger's proposal is: shape = scope + [filter +] constraints

pfps: shapes has a scope, optional filter and a set of constraints. a global shape doesn't look that way, it doesn;t have a scope, it just runs on everything

<pfps> But a global shape doesn't look like that - maybe you can have an implicit scope for them

<simonstey> and then you have different kinds of general scopes https://w3c.github.io/data-shapes/shacl/#scope

arnaud: there is difference of how you used the terms

<Labra> +present labra

pfps: you have to be careful to not exclude the other posibilities

<simonstey> but we have sh:constraint which can be defined inside a shape

pfps: as long as the wording is right and covers the corner cases it is fine

arnaud: what do we need to change in the draft

pfps: many places in the draft got me confused. There are a bunch of cases beyond the ones mentioned in the issue where the wording needs to change

<simonstey> +q

arnaud: first we need to agree on the definition of the terms and then the spec has to be inline with the definitions

simonstey: Holger should be involved in this

<BartvanLeeuwen> +1

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

arnaud: if you look at section 2 on shapes (...reading definition...)
... are we ok with that?

pfps: I don't agree with that. the example afterwards is much better but the definition is not what shapes and constraints are

<pfps> a constraint, by itself, doesn't define a restriction on anything

<pfps> a shape is not a group of constraints have have the same focus nodes

arnaud: I would like to have a section on terminology

<pfps> the constraints in a shape work in concert, but that's very different from what is said at the beginning of section 2

TallTed: a glossary would be useful
... peter what is your definition?

<simonstey> constraint: https://w3c.github.io/data-shapes/shacl/#general-constraints

pfps: constraints by them selves don't do anything
... you 'd have to say something like : a shape defines a constraint / restriction on a graph
... and shapes are evaluated based on their scopes and filter and once they are selected they are executed
... shapes are the ones that do things
... shape would be a restriction on how a graph should be
... a constraint says x has to have a name, it's nothing by itself
... constraints are the worker bees that do the validations
... after you evaluate the filters/scope then you evaluate constraints on the remaining nodes

TallTed: we can have something graphical along with some text to define that. I agree with your definitions

pfps: my proposal reads perfect, I cannot easily adjust it to another proposal I do not agree in

arnaud: we decided to use Holger's proposal and merge it with Peter's proposal
... and Peter's proposal reads really well and the current draft can really benefit from

<TallTed> +1 simonstey re http://w3c.github.io/data-shapes/shacl/images/SHACL-Validation-Process.png

arnaud: everyone should read Peter's proposal and see how definitions are introduced

pfps: in my wording shapes and constraints are flipped
... the reason I did this was by influencing from ShEx

tallted: constraints are components of a shape

arnaud: I asking people for their opinion on this

BartvanLeeuwen: I hear constraints are nothing by themselves
... it is still rdf

<pfps> The syntax permits reuse of constraints, i.e., a constraint can be in several shapes

constraint can the same whenever you need it e.g. on a social number

pfps: in the editors draft there is nothing that prohibits reuse
... libraries in RDF does not ease inclusion

<pfps> Actually, RDF is missing the facilities to set up libraries, in that it doesn't have an inclusion mechanism

arnaud: there is not issue with scopes but we need to tackle this before a public WD

<BartvanLeeuwen> +1

arnaud: decide on the definition and try to update the spec

hknublau: I am happy with the current definition

<hknublau> Constraint is used as in SPIN, so for these people it’s consistent.

arnaud: Peter states that the definition is wrong, I'd like to request for next week's call we decide on the definitions

+1

scribe: let's move to issue-76, unless someone would rather tackle a different one

<pfps> I would prefer knowing what issues are going to be discussed before the meeting so that I can do any homework required

simonstey: I opened some issues holger linked like issue 74 that we can easily close
... at least the naming issues are easy to resolve

holger: I proposed trivial issues since people might be on holidays

ISSUE-37: Naming of node kind facet

<trackbot> issue-37 -- Naming of node kind facet -- open

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

<simonstey> https://www.w3.org/2014/data-shapes/wiki/Facet_Property_Names

holger: on the wiki page we decided on all except of node kind

<simonstey> https://w3c.github.io/data-shapes/shacl/#property-constraints-property

tallted: we should see the rest of the naming we decided
... let's use valueKind to be consistent

<pfps> I care very little about these kinds, and would not vote against valueKind. However, I view it as a very unfortunate name, for the reasons that Holger states

hknublau: valueKind could be confused with type

<Arnaud> STRAWPOLL: a) stick with sh:nodeKind, b) rename sh:nodeKind to sh:valueKind

hknublau: let's vote

<pfps> a

<hknublau> a) +0.7 b) 0

<BartvanLeeuwen> a

<simonstey> a) +0.5 b) 1

<Labra> a) +0.5 b) 0

a

<TallTed> a +1 b -0.5

<Arnaud> PROPOSED: Close ISSUE-37, keeping sh:nodeKind

<hknublau> +1

<simonstey> +1

<TallTed> +1

<BartvanLeeuwen> +1

+1

<pfps> +1

RESOLUTION: Close ISSUE-37, keeping sh:nodeKind

<simonstey> http://www.w3.org/2014/data-shapes/track/issues/59

ISSUE-59: What are the default values for cardinalities?

<trackbot> issue-59 -- What are the default values for cardinalities? -- open

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

<pfps> I'm happy with 0,* as that is the least restrictive, even though ShEx used 1,1

hknublau: in the current spec default is [0,unbound]

labra: I have no problem

<simonstey> sh:minCount xsd:integer The minimum cardinality. Optional. Default value is 0.

<simonstey> sh:maxCount xsd:integer The maximum cardinality. Optional. Default interpretation is unlimited.

<pfps> because ShEx is 1,1

arnaud: do you think if we decide on [0,unbound] other ShEx people are ok?

labra: I think yes but cannot speak for them

<Arnaud> PROPOSED: Close ISSUE-59, sticking with the current draft which is {0, unbound/unlimied}

<simonstey> +1

<hknublau> +1

<BartvanLeeuwen> +1

arnaud: Eric can object afterward

+1

<Labra> +0.5

<pfps> +1

ericp: I would prefer [1,]1

s/[q.]1/[1,1]/

arnaud: let's have a strawpoll

<Arnaud> STRAWPOLL: a) stick with {0, unbound/unlimited}, b) changed to {1,1}

<simonstey> a) 1 b) 0

<pfps> 1, -0.7

<hknublau> a) +1 b) -0.5

<Labra> a) 0.5 b) 1

<Arnaud> ericP: a) -.5, b) +1

a) +1 b) -0

<TallTed> a) +1 b) -0.5

arnaud: I see majority voting on (a)

hknublau: (a) is more natural to what people expect

RESOLUTION: Close ISSUE-59, sticking with the current draft which is {0, unbound/unlimited}

<hknublau> http://www.w3.org/2014/data-shapes/track/issues/61

ISSUE-61: Direction of individual scoping: sh:nodeShape vs. sh:individualScope

<trackbot> issue-61 -- Direction of individual scoping: sh:nodeShape vs. sh:individualScope -- open

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

pfps: do we have individual scope?

hknublau: we only have class scope and filtering
... for consistency we could link from the scope to the intances but it is not easy

+q

<simonstey> +1 to holger's point

<pfps> pointing from the shape to the individual is in essence a kind of scoping, so you don't need a whole new kind of relationship

dimitris: I would prefer reverse relations or link to an intermediate node

*example ex:resA sh:nodeShape [ ex:scope http://dbpedia.org ex:shape ex:Shape]

hknublau: it is not easy to work on linked data
... this triple is shows up in all forms and it is annoying

dimitris: that is why I don't like mixing data with validation context

arnaud: let's leave this and Dimitris can write an email on this

ISSUE-64: Should the Core vocabulary support datatype facets such as sh:minInclusive and sh:maxLength?

<trackbot> issue-64 -- Should the Core vocabulary support datatype facets such as sh:minInclusive and sh:maxLength? -- open

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

<pfps> Sure, let's have a coherent set of stuff in the core

<Arnaud> PROPOSED: Close ISSUE-64, adding minInclusive/minExclusive/maxInclusive/maxExclusive, minLength/maxLength (XSD also has xsd:length), pattern (regex)

<Arnaud> PROPOSED: Close ISSUE-64, adding minInclusive/minExclusive/maxInclusive/maxExclusive, minLength/maxLength (dropping xsd:length), pattern (regex)

<pfps> +1

+1

<BartvanLeeuwen> +1

<hknublau> +1

<simonstey> +1

* I did not hear Eric*

ericP: on the ShEx survey there was equal support for xsd facets

<Labra> 0.5

<TallTed> +1

RESOLUTION: Close ISSUE-64, adding minInclusive/minExclusive/maxInclusive/maxExclusive, minLength/maxLength (dropping xsd:length), pattern (regex)

<BartvanLeeuwen> thx and bye

arnuad: thank you and see you next week

<Arnaud> trackbot, end meeting