18:57:03 <RRSAgent> RRSAgent has joined #shapes
18:57:03 <RRSAgent> logging to http://www.w3.org/2015/11/19-shapes-irc
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> indeed
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> present+
19:00:09 <Arnaud> present+
19:00:44 <pfps> present+
19:01:50 <hknublau> present+
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> present+
19:03:15 <pfps> The solution surely must be to fix WebEx!
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> agenda: https://www.w3.org/2014/data-shapes/wiki/Meetings:Telecon2015.11.19
19:04:40 <Dimitris> Dimitris has joined #shapes
19:05:04 <Dimitris> present+ dimitris
19:05:06 <Arnaud> chair: Arnaud
<Arnaud> topic: Admin
19:05:25 <Arnaud> PROPOSED: Approve minutes of the 12 November Telecon: http://www.w3.org/2015/11/12-shapes-minutes.html
19:05:48 <Arnaud> RESOLVED: Approve minutes of the 12 November Telecon: http://www.w3.org/2015/11/12-shapes-minutes.html
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.
<Arnaud> topic: Disposal of raised issues
19:08:09 <Arnaud> PROPOSED: Open ISSUE-113, ISSUE-114
19:08:15 <hknublau> +1
19:08:21 <kcoyle> +1
19:08:22 <aryman> +1
19:08:23 <pfps> +1
19:08:25 <TallTed> +1
19:08:30 <hsolbrig> +1
19:08:44 <Dimitris> +1
19:08:49 <ericP> +1
19:09:00 <Arnaud> RESOLVED: Open ISSUE-113, ISSUE-114
19:09:33 <hknublau> Arnaud: Difficult to put agenda together, due to lack of activity
19:09:46 <pfps> q+
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 -- https://www.w3.org/2014/data-shapes/track/products
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> issue-95
19:18:22 <trackbot> issue-95 -- Proposed simplification and clean up of template mechanism -- open
19:18:22 <trackbot> http://www.w3.org/2014/data-shapes/track/issues/95
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: https://lists.w3.org/Archives/Public/public-data-shapes-wg/2015Nov/0149.html
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> q+
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> q+
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> q+
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> issue-63?
19:42:40 <trackbot> issue-63 -- Nested shapes: sh:hasShape function versus recursive SPARQL code generation -- open
19:42:40 <trackbot> http://www.w3.org/2014/data-shapes/track/issues/63
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> q+
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> q+
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> q+
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> +1
20:00:06 <TallTed> +1
20:00:25 <kcoyle> 0 (possibly n/a)
20:00:34 <hsolbrig> +1
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> +0.5
20:01:10 <hknublau> (proxy vote +1 for Simon)
20:01:16 <Dimitris> 0+
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> q+
20:02:56 <hknublau> Arnaud: did we agree that there is a misuse?
20:03:15 <Arnaud> ack aryman
20:03:23 <Arnaud> issue-112
20:03:23 <trackbot> issue-112 -- SHACL uses RDFS properties in ways that violate their intended RDFS meaning -- open
20:03:23 <trackbot> http://www.w3.org/2014/data-shapes/track/issues/112
20:03:36 <hknublau> aryman: definition of rdfs:comment and rdfs:label is that they refer to the subject
20:03:49 <hknublau> (typo: rdfs:comment)
20:03:50 <hknublau> q+
20:04:03 <TallTed> q+
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> q+
20:07:31 <aryman> +q
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> q+
20:09:00 <Arnaud> ack aryman
20:09:20 <hknublau> aryman: I looked at the current spec, Example 10
20:09:41 <aryman> http://w3c.github.io/data-shapes/shacl/#constraints-property
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> q+
20:13:49 <kcoyle> q+
20:14:03 <Arnaud> ack aryman
20:14:11 <kcoyle> q-
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> -1
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> q+
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> yeah,ok
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> q+
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> q-
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> s/sh:ddescription/sh:description/
20:23:34 <hknublau> 0
20:23:52 <aryman> +1
20:24:08 <TallTed> s/sh:dcomment/sh:comment/
20:24:11 <TallTed> +1
20:24:15 <Dimitris> +1
20:24:15 <kcoyle> +1
20:24:15 <hsolbrig> +1
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> +1
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> issue-87
20:26:35 <trackbot> issue-87 -- Shall we publish RDF files for the SHACL namespace? -- open
20:26:35 <trackbot> http://www.w3.org/2014/data-shapes/track/issues/87
20:27:21 <kcoyle> q+
20:27:24 <Arnaud> PROPOSED: Close ISSUE-87 with two files: shacl.ttl and shacl.shacl.ttl as per Arthur Ryman's proposal http://www.w3.org/mid/CAApBiOn9eBvt99Eyu%253DjGUL9FxGHB%252B4r6%253DmPrUrwzCAHjmsQpSA%2540mail.gmail.com
20:27:28 <aryman> q+
20:27:50 <TallTed> +1
20:28:09 <Arnaud> ack kcoyle
20:28:11 <hknublau> +1
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> +1
20:29:58 <pfps> +0
20:29:59 <kcoyle> +1
20:30:01 <hsolbrig> +1
20:30:04 <ericP> +1
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 http://www.w3.org/mid/CAApBiOn9eBvt99Eyu%253DjGUL9FxGHB%252B4r6%253DmPrUrwzCAHjmsQpSA%2540mail.gmail.com
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> +1
20:30:56 <aryman> s/vocal/vocab/
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 http://www.w3.org/2015/11/19-shapes-minutes.html trackbot
20:31:34 <trackbot> RRSAgent, bye
20:31:34 <RRSAgent> I see no action items