18:57:09 <RRSAgent> RRSAgent has joined #shapes
18:57:09 <RRSAgent> logging to http://www.w3.org/2016/03/03-shapes-irc
18:57:11 <trackbot> RRSAgent, make logs rdf-data-shapes
18:57:11 <Zakim> Zakim has joined #shapes
18:57:13 <trackbot> Zakim, this will be SHAPES
18:57:13 <Zakim> I do not see a conference matching that name scheduled within the next hour, trackbot
18:57:14 <trackbot> Meeting: RDF Data Shapes Working Group Teleconference
18:57:14 <trackbot> Date: 03 March 2016
18:58:06 <Arnaud> Arnaud has changed the topic to: RDF Data Shapes WG https://www.w3.org/2014/data-shapes - Next agenda: https://www.w3.org/2014/data-shapes/wiki/Meetings:Telecon2016.03.03
18:58:17 <Arnaud> agenda: https://www.w3.org/2014/data-shapes/wiki/Meetings:Telecon2016.03.03
18:58:20 <Arnaud> chair: Arnaud
19:01:14 <simonstey> simonstey has joined #shapes
19:01:21 <Arnaud> present+
19:01:33 <TallTed> present+
19:01:45 <jamsden> jamsden has joined #shapes
19:01:53 <Arnaud> present+ kcoyle, dimitris
19:02:27 <hknublau> hknublau has joined #shapes
19:03:02 <simonstey> present+
19:03:29 <hknublau> present+
19:03:36 <hknublau> scribenick: hknublau
19:06:54 <Labra> Labra has joined #shapes
19:07:32 <hsolbrig> hsolbrig has joined #shapes
<hknublau> topic: Admin
19:08:03 <Arnaud> PROPOSED: Approve minutes of the 25 February 2016 Telecon: http://www.w3.org/2016/02/25-shapes-minutes.html
19:08:19 <Dimitris> present+
19:08:20 <hsolbrig> present+ hsolbrig
19:08:25 <Labra> present+ labra
19:08:33 <jamsden> present+
19:08:59 <jamsden> present+ jamsden
19:09:26 <Arnaud> RESOLVED: Approve minutes of the 25 February 2016 Telecon: http://www.w3.org/2016/02/25-shapes-minutes.html
19:09:40 <hknublau> (Missing Harold from minutes)
<hknublau> topic: Disposal of Raised Issues
19:10:12 <Arnaud> PROPOSED: Open ISSUE-123 DirectType syntax
19:10:26 <simonstey> issue-123
19:10:26 <trackbot> issue-123 -- Shall we unify the syntax of sh:directType and sh:class? -- raised
19:10:26 <trackbot> http://www.w3.org/2014/data-shapes/track/issues/123
19:12:50 <hknublau> jamsden: what was the motivation for directType anyway?
19:13:09 <hknublau> hknublau: From Arthur, OSLC
19:13:51 <hknublau> jamsden: I would prefer being consistent with inheritance
19:14:19 <hknublau> ... I will talk to Shapes users to see why this is needed.
19:15:43 <hknublau> ... Unintended inferencing is a different problem
19:15:54 <Dimitris> +1
19:15:54 <TallTed> +1 open it
19:15:55 <hknublau> +1 open for now
19:16:15 <simonstey> +1
19:16:23 <Arnaud> RESOLVED: Open ISSUE-123 DirectType syntax
19:17:24 <hknublau> Arnaud: I would like to get feedback on the status of a few issues
19:17:40 <simonstey> topic: ISSUE-92
19:17:40 <trackbot> issue-92 -- Should repeated properties be interpreted as additive or conjunctive? -- open
19:17:40 <trackbot> http://www.w3.org/2014/data-shapes/track/issues/92
19:18:27 <hknublau> ericP: Differences between ShEx and SHACL - properties can be disjoint by default
19:18:43 <hknublau> ... we are trying to come up with an approach that works for all
19:19:05 <hknublau> ... iovka may join later
19:19:39 <hknublau> topic: ISSUE-68
19:19:39 <trackbot> ISSUE-68 -- pre-binding not defined in SHACL spec -- open
19:19:39 <trackbot> http://www.w3.org/2014/data-shapes/track/issues/68
19:20:01 <kcoyle> (as I predicted, app dropped me; back on computer)
19:20:53 <hknublau> +q
19:21:19 <Arnaud> ack hknublau
19:21:40 <simonstey> is this about the $varname stuff?
19:22:49 <hknublau> hknublau: The proposals page is not yet up to date. The spec has a new paragraph.
19:23:38 <hknublau> ... my preference would be to expose this to implementers
19:23:39 <hknublau> http://w3c.github.io/data-shapes/shacl/#pre-binding
19:25:38 <jamsden> It would be nice to see an example
19:25:55 <hknublau> hknublau: will send an update email, please look
19:27:38 <simonstey> topic: ISSUE-80
19:27:38 <trackbot> issue-80 -- Constraint to limit IRIs against scheme/namespace, possibly with dereferencing -- open
19:27:38 <trackbot> http://www.w3.org/2014/data-shapes/track/issues/80
19:28:21 <simonstey> +q
19:29:08 <Arnaud> https://www.w3.org/2015/12/17-shapes-minutes.html#item06
19:29:14 <hknublau> ericP: ShEx has a notion of URI stems
19:29:44 <kcoyle> q+
19:29:51 <hknublau> ... for value matching, only gets us halfway
19:30:25 <Arnaud> ack simonstey
19:31:17 <hknublau> simonstey: Dereferencing is mentioned in Use Cases document
19:31:37 <hknublau> ... people agreed this is out of scope for SHACL
19:31:41 <Arnaud> ack kcoyle
19:32:29 <hknublau> kcoyle: Regex matching is similar to stemming, but stemming is very common in our use cases.
19:33:01 <hknublau> ericP: ShEx stemming construct is for convenience only.
19:33:11 <kcoyle> agreed
19:34:33 <kcoyle> We would definitely use the simpler interface
19:34:40 <hknublau> ericP: Do people support this (slightly redundant) stemming feature?
19:37:05 <Arnaud> action: ericP to send proposal for sh:Stem in response to ISSUE-80
19:37:05 <trackbot> Created ACTION-36 - Send proposal for sh:stem in response to issue-80 [on Eric Prud'hommeaux - due 2016-03-10].
19:37:58 <hknublau> Arnaud: Some tickets were never talked about.
19:38:12 <simonstey> topic: ISSUE-52
19:38:12 <trackbot> issue-52 -- Define an Abstract Syntax for SHACL -- open
19:38:12 <trackbot> http://www.w3.org/2014/data-shapes/track/issues/52
19:39:09 <hknublau> Arnaud: Since Arthur left, would anyone want to continue?
19:39:53 <hknublau> ericP: ShEx Abstract Syntax could be harvested, I could work out something
19:40:19 <jamsden> q+
19:40:56 <Arnaud> ack jamsden
19:41:24 <hknublau> jamsden: Abstract Syntax is a good idea, but if there is only one Concrete Syntax then what is the point
19:42:09 <hknublau> ... also SHACL is tied to RDF, so this feels like a nice to have only, should not delay the process
19:42:56 <hknublau> Arnaud: maybe there is value for documentation purposes, as a side project
19:43:44 <hknublau> ... we are not ready to kill this off yet, let's wait for Eric's proposal
19:44:44 <TallTed> topic: ISSUE-99
19:44:44 <trackbot> issue-99 -- special treatment of rdfs:Resource and rdf:List in sh:valueClass (and possibly elsewhere) -- open
19:44:44 <trackbot> http://www.w3.org/2014/data-shapes/track/issues/99
19:45:14 <Arnaud> https://www.w3.org/2016/02/25-shapes-minutes.html#item06
19:45:40 <hknublau> hknublau: Updated proposals are on the wiki page, would be nice to see more feedback
19:45:59 <Dimitris> https://www.w3.org/2014/data-shapes/wiki/Proposals#ISSUE-99.5:_handling_lists_and_resources
19:48:15 <Arnaud> PROPOSED: No special cases for sh:class and friends. This means that  Turtle lists don't validate against sh:class rdf:List and that many  nodes don't validate against rdfs:Resource
19:48:26 <Dimitris> +1
19:48:30 <hknublau> +0.5
19:48:51 <TallTed> +0
19:48:57 <Labra> 0
19:49:00 <kcoyle> 0 (kinda what the hell)
19:49:05 <jamsden> +0
19:49:19 <hsolbrig> 0
19:49:23 <simonstey> 0
19:49:36 <ericP> 0 (kinda what the hell)
19:49:49 <simonstey> what are those "many nodes"?
19:51:30 <hknublau> hsolbrig: I am confused about Turtle lists. Why should they be different than any other list
19:53:18 <TallTed> q+
19:53:51 <Arnaud> ack TallTed
19:53:51 <hknublau> hknublau: It's about that lists written in Turtle don't produce an rdf:type triple.
19:55:24 <Dimitris> q+
19:55:32 <Arnaud> ack Dimitris
19:55:49 <hknublau> TallTed: We could solve this by adding a Shape and use sh:valueShape
19:56:02 <hknublau> Dimitris: I suggest using NodeKind
19:56:36 <iovka> iovka has joined #shapes
19:57:03 <iovka_> iovka_ has joined #shapes
19:58:23 <Arnaud> PROPOSED: No special treaments of rdf:List and rdf:Resource at sh:class.  This means that  Turtle lists don't validate against sh:class rdf:List and that many  nodes don't validate against rdfs:Resource.
19:59:09 <kcoyle> +.5
19:59:10 <simonstey> +0.9
19:59:11 <hknublau> 0.5
19:59:18 <Labra> +0.5
19:59:19 <Dimitris> +1
19:59:27 <hsolbrig> 0.5
19:59:33 <TallTed> +0.5
19:59:42 <ericP> 0 (kinda what the hell)
19:59:44 <jamsden> +0.5
19:59:57 <ericP> +1 -kinda what the hell
20:00:07 <Arnaud> RESOLVED: No special treaments of rdf:List and rdf:Resource at sh:class.  This means that  Turtle lists don't validate against sh:class rdf:List and that many  nodes don't validate against rdfs:Resource.
20:01:00 <TallTed> q+
20:01:05 <Arnaud> ack TallTed
20:01:39 <hsolbrig> q+
20:01:53 <Arnaud> ack hsolbrig
20:02:12 <hknublau> TallTed: This WG is best suitable to define a standard Shape for well-formed rdf:Lists
20:02:44 <simonstey> https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Feb/0045.html
20:03:05 <simonstey> +q
20:03:12 <Arnaud> ack simonstey
20:04:38 <hknublau> simonstey: Special construct was asked for by various use cases. I would prefer to have such a feature. But we left this to future work.
20:04:45 <hknublau> q+
20:04:47 <kcoyle> q+
20:05:39 <Arnaud> ack hknublau
20:06:27 <simonstey> issue-119
20:06:27 <trackbot> issue-119 -- Defining constraints on (values of) rdf:Lists -- closed
20:06:27 <trackbot> http://www.w3.org/2014/data-shapes/track/issues/119
20:06:52 <hknublau> hknublau: We could leave this to a general rdf:List library that can be created by 3rd parties
20:06:55 <Arnaud> ack kcoyle
20:07:33 <hknublau> kcoyle: Many people hate rdf:Lists, but it's basic RDF standard, so we need to do something about it.
20:10:26 <hknublau> hknublau: if we are to add a standard Shape, someone needs to produce a draft
20:10:50 <hknublau> ... We should however add three NodeKinds, esp for BlankNodeOrIRI
20:11:39 <Arnaud> PROPOSED: sh:NodeKind should be extended with sh:BlankNodeOrIRI (and the two other combinations)
20:11:48 <hknublau> +1
20:11:56 <jamsden> These aren't well enouth specified for me to adequately assess them
20:12:20 <Dimitris> +1 but indeed we should enumerate all options
20:12:53 <simonstey> +-0
20:12:57 <kcoyle> q+
20:13:09 <Dimitris> q+
20:13:19 <Arnaud> ack Dimitris
20:13:44 <Arnaud> ack kcoyle
20:13:53 <hknublau> hknublau: The three new terms could be sh:BlankNodeOrIRI, sh:BlankNodeOrLiteral, sh:IRIorLiteral
20:15:30 <Arnaud> http://w3c.github.io/data-shapes/shacl/#AbstractNodeKindPropertyConstraint
20:15:59 <Dimitris> i would suggest to add only sh:NonLiteral + the old ones (sh:IRI, sh;BlankNode, sh:Literal)
20:16:49 <hknublau> @Dimitris, I have seen use cases for sh:NonBlankNode (aka IRIOrLiteral).
20:17:23 <Dimitris> we can use sh:or for special cases I think but I don;t mind to add more if needed
20:17:45 <kcoyle> can they not be combined as individuals?
20:20:46 <Dimitris> sh:IRI, sh;BlankNode, sh:Literal, sh:NonIRI, sh;NonBlankNode, sh:NonLiteral ?
20:21:37 <kcoyle> q+
20:21:47 <Arnaud> ack kcoyle
20:21:53 <simonstey> sh:not ?
20:22:25 <simonstey> +1 to Karen's concerns
20:22:33 <Arnaud> PROPOSED: sh:NodeKind should be extended with sh:BlankNodeOrIRI, sh:BlankNodeOrLiteral, sh:IRIorLiteral
20:22:35 <ericP> and any node would be blurlteral?
20:22:46 <hsolbrig> +1
20:22:47 <ericP> +1
20:22:55 <kcoyle> +1
20:22:57 <hknublau> +1 (But Dimitr's syntax would be fine too)
20:23:04 <Dimitris> +1
20:23:12 <jamsden> I don't undestand how this would be used to constrain the list, so can't vote intelligently
20:23:12 <iovka_> +1
20:23:17 <Labra> +0.5 (I would prefer NonLiteral)
20:23:21 <simonstey> sh:not [ sh:property [ sh:predicate ex:prop; sh:nodekind sh:Literal ] ]
20:23:24 <TallTed> +0.5
20:23:37 <simonstey> +0.5
20:24:02 <TallTed> I like Dimitris alternative sugar, too
20:26:12 <Arnaud> RESOLVED: sh:NodeKind should be extended with sh:BlankNodeOrIRI, sh:BlankNodeOrLiteral, sh:IRIorLiteral
20:27:08 <Arnaud> PROPOSED: change possible values of sh:NodeKind to sh:IRI, sh;BlankNode, sh:Literal, sh:NonIRI, sh;NonBlankNode, sh:NonLiteral
20:27:28 <hknublau> +0
20:27:32 <Arnaud> PROPOSED: change possible values of sh:NodeKind to sh:IRI, sh:BlankNode, sh:Literal, sh:NonIRI, sh:NonBlankNode, sh:NonLiteral
20:27:37 <hsolbrig> +0
20:27:49 <Dimitris> +1
20:28:00 <simonstey> +0,5
20:28:05 <kcoyle> -.5
20:28:07 <TallTed> +0.5  (shorter strings, same meaning, I think will fit thinking more often)
20:28:15 <Labra> +0.8
20:28:18 <ericP> +1
20:29:26 <hknublau> kcoyle: Not would be better than Non.
20:30:30 <TallTed> Non is perfectly valid English usage...
20:30:58 <ericP> +1 to naan
20:32:38 <TallTed> BlankNode should all become Blanknode -- everywhere
20:32:43 <Dimitris> NonBlanknode with lower n
20:32:50 <kcoyle> -1
20:34:21 <TallTed> TallTed: inappropriate camelcasing on Blanknode should be undone.  `BlankNode` should all become `Blanknode`.
20:34:43 <Arnaud> trackbot, end meeting
20:34:43 <trackbot> Zakim, list attendees
20:34:43 <Zakim> As of this point the attendees have been Arnaud, TallTed, kcoyle, dimitris, simonstey, hknublau, hsolbrig, labra, jamsden, iovka, ericP
<hknublau> regrets: pfps
20:34:51 <trackbot> RRSAgent, please draft minutes
20:34:51 <RRSAgent> I have made the request to generate http://www.w3.org/2016/03/03-shapes-minutes.html trackbot
20:34:52 <trackbot> RRSAgent, bye
20:34:52 <RRSAgent> I see 1 open action item saved in http://www.w3.org/2016/03/03-shapes-actions.rdf :
20:34:52 <RRSAgent> ACTION: ericP to send proposal for sh:Stem in response to ISSUE-80 [1]
20:34:52 <RRSAgent>   recorded in http://www.w3.org/2016/03/03-shapes-irc#T19-37-05