IRC log of shapes on 2015-11-19

Timestamps are in UTC.

18:57:03 [RRSAgent]
RRSAgent has joined #shapes
18:57:03 [RRSAgent]
logging to
18:57:05 [trackbot]
RRSAgent, make logs rdf-data-shapes
18:57:05 [Zakim]
Zakim has joined #shapes
18:57:07 [trackbot]
Zakim, this will be SHAPES
18:57:07 [Zakim]
I do not see a conference matching that name scheduled within the next hour, trackbot
18:57:08 [trackbot]
Meeting: RDF Data Shapes Working Group Teleconference
18:57:08 [trackbot]
Date: 19 November 2015
18:58:04 [kcoyle]
it''s not on the telecon page, and never asked before, afaik
18:58:15 [Arnaud]
18:58:32 [Arnaud]
there have been problems of people accessing webex and misusing it
18:58:43 [Arnaud]
so eric had to tighten the security
18:58:59 [Arnaud]
and entering the password is now mandatory
18:59:08 [aryman]
aryman has joined #shapes
18:59:10 [Arnaud]
we'll get it on a protected page for future calls
18:59:19 [aryman]
present+ aryman
18:59:22 [Arnaud]
we don't want it written in the logs
18:59:51 [pfps]
pfps has joined #shapes
18:59:57 [kcoyle]
19:00:09 [Arnaud]
19:00:44 [pfps]
19:01:50 [hknublau]
19:02:01 [hknublau]
scribenick: hknublau
19:02:46 [pfps]
All this quasi-security is not going to be very useful.
19:03:06 [TallTed]
19:03:15 [pfps]
The solution surely must be to fix WebEx!
19:03:27 [Arnaud]
present+ Dimitris
19:03:38 [hsolbrig]
hsolbrig has joined #shapes
19:04:02 [TallTed]
apparently "scheduled WebEx meetings" aren't really scheduled ... unlike zakim
19:04:19 [Arnaud]
regrets: labra, simonstey
19:04:28 [Arnaud]
19:04:40 [Dimitris]
Dimitris has joined #shapes
19:05:04 [Dimitris]
present+ dimitris
19:05:06 [Arnaud]
chair: Arnaud
19:05:25 [Arnaud]
PROPOSED: Approve minutes of the 12 November Telecon:
19:05:48 [Arnaud]
RESOLVED: Approve minutes of the 12 November Telecon:
19:06:10 [kcoyle]
getting noise from call-in user5
19:07:02 [hknublau]
Arnaud: I will start a proposed aganda for the F2F soon.
19:07:16 [hsolbrig]
present+ hsolbrig
19:07:21 [hknublau]
... hopefully we can address the fundamental issues.
19:08:09 [Arnaud]
19:08:15 [hknublau]
19:08:21 [kcoyle]
19:08:22 [aryman]
19:08:23 [pfps]
19:08:25 [TallTed]
19:08:30 [hsolbrig]
19:08:44 [Dimitris]
19:08:49 [ericP]
19:09:00 [Arnaud]
19:09:33 [hknublau]
Arnaud: Difficult to put agenda together, due to lack of activity
19:09:46 [pfps]
19:10:05 [hknublau]
... Benefits of Proposals wiki page unclear
19:10:34 [hknublau]
... only a couple of people seem to vote regularly
19:10:44 [hknublau]
... some topics are not even covered there at all
19:10:49 [Arnaud]
ack pfps
19:11:37 [hknublau]
pfps: Why is this so? We are back in the same situation - lots of proposals, only limited amount of time
19:12:27 [hknublau]
... Maybe we should collect significant issues that we want to spend time on
19:12:37 [hknublau]
... not enough time between agenda and call to prepare
19:12:47 [hknublau]
... requires more focus
19:13:30 [hknublau]
Arnaud: There is really just a handful of fundamental issues, the rest will follow automatically
19:14:29 [hknublau]
... we should try to list those, help invited.
19:15:11 [hknublau]
... categories e.g. nice-to-have's, UI
19:16:01 [hknublau]
... still everyone should make an effort to vote where they can.
19:16:11 [TallTed]
categorization --
19:16:11 [TallTed]
I don't think there's any rule that says we can't make sub-products within SHACL spec...
19:16:55 [hknublau]
... good point, Ted.
19:18:15 [hknublau]
Topic: ISSUE-95
19:18:22 [Arnaud]
19:18:22 [trackbot]
issue-95 -- Proposed simplification and clean up of template mechanism -- open
19:18:22 [trackbot]
19:18:48 [hknublau]
aryman: Simplification goes beyond templates
19:19:02 [hknublau]
... main idea is to refactor the concept of constraints
19:19:09 [TallTed]
I've read aryman's refactoring email quickly ... and it looks good so far
19:19:26 [Arnaud]
arthur's email:
19:19:36 [hknublau]
... constraint has two parts: domain and assertion
19:19:55 [hknublau]
... domain is the set of nodes, e.g. objects for property constraints
19:21:45 [hknublau]
... sh:hasValue is existential, others follow a pattern
19:21:59 [hknublau]
... can also simplify the SPARQL
19:22:08 [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.
19:23:04 [hknublau]
... three kinds of domains: focus node, property, inverse property
19:23:23 [hknublau]
@pfps yes and general cardinality
19:23:47 [hknublau]
... three subclasses for them
19:24:16 [hknublau]
... assertion types like minCount, node kind
19:24:35 [hknublau]
... one class for each assertion type
19:24:48 [hknublau]
... driven by presence of parameters
19:25:08 [hknublau]
... most are associated with a single parameter, some use a pair
19:26:28 [hknublau]
... exceptions currently include sh:AndConstraint
19:27:00 [hknublau]
... better would be sh:and, sh:or (HK: which was already proposed anyway)
19:28:21 [hknublau]
... no need for templates
19:29:02 [hknublau]
... replaced with assertions with an implementation, e.g. in SPARQL
19:29:18 [pfps]
19:31:08 [hknublau]
(Distraction by unidentified user on WebEx)
19:31:57 [Arnaud]
ack pfps
19:32:15 [hknublau]
pfps: goes into the right direction
19:32:29 [hknublau]
... we don't want to repeat property/inverse properties
19:32:48 [hknublau]
... quite a number of constraints that don't follow the simple pattern
19:33:51 [aryman]
19:34:12 [hknublau]
... I would propose node constraints and property path constraints
19:34:37 [Arnaud]
ack aryman
19:35:52 [hknublau]
aryman: (missed that, Arthur could you capture?)
19:36:39 [hknublau]
Arnaud: encourage feedback
19:36:50 [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
19:38:53 [hknublau]
hknublau: we can certainly find common ground, some concepts in Arthur's approach seem to be very similar to what we currently have.
19:40:17 [ericP]
topic: issue-63
19:40:33 [ericP]
hknublau: this is used to say that a node meet some shape
19:40:46 [ericP]
... also used for recursive templates, e.g. QCRs
19:40:57 [ericP]
... using this as a general function has a cost
19:41:04 [ericP]
... requires implementation for SHACL
19:41:25 [ericP]
... but it makes our job of specifying the language easier
19:41:37 [ericP]
... also needed for some extensions
19:41:45 [aryman]
19:41:57 [ericP]
... so i believe we should make it a req for SPARQL implementations
19:42:06 [ericP]
... there are work-arounds for the core.
19:42:15 [ericP]
... there are work-arounds for recursion
19:42:32 [Arnaud]
ack aryman
19:42:40 [TallTed]
19:42:40 [trackbot]
issue-63 -- Nested shapes: sh:hasShape function versus recursive SPARQL code generation -- open
19:42:40 [trackbot]
19:42:49 [hknublau]
aryman: this falls into the SPARQL binding
19:43:04 [hknublau]
... SPARQL engines need to implement this functionality anyway
19:43:07 [pfps]
19:43:10 [hknublau]
... in favor, as it's low cost
19:43:24 [hknublau]
... we need a very clear definition though.
19:43:51 [Arnaud]
ack pfps
19:44:18 [hknublau]
pfps: current specification is pretty bad, unclear what I would need to implement.
19:44:31 [hknublau]
... it's use in the documentation doesn't conform with the partial spec
19:44:58 [hknublau]
... unless these two problems are fixed I cannot approve it
19:45:16 [hknublau]
... it's premature.
19:45:54 [hknublau]
... it reflects a specific SHACL implementation philosophy
19:47:42 [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
19:47:48 [hknublau]
hknublauc: this is blocked by recursion
19:49:42 [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
19:49:43 [hknublau]
hknublau: Waiting for general resolution on recursion
19:50:14 [pfps]
Because of this use of SHACL, I don't see how making sh:hasShape at risk would be suitable
19:50:36 [hknublau]
Arnaud: We could not simply mark this as a feature at risk
19:50:47 [hknublau]
... since other things of the spec depend on it
19:51:17 [hknublau]
topic: ISSUE-97 derived values
19:52:41 [pfps]
19:53:42 [hknublau]
hknublau: Lots of use cases in our experience
19:54:09 [Arnaud]
ack pfps
19:55:08 [hknublau]
... it's basically syntactic sugar
19:55:19 [hknublau]
pfps: Lets' first get other things done.
19:55:24 [hknublau]
19:56:27 [hknublau]
Arnaud: tempting to handle low-hanging fruits
19:56:38 [Arnaud]
ack hknublau
19:56:59 [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
19:57:02 [ericP]
hknublau: the problem is that the layering of SHACL is that we can spend all our time with only the core language
19:57:11 [ericP]
... there's a risk that we won't get what we want
19:57:33 [ericP]
... at some stage we have to acknowledge that there are other people
19:57:44 [ericP]
... i've done my part for the core language.
19:57:52 [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
19:59:40 [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
19:59:55 [Arnaud]
PROPOSED: Close ISSUE-97, adding sh:derivedValues as suggested
19:59:59 [hknublau]
20:00:06 [TallTed]
20:00:25 [kcoyle]
0 (possibly n/a)
20:00:34 [hsolbrig]
20:00:39 [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
20:00:44 [aryman]
20:01:10 [hknublau]
(proxy vote +1 for Simon)
20:01:16 [Dimitris]
20:01:34 [Arnaud]
RESOLVED: Close ISSUE-97, adding sh:derivedValues as suggested
20:01:40 [hknublau]
Thanks, everyone.
20:02:16 [hknublau]
Topic: ISSUE-112
20:02:52 [aryman]
20:02:56 [hknublau]
Arnaud: did we agree that there is a misuse?
20:03:15 [Arnaud]
ack aryman
20:03:23 [Arnaud]
20:03:23 [trackbot]
issue-112 -- SHACL uses RDFS properties in ways that violate their intended RDFS meaning -- open
20:03:23 [trackbot]
20:03:36 [hknublau]
aryman: definition of rdfs:command and label is that they refer to the subject
20:03:49 [hknublau]
(typo: rdfs:comment)
20:03:50 [hknublau]
20:04:03 [TallTed]
20:04:09 [Arnaud]
ack hknublau
20:04:40 [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.
20:05:19 [ericP]
... the subject of the triple is the the predicate being described so it's not such a misuse
20:05:28 [Arnaud]
ack TallTed
20:05:32 [ericP]
... people use rdfs:label everywhere
20:05:52 [hknublau]
TallTed: subject of a triple is not necessarily the subject that people here talked about
20:06:01 [kcoyle]
subject vs. topic
20:06:59 [hknublau]
... maybe I misunderstood
20:07:17 [kcoyle]
20:07:31 [aryman]
20:07:33 [Arnaud]
ack kcoyle
20:08:28 [hknublau]
kcoyle: I am concerned that global labels already exist, how to handle those is not clarified
20:08:33 [hknublau]
20:09:00 [Arnaud]
ack aryman
20:09:20 [hknublau]
aryman: I looked at the current spec, Example 10
20:09:41 [aryman]
20:10:11 [hknublau]
... subject of the label triple is the constraint
20:10:49 [hknublau]
... a generic UI agent would use that rdfs:label for the constraint
20:11:07 [TallTed]
I think that Example 10's `rdfs:label "some property" ;` is misplaced or the literal misworded....
20:11:33 [Arnaud]
ack hknublau
20:11:53 [pfps]
One actually might want to do both, a label for the constraint itself and a label for the property in this context.
20:12:00 [aryman]
20:13:49 [kcoyle]
20:14:03 [Arnaud]
ack aryman
20:14:11 [kcoyle]
20:14:25 [hknublau]
aryman: agreed with Peter above
20:15:34 [hknublau]
(general discussion about whether we violate rdfs:label semantics or not)
20:15:47 [Arnaud]
PROPOSED: Close ISSUE-112 replacing the use of rdfs:label and rdfs:comment in property constraints with sh:name and sh:description
20:16:04 [TallTed]
20:16:25 [Arnaud]
PROPOSED: Close ISSUE-112 replacing the current use of rdfs:label and rdfs:comment in property constraints with sh:name and sh:description
20:17:12 [aryman]
Use sh:label and sh:comment for the property and rdfs:label and rdfs:comment for the constraint
20:18:12 [hknublau]
sh:label and sh:comment seem too similar
20:18:12 [pfps]
I didn't want to get into naming issues, so I didn't propose changes.
20:18:14 [pfps]
20:18:25 [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
20:18:51 [Arnaud]
ack pfps
20:19:17 [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
20:19:29 [TallTed]
or possibly `Use sh:propertyLabel and sh:propertyComment (and sh:propertyDescription) ...`
20:19:59 [hknublau]
pfps: These are just exemplars, there may be other places of misuse
20:20:11 [pfps]
If closing ISSUE-112 means that SHACL's remaining use of RDFS properties is perfect then I would vote against it
20:21:23 [hknublau]
pfps: I changed the issue text
20:21:37 [pfps]
I'm happy with the resolution
20:21:42 [pfps]
... now
20:21:42 [kcoyle]
20:21:47 [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
20:22:05 [hknublau]
typo: sh:description
20:22:16 [kcoyle]
20:22:29 [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
20:22:35 [kcoyle]
20:22:47 [hknublau]
20:22:50 [aryman]
btw, OSLC used oslc:name for this purpose
20:23:09 [Arnaud]
PROPOSED: Close ISSUE-112 by *within constraint* Use sh:name and sh:ddescription for the property and rdfs:label and rdfs:comment for the constraint, renaming the issue to be specifically about sh:label and sh:dcomment
20:23:20 [TallTed]
20:23:34 [hknublau]
20:23:52 [aryman]
20:24:08 [TallTed]
20:24:11 [TallTed]
20:24:15 [Dimitris]
20:24:15 [kcoyle]
20:24:15 [hsolbrig]
20:24:18 [pfps]
+1, but there may be some further work to get the absolute best names for this
20:24:25 [hknublau]
(Just for the record I believe users will trip over this all the time)
20:24:26 [ericP]
20:25:27 [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
20:25:48 [Arnaud]
RESOLVED: 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
20:25:48 [kcoyle]
I don't think users will trip over it because they define labels in their vocabulary
20:25:56 [kcoyle]
at least my peeps do
20:26:22 [hknublau]
topic: ISSUE-87
20:26:35 [Arnaud]
20:26:35 [trackbot]
issue-87 -- Shall we publish RDF files for the SHACL namespace? -- open
20:26:35 [trackbot]
20:27:21 [kcoyle]
20:27:24 [Arnaud]
PROPOSED: Close ISSUE-87 with two files: shacl.ttl and shacl.shacl.ttl as per Arthur Ryman's proposal
20:27:28 [aryman]
20:27:50 [TallTed]
20:28:09 [Arnaud]
ack kcoyle
20:28:11 [hknublau]
20:28:11 [TallTed]
s/shacl.ttl and shacl.shacl.ttl /shacl-vocab.ttl and shacl-shacl.ttl/
20:28:12 [Arnaud]
ack aryman
20:29:37 [hknublau]
Arnaud: can we agree on the general direction for now?
20:29:45 [pfps]
Arthur's proposal does go in the right direction, i think
20:29:55 [aryman]
20:29:58 [pfps]
20:29:59 [kcoyle]
20:30:01 [hsolbrig]
20:30:04 [ericP]
20:30:29 [pfps]
Someone (else) is going to have to create these files!
20:30:41 [Arnaud]
RESOLVED: Close ISSUE-87 with two files: shacl-vocab.ttl and shacl.shacl.ttl as per Arthur Ryman's proposal
20:30:46 [aryman]
I will create the vocal file
20:30:50 [hknublau]
A follow-up question will be the graph URIs, i.e. how to reference those files.
20:30:50 [Dimitris]
20:30:56 [aryman]
20:31:02 [aryman]
damn autocorrect
20:31:14 [kcoyle]
it's autocrap
20:31:25 [Arnaud]
trackbot, end meeting
20:31:25 [trackbot]
Zakim, list attendees
20:31:25 [Zakim]
As of this point the attendees have been aryman, kcoyle, Arnaud, pfps, hknublau, TallTed, Dimitris, hsolbrig
20:31:33 [trackbot]
RRSAgent, please draft minutes
20:31:33 [RRSAgent]
I have made the request to generate trackbot
20:31:34 [trackbot]
RRSAgent, bye
20:31:34 [RRSAgent]
I see no action items