RDF Data Shapes Working Group Teleconference -- 01 Feb 2017

<ipolikoff> present

<pano> https://www.w3.org/2009/CommonScribe/manual.html

<ipolikoff> scribenick: Nicky

ipolokoff: Opens the meeting

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

<hknublau> +1

<Dimitris> +1

<pano> +1

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

ipolikoff: Three issues opened since last meeting

<ipolikoff> ISSUE-220: defining shapes in a shapes graph

<trackbot> Notes added to ISSUE-220 defining shapes in a shapes graph.

<ipolikoff> PROPOSAL: OPEN ISSIUE-220

<Dimitris> +1

<hknublau> +1

<pano> +1

RESOLUTION: OPEN ISSIUE-220

hknublau: proposal to close it, because the definition has been formilised already

<ipolikoff> PROPOSAL: CLOSE ISSIUE-220 as addressed in section 2.1

<hknublau> +1

<Dimitris> +1

<ipolikoff> PROPOSAL: CLOSE ISSUE-220 as addressed in section 2.1

RESOLUTION: CLOSE ISSUE-220 as addressed in section 2.1 http://w3c.github.io/data-shapes/shacl/#shapes

<TallTed> +1

<ipolikoff> ISSUE-221: Simplify the class hierarchy of shapes

<trackbot> Notes added to ISSUE-221 Simplify the class hierarchy of shapes.

<TallTed> issue-221?

<trackbot> issue-221 -- Simplify the class hierarchy of shapes -- raised

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

<ipolikoff> PROPOSAL: ISSUE-221

<ipolikoff> PROPOSAL: OPEN ISSUE-221

hknublau: Question: we can close this one and open 211, since these are related

Dimitris: Does it make a difference if we do it via 211?

hknublau: We should do it via 211, since if we revisite one part we should reviste through the whole issue

<hknublau> 0

<TallTed> +1 open 221

<Dimitris> 0 it makes no difference with which issue we track it with

<ipolikoff> +1

<pano> +0.5

ipolikoff: I think that it is clean to open issue 211, since there already has been a chain of emails about 211.

RESOLUTION: OPEN ISSUE-221

<Dimitris> https://lists.w3.org/Archives/Public/public-data-shapes-wg/2017Feb/att-0001/SHACLmetamodelhistory.pdf

dimitirs: I sent a mail this morning about the current version

dimitris: latest model improved the language, everthing is more lingual.
... still some problems
... it doenst make sense what type of shape it is. Therefore a simpeler hierarchy is created instead of different shape types
... propertyshapes and nodeshapes makes SHACL more complex than only just useshapes
... is there is no reason for it (type of shapes not used in the model), it makes it only confusing for the user

pano: See the problem, tradeoff between semanic enrichment and simplicity
... semantic enrichtment makes the model a better sophisticated model, removing parts of this will make it more confusing

hknublau: returning all violations of the shapes important
... difference in violations between property and node shapes is important, because violation handling are determined by design
... possible to rename nodeShapes to just node, to resolve the asymmerty

<hknublau> ex:Class a owl:Class ; owl:onProperty ex:property ; owl:minCardinality 1 .

hknublau: The change is unhelpfull if we would remove the subclasses, because it is a normal way of defining the it with subclasses
... Owl and rdfs are working in the same way

<ipolikoff> Holger, we can't hear you

Tallted: hknublau proposal would be to change the range to only node shapes

ipolikoff: I find the current model clear
... with the different constraintnodes

Tallted: I think we would to read the versions side by side

<ipolikoff> PROPOSAL: CLOSE ISSUE-221 by renaming sh:shape to sh:node and changing its range

<hknublau> CRAP! My meeting crashed

<hknublau> I talked 3 minutes to myself. Rejoining...

<hknublau> Webex crashed again. I will reboot.

ipolikoff: one other issue to deal with, on pre-binding
... should dimitris proposal be rewritten

Tallted: no it is clear enough

ipolikoff: what is in the specs now, there should be one name changing and one range changing
... dimitris proposal is clear, the otherone should be clear as well

hknublau: Single concept of a shape has already been achieved in the current design by the subclasses of a shape
... we do not gain anything by deleting the subclasses
... it is a matter of taste

tallted: no body is looking for the argument at this moment
... understand the clear definition in the draft for bookkeeping purposes

<hknublau> Proposal: rename sh:shape to sh:node, the values of sh:node must be well-formed node shapes.

tallted: unfortunatly a pdf instead of WIKI, WIKI could be easily edited by other users
... it is clear what the situation was (like the scope and thoughts) while do the editing
... by changing again the specs, this is causing all the reopens op closed issues

pano: I think it is not true, that the different shape type have other behavioral.
... using sh:property has a other behaviour than using sh:shape

s/< Dimitris: using sh:property has a other behaviour than using sh:shape>/<dimitris: using sh:property has a other behaviour than using sh:shape>/

<TallTed> s/s\/pano/s pano

hknublau: the difinitions of the different shape types are clear defined in the model
... you can create invalid things everywhere

ipolikoff: we have to propose both
... strawpoll to know how people feel about the different proposals

<ipolikoff> STRAWPOLL: CLOSE ISSUE-221 by renaming sh:shape to sh:node and changing its range, the values of sh:node must be well-formed node shapes.

<hknublau> +1

<ipolikoff> STRAWPOLL: a) CLOSE ISSUE-221 by renaming sh:shape to sh:node and changing its range, the values of sh:node must be well-formed node shapes. b) do nothing c) removing sh:NodeShape, sh:PropertyShape and removing sh:propery

<hknublau> a) +1 b) +0.8 c) -1

<TallTed> a +1 b +0.5 c 0

a) 0 b) +1 c) 0

<ipolikoff> a) +.5 b) +.5 c) -.8

<pano> a) +1 b) 0 c) -0.5

<Dimitris> a) -0.8 b) -0.9 c) +1

ipolikoff: A seems to have the most votes

<TallTed> PROPOSAL: CLOSE ISSUE-221 by renaming sh:shape to sh:node and changing its range, the values of sh:node must be well-formed node shapes.

<ipolikoff> PROPOSAL: CLOSE ISSUE-221 by renaming sh:shape to sh:node and changing its range, the values of sh:node must be well-formed node shapes.

<hknublau> +1

<TallTed> +1

<pano> +1

<ipolikoff> +1

<Dimitris> -.8

RESOLUTION: CLOSE ISSUE-221 by renaming sh:shape to sh:node and changing its range, the values of sh:node must be well-formed node shapes.

<ipolikoff> ISSUE-222: Response to "On pre-binding"

<trackbot> Notes added to ISSUE-222 Response to "On pre-binding".

ipolikoff: Issue 222 this regards email from peter, about pre-binding
... shall we open the issue?

<TallTed> issue-222?

<trackbot> issue-222 -- Response to "On pre-binding" -- raised

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

<ipolikoff> PROPOSAL: OPEN ISSUE-222

<hknublau> +1

<Dimitris> +1

<pano> +1

<ipolikoff> +1

<TallTed> +1

RESOLUTION: OPEN ISSUE-222

hknublau: andy knows this the best
... good thing peter sent his comments upfront

ipolikoff: action item for andy, to propose additionts to the spec

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

<hknublau> +1

nicky: Missing greaterThan and greaterOrEquals is there a reason

hknublau: can use them inverse
... we can use the lessthan inverse

Tallted: more work for implementation to have both

<ipolikoff> +1

<TallTed> +1

ipolikoff: we should open an issue so we can get opnions

<pano> +1

nicky: not necessary to open an issue, just noticed

<Dimitris> 0

dimitris: the changed a lot last week, but I dont want to block the publication

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

ipolikoff: that the text changed a lot, is the reason why we want to publish it, so more people can take a look at it
... we publish the spec and we will see what happens

<hknublau> trackbot, end meeting

- DRAFT -

RDF Data Shapes Working Group Teleconference

01 Feb 2017

Attendees

Contents

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output