RDF Data Shapes Working Group Teleconference

<scribe> scribe: simonstey

admin

RESOLUTION: Approve minutes of the 19 May 2016 Telecon: http://www.w3.org/2016/05/19-shapes-minutes.html

<marqh> me too

Disposal of Raised Issues

<Arnaud> PROPOSED: Open ISSUE-163, ISSUE-166

issue-163

<trackbot> issue-163 -- should "constraining" and other forms of "constraint" be used less in the specification -- raised

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

issue-166

<trackbot> issue-166 -- separate out advanced part of specification -- raised

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

<pfps> ./me I'll drop off and dial back in momentarily

<hknublau> +1

Arnaud: couple of non editorial questions that we may want to open

+1

scribe: relating to Tom's comments on the mailing list

<pfps> \me better

<Dimitris> +1

<marqh> +1

<pfps> +1

<kcoyle> +1

RESOLUTION: Open ISSUE-163, ISSUE-166

Public comment

<hknublau> Response draft looked OK to me.

Arnaud: pfps drafted a possible response addressing Tom's comments
... but I haven't seen any comments to his proposed response

marqh: I had a look at the comments and think opening respective issues makes sense

<Arnaud> PROPOSED: Send Peter's proposed response as the WG's response to Tom's comments https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016May/0224.html

+1

<pfps> +1

<marqh> +1

<Dimitris> +1

<hknublau> +1

<kcoyle> +1

RESOLUTION: Send Peter's proposed response as the WG's response to Tom's comments https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016May/0224.html

<pfps> I'll send out the message.

SHACL draft publication

Arnaud: I wanted to discuss that at last week's call already
... one of the advantages of publishing the document to the TR space is, that's stable, documented, and dated
... we should publish to TR space more often as we currently do
... I would like to hear from the editors what their point of view is

hknublau: I'm fine with publishing it now as it is

Dimitris: I agree with hknublau
... I would like to have some feedback on section 3

Arnaud: what do the other's think of publishing it now?

pfps: I just had a quick read-through the draft this morning and I'm not really happy as it is right now
... some repetitions, issues with the terminology section, etc.

jamsden: I think we missed an opportunity to publish the draft more often
... it's difficult to keep track of all the emails going on
... I think we should publish periodically

<kcoyle> no, ok for me

<pfps> The latest version of the SHACL spec is W3C Working Draft 28 January 2016. But in any case the WG is supposed to be reviewing the draft versions, not the WD versions. The WD versions are for *external* review.

marqh: I think publishing more often is a good idea

Arnaud: I think we should have some boilerplate text at the beginning of the document to make things clear
... i.e., that it's a moving target etc.

pfps: we aren't preparing WD for the WG
... the WG should review the ED

Arnaud: W3C used to require WGs to provide a heart beat every 3 months
... and we are way past that deadline now

<Arnaud> PROPOSED: Publish current SHACL editor's draft to TR space

<kcoyle> +1

<Dimitris> +1

Arnaud: we could also have certain parts of the document/issues highlighted just to make things more clear

+1

<marqh> +1

<hknublau> +1

<pfps> 0 The document is not very readable in its current state

<Labra> 0

<jamsden> +1

Arnaud: I think we should publish now and work hard to get a refined version out as soon as possible

marqh: I wanted to ask whether we should propose changes to e.g. paragraphs of the document directly in github
... where the editors can then decide whether they want to make it an issue

Arnaud: yes!

<kcoyle> uh oh!

RESOLUTION: Publish current SHACL editor's draft to TR space

issue-141

issue-141

<trackbot> issue-141 -- How to represent mixed datatype-or-class ranges -- open

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

Arnaud: last week we decided to postpone it
... I don't want to force this issue now; shall we postpone it as hknublau suggests since it's impacted by other issues?

<scribe> ... postponed!

issue-160

issue-160

<trackbot> issue-160 -- Shall we generalize sh:valueShape to sh:shape -- open

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

Arnaud: no one chimed in on the discussion at the proposals page
... pfps raised some concerns

<Dimitris> for me it is fine to generalize sh:valueShape

pfps: right now there are at least 3 descriptions of what valueShape actually does
... it's not clear on what of those the proposed generalization is based on
... such a generalization would further have implications of other parts of the section too

<pfps> Actually the first sentence of 4.1.1 sh:valueShape is currently incorrect.

marqh: is the text in the issue the complete text that needs to be changed?
... or is there more to it?

hknublau: the proposal is very brief
... I didn't create an extra branch for this issue
... we would only have to make two small changes

<Arnaud> PROPOSED: Close ISSUE-160, renaming sh:valueShape to sh:shape, adding sh:NodeConstraint to its context

<hknublau> +1

<Dimitris> +1

<kcoyle> +1

<pfps> There are similar problems for sh:minCount, sh:maxCount, sh:equals, and quite a few more.

<pfps> +1

<Labra> +1

+1

<jamsden> +1

<marqh> +1

RESOLUTION: Close ISSUE-160, renaming sh:valueShape to sh:shape, adding sh:NodeConstraint to its context

pfps: my remark is a follow-up on the first sentence of respective sections
... I think there's a utility in having a short description of what's going on
... as long as it's correct

kcoyle: what's the section number we're talking about

hknublau: e.g. 4.7.1

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

<pfps> 4.7.1 sh:valueShape

<pfps> The property sh:valueShape can be used verify that all values of the given property must have a given shape. The value type of sh:valueShape is sh:Shape, but the rdf:type triple of those shapes can be omitted.

Dimitris: we can either be very verbose or make up a new term for all those cases and use that

Arnaud: the editors should try to fix those parts as they progress

<pfps> In most cases, uising "value node" can produce a short, correct, informal description.

issue-133

Arnaud: I want to make progress on all syntax related issues

<Arnaud> https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016May/0080.html

Dimitris: the problem was that we have sh:constraint containing a group of constraint types
... e.g., nodeconstraint, sparql constraint, ...
... which might cause some problems if one wants to exclude certain constraint types

hknublau: I'm generally supportive of splitting it up
... e.g, using sh:constraint for nodeconstraints only (or even delete it at all) and spawn of another property for sparqlconstraints only

+q

<pfps> Dimitri's proposal retains the dual-control nature of constraint typing. A property constraint, for example, has SHACL type sh:PropertyConstraint but also sh:property is used only for property constraints. This dual control setup ends up being complex.

<pfps> Dimitri's proposal does eliminate some of the complexity.

hknublau: we could mark those properties, such that an engine could identify them

pfps: we have default types, explicit typing, and those properties for constraint typing
... and I think we should try to reduce the complexity

marqh: I think incremental regularizing is a step in the right direction
... makes things easier to comprehend

Dimitris: I don't have a clear solution to pfps's concerns

<pfps> The problem with incremental steps is that they often do not lead to the best solutions, only locally best ones.

<Arnaud> PROPOSED: Adopt Dimitris's proposed simplifications and regularizations descrbied in https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016May/0080.html

there are 2 aspects to 133

<marqh> is the proposal explicitly this: https://github.com/w3c/data-shapes/compare/editorial-dk?diff=split&name=editorial-dk

issue-131

<trackbot> issue-131 -- The definition of sh:hasShape has errors and holes -- open

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

whoops

issue-133

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

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

<Dimitris> PROPOSED: simplify sh:constraint and allow only sh:NodeConstraints, SPARQL constraints will be defined with a separate property

+1

<hknublau> +1

<Dimitris> +1

<kcoyle> 0

<pfps> 0 There are lots of better ways to simplify the syntax, including having only one property that links from shapes to constraints and distinguishing the different kinds of properties by their types.

<Labra> +0.5

<marqh> +1

RESOLUTION: Simplify sh:constraint and allow only sh:NodeConstraints, SPARQL constraints will be defined with a separate property

kcoyle: I don't think that just having "sparql" there isn't doing the trick
... it's not telling me that it's a constraint

<Dimitris> PROPOSED: sparql constraints will be defined with the sh:sparql predicate and rename the existing sh:sparql to sh:select and sh:ask

pfps: by that logic sh:property & co would be affected too

<pfps> sh:property and sh:inverseProperty have the same problem as sh:shape

<kcoyle> +q

hknublau: there are pros and cons to this, I don't have a strong opinion on this

+q

<pfps> Similarly "property" already has an external meaning.

kcoyle: I agree that it could affect many others too, but if we use something like SPARQL.. I think it's very "nounish"
... I don't think we should use words that mean other things

simonstey: what about sh:native?

Dimitris: why not using sh:node and sh:sparql for now and raise an issue for potentially renaming them in the future

<Dimitris> PROPOSED: sparql constraints will be defined with the sh:sparql predicate and rename the existing sh:sparql to sh:select and sh:ask. Rename sh:constraint to sh:node

<Dimitris> PROPOSED: sparql constraints will be defined with the sh:sparql predicate and rename the existing sh:sparql to sh:select and sh:ask

0

<hknublau> +1

<Dimitris> +1

<kcoyle> +1

<pfps> 0

<Labra> 0

RESOLUTION: sparql constraints will be defined with the sh:sparql predicate and rename the existing sh:sparql to sh:select and sh:ask

Arnaud: if someone feels the need for renaming them, file an issue

hknublau: I think there was consensus on the scope renaming
... maybe we should tackle that next

ISSUE-148

<trackbot> issue-148 -- non-uniform syntax in scopes -- open

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

<Arnaud> https://www.w3.org/2014/data-shapes/wiki/Proposals#ISSUE-148:_Scope_declaration_simplification

hknublau: there are two aspects to it
... 1) change syntax of scopes, making it a single property
... 2) whether we still need allsubjects/allobjects scopes

<kcoyle> +q

<Arnaud> PROPOSED: For propertyScope and inverse property scopes, do not use sh:scope but the dedicated properties sh:scopeProperty and sh:scopeInverseProperty that point to a property directly. e.g. ex:shape sh:propertyScope ex:myPredicate .

<pfps> Except that SIP already has an external meaning.

kcoyle: those names don't make sense

[kcoyle and hknublau discussing about the meaning of the term scope]

<marqh> sh:scopeProperty and sh:scopeInverseProperty make sense to me

Dimitris: I'm with hknublau on this

kcoyle: there are those levels in the order of the workflow, and I think scoping and constraining makes sense

<Arnaud> PROPOSED: For propertyScope and inverse property scopes, do not use sh:scope but the dedicated properties sh:scopeProperty and sh:scopeInverseProperty that point to a property directly. e.g. ex:shape sh:propertyScope ex:myPredicate

<Dimitris> +1

kcoyle: but this seems more like constraining

<hknublau> +1

<kcoyle> .5

<pfps> +1, although the names don't work for me

<marqh> +1

+0.5

<Labra> +0.5

RESOLUTION: For propertyScope and inverse property scopes, do not use sh:scope but the dedicated properties sh:scopeProperty and sh:scopeInverseProperty that point to a property directly. e.g. ex:shape sh:propertyScope ex:myPredicate

+q

<Arnaud> wow

<Arnaud> somehow the meeting ended

<hknublau> Just as the tension was unbearable. Could you finish the sentence in writing?

<pfps> It's a sign from WEBEX!

<marqh> our time is up: webex has spoken :|

<Arnaud> is it just me?

no worries

my mistake

<Dimitris> I lost the interesting part of SImon's talk

<Arnaud> ok, that was very unfriendly from Cisco ;-)

<kcoyle> simon, can you finish your sentence?

I thought you proposed propertyScope rather than scopeProperty

my fault

<Arnaud> ok

<hknublau> Ok then.

<Arnaud> so, we will end the meeting on this then (have to!)

<hknublau> Bye.

<kcoyle> propertyscope at least is understandable as words

<Arnaud> thank you all for joining

<kcoyle> bye

<Arnaud> thank you simon for scribing

<Arnaud> talk to you next week

<Arnaud> hknublau and Dimitris, I will follow up on publishing the draft but I believe we should already be set with Echidna because we published 2 drafts

<Arnaud> the first one has to be published manually but the second one ought to have been published with Echidna

<Arnaud> I'll send an email

<Arnaud> trackbot, end meeting