13:49:11 <RRSAgent> RRSAgent has joined #shapes
13:49:11 <RRSAgent> logging to http://www.w3.org/2015/12/16-shapes-irc
13:49:13 <trackbot> RRSAgent, make logs rdf-data-shapes
13:49:13 <Zakim> Zakim has joined #shapes
13:49:15 <trackbot> Zakim, this will be SHAPES
13:49:15 <Zakim> I do not see a conference matching that name scheduled within the next hour, trackbot
13:49:16 <trackbot> Meeting: RDF Data Shapes Working Group Teleconference
13:49:16 <trackbot> Date: 16 December 2015
13:49:29 <Arnaud> agenda: https://www.w3.org/2014/data-shapes/wiki/F2F5#Day_2_-_Wednesday_Dec_16
13:49:32 <Arnaud> chair: Arnaud
13:49:48 <Arnaud> present+
13:49:54 <Dimitris> Dimitris has joined #shapes
13:53:07 <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/F2F5 call-in info: https://www.w3.org/2014/data-shapes/wiki/F2F5#Remote_Participation
13:53:51 <Arnaud> present+ kcoyle, hknublau
13:54:06 <hsolbrig> hsolbrig has joined #shapes
13:56:04 <simonstey> simonstey has joined #shapes
13:56:12 <ericP> present+ ericP
13:56:23 <pfps> pfps has joined #shapes
13:57:13 <Arnaud> present+ hsolbrig, pfps
13:57:44 <simonstey> present+
14:00:03 <pfps> present+
14:01:16 <hsolbrig> present+ hsolbrig
14:02:14 <Dimitris> present+ dimitris
14:02:24 <hknublau> present+ hknublau
14:02:44 <aryman> aryman has joined #shapes
14:02:46 <Dimitris> I can scribe
14:02:59 <Dimitris> scribe: dimitris
<Dimitris> topic: UI concerns
14:03:31 <Dimitris> arnaud: let's talk about the UI-related issues
14:03:59 <Dimitris> ... shacl annotations to drive user interfaces
14:04:10 <aryman> present+
14:04:56 <Dimitris> ... peter said UI is a complex matter and we cannot do the full job
14:05:45 <aryman> q+
14:06:03 <Dimitris> ... before we look at specific issues we should do a high level talk
14:06:27 <Dimitris> ... strip all UI annotations or add at least some annotations
14:07:09 <Arnaud> ack aryman
14:07:11 <kcoyle> q+
14:08:01 <Dimitris> arthur: shacl should enable UI, at a high level that a form builder can display fields and perform validation
14:08:15 <pfps> Even the simple stuff currently in SHACL or being proposed should have two interoperating implementations for it to be acceptable to W3C.
14:08:17 <hknublau> q+
14:08:27 <pfps> q+
14:08:44 <Dimitris> ... we need to enable UI features
14:08:46 <Arnaud> ack kcoyle
14:09:20 <Dimitris> Kcoyle: we should call it UI, form building is more approapriate
14:09:36 <Dimitris> ... agree with arthur, UI is complex
14:10:11 <Arnaud> ack hknublau
14:10:36 <Dimitris> hknublau: it is part of our mission to enable form building, also part of the charter
14:10:53 <Dimitris> ... giving up should be under strong reasons
14:11:09 <kcoyle> q+
14:11:12 <Dimitris> ... index and property groups are simple enough to include and I will not suggest other features
14:11:23 <simonstey> q+
14:11:49 <Dimitris> ... shacl already includes a lot of features (e.g. datatypes) that can drive form building
14:12:33 <Dimitris> ... groups and index are very common and easy to include
14:14:27 <Dimitris> arnaud: the charter does not tell us how far we go
14:14:39 <Arnaud> ack pfps
14:15:16 <Dimitris> pfps: there is some stuff in shacl, quite useful for forms
14:15:47 <hknublau> q+
14:16:09 <Dimitris> ... we can stop here, that doesn't get us in the difficult decision on how far we go
14:16:23 <Dimitris> .. like liner / tree interfaces
14:16:54 <Dimitris> ... UI needs implementation e.g. sh:defaultValue
14:17:18 <Dimitris> arnaud: not sure how much implementation proof we need
14:17:32 <Dimitris> pfps: we need proof of usage
14:18:03 <Dimitris> arnaud: right, we don't need a test suite but at least some proof
14:18:18 <Arnaud> ack kcoyle
14:18:23 <Dimitris> arnaud: who would implement these features?
14:18:52 <Dimitris> kcoyle: we have different workflows
14:19:12 <Dimitris> ... the same data will be used in different context and UI is one context
14:19:20 <Arnaud> ack simonstey
14:19:59 <Dimitris> simonstey: I have a different opinion, some features can only be used in UI-stuff e.g. defaultValue
14:20:40 <Dimitris> ... in Siemens we have use cases and e.g. sh:defaultValue is needed
14:21:14 <pfps> if sh:defaultValue has a different use, then that different use could be the defining one, so long as there was an implementation.  however, my view is that W3C process requires some sort of interoperable implementation for each feature of SHACL
14:21:15 <Dimitris> ... we can not focus on UI stuff but we can enable ordering
14:21:45 <Arnaud> ack hknublau
14:21:55 <Dimitris> arnaud: defaultValue does not strike as solely UI but others do
14:22:48 <Dimitris> hknublau: in respond to Karen, shapes are the perfect match. we need a minimal framework
14:22:58 <pfps> I don't see how scopes can be used to differentiate between different UI setups on the same shape
14:23:19 <Dimitris> ... my previous approach was to focus on the templates while the WG needs more things in the core language
14:23:23 <pfps> q+
14:24:24 <Dimitris> ... testing is indeed hard, we can write some appendix on how to use that
14:25:02 <simonstey> implementations in the sense of applications using shacl or actual shacl engines?
14:25:11 <Dimitris> arnaud: we need to show we have implementations from the W3C process
14:26:06 <Arnaud> ack pfps
14:26:23 <Dimitris> ... we don't need a test suite but we need a least two people who claim they implement it
14:27:19 <Dimitris> pfps: if we add sh:index and put together a use case none believes in it is a bad idea
14:28:03 <Dimitris> ... if we put things in shacl we should do it only if we believe people will use it
14:29:30 <Dimitris> pfps, can you scribe you last comment?
14:30:09 <Arnaud> STRAWPOLL: a) drop off UI related features, b) support some UI related features
14:30:31 <hknublau> a) -1 b) +1
14:30:33 <simonstey> a) -1 b) +1
14:30:42 <Dimitris> a) -0.5, b) +1
14:31:10 <pfps> the rationale for changing the SHACL spec document with respect to the SHACL core has no commonallity with not having UI features in SHACL
14:31:13 <aryman> aryman has joined #shapes
14:31:32 <pfps> a) -1, b) +1
14:31:33 <aryman> irc dropped me - please reenter the proposal
14:32:03 <pfps> I agree with Karen but I think that the thrust of the straw poll is correct
14:32:08 <pfps> oops
14:32:10 <Dimitris> kcoyle: it's not black & white, some parts are also documentation
14:32:14 <pfps> a) +1, b) -1
14:32:25 <hknublau> @pfps I think we are talking about different things.
14:32:34 <ericP> i'm completely undecided
14:32:35 <Dimitris> ... some parts of shacl but be only UI and some both
14:32:41 <ericP> a) ?, b) ?
14:33:06 <simonstey> that was my point
14:33:19 <Dimitris> s/but/can be/
14:33:45 <simonstey> +q
14:33:48 <hknublau> To me it already looks like we cannot make a general decision.
14:33:53 <hsolbrig> hsolbrig has joined #shapes
14:33:56 <aryman> please repeat the straw poll question
14:34:16 <kcoyle> STRAWPOLL: a) drop off UI related features, b) support some UI related features
14:34:29 <Arnaud> ack simonstey
14:34:30 <Dimitris> ... we need to define our terms, what do we mean by UI-related
14:35:22 <Dimitris> simonstey: we can drop external UI-related requests
14:36:01 <simonstey> maybe https://www.w3.org/2014/data-shapes/track/issues/114
14:36:32 <Dimitris> arnaud: can you give me an example of a feature that can be used both for UI ?
14:36:58 <Dimitris> hknublau: sh:index can also be used to write turtle files and preserve the order
14:37:40 <aryman> a) -0.5 b) +0.5
14:38:07 <Dimitris> arnaud: are we limiting ourself to validation only?
14:38:19 <pfps> sh:description is a SHACL property that could be used for UIs.  In fact, its main purpose is UI-related.  However, sh:description is hooked into SHACL error reporting, which, I think, was its initial purpose.  That said, there is still a need for implementation experience related to sh:description.
14:38:32 <Dimitris> kcoyle: if parts of shacl can be used for UI that's fine
14:39:04 <kcoyle> a) + .5 b) -.5
14:39:49 <Dimitris> arnaud: strawpoll indicates people are interested in UI, we will look in a case by case basis
14:40:09 <Arnaud> topic: ISSUE-100 -- sh:index
14:40:09 <trackbot> issue-100 -- Specifying the order of property constraints (e.g. with sh:index) -- open
14:40:09 <trackbot> http://www.w3.org/2014/data-shapes/track/issues/100
14:40:38 <hknublau> (sh:index should be renamed to sh:order)
14:41:26 <aryman> maybe sh:sortKey
14:41:49 <Dimitris> hknublau: harold suggested sh:order, index starts from 0 order is more flexible
14:41:49 <aryman> allows xsd:decimal values
14:42:12 <hsolbrig> plus, index could be perceived as an identifier.  Confusing...
14:43:08 <Arnaud> https://www.w3.org/2014/data-shapes/wiki/Proposals#ISSUE-100:_sh:index
14:43:44 <hknublau> PROPOSED: Add an optional annotation property sh:order (datatype: xsd:decimal) to property constraints, with the intention of representing the relative ordering of properties, e.g. for display purposes.
14:43:53 <pfps> q+
14:44:06 <Arnaud> ack pfps
14:44:26 <Dimitris> pfps: what optional means here?
14:44:46 <Dimitris> ... this proposal comes out of the blue, it's different from issue 100
14:45:49 <Dimitris> ... issue 100 specifies the order of property constraints, this proposal talks about properties
14:46:38 <kcoyle> q+
14:46:56 <aryman> q+
14:47:13 <Arnaud> PROPOSED: Add an annotation property sh:order (datatype: xsd:decimal) to property constraints, to represent the relative ordering of properties in the context of a shape, e.g. for display purposes.
14:48:05 <simonstey> the order in which property constraints shall be evaluated?
14:48:20 <Arnaud> PROPOSED: Add an annotation property sh:order (datatype: xsd:decimal) to property constraints, to represent the relative ordering of property constraints, e.g. for display purposes.
14:49:48 <TallTed> TallTed has joined #shapes
14:54:19 <Arnaud> PROPOSED: Add an annotation property sh:order (datatype: xsd:decimal) to property constraints, to represent the relative ordering of property constraints, for uses such as form building
14:54:58 <hknublau> +1
14:55:17 <Dimitris> ericP: in shex everything is ordered and we don't anything special
14:56:22 <Dimitris> arnuad: if you need to translate shex in shacl would you need this feature?
14:56:37 <Dimitris> hsolbrig: yes
14:58:16 <Dimitris> ericp: if shacl doesn't have order, we would need a way to translate shex into shacl
14:58:25 <pfps> 0 but note that for this feature to survive there needs to be an implementation that uses it for a useful purpose
14:58:53 <hsolbrig> +1
14:58:56 <ericP> +1
14:58:58 <Dimitris> +1
14:59:00 <simonstey> +1
14:59:09 <aryman> +1
14:59:15 <kcoyle> +.5
14:59:45 <Arnaud> q?
14:59:49 <Arnaud> ack kcoyle
15:00:12 <Dimitris> kcoyle: is annotation the same as owl annotation property?
15:00:46 <Dimitris> https://www.w3.org/2014/data-shapes/wiki/Requirements#Annotations
15:01:18 <Dimitris> hknublau: similar but not the same
15:01:33 <Arnaud> ack aryman
15:01:51 <simonstey> but for the ShEx use, it should affect the validation right?
15:02:01 <Dimitris> aryman: this also applies to inverse property constraints
15:02:39 <Dimitris> ... the wording of the original proposal was correct
15:02:54 <Dimitris> ... we can have multiple property constraints for the same property
15:03:40 <Arnaud> RESOLVED: Close ISSUE-100, add a property sh:order (datatype: xsd:decimal) to property constraints (and inverse ones), to represent the relative ordering of property constraints, for uses such as form building
15:04:16 <hknublau> Looks good to me.
15:04:30 <kcoyle> yes
15:04:33 <hsolbrig> yes
15:04:37 <Dimitris> yes
15:04:43 <ericP> yes
15:04:59 <Dimitris> topic: ISSUE-113 -- SHACL and user interfaces 
15:04:59 <trackbot> ISSUE-113 -- Let a user interface group design the connection between SHACL and UI tools -- open
15:04:59 <trackbot> http://www.w3.org/2014/data-shapes/track/issues/113
15:06:05 <Dimitris> arnaud: should we close this?
15:06:43 <Arnaud> PROPOSED: Close ISSUE-113, with no action
15:06:44 <Dimitris> pfps: the WG  can  close this with no action
15:06:52 <pfps> 0
15:07:16 <Arnaud> RESOLVED: Close ISSUE-113, with no action
15:07:39 <Dimitris> topic: ISSUE-114 -- Property Groups
15:07:39 <trackbot> ISSUE-114 -- Should SHACL include a grouping mechanism of properties (for UI purposes) -- open
15:07:39 <trackbot> http://www.w3.org/2014/data-shapes/track/issues/114
15:08:05 <Arnaud> https://www.w3.org/2014/data-shapes/wiki/Proposals#ISSUE-114:_Property_Groups
15:09:25 <Dimitris> hknublau: in forms we can create groups of properties e.g. address-related fields
15:09:39 <Dimitris> ... the properties will be ordered and the groups can also be ordered
15:09:55 <Dimitris> ... this is a common pattern we have in practice
15:10:14 <Arnaud> PROPOSED: Close ISSUE-114, adding property groups as proposed
15:10:24 <hknublau> +1
15:10:32 <hsolbrig> +1
15:10:46 <simonstey> +0.5
15:10:47 <Dimitris> +0.5
15:10:59 <kcoyle> -.2
15:11:00 <pfps> 0 noting that this feature will need UI usage to survive
15:11:09 <aryman> +0.5
15:11:17 <ericP> +1
15:11:32 <pfps> karen?
15:11:47 <kcoyle> yeah?
15:11:59 <pfps> i'm surprised at your vote
15:12:36 <Dimitris> kcoyle: I feel this is heading down in adding things only intended for UI
15:13:06 <hknublau> To me this is the last of this kind for the foreseeable future.
15:13:08 <aryman> q+
15:13:13 <Dimitris> for ordering turtle documents again?
15:13:16 <simonstey> we just talked about that but didn't vote
15:13:18 <Arnaud> ack aryman
15:13:36 <hsolbrig> q+
15:13:40 <Dimitris> aryman: this can be used for documentation
15:13:49 <Arnaud> ack hsolbrig
15:14:46 <Dimitris> hsolbrig: this is useful for grouping
15:14:50 <Arnaud> RESOLVED: Close ISSUE-114, adding property groups as proposed
15:15:05 <pfps> the implementation experience is going to need two implementations for the same purpose, otherwise there is no interoperability
15:15:59 <Dimitris> arnaud: if there is no implementation at the end we will drop them
15:16:28 <Dimitris> ... 15 minutes break
15:33:50 <hsolbrig> test
15:35:04 <aryman> aryman has joined #shapes
15:35:42 <aryman> Scribe: aryman
15:36:09 <hknublau> This was already discussed yesterday. We can skip this today.
15:36:38 <aryman> Topic: ISSUE-23
15:39:00 <Arnaud> PROPOSED:  Close ISSUE-23, don't have sh:ShapeClass, require explicit scopeClass
15:39:05 <aryman> Arnaud: yesterday the WG voted to not infer sh:scopeClass in the absence of Holger
15:39:12 <hknublau> -1
15:39:21 <aryman> +1
15:39:22 <ericP> +1
15:39:23 <pfps> +1
15:39:25 <hsolbrig> +1
15:39:27 <kcoyle> +1
15:39:36 <simonstey> +0.5
15:39:41 <Dimitris> +1
15:39:44 <pfps> any comments from Holger?
15:39:51 <aryman> chair: Arnaud
15:42:02 <aryman> Arnaud: asks Holger why the -1? what does it take to change your vote?
15:43:24 <aryman> hknublau: disappointed that the topic was discussed in my absence. doesn't know what was discussed so can't really react
15:44:30 <hsolbrig> q+
15:45:49 <aryman> Arnaud: asks why is it a problem that sh:scopeClass be present explicitly
15:46:45 <aryman> hknublau: this is a major usability issue. It will impair the adoption of SHACL.
15:48:19 <aryman> hknublau: the semantic web needs a modelling language like SHACL. OWL is not suitable and has not been adopted much. Too academic. Requiring three triples looks bad.
15:48:19 <hsolbrig> q-
15:49:54 <aryman> hknublau: suggest adding rules to SHACL, as in SPIN, that add additional triples
15:51:32 <aryman> hknublau: similar to OWL-RL. Use SPARQL CONSTRUCT queries.
15:52:17 <aryman> Arnaud: what's the connection between sh:scopeClass and Rules?
15:53:15 <ericP> q+
15:53:20 <aryman> the rule add missing triples like sh:scopeClass
15:53:20 <Arnaud> ack ericP
15:53:22 <pfps> q+
15:54:23 <aryman> ericP: which of your users would object since they use TopBraid and the form based interface to create shapes?
15:56:12 <aryman> hknublau: I believe the main growth area is JSON users. SHACL could become a better schema language for JSON, better than JSON-schema
15:56:16 <Arnaud> ack pfps
15:57:00 <aryman> pfps: would adding rules to SHACL require a re-chartering?
15:57:49 <aryman> Arnaud: it sounds like Holger is just looking for reaction of the WG at this point
15:59:14 <simonstey> I would like to see rules in SHACL ;)
16:00:11 <aryman> Arnaud: the clear majority of the WG voted to not infer sh:scopeClass
16:00:52 <aryman> hknublau: can we discuss my proposal for rules?
16:01:18 <aryman> Arnaud: first let's resolve ISSUE-23
16:02:41 <pfps> q+
16:02:42 <simonstey> q+
16:02:46 <Arnaud> ack pfps
16:03:11 <Arnaud> ack simonstey
16:03:19 <aryman> pfps: against expanding the charter of this WG, not the right people here
16:04:05 <aryman> simonstey: I am in favour of rules since they are very useful in many cases
16:04:45 <aryman> q+
16:04:47 <Dimitris> I agree with Simon
16:05:06 <pfps> q+
16:05:12 <Arnaud> ack aryman
16:05:42 <hknublau> q+
16:06:02 <pfps> do the minutes reflect whether simon and dimitris agree with taking up rules in the wg?
16:06:05 <Arnaud> ack pfps
16:07:05 <Dimitris> q+
16:07:17 <Arnaud> ack hknublau
16:09:02 <Arnaud> ack Dimitris
16:09:16 <aryman> hknublau: inferring the triples seems very low hanging - what is the objection
16:10:20 <aryman> Dimitris: rules would be useful, but it does look out of scope
16:11:17 <aryman> Arnaud: asks pfps why he feels inferencing would be difficult
16:12:33 <aryman> pfps: the main point of difference is the role of SHACL as a modelling language. Holger believes SHACL should be a modelling, I believe it should not since there are other W3C modelling languages and we should build on those
16:13:25 <ericP> q+ to say that it's one extra triple at the minimum, 2 extra at the max, needlessly obscures scopeClass, and encourages short-sighted modeling with non-reusable classes.
16:13:35 <pfps> q+
16:13:57 <aryman> hknublau: so there is really no technical obstacle to inferring sh:scopeClass - this is purely a philosophical argument about the role of SHACL.
16:14:00 <Arnaud> ack ericP
16:14:00 <Zakim> ericP, you wanted to say that it's one extra triple at the minimum, 2 extra at the max, needlessly obscures scopeClass, and encourages short-sighted modeling with non-reusable
16:14:00 <Dimitris> q+
16:14:03 <Zakim> ... classes.
16:14:23 <aryman> hknublau: OWL has not succeeded in the marketplace.
16:16:16 <pfps> q-
16:16:26 <Arnaud> ack Dimitris
16:16:36 <aryman> ericP: inferring sh:scopeClass would make it difficult for people to understand the scope since it requires inferencing and is not explicit
16:16:49 <pfps> holger had a very nice argument, but that argument needs to be made to W3C, not to this working group
16:17:39 <aryman> Dimitris: preferred option (d) which eliminated RDFS inferencing
16:17:55 <aryman> q+
16:18:28 <Arnaud> ack aryman
16:18:40 <aryman> Arnaud: has been championing Holgers proposal but it didn't fly
16:20:29 <Dimitris> q+
16:20:35 <hknublau> q+
16:20:54 <aryman> aryman: both camps are raising spurious objections to this ISSUE-23. The real issue is the status of SHACL as a modelling language. Let's resolve this issue.
16:21:09 <pfps> q+
16:21:25 <pfps> q-
16:22:14 <Arnaud> ack Dimitris
16:22:44 <aryman> Arnaud: If TQ implements inferencing then they can gauge the market acceptance and influence SHACL.
16:23:04 <Arnaud> ack hknublau
16:23:17 <aryman> Dimitris: SKOS was not intended as a modelling language but is used this way now.
16:24:20 <pfps> there are many things that the working group has done that I am strongly against - that's how things go in a working group
16:25:05 <aryman> hknublau: TQ did concede on the decision to separate Shapes and Classes even though we believed it was wrong. I am disappointed in the process.
16:25:23 <Arnaud> PROPOSED:  Close ISSUE-23, don't have sh:ShapeClass, do not require explicit scopeClass
16:25:31 <Dimitris> q+
16:25:42 <Arnaud> ack Dimitris
16:26:15 <aryman> Dimitris: This requires the ontologies to always be available.
16:27:21 <pfps> -1 assuming that this means roughly do what is in the editors' draft right now
16:27:25 <hknublau> +1
16:27:27 <aryman> Dimitris: still need to do inferencing e.g. on rdfs:subClassOf
16:27:33 <kcoyle> ?? not a clue
16:27:40 <aryman> +0
16:27:44 <hknublau> For the record I could also live with Dimitris approach.
16:27:49 <Dimitris> -0.9
16:27:54 <simonstey> 0 not sure about the implications
16:28:12 <hsolbrig> +0
16:29:29 <aryman> Arnaud: asks Dimitris to rephrase proposal using option (d)
16:30:59 <Arnaud> break 30mn
16:31:14 <hsolbrig> I have to step out in half an hour
16:31:51 <Arnaud> ok, so maybe we'll just postpone that to tomorrow
16:33:53 <Dimitris> PROPOSED: Close ISSUE-23 by introducing sh:ClassShape, a rdfs:subClassOf sh:Shape. sh:ClassShape indicates that the Shape IRI is also the sh:scopeClass of the Shape and forbids an explicit sh:scopeClass declaration. If and where the shape IRI is defined as an rdfs:Class is out of scope for SHACL.
16:36:10 <Arnaud> do you really mean "forbids"?
16:36:31 <Arnaud> I think that's stronger than you mean
16:36:56 <Arnaud> what if I still had scopeClass? wouldn't necessarily be a problem, right?
16:38:45 <Dimitris> this would lead to confusion on which scope is used (if different)
16:38:54 <Dimitris> but we can discuss that
17:04:46 <pfps> i can scribe
17:04:59 <pfps> scribe: pfps
17:05:11 <pfps> Topic: Next meeting
17:05:26 <pfps> Arnaud: is there is a chance for a real F2F?
17:05:43 <pfps> My travel budget for 2016 is still unknown, but likely to be small
17:06:00 <pfps> Arnaud: It would be nice to get a few options and then maybe do a poll
17:06:20 <pfps> Arnaud: MIT may be the best option
17:07:09 <pfps> Arnaud: we need critical mass at the actual meeting
17:07:36 <pfps> Holger: I think that the format for this meeting is good, particularly the six hours and short breaks
17:08:03 <pfps> Arnaud: Short lunch breaks make it difficult to go out for lunch
17:08:28 <pfps> Arnaud: should we try to have a F2F meeting?
17:08:41 <pfps> Eric:  I don't think I will have funds to travel
17:08:48 <aryman> aryman has joined #shapes
17:09:04 <pfps> Dimitris: US will be hard for me
17:09:16 <pfps> Arnaud: should we just go for virtual
17:09:24 <pfps> q+
17:09:45 <Arnaud> ack pfps
17:10:01 <pfps> pfps: I have a slight preference for a physical F2F, but only if nearly everybody shows up
17:10:44 <pfps> Arnaud: I also prefer a physical F2F, but with few people there, then no
17:11:28 <pfps> Arnaud: the F2F in France had attendance but even not everyone in Europe was there
17:11:54 <pfps> Arnaud: what dates work?
17:12:07 <pfps> Arnaud: three months from now is March
17:12:09 <pfps> q+
17:12:40 <Arnaud> ack pfps
17:12:46 <pfps> pfps: mid to late march works well for me
17:13:06 <Dimitris> I will be unavailable from 26/2 - 5/3
17:14:37 <pfps> Arnaud: W3C AC meeting is 20-22 March
17:15:11 <pfps> Arnaud: three months from now is 15-17 March
17:15:34 <pfps> pfps: we probably should have an alternate time
17:17:57 <pfps> Arnaud: March 8-10 or 29-31 are options
17:18:26 <pfps> Araud: also physical at MIT 23-25
17:18:49 <pfps> Arnaud: I'll set up a doodle poll
17:19:29 <pfps> eric: I have a meeting in San Francisco March 21-24
17:20:43 <pfps> Arnaud: I'll drop that option off the poll
17:21:21 <pfps> Topic: Recursion
17:21:31 <aryman_> aryman_ has joined #shapes
17:21:49 <pfps> Arnaud: recursion is one of the big issues
17:22:03 <pfps> Arnaud:  one extreme is to disallow recursion
17:22:41 <pfps> Arnaud: people find recursion useful, but full-fledged recursion has problems
17:22:55 <aryman_> q+
17:23:00 <pfps> Arnaud: can we find a sweet spot that does not have problems
17:23:13 <pfps> Arnaud: there are specific issues that are open as well
17:23:20 <Arnaud> ack aryman
17:23:42 <pfps> arthur: there is a wiki page with use cases for ISSUE-66
17:23:50 <Arnaud> https://www.w3.org/2014/data-shapes/wiki/ISSUE-66:_SHACL_spec_ill-founded_due_to_non-convergence_on_data_loops
17:23:53 <pfps> arthur: so there is interest in recursion
17:24:13 <pfps> arthur: we don't really have a good spec for recursion
17:24:30 <pfps> arthur: there is nothing in the spec that defines how recursion works
17:24:57 <pfps> arthur: we could take a conservative position and reject any shapes graph that where a shape refers to itself
17:25:11 <pfps> arthur: this gives us a starting point that will work
17:25:41 <pfps> arthur: I have a document that specifies how to interpret positive recursion - no negation, no disjunction
17:26:19 <pfps> arthur: if you limit yourself to that subset there is no semantic problem but this needs to be turned into suitable stuff for the SHACL spec
17:26:42 <pfps> arthur: you could go further and look at recursion with negation and disjunction
17:27:19 <pfps> arthur: a definition of recursion with negation came from Iovka, I think that it had no problems
17:27:37 <pfps> arthur: however that approach is not being maintained
17:28:21 <pfps> arthur: perhaps the most recent ShEx spec has a good definition of limited recursion but I'm not motivated to look at a ShEx version of recursion again
17:28:37 <pfps> arthur: I'm not sure how much further than the positive case we can go
17:28:59 <aryman> aryman has joined #shapes
17:29:16 <pfps> arnaud: it seems like negation always comes up and maybe we can agree not to include this
17:29:41 <hknublau> q+
17:29:43 <pfps> arthur: with recursion over negation you can easily get inconsistent shapes
17:29:44 <pfps> q+
17:29:48 <Arnaud> ack hknublau
17:30:27 <pfps> holger: I generally agree that we can go for the simple solution and support recursion for only the simple cases
17:30:50 <pfps> holger: this should cover most of the useful cases and not be hard to implement
17:30:58 <Arnaud> ack pfps
17:31:25 <pfps> pfps: I'm not sure that arthur and holger are saying the same thing
17:31:27 <aryman> q+
17:31:33 <Arnaud> ack aryman
17:31:39 <pfps> pfps: I think that arthur's base case is no self-reference
17:32:00 <pfps> arthur: the starting position should be no self-reference in shapes
17:32:23 <pfps> arthur: I believe that it is possible to have a clean spec for positive recursion
17:32:47 <pfps> arthur: positive recursion can be included when a solution is found
17:33:05 <pfps> arthur: further expansions could also be possible
17:33:09 <pfps> q+
17:33:15 <Arnaud> ack pfps
17:33:29 <pfps> pfps: the diference I see is recursion vs data loops
17:33:40 <pfps> pfps: arthur wants to be conservative on recursion
17:33:54 <pfps> pfps: the current spec is conservative on data loops
17:34:01 <pfps> pfps: that's a big difference
17:34:03 <aryman> q+
17:34:11 <Arnaud> ack aryman
17:34:15 <pfps> arthur: correct
17:34:45 <pfps> arthur: the reason is that we don't say what happens when we hit a data loop and that causes circularity
17:35:01 <pfps> arthur: if you allow recursion then you have to say what happens on data loops
17:35:30 <pfps> arthur: this is complicated and not specified well in the current spec
17:35:46 <pfps> arnaud: is there any disgreement on this?
17:36:16 <ericP> q+ to ask about working with Iovka on recursion
17:36:19 <pfps> arthur: I propose that if there are any dependency loops in the shape graph then it is invalid
17:36:21 <Arnaud> ack ericP
17:36:21 <Zakim> ericP, you wanted to ask about working with Iovka on recursion
17:36:50 <pfps> eric: it seems like the people who have done the most work on recursion ...
17:37:37 <pfps> eric: ... ShEx allows shapes recursion but only in limited circumstances
17:38:00 <pfps> eric: recursion is allowed and loops are defined as success
17:38:13 <pfps> eric: why can that not be the base case?
17:38:20 <pfps> arthur: that is unintuitive
17:38:47 <pfps> arthur: that doesn't give you a procedure for computing the typings
17:39:26 <pfps> scribe note:  I may have messed up the ShEx situation - ShEx is more like "guess an assignment and then verify that it works"
17:40:01 <pfps> arthur: I'm not motivated to look at yet another ShEx paper unless it is tied to SHACL somehow
17:40:33 <pfps> eric: what kind of contribution would you like
17:40:46 <pfps> arthur: how about a spec (for recursion) that used the terms of SHACL/
17:40:50 <pfps> eric: OK
17:40:57 <pfps> q+
17:41:00 <pfps> q-
17:41:33 <pfps> arnaud: there is time for SHACL vs ShEx later so let's leave that aside for now
17:42:40 <pfps> arthur: I'm proposing that the spec should be well grounded and only include what is known to work completely
17:42:48 <pfps> arnaud: that is a pragmatic approach
17:43:07 <pfps> arnaud: arthur is saying that we should simplify the problem for now
17:43:25 <pfps> arnaud: without prohibiting expansions
17:43:32 <pfps> arnaud: is that reasonable?
17:43:41 <pfps> q+
17:43:44 <Dimitris> +1
17:43:57 <pfps> q-
17:44:04 <pfps> this works for me
17:44:33 <pfps> arthur: a shacl graph with a loop would be invalid and throw an error
17:44:46 <pfps> arthur: before any validation
17:45:19 <pfps> arthur: a shape can depend on another shape - that defines a relation between shapes
17:45:37 <pfps> arthur: the prohibition would be against loops in the transitive closure of this relation
17:45:43 <Arnaud> PROPOSED: shapes graphs with loops are invalid
17:46:24 <pfps> arthur: a SHACL processor would have to check for loops in the dependency relation
17:46:39 <pfps> q+
17:46:49 <Arnaud> ack pfps
17:47:15 <pfps> arnaud: this proposal could be revisited if further information comes to light
17:47:31 <pfps> pfps: I think that this proposal is a bit harsh on recursion
17:48:45 <pfps> PROPOSED: the starting point for recursion in SHACL is that shapes graphs with dependency loops are invalid, suitable limitations of this will be explored
17:49:05 <pfps> arthur: that is the intention
17:49:21 <hknublau> 0
17:49:21 <aryman> +1
17:49:26 <pfps> +1
17:49:34 <ericP> 0
17:49:35 <Dimitris> +1
17:49:46 <pfps> q+
17:50:14 <Arnaud> RESOLVED: The starting point for recursion in SHACL is that shapes graphs with dependency loops are invalid, suitable limitations of this will be explored
17:50:24 <Arnaud> ack pfps
17:50:43 <pfps> pfps: from the point of the working group all this says is that there should be a clean version of the spec for recursion
17:50:59 <pfps> pfps: the spec should say that recursion remains open
17:51:01 <aryman> +1
17:51:32 <pfps> arnaud: as long as we don't close the door it is useful to have limited solutions
17:52:04 <pfps> arnaud: what else is there to do?
17:53:17 <pfps> pfps: I think that someone should push on recursion, or maybe several someones
17:53:48 <pfps> pfps: there are a number of proposals for recursion on the table
17:54:17 <pfps> arnaud: with that resolution is there anything else that needs to be fixed in the spec
17:54:29 <pfps> arthur: if we make that change then the spec is OK
17:54:48 <pfps> arnaud: so we can live with that for now until there is a workable proposal for recursion
17:55:04 <pfps> arthur: I think that the spec is in good shape if recursion is removed for now
17:55:31 <pfps> arnaud: arthur and others will be working on recursion
17:56:19 <pfps> arnaud: can we close issues
17:56:20 <pfps> q+
17:56:24 <Arnaud> ack pfps
17:56:49 <pfps> pfps: I don't think that we want to close this issue, as there is still work on recursion
17:57:15 <pfps> arnaud: can we close ISSUE-66
17:57:37 <pfps> arthur: issue 22 is about static analysis issue 66 is about dynamic analysis
17:58:12 <pfps> arthur: the current resolution covers both, but if recursion is handled then dynamic analysis is needed
17:58:26 <pfps> arnaud: we could close 66
17:58:29 <pfps> q+
17:58:34 <Arnaud> ack pfps
17:58:56 <pfps> pfps: fine by me
18:00:05 <pfps> PROPOSED: Close ISSUE-66 as being covered (for now) by the previous resolution.  Recursion in shapes will need to cover data loops, as indicated in ISSUE-22
18:00:19 <pfps> +1
18:00:23 <aryman> +1
18:00:31 <ericP> +1
18:00:41 <hknublau> +1
18:00:58 <Dimitris> +1
18:01:09 <Arnaud> RESOLVED: Close ISSUE-66 as being covered (for now) by the previous resolution.  Recursion in shapes will need to cover data loops, as indicated in ISSUE-22
18:02:14 <pfps> arnaud: no other recursion issues
18:02:45 <pfps> arnaud: did we talk about issue-73?
18:03:16 <pfps> ....
18:03:57 <pfps> arnaud: I'm surprised that this went so fast
18:04:08 <pfps> arnaud: maybe it's because we punted
18:04:54 <pfps> arthur: the spec is complicated so we need to have a firm definition of recursion before proceedings
18:05:21 <pfps> arthur: in OLSC resource shapes things were simpler so recursion caused fewer problems
18:05:59 <pfps> arthur: without recursion macro-expansion is a possible implementation technique
18:06:24 <pfps> arthur: it's conceivable that we could define SHACL-lite that excluded recursion
18:07:23 <pfps> pfps: the problem with ISSUE-73 is that it is very technical
18:08:05 <pfps> pfps: I was meaning recursion error, but other errors have same issue
18:08:22 <pfps> pfps: which is how to errors interact with validation
18:08:28 <hknublau> q+
18:08:53 <pfps> pfps: do we need a notion of runtime ordering or can we have a spec that is neutral on that
18:09:13 <pfps> arnaud: we did discuss errors in the context of conjunction
18:09:30 <Arnaud> ack hknublau
18:09:31 <pfps> arnaud: the spec was ambiguous
18:10:48 <pfps> holger: I believe that I have a solution that is independent of order, and that depends on three different return values (true, false, and error)
18:11:23 <pfps> holger: any place where unbound (error) can arise needs to propagate that error
18:11:36 <pfps> arthur: we agreed that hasShape is in the spec
18:12:12 <Arnaud> http://w3c.github.io/data-shapes/shacl/#constraints
18:12:16 <pfps> holger: the spec needs to consider the three return values
18:12:25 <pfps> arthur: are there any other errors?
18:12:38 <pfps> holger: unknown execution engines
18:12:55 <pfps> arthur: in just the core are there any other errors
18:13:04 <pfps> holger: I don't think so
18:13:09 <pfps> q+
18:13:44 <pfps> arthur: just hitting a data loop may not be an error
18:13:55 <pfps> arthur: what about run time errors like division by zero
18:14:21 <pfps> holger: division by zero is a different situation
18:14:33 <pfps> arthur: you shouldn't get exceptions
18:14:46 <pfps> arthur: the SPARQL spec says what happens
18:14:59 <pfps> eric: SPARQL does consider these situations
18:15:22 <pfps> arthur: i put a pointer to the section of the spec that discusses sh:hasShape
18:15:32 <pfps> s/arthur/arnaud/
18:15:41 <pfps> arnaud: there is an explanation there
18:15:46 <Arnaud> ack pfps
18:15:50 <pfps> arnaud: the question is wether this is sufficient
18:16:51 <pfps> pfps: it's been a little since I looked at SPARQL, my understanding is that it does do a right thing, we need to also do a right thing
18:17:21 <ericP> sparql -e 'ASK { FILTER (1 / 0) }'
18:17:22 <ericP> false
18:18:11 <pfps> pfps: my understanding is that SPARQL has problems with silently dropping solutions
18:18:34 <pfps> arnaud: this looks a bit strange
18:19:01 <pfps> arthur: SPARQL can do something different as long as it is coherent
18:19:33 <pfps> eric: SPARQL doesn't try to patch the behaviour of XPATH, which it depends on
18:20:56 <pfps> arnaud: we need to figure out what to do with the last session today
18:21:28 <pfps> arnaud: can we have a plan on how to close this issue
18:21:39 <pfps> good enough
18:33:11 <pfps> topic: Continuing on ISSUE-73
<pfps> ISSUE-76 was closed, specifying that information order does not matter
18:34:16 <pfps> this indicates that SHACL should treat errors in such a way that execution order does not matter
18:34:20 <pfps> s/information/execution/
18:34:48 <pfps> of course, there needs to be some fudging about the meaning of "matter"
18:35:02 <aryman> 
18:35:24 <aryman_> aryman_ has joined #shapes
18:37:01 <hknublau> scribe: hknublau
18:37:38 <hknublau> Arnaud: I think we should continue with ISSUE-73
18:37:54 <pfps> q+
18:38:09 <Arnaud> ack pfps
18:38:13 <pfps> continuing on ISSUE-73 - ISSUE-76 was closed, specifying that execution order does not matter
18:38:37 <pfps> this indicates that SHACL should treat errors in such a way that execution order does not matter
18:39:19 <pfps> we could close this issue, saying that the same idea is to be applied as for ISSUE-76, and leave implementation to the implementators
18:40:00 <pfps> of course, there needs to be some fudging about the meaning of "matter"
18:40:16 <hknublau> pfps: This means that someone needs to go through the spec to make sure that definition order does not matter
18:40:37 <hknublau> ... e.g. if there are two errors, who knows which one you get.
18:40:58 <ericP> sparql -e 'ASK { { FILTER (1 / 0) } UNION { FILTER (1 / 0) } }'
18:40:59 <ericP> I'm sorry Dave, I can't do that.
18:41:03 <hknublau> (I think we specced this out already)
18:42:12 <hknublau> ericP: The above produces no solution, errors get masked.
18:42:32 <ericP> sparql -e 'SELECT * { { FILTER (1 / 0) } UNION { BIND (1 AS ?x) } }'
18:42:32 <ericP> +----+
18:42:32 <ericP> | ?x |
18:42:32 <ericP> |  1 |
18:42:32 <ericP> +----+
18:43:52 <hknublau> pfps: I think we can close this until someone shows a problem in the spec.
18:45:05 <Arnaud> PROPOSED: Close ISSUE-73, no need until evidence of an actual problem, addressed with previous resolution of execution order doesn't matter
18:45:26 <hknublau> +1
18:45:39 <aryman_> perhaps we should spell this out as a design principle for SHACL
18:45:41 <pfps> +1
18:45:49 <aryman_> add a statement to the spec
18:45:57 <aryman_> +1
18:46:08 <ericP> 0
18:46:22 <Dimitris> +1
18:47:03 <pfps> I don't think that there is a general statement in the spec to the effect that evaluation order does not matter
18:47:21 <hknublau> I don'tr remember
18:47:28 <pfps> I believe that the spec did change
18:49:05 <Arnaud> RESOLVED: Close ISSUE-73, no need until evidence of an actual problem, addressed with previous resolution of execution order doesn't matter
18:50:57 <hknublau> Arnaud: We could go back to ISSUE-23 now to make sure everyone understands Dimitris' proposal.
<hknublau> topic: ISSUE-23
18:51:36 <Dimitris> here's the proposal again
18:51:38 <Dimitris> PROPOSED: Close ISSUE-23 by introducing sh:ClassShape, a rdfs:subClassOf sh:Shape. sh:ClassShape indicates that the Shape IRI is also the sh:scopeClass of the Shape and forbids an explicit sh:scopeClass declaration. If and where the shape IRI is defined as an rdfs:Class is out of scope for SHACL.
18:53:16 <hknublau> It should also not have any other sh:scope triple.
18:53:21 <pfps> Isn't this the current situation?
18:53:38 <pfps> q+
18:53:46 <Arnaud> ack pfps
18:53:47 <Dimitris> q+
18:53:56 <Arnaud> ack Dimitris
18:54:10 <hknublau> Dimitris: sh:ClassShape is not a metaclass anymore.
18:54:27 <hknublau> ... It doesn't automatically make this a class, it just assumes it's a class (declared elsewhere)
18:55:06 <hknublau> Arnaud: An example would help.
18:55:34 <Dimitris> foaf:Person a sh:ClassShape is an example which translates to foaf:Person a sh:Shape; sh:scopeClass foaf:Person
18:55:38 <pfps> I would also like to see some examples of this in use
18:56:08 <Dimitris> the different is that we make no assertions on foaf:Person a rdfs:Class
18:56:31 <hknublau> pfps: This is hard to answer, requires detailed investigation
18:57:29 <hknublau> Arnaud: example in an email for tomorrow would be good
18:59:39 <hknublau> hknublau: This would typically be used in conjunction with a separate RDFS/OWL file that contains the class definitions, without corrupting existing apps
19:00:19 <hknublau> What about the release cycle of the next spec?
19:00:38 <hknublau> It sounds like we made good progress so far
19:02:00 <aryman_> q+
19:02:34 <hknublau> topic: ISSUE-102 -- specifying defaults
19:02:34 <trackbot> ISSUE-102 -- Missing a way to explicitly code unbound cardinality and open shapes -- open
19:02:34 <trackbot> http://www.w3.org/2014/data-shapes/track/issues/102
19:03:07 <hknublau> Arnaud: We have various places with implicit default values - there are lots of them. If you don't specify anything then there is no constraint.
19:03:43 <Arnaud> ack aryman_
19:03:49 <hknublau> ... we could decide max count is not an integer but an indentifier such as "unbound"
19:04:11 <pfps> no sound
19:05:05 <pfps> q+
19:05:08 <hknublau> aryman_: While I am sympathetic to Karen, where do we draw the line - we would have to define default values for many other things too
19:05:12 <ericP> q+ to ask about defaults
19:05:25 <Arnaud> ack pfps
19:05:47 <hknublau> pfps: Current situation is that if there is nothing specified then no constraint is checked.
19:06:07 <hknublau> ... one might argue that minCount=0 is useless and should be removed.
19:06:09 <aryman_> q+
19:07:08 <Arnaud> ack ericP
19:07:08 <Zakim> ericP, you wanted to ask about defaults
19:07:32 <hknublau> ericP: This works for min/maxCount but has the opposite effect on filterShape
19:07:53 <hknublau> pfps: I would say not.
19:08:18 <hknublau> ... filter is an implicit negation
19:08:49 <hknublau> ericP: this may be true but is there value in having this dogma
19:09:27 <hknublau> pfps: We have invisible defaults to do nothing.
19:09:43 <hknublau> ... every constraint would have to have an unbounded syntax.
19:10:44 <Arnaud> ack aryman_
19:11:09 <hknublau> aryman_: sh:minCount=0 actually has some semantics - just to mention the property (open and closed shape)
19:11:42 <pfps> you can have a constraint with no pieces, so it is not the mincount=0 that is the culprit
19:11:43 <hknublau> hknublau: I don't think so. Just stating sh:predicate is enough.
19:12:05 <hknublau> q+
19:12:40 <Arnaud> ack hknublau
19:12:44 <pfps> in the presence of closed, it is true that just mentioning a property is semantically important, but that is also covered here
19:13:14 <aryman_> @hknublau right - sh:property [ sh:predicate ex:foo]
19:13:21 <pfps> +1 to holger's suggestion
19:13:48 <pfps> actually I would like to see a compact syntax that allows [1,], i.e., doesn't need an explicit max
19:14:06 <hknublau> hknublau: I think this should be handled by other (compact) syntaxes and tools, e.g. [0..*]
19:14:50 <hknublau> Arnaud: I don't think we need to blow this out of proportion - Karen only asked for sh:maxCount. Let's be pragmatic.
19:16:02 <pfps> there are lots of ways of creating vacuous constraints in SHACL, so having mincount=0 isn't special
19:16:05 <hknublau> Dimitris: I agree with the others who are present.
19:16:50 <hknublau> Arnaud: Looks like we cannot make this default for sh:maxCount. What about open shapes?
19:17:46 <pfps> having special syntax that says nothing isn't a great idea, in my opinion
19:17:53 <hknublau> hknublau: With sh:closed as a boolean you already have false
19:18:08 <Arnaud> PROPOSED: leave SHACL as is, but create a maxCount value in the high-level language that is interpreted as the maxCount default in SHACL
19:18:14 <hknublau> +1
19:18:21 <aryman_> +1
19:18:26 <Dimitris> +1
19:18:29 <hknublau> (assuming "high level" means compact syntaxt)
19:18:32 <pfps> why don't I go against mincount=0 then?  because mincount=0 just fits into the other mincounts, with no special attention, similarly for empty and and or
19:18:34 <pfps> +1
19:19:09 <ericP> 0
19:19:19 <pfps> I agree with Holger about the meaning of high level
19:20:10 <pfps> to add unbounded maxcount we need to add a new piece of vocabulary - that has a decided cost
19:20:11 <hknublau> ericP: Machine generated code may benefit from an explicit value, so I am divided about this
19:20:29 <pfps> in a compact syntax the cost is much lower
19:20:40 <aryman_> q+
19:20:44 <pfps> there is no overriding in SHACL, I hope
19:21:05 <Arnaud> ack aryman_
19:21:51 <pfps> q+
19:22:04 <hknublau> aryman_: Semantics are that you can only narrow down constraints.
19:22:17 <Arnaud> RESOLVED: Leave SHACL as is, but create a maxCount value in the high-level language that is interpreted as the maxCount default in SHACL
19:22:30 <Arnaud> ack pfps
19:22:37 <pfps> q-
19:22:59 <pfps> I agree with Arthur
19:23:47 <pfps> q+
19:24:00 <Arnaud> ack pfps
19:24:26 <pfps> adding in an explicit OPEN would just be adding in extra vocabulary, which has a cost, for expressive purpose
19:24:30 <aryman_> q+
19:25:49 <Arnaud> ack aryman_
19:26:53 <hknublau> aryman_: Karen is advocating this based on feedback from her user community. Their mindset may be different from what is needed in SHACL. On the long term adding extra syntax may actually confuse other users.
19:27:31 <hknublau> ... a more consistent language is easier to learn.
19:27:58 <hknublau> Arnaud: We could put this as a statement into the document - no constraint triple means unconstrained.
19:30:29 <Dimitris> q+
19:31:48 <hknublau> Which ticket number is this?
19:32:15 <Arnaud> http://www.w3.org/2015/12/10-shapes-minutes.html#resolution02
19:32:19 <hknublau> Dimitris: It was ISSUE-103 but we left sh:ClosedShape out of that resolution.
19:32:28 <Arnaud> resolution was: Close ISSUE-103, accepting the proposed simplification except for closed shapes which should be treated differently
19:33:12 <hknublau> Arnaud: So we cannot rely on this to resolve Karen's issue.
19:34:58 <Dimitris> q+
19:35:24 <Arnaud> ack Dimitris
19:35:35 <aryman_> q+
19:35:48 <pfps> so the idea is to retain closed constraints?
19:36:14 <hknublau> Dimitris: One issue was what would happen with multiple closed shape statements.
19:37:06 <hknublau> Arnaud: Maybe we could close 102 and open a new issue on closed shapes
19:38:38 <hknublau> +1
19:40:09 <Arnaud> PROPOSED: Close ISSUE-102, based on resolution for maxCount and leaving the question of how closed shape are specified to a separate issue
19:40:20 <hknublau> +1
19:40:22 <pfps> +1
19:40:25 <aryman_> +1
19:40:26 <Dimitris> +1
19:41:17 <Arnaud> RESOLVED: Close ISSUE-102, based on resolution for maxCount and leaving the question of how closed shape are specified to a separate issue
19:42:52 <Arnaud> ISSUE-115
19:42:52 <trackbot> ISSUE-115 -- Current way of specifying closed shapes is not satisfactory -- raised
19:42:52 <trackbot> http://www.w3.org/2014/data-shapes/track/issues/115
19:43:22 <Arnaud> PROPOSED: Open ISSUE-115
19:43:23 <aryman_> q+
19:43:32 <Arnaud> ack aryman_
19:44:08 <hknublau> aryman_: Question to Eric. Looking at the actual SPARQL query in the spec, which only considers sh:property but not inverse properties.
19:44:34 <hknublau> ... Is this intentional?
19:45:02 <hknublau> ericP: ShEx is symmetric because (?) nobody uses it.
19:45:45 <hknublau> ... for now it's fine if we just go in one direction.
19:46:04 <hknublau> aryman_: In OSLC use cases we would like to also have inverse properties.
19:46:14 <Arnaud> RESOLVED: Open ISSUE-115
19:48:54 <hknublau> ericP: I very rarely (or never) came across use cases for inverse.
19:50:20 <hknublau> ... two kinds of closeness: closeness of predicates, closeness of shape
19:51:36 <pfps> got to go now
19:52:58 <Arnaud> trackbot, end meeting
19:52:58 <trackbot> Zakim, list attendees
19:52:58 <Zakim> As of this point the attendees have been Arnaud, kcoyle, hknublau, ericP, hsolbrig, pfps, simonstey, dimitris, aryman
19:53:06 <trackbot> RRSAgent, please draft minutes
19:53:06 <RRSAgent> I have made the request to generate http://www.w3.org/2015/12/16-shapes-minutes.html trackbot
19:53:07 <trackbot> RRSAgent, bye
19:53:07 <RRSAgent> I see no action items