07:48:40 RRSAgent has joined #shapes 07:48:40 logging to http://www.w3.org/2015/09/08-shapes-irc 07:48:42 RRSAgent, make logs rdf-data-shapes 07:48:42 Zakim has joined #shapes 07:48:44 Zakim, this will be SHAPES 07:48:44 I do not see a conference matching that name scheduled within the next hour, trackbot 07:48:45 Meeting: RDF Data Shapes Working Group Teleconference 07:48:45 Date: 08 September 2015 07:53:16 hknublau has joined #shapes 07:53:50 webex doesn't work 07:54:10 we'll use a different teleconference bridge: Passcode: 406-4254 Tel: 888-426-6840/215-861-6239 More access numbers: https://www.teleconference.att.com/servlet/glbAccess?process=1&accessCode=4064254&accessNumber=2158616239 07:55:29 simonstey has joined #shapes 07:56:27 Arnaud has changed the topic to: we'll use a different teleconference bridge: Passcode: 406-4254 Tel: 888-426-6840/215-861-6239 More access numbers: https://www.teleconference.att.com/servlet/glbAccess?process=1&accessCode=4064254&accessNumber=2158616239 07:58:41 present+ hknublau 07:58:46 present+ Dimitris 07:58:51 pfps has joined #shapes 07:59:07 present+ ericp, Arnaud 07:59:20 iovka has joined #shapes 07:59:44 beware, check the call-in info: we are using a different teleconference bridge: Passcode: 406-4254 Tel: 888-426-6840/215-861-6239 More access numbers: https://www.teleconference.att.com/servlet/glbAccess?process=1&accessCode=4064254&accessNumber=2158616239 07:59:57 present+ iovka 07:59:58 hsolbrig has joined #shapes 08:00:53 have you joined webex alreadxy? 08:01:05 hi simon 08:01:08 no webex today 08:01:17 aryman has joined #shapes 08:01:22 we are using a different teleconference bridge: Passcode: 406-4254 Tel: 888-426-6840/215-861-6239 More access numbers: https://www.teleconference.att.com/servlet/glbAccess?process=1&accessCode=4064254&accessNumber=2158616239 08:02:00 is there a way to dial in via voip/sip? 08:02:11 I'm afraid not 08:02:19 the access code is not recognized 08:02:22 oh.. 08:02:43 because you need the passcode 08:02:55 hi, the access code works for me 08:02:57 pfps, did you try what I just put on irc? 08:03:06 I am using the Aussie toll-free number via Skype. No idea yet if Skype charges me for that… 08:03:18 webex isn't working 08:03:29 hknublau, it shouldn't 08:03:34 this worked for me: 406-4254 Tel: 888-426-6840 08:03:36 Skype isn't charging for the US toll free 08:03:45 present+ aryman 08:03:51 You need to enter the passcode when it asks for the access code. 08:03:53 present+ pfps 08:04:07 present+ hsolbrig 08:04:36 simonstey, can you try skype? 08:05:03 you should be able to have a toll free number from https://www.teleconference.att.com/servlet/glbAccess?process=1&accessCode=4064254&accessNumber=2158616239 08:05:08 you don't have a phone at all? 08:06:37 I'm joining via skype 08:06:43 sounds good 08:06:49 You need to enter the "passcode" when it asks for the "access code". 08:07:00 and after that? 08:07:08 you should be on 08:07:13 I edited the meeting page to get rid of the webex information. 08:07:27 can you hear me? 08:07:32 no 08:07:33 no 08:07:38 ok mom 08:07:45 ive joined 08:07:53 trying to get the mic working 08:07:54 yes 08:09:51 skype tells me my mic is working 08:10:14 ;) 08:10:32 scribenick: iovka chair: Arnaud agenda: https://www.w3.org/2014/data-shapes/wiki/F2F4#Day_1_-_Tuesday_September_8 08:11:31 TOPIC: SHACL draft 08:15:27 Labra has joined #shapes 08:16:10 kcoyle has joined #shapes 08:16:44 Arnaud: we should go closer to a first working draft 08:17:19 Arnaud: one way to go is to scale down the document on which we all agree 08:18:38 s/document/document to something/ 08:19:23 lol 08:19:37 pfps: I sent an e-mail with the problems in the document 08:19:57 pfps: the introduction is not a consensus and is misleading for what shacl is 08:20:23 pfps: another issue are technical flaws, terminology issues 08:21:35 pfps: missing a less technical introduction of what shacl is supposed to be 08:22:32 pfps: relationship between shacl and rdfs, recursive shapes 08:23:23 q+ 08:23:47 aryman has joined #shapes 08:23:52 q+ 08:24:02 Arnaud: summarizing pfps 08:24:08 Arnaud: summarizing pfps's issues: 08:24:15 ack kcoyle 08:24:46 kcoyle: does not understand what is behind the 3 bullets 08:24:55 ack aryman 08:25:36 arthur: the draft is very influenced by holger's implementation 08:25:47 arthur: things are there that have not been discussed by the wg 08:27:22 arthur: holger is making sparql much more essencial for the draft than what the wg agreed on (namely, defining semantics in sparql as much as possible, and extension language) 08:27:42 s/arthur/aryman/ 08:28:47 aryman: calling the built-in features "templates" is misleading, templates are supposed to be extnesions 08:29:29 aryman: extension API does not need to be defined in detail, it can be implementation specific 08:29:53 +1 to what Arthur says 08:29:59 q+ 08:30:06 aryman: we need a precise description of the syntax and semantics of shacl, and that's the essential thing 08:30:45 Arnaud: resolutions we took regarding sparql are: define the semantics with sparql as much as possible 08:30:52 ... use sparql as extension mechanism 08:31:08 ... the core does not require implementation in sparql 08:31:12 ack hknublau 08:31:41 hknublau: everything aryman said is already in the spec 08:32:05 q+ 08:32:09 ... very little sparql left, don't understand what aryman is talking about 08:32:49 ack aryman 08:34:00 aryman: if hknublau already addressed my comments, then it's fine for me 08:35:02 aryman and hknublau discussing on what is currently in the spec 08:36:29 hknublau explains in details how templates work 08:37:10 aryman: putting the abstract classes for templates makes them a kind of an api 08:38:54 q+ 08:39:15 Arnaud: we could not solve all these issues today, but we can agree on a plan for getting something that is good enough to be published 08:39:17 q- 08:40:16 pfps: explains what he thinks is the main issue with the spec 08:40:23 q+ 08:40:30 ... this is the example in the introduction, which relates classes with shapes 08:41:11 Arnaud: agrees that this example is not appropriate, as it is on a contraversial topic 08:41:27 ack hknublau 08:41:56 q+ 08:42:02 hknublau: how much longer do we plan to delay this problem ? why not solve it right now 08:42:43 ... let's decide whether we delete or not shapeclass, and if the wg decides not to delete it, then why removing the example ? 08:42:59 q- as Arnaud is saying what I was going to say 08:43:03 q- 08:43:15 Arnaud: even if we resolve the issue, and we keep shape class, still this is not the best first and foremost example 08:43:23 a big +1 to Arnaud's comments about not emphasizing shapes as classes 08:43:55 q+ 08:43:56 q+ to disagree about class 08:44:07 q+ 08:44:10 ack pfps 08:44:22 pfps: totally disagree 08:44:25 ack ericP 08:44:25 ericP, you wanted to disagree about class 08:45:00 ericP: totally disagree with holger's assertion that having a class in the leading example is more instructive for people using owl and rdf classes 08:45:06 +1 to eric 08:45:09 ack aryman 08:45:50 aryman: the first example should be as simple and useful and possible, to illustrate some key point and one point at a time, and not several points at a time 08:45:50 q+ 08:45:58 ack hknublau 08:46:33 ericP: the majority of users of OWL and RDFS classes intend them to defined reusable classes, and this is contrary to the use of shapeClass 08:46:38 hknublau: the most important thing is to publish this document, so I can remove the example if it is necessary 08:47:05 ... let's resorve it now 08:47:45 q+ 08:47:48 ... I would prefer to remove any example, and leave it to a primer 08:48:05 q+ 08:48:19 ack pfps 08:48:20 Arnaud: specs do have examples 08:50:10 ack aryman 08:50:15 pfps: maybe in the final version, there might not be a need for examples. But we have better examples 08:50:24 q+ 08:50:38 +1 to arthur's comment 08:50:53 aryman: a spec w/o examples is unreadable. for the first publication we need examples, and even for the final. otherwise people won't refer to the spec, but to the primer 08:51:02 ack hknublau 08:51:09 my feeling is that the first technical document on SHACL needs a comprehensible introduction to SHACL and that this requires an example, at least for now 08:51:43 hknublau: I can make an introduction similar to what pfps suggested 08:51:52 q+ 08:52:00 ack kcoyle 08:52:29 +1 08:52:43 kcoyle: strongly believe that the current introduction should be removed, and the pfps wording would be used as an introduction 08:53:58 hknublau: the introduction was written to give a high level idea of shacl is, mentioning different features of shacl 08:54:16 kcoyle: asks to pfps to make precise what edit he proposes 08:54:45 pfps: replace 1.1, 1,2, 1.3 08:56:35 kcoyle: we should have a document outline (explains what's in the document) which would be 1.1 08:57:05 kcoyle: it's different from an outline on the specification and the points being addressed 08:57:30 Arnaud: proposes that pfps's text is integrated in the current introduction 08:57:53 ... I would propose to consider now aryman's concerns 08:58:12 there should be a core of the language that addresses 80% of the use cases 08:58:22 ... sparql is an extension 08:58:23 q+ 08:58:43 +1 to Arnaud's summary of the role of SPARQL 09:00:04 hknublau: sparql could be mentioned in the introduction 09:00:20 ... or move it to Secti. 6 (extension) 09:00:40 ericP: agrees with moving sparql to section 6 09:00:44 kcoyle: agrees 09:01:01 Arnaud: the introduction should talk about whole shacl, not only core 09:01:22 kcoyle: still we do not need to explain sparql extension in the introduction, we can simply mention it is an extension mechanism 09:02:09 hknublau: we could have an abstract section before the introduction, and mention there what is in the document 09:04:05 Arnaud has joined #shapes 09:04:12 q? 09:04:18 q- 09:04:56 Arnaud: propose to give hknublau a chance to edit the introduction in the sense we propesed, and see what we get 09:05:21 ... let's get to pfps's concern that the current document does not describe what shacl is 09:05:35 ... how can we solve it, is it an nomenclature issue 09:06:18 pfps: my comments refered to the version I read 09:06:58 I didn't recognize shacl 09:07:25 s/I/pfps: I/ 09:07:34 Arnaud: can you give an example ? 09:07:54 pfps: shacl is presented as an rdf vocabulary. it is a language, not a vocabulary 09:08:25 ... shacl does not describe graph structures, this is not its purpose 09:08:42 q+ 09:08:46 ... shacl is a constraint language, it is not to describe to graph structures, but to validate rdf graphs 09:09:03 ... i turns out that it has to describe graph strucutres, but it not its purpose 09:09:18 pfps: towards the document "shacl mandates ..." 09:09:43 ... it checks constraints, it does not mandate 09:10:50 ... regarding the relationshipe between shapes and constraints, didn't understand what the wording wanted to say, I didn't understand how to read it (referring to the version form August 10) 09:10:59 ... don't know how it was changed 09:11:33 Arnaud: hknublau is making edits to reflect our comments, so we can hope the wording goes in your direction 09:11:59 there is a revision history in the beginning of the document 09:12:37 Arnaud: so the question is : how do we collectively descibe what shacl is, so that we know what to write in the introduction and a first-time reader gets the right idea of shacl 09:12:38 q+ to disagree with one of pfps's points: whether shacl "describes" structure 09:13:03 Arnaud: maybe the further sections are more controversal, the introduction should give the right idea 09:13:21 ... validation is not the primary purpose of all users 09:13:44 ... e.g. people from the linked data platforms want to describe the data 09:14:15 q+ 09:14:28 ... are there other interests ? 09:14:44 pfps: who wants shacl for primarily describe structures ? 09:15:43 ericP: me. first you describe the data, then this description can be used for validation. Cites the introductory sentence for XMLSchema 09:16:26 ... shacl is a language for describing the graph structure, and a validation mechanism for checking whether a graph satisfies the structure 09:16:51 kcoyle: is not convinced that "structure" is the best wording 09:17:13 hknublau: definitely, describing the sttructure is important 09:17:19 q+ 09:17:32 q+ 09:18:14 ack next 09:18:15 ack next 09:18:16 ericP, you wanted to disagree with one of pfps's points: whether shacl "describes" structure 09:18:17 ack next 09:18:31 Arnaud_ has joined #shapes 09:18:53 I agree with Eric that conflating "describing graph structures" and "modelling" is a stretch 09:18:57 q? 09:18:59 q- 09:19:06 aryman: oslc is a description language for rdf data 09:19:32 ... many of our users are not familiar with rdf and want description of the data 09:19:48 q+ 09:20:17 ack kcoyle 09:20:29 ... also having a pragmatic way of validating rdf data 09:21:38 ack pfps 09:21:56 kcoyle: our primary need is to describe data. we do not separate validation and description. the word 'validation' is hard to find in the current introduction. if people do not need to validate, then they would not use shacl 09:22:20 pfps: agrees that one does not use shacl for only description. The design of shacl was oriented towards valdiation. 09:22:35 +1 on description is not modeling 09:22:36 ... description is not modelling4 09:22:50 Arnaud: we can talk about description, validation, constraints 09:22:56 ... no modelling 09:23:04 hknublau: agree with that 09:23:27 q+ 09:23:34 Arnaud: would that address the primary concerns about the current draft and its introduction of what shacl is 09:23:34 ack pfps 09:23:52 pfps: it appears so 09:24:12 ... there is also the issue for the relationship between shacl and rdfs 09:25:25 pfps: it's also about terminology. the document uses the words classes, rdf:type, rdfs:subClass etc, but not in a way RDFS does 09:25:46 q+ 09:25:51 ... these uses are not conform with RDFS, so I fear that people would misunderstand shacl 09:26:39 ... at the very minimum, we need a disclaimer. explain to people that shacl does not use RDFS as it is 09:27:01 ack hknublau 09:27:07 to what extend is the current spec using subclassof wrong wrt to the official spec? 09:27:12 ... misunderstanding of shacl would discourage people from using it 09:28:01 q+ 09:28:03 hknublau: pfps, maybe you can suggest a paragraph that explains to RDFS-aware people woh to read the document in order to avoid the misunderstanding ? 09:28:30 q+ 09:28:58 ... not sure that our understanding is so different 09:30:00 pfps: very different. the usage of subclass is different 09:30:12 ... also, does not use domain and range from RDFS 09:30:29 ... also, no subProperty in shacl 09:31:53 Arnaud_ has joined #shapes 09:31:55 hknublau: we had an agreement that if one wants inference, it should be done on the graph level, by turning inference on 09:32:06 q? 09:32:11 ack pfps 09:33:06 ack aryman 09:33:08 pfps: this is not the unique differences. the document should state it explicitly how shacl uses the rdfs vocabulary 09:33:21 Arnaud: pfps, can you write this explanation 09:33:25 pfps: agrees 09:34:07 aryman: from a pragmatic point of view, ce nannot rely on entailment being turned on or turned off 09:34:16 http://w3c.github.io/data-shapes/shacl/#entailment 09:34:28 ... we could have an entailment property, that specifies whether entailment is supposed to be used 09:35:07 ... when we say that A is subclass of B, we simply require a subclass triple, we are not interested to know whether it is explicit or obtained by inference 09:35:41 ... sublcass can be also implemented as a transitive closure 09:35:53 q+ 09:35:54 ... which is a pragmatic solution 09:36:09 ack pfps 09:36:12 +1 to arthur 09:36:12 ... for me this would describe our relation to rdfs 09:36:48 pfps: agree with aryman, except can't seay we both require explicit rdfs:subclass links, and we compute a transitive closure 09:37:58 q? 09:38:26 +q 09:38:56 pfps: rdfs:subclass not being uniformly applied 09:39:18 aryman: you can be pragmatic, explain it, and see how people from RDFS community react 09:39:23 ack Dimitris 09:39:30 Arnaud: let's peter make a first draft, and we see how it goes 09:40:21 Dimitris: scribe didn't get the point because of bad phone connexion 09:41:07 we should also define how rdfs reasoning is applied inside the shacl graph for the shape / template definition 09:41:22 Arnaud: we have a general plan: change teh introduction using peter's text, add a section on relatioship with rdfs, and remove the reference to classes in the leading example 09:41:37 ... peter, is that ok for you ? 09:42:26 pfps: other things are missing, the document does not talk about recursive shapes, the relationship with sparql is incorrect 09:42:47 ... these are very serious technical problems 09:42:57 Arnaud: we've got issues for most of these 09:43:16 ... if not, raise an issue 09:43:47 pfps: enumerates some technical problems, e.g. the documents talks about 'matching' and 'typing' and these are not defined. shall I raise an issue for that ? 09:44:07 Arnaud: agrees this is a serious issue, the document suffers from consistency 09:44:27 pfps: also missing how do you start a validation 09:45:09 +q to say that most of this is already fixed 09:46:29 Arnaud: wonders how deep we should go in the spec. for instance, should we describe the api in the spec, or how errors are reported ? 09:46:33 ack hknublau 09:46:33 hknublau, you wanted to say that most of this is already fixed 09:46:53 hknublau: I believe that pfps's issues and yours have been addressed now 09:47:19 ... I'm trying to improve it, but it will never be perfect 09:47:42 q+ 09:47:44 ... difficult situation to keep the document consistent whereas things are changing so often 09:48:01 ... I'm waiting for resolutions before editing the document 09:48:11 q- 09:49:02 q+ 09:49:48 q+ 09:50:01 Arnaud has joined #shapes 09:50:04 ack aryman 09:50:16 aryman: there should be a description of what input and output is 09:50:41 ... but not going into so much details as hknublau 09:50:55 +q 09:51:18 ... we should have the relationship between the input and the output 09:51:38 hknublau: trying to do that, but we need to describe it with sparql queries 09:52:11 ack pfps 09:52:22 q- 09:52:29 ack simonstey 09:53:00 simonstey: also think that section 10 is not needed in the main document, all the operations are not referenced anywhere else in the document 09:53:52 ... agree that we should remove that from the normative document 09:54:20 Arnaud: maybe we can agree to move it to another document 09:54:43 ... let's try to address some of the aryman's concerns 09:54:55 ... for instance the role of sparql in the document and for shacl 09:55:22 ... for instance, notions of template definition and execution engine which is sparql 09:55:38 ... shouldn't 'engine' be replaced by 'extension' ? 09:55:58 q+ 09:56:12 hknublau: asks for a clarification 09:57:06 Arnaud: for instance title of sect 13: Sparql execution to be replaced by sparql extension 09:57:15 ... templates are part of the extension mechanism. 09:57:21 ... we have the core and the extensions 09:57:38 ... two kinds of extensions, one of which is templates 09:57:51 can't hear holger 09:58:08 ack aryman 09:59:06 the core elements are also defined in terms of templates (which are defined using sparql queries) 09:59:12 aryman: agrees with Arnaud. refers to an e-mail in which hknublau does not agree that sparql is just an extension language 09:59:36 I was going to make the point that the other document has a definition of recursive shapes. 10:01:12 hknublau: sparql has a special role because we are defining the semantics of shacl using sparql 10:01:16 ... so that it is special 10:01:22 The current document gives the impression that SHACL can be implemented in SPARQL, which is not currently correct. 10:01:25 Arnaud: want to clarify this 10:01:29 ... sparql has two roles 10:01:35 ... one is defining the semantics 10:01:42 ... the other is an extension mechanism 10:01:53 ... I do not think that sparql should be presented as the foundation of the core 10:02:00 q+ 10:02:18 ack pfps 10:02:23 ... I know that in your implementation, holger, you do use it as the foundation of the core. But this is your implementation choice, and we should not impose this to everybody 10:02:26 wouldn't we then have to decouple the .ttl from the spec? since it uses sparql to define those constructs 10:02:47 pfps: scribe didn't hear the question of pfps 10:03:11 aryman: we are using sparql as a precise formalism, but not an execution mechanism 10:04:09 my comment was that SPARQL is inadequate for the definition of SHACL 10:04:11 Arnaud_ has joined #shapes 10:04:14 q? 10:04:36 hknublau: doesn't understand the issue with sparql, it is not mentioned before section ?? 10:04:43 Arthur noted that large chunks of SHACL (i.e. almost all of SHACL) can be formalized as SPARQL, and I agreed. 10:05:15 Arnaud: the proposal is just to rename 'execution' to 'extension' 10:05:31 hknublau: I do not understand why I should do that 10:05:48 Arnaud: because it gives the impression that sparql is the foundation 10:06:01 hknublau: does not agree with this statement 10:06:14 kcoyle: you are saying it in Sect. 13 10:06:30 then make it a subsection instead of a section 10:07:17 \section(extension/execution languages) -> \subsection{SPARQL-based ...} 10:07:24 q+ 10:07:33 Arnaud: insists that we only ask to rename execution by evaluation, because now this gives the impression that it is the foundation 10:07:42 kcoyle: maybe it should be a seperate document 10:07:44 +q 10:08:01 s/evaluation/extension/ 10:08:17 ack aryman 10:08:21 hknublau: how can we have a self contained document if we do not give the semantics in sparql 10:08:39 kcoyle: the details of any implementation do not belong to the spec 10:08:41 -q 10:08:51 +q 10:09:01 +1 to Arthur 10:09:24 aryman: sparql should be used to specify the semantics independently on any implementation 10:09:42 -q wanted to say basically what aryman says 10:09:46 ericP-via-http has joined #shapes 10:09:52 -q 10:10:00 ack iovka 10:10:25 iovka: you can specify without executing it. a declarative execution doesn't need an "execution" 10:10:53 s/declarative execution/declarative specification/ 10:11:03 Arnaud: maybe a solution is to move it out 10:11:20 ... and go forward to a publishable working draft 10:11:34 hknublau: asks whether peter agrees 10:11:58 pfps: it would be a shape to remove from the document the connexion between shacl and sparql 10:12:17 s/shape/shame/ 10:12:19 ... but I agree that giving the impression that the execution mechanism of shacl is sparql is problematic 10:12:54 hknublau: asks that somebody points him the precise sentences to be removed 10:13:47 Arnaud: the consensus seems to be to move this section to a separate document 10:14:04 I think that there needs to be some discussion of the formal basis of SHACL in the document. 10:14:53 ... we should edit the changes that we already discussed, review the resulting document, and see whether we get closer to a public working draft 10:15:13 q+ 10:15:26 ack aryman 10:16:03 aryman: in some specs, you can have separate document for the formal semantics 10:16:12 ... in order to keep the spec readable from the largest part 10:16:26 ... the semantics document is read by people who are making an implementation 10:16:45 ... i think we should keep the extension mechanism in the main document, and sparql is the preferred extension language 10:17:14 Arnaud: we stop for a lunch break, the topic is apparently not closed 10:17:27 No sunrise here yet 10:53:44 Yes I used Skype. The Australian toll-free number :) 10:53:56 try 0800-000-1018 for germany 11:01:17 aryman has joined #shapes 11:05:28 * and loud 11:06:41 Isn't this the sort of thing they play to prisoners to get them to confess? 11:07:04 just in "A Clockwork Orange" 11:07:19 I want to strangle the happy "Your conference will begin momentarily..." woman 11:07:55 especially when she repeats herself 3-4 times within a few seconds 11:08:44 And strange warbly distortions, like she isn't quite sane 11:08:59 Arnaud has joined #shapes 11:09:26 haha 11:09:42 Welcome Arnaud. The conference woman has worked us into a killing frenzy 11:09:48 @Arnaud, please tell us when to call back in 11:10:05 kcoyle has joined #shapes 11:10:05 All that music and then the happy woman just hangs up! 11:10:08 now 11:10:25 sorry guys, we're a bit behind 11:10:25