RDF Data Shapes Working Group Teleconference

<kcoyle> it''s not on the telecon page, and never asked before, afaik

<Arnaud> indeed

<Arnaud> there have been problems of people accessing webex and misusing it

<Arnaud> so eric had to tighten the security

<Arnaud> and entering the password is now mandatory

<Arnaud> we'll get it on a protected page for future calls

<Arnaud> we don't want it written in the logs

<scribe> scribenick: hknublau

<pfps> All this quasi-security is not going to be very useful.

<pfps> The solution surely must be to fix WebEx!

<TallTed> apparently "scheduled WebEx meetings" aren't really scheduled ... unlike zakim

Admin

<Arnaud> PROPOSED: Approve minutes of the 12 November Telecon: http://www.w3.org/2015/11/12-shapes-minutes.html

RESOLUTION: Approve minutes of the 12 November Telecon: http://www.w3.org/2015/11/12-shapes-minutes.html

<kcoyle> getting noise from call-in user5

Arnaud: I will start a proposed aganda for the F2F soon.
... hopefully we can address the fundamental issues.

Disposal of raised issues

<Arnaud> PROPOSED: Open ISSUE-113, ISSUE-114

+1

<kcoyle> +1

<aryman> +1

<pfps> +1

<TallTed> +1

<hsolbrig> +1

<Dimitris> +1

<ericP> +1

RESOLUTION: Open ISSUE-113, ISSUE-114

Arnaud: Difficult to put agenda together, due to lack of activity
... Benefits of Proposals wiki page unclear
... only a couple of people seem to vote regularly
... some topics are not even covered there at all

pfps: Why is this so? We are back in the same situation - lots of proposals, only limited amount of time
... Maybe we should collect significant issues that we want to spend time on
... not enough time between agenda and call to prepare
... requires more focus

Arnaud: There is really just a handful of fundamental issues, the rest will follow automatically
... we should try to list those, help invited.
... categories e.g. nice-to-have's, UI
... still everyone should make an effort to vote where they can.

<TallTed> categorization -- https://www.w3.org/2014/data-shapes/track/products

<TallTed> I don't think there's any rule that says we can't make sub-products within SHACL spec...

Arnaud: good point, Ted.

ISSUE-95

<Arnaud> issue-95

<trackbot> issue-95 -- Proposed simplification and clean up of template mechanism -- open

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

aryman: Simplification goes beyond templates
... main idea is to refactor the concept of constraints

<TallTed> I've read aryman's refactoring email quickly ... and it looks good so far

<Arnaud> arthur's email: https://lists.w3.org/Archives/Public/public-data-shapes-wg/2015Nov/0149.html

aryman: constraint has two parts: domain and assertion
... domain is the set of nodes, e.g. objects for property constraints
... sh:hasValue is existential, others follow a pattern
... can also simplify the SPARQL

<pfps> There are quite a number of constraints that don't fall into the "all of these" paradigm. These include hasValue and the qualified cardinality constraints.

aryman: three kinds of domains: focus node, property, inverse property

@pfps yes and general cardinality

scribe: three subclasses for them
... assertion types like minCount, node kind
... one class for each assertion type
... driven by presence of parameters
... most are associated with a single parameter, some use a pair
... exceptions currently include sh:AndConstraint
... better would be sh:and, sh:or (HK: which was already proposed anyway)
... no need for templates
... replaced with assertions with an implementation, e.g. in SPARQL

(Distraction by unidentified user on WebEx)

pfps: goes into the right direction
... we don't want to repeat property/inverse properties
... quite a number of constraints that don't follow the simple pattern
... I would propose node constraints and property path constraints

aryman: (missed that, Arthur could you capture?)

Arnaud: encourage feedback

<aryman> I accept Peter's comment as a friendly amendment. I considered introducing logical tests in individual nodes and a way to quantify, ie. some, all

hknublau: we can certainly find common ground, some concepts in Arthur's approach seem to be very similar to what we currently have.

ISSUE-63

<ericP> hknublau: this is used to say that a node meet some shape

<ericP> ... also used for recursive templates, e.g. QCRs

<ericP> ... using this as a general function has a cost

<ericP> ... requires implementation for SHACL

<ericP> ... but it makes our job of specifying the language easier

<ericP> ... also needed for some extensions

<ericP> ... so i believe we should make it a req for SPARQL implementations

<ericP> ... there are work-arounds for the core.

<ericP> ... there are work-arounds for recursion

<TallTed> issue-63?

<trackbot> issue-63 -- Nested shapes: sh:hasShape function versus recursive SPARQL code generation -- open

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

aryman: this falls into the SPARQL binding
... SPARQL engines need to implement this functionality anyway
... in favor, as it's low cost
... we need a very clear definition though.

pfps: current specification is pretty bad, unclear what I would need to implement.
... it's use in the documentation doesn't conform with the partial spec
... unless these two problems are fixed I cannot approve it
... it's premature.
... it reflects a specific SHACL implementation philosophy

<pfps> There is a proposal for recursion in SPARQL in a paper in ISWC this year that does not use something like sh:hasShape, so it is not necessary to use something like sh:hasShape to allow for recursive shapes in SPARQL

hknublauc: this is blocked by recursion

<pfps> The SPARQL semantics of SHACL are currently specified in terms of a translation from SHACL to SPARQL plus a few extension functions, including sh:hasShape so sh:hasShape is indeed quite central to the current definition of SHACL

hknublau: Waiting for general resolution on recursion

<pfps> Because of this use of SHACL, I don't see how making sh:hasShape at risk would be suitable

Arnaud: We could not simply mark this as a feature at risk
... since other things of the spec depend on it

ISSUE-97 derived values

hknublau: Lots of use cases in our experience
... it's basically syntactic sugar

pfps: Lets' first get other things done.

Arnaud: tempting to handle low-hanging fruits

<pfps> There are low-hanging fruits in the part that need to be done, and low-hanging fruits in stuff that we don't need to do

<ericP> hknublau: the problem is that the layering of SHACL is that we can spend all our time with only the core language

<ericP> ... there's a risk that we won't get what we want

<ericP> ... at some stage we have to acknowledge that there are other people

<ericP> ... i've done my part for the core language.

<pfps> There is also the risk that we don't get anything done, instead of getting something done that some might not think of as completely optimal

<pfps> As long as these sorts of decisions are subject to being overturned because of changes to the core of SHACL I'm not going to stand in the way of this

<Arnaud> PROPOSED: Close ISSUE-97, adding sh:derivedValues as suggested

+1

<TallTed> +1

<kcoyle> 0 (possibly n/a)

<hsolbrig> +1

<pfps> -0.5 I think that this is premature, and it must be possible to overturn this sort of decision based on changes to the design of SHACL

<aryman> +0.5

(proxy vote +1 for Simon)

<Dimitris> 0+

RESOLUTION: Close ISSUE-97, adding sh:derivedValues as suggested

Thanks, everyone.

ISSUE-112

Arnaud: did we agree that there is a misuse?

<Arnaud> issue-112

<trackbot> issue-112 -- SHACL uses RDFS properties in ways that violate their intended RDFS meaning -- open

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

aryman: definition of rdfs:comment and rdfs:label is that they refer to the subject

(typo: rdfs:comment)

<ericP> hknublau: you could interpret it as a misuse or you could close your eyes a little and decide that it's not so bad.

<ericP> ... the subject of the triple is the the predicate being described so it's not such a misuse

<ericP> ... people use rdfs:label everywhere

TallTed: subject of a triple is not necessarily the subject that people here talked about

<kcoyle> subject vs. topic

TallTed: maybe I misunderstood

<aryman> +q

kcoyle: I am concerned that global labels already exist, how to handle those is not clarified

aryman: I looked at the current spec, Example 10

<aryman> http://w3c.github.io/data-shapes/shacl/#constraints-property

aryman: subject of the label triple is the constraint
... a generic UI agent would use that rdfs:label for the constraint

<TallTed> I think that Example 10's `rdfs:label "some property" ;` is misplaced or the literal misworded....

<pfps> One actually might want to do both, a label for the constraint itself and a label for the property in this context.

aryman: agreed with Peter above

(general discussion about whether we violate rdfs:label semantics or not)

<Arnaud> PROPOSED: Close ISSUE-112 replacing the use of rdfs:label and rdfs:comment in property constraints with sh:name and sh:description

<TallTed> -1

<Arnaud> PROPOSED: Close ISSUE-112 replacing the current use of rdfs:label and rdfs:comment in property constraints with sh:name and sh:description

<aryman> Use sh:label and sh:comment for the property and rdfs:label and rdfs:comment for the constraint

sh: label and sh:comment seem too similar

<pfps> I didn't want to get into naming issues, so I didn't propose changes.

<TallTed> PROPOSED: Close ISSUE-112 by *within constraint* Use sh:label and sh:comment for the property and rdfs:label and rdfs:comment for the constraint

<Arnaud> PROPOSED: Close ISSUE-112 by *within constraint* Use sh:name and sh:derscription for the property and rdfs:label and rdfs:comment for the constraint

<TallTed> or possibly `Use sh:propertyLabel and sh:propertyComment (and sh:propertyDescription) ...`

pfps: These are just exemplars, there may be other places of misuse

<pfps> If closing ISSUE-112 means that SHACL's remaining use of RDFS properties is perfect then I would vote against it

pfps: I changed the issue text

<pfps> I'm happy with the resolution

<pfps> ... now

<kcoyle> yeah,ok

<Arnaud> PROPOSED: Close ISSUE-112 by *within constraint* Use sh:name and sh:derscription for the property and rdfs:label and rdfs:comment for the constraint, renaming the issue to be specifically about sh:label and sh:description

typo: sh:description

<Arnaud> PROPOSED: Close ISSUE-112 by *within constraint* Use sh:name and sh:dderscription for the property and rdfs:label and rdfs:comment for the constraint, renaming the issue to be

:)

<aryman> btw, OSLC used oslc:name for this purpose

<Arnaud> PROPOSED: Close ISSUE-112 by *within constraint* Use sh:name and sh:description for the property and rdfs:label and rdfs:comment for the constraint, renaming the issue to be specifically about sh:label and sh:comment

0

<aryman> +1

<TallTed> +1

<Dimitris> +1

<kcoyle> +1

<hsolbrig> +1

<pfps> +1, but there may be some further work to get the absolute best names for this

(Just for the record I believe users will trip over this all the time)

<ericP> +1

<pfps> I do agree that some people may end up using rdfs: stuff for this - this is a case where "be liberal in what you accept" could be a good idea

RESOLUTION: Close ISSUE-112 by *within constraint* Use sh:name and sh:description for the property and rdfs:label and rdfs:comment for the constraint, renaming the issue to be specifically about rfs:label and rdfs:comment

<kcoyle> I don't think users will trip over it because they define labels in their vocabulary

<kcoyle> at least my peeps do

ISSUE-87

<Arnaud> issue-87

<trackbot> issue-87 -- Shall we publish RDF files for the SHACL namespace? -- open

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

<Arnaud> PROPOSED: Close ISSUE-87 with two files: shacl-vocab.ttl and shacl-shacl.ttlas per Arthur Ryman's proposal http://www.w3.org/mid/CAApBiOn9eBvt99Eyu%253DjGUL9FxGHB%252B4r6%253DmPrUrwzCAHjmsQpSA%2540mail.gmail.com

<TallTed> +1

+1

Arnaud: can we agree on the general direction for now?

<pfps> Arthur's proposal does go in the right direction, i think

<aryman> +1

<pfps> +0

<kcoyle> +1

<hsolbrig> +1

<ericP> +1

<pfps> Someone (else) is going to have to create these files!

RESOLUTION: Close ISSUE-87 with two files: shacl-vocab.ttl and shacl.shacl.ttl as per Arthur Ryman's proposal http://www.w3.org/mid/CAApBiOn9eBvt99Eyu%253DjGUL9FxGHB%252B4r6%253DmPrUrwzCAHjmsQpSA%2540mail.gmail.com

<aryman> I will create the vocab file

A follow-up question will be the graph URIs, i.e. how to reference those files.

<Dimitris> +1

<aryman> damn autocorrect

<kcoyle> it's autocrap

<Arnaud> trackbot, end meeting