12:59:36 RRSAgent has joined #shapes 12:59:36 logging to http://www.w3.org/2015/05/21-shapes-irc 12:59:38 RRSAgent, make logs rdf-data-shapes 12:59:40 Zakim, this will be SHAPES 12:59:40 I do not see a conference matching that name scheduled within the next hour, trackbot 12:59:41 Meeting: RDF Data Shapes Working Group Teleconference 12:59:41 Date: 21 May 2015 13:00:55 aryman has joined #shapes 13:02:58 pfps has joined #shapes 13:03:15 Labra has joined #shapes 13:04:26 Dimitris has joined #shapes 13:05:08 hsolbrig has joined #shapes 13:05:09 iovka has joined #shapes 13:06:54 I can scribe for session 2. 13:07:38 http://w3c.github.io/data-shapes/data-shapes-ucr/ 13:08:07 (how do I say zakim I'm scribe ?) 13:08:20 scribenick: iovka 13:08:44 Topic: User Stories 13:08:54 +q 13:09:26 Arnaud: the aim is discussing on the status of the document 13:09:59 ***simonstey maybe he is angry because he was replaced by webex 13:11:49 OK, having the log is the most important thing 13:12:09 Arnaud: publish the document as public note 13:13:01 simonstey: my concerns are that the current document is the user stories renamed as use cases 13:13:27 simonstey: there is no standard way to model user stories 13:14:00 ... : for me, a user story is a an organization describing what they want to do 13:14:40 ...: use case is an agent with its role, and a particular think tha agent want to do (e.g. cardinality constraints) 13:15:20 ... I want go through the current list and identify the user cases, and keep them separated from the user stories 13:15:35 ... I have to admit that I didn't get to it for now 13:15:42 ***ericP jay maintenance ongoing, zakim and rrsagent bots will be restarted after 13:16:26 ***ericP sysreq folks were surprised that jay and rrsagent fell over; will restart after libs are updated. 13:16:39 ... maybe we fix a date for that 13:16:43 ***ericP (i'd guess 10 mins if all goes well) 13:17:23 it would be ok if we clean the document like it is now, and maybe not necessary to separating use cases from user stories 13:18:15 Arnaud: should we publish the latest draft ? is it worth ? 13:18:46 kcoyle: few things added, but 95% the same 13:19:04 Arnaud and Kcoyle agree not worth re-publishing now 13:19:17 ***simonstey wohoo 13:20:23 Arnaud: it used to be tedious process for publishing documents for the wg 13:20:29 ... now it has become easy 13:21:28 ... it's almost a one-click process now, everything is in the control of the editors; if validation errors, then it won't be published 13:22:19 +q 13:22:36 ack kcoyle 13:22:41 Arnaud: we can set a deadline if simonstey wants one 13:23:10 kcoyle: there are user requiremenst that we never approved, now these are commented out, I think we should remove these 13:23:38 kcoyle: use case 40 does not have associated requirement. should I raise this as an issue ? 13:23:45 Araud: yes, bring it as an issue 13:25:41 Arnaud: in the future, we can still add new use cases, and people vote for these 13:26:06 Arnaud and simonstey agree on end of june as deadline 13:27:06 q+ 13:27:08 Arnaud: if not finished by the deadline, it's not critical. having progress on that is already good 13:27:21 ack labra 13:27:28 topic: Test Suite 13:28:59 Arnaud: the most usual is to have a test harness, implementers run the tests and report on these, we collect the results and report to the managers 13:29:13 ... there is no single framework to do it, different approaches are possible 13:29:34 ... we need to figure out how to do it in this wg 13:30:06 ... what is the format of the test suites ? of the tests ? what the tests look like so that people can write tests ? who manages the test suite ? 13:30:46 ... when we publish a draft, we invite people to implement these, implementers run the tests and post the results 13:31:03 ... somebody has to be in charge of collecting the results, monitoring the mail list 13:31:14 ... there are tools helping for doing that 13:32:06 ... the difficulty for now is that we do not have a syntax, so difficult to define tests 13:32:30 ... for now it seems like we will have 2 syntaxes: rdf and shex-like compact syntax 13:32:44 http://www.slideshare.net/jelabra/data-shapestestsuite 13:32:55 Labra: a presentation slides 13:33:22 aryman left the room (quit: "Page closed"). 13:33:36 aryman [~aryman@public.cloak] entered the room. 13:34:05 rejoined - pls paste the test suite web page link 13:34:17 http://www.slideshare.net/jelabra/data-shapestestsuite 13:34:22 thx 13:34:30 Labra : for the format of the test suite, I propose a main forlder, and subfolders for different cases 13:35:44 I would very much prefer to have presentations to the working group available beforehand. This following along with new information is difficult and wasteful. 13:36:33 ericP left the room (quit: Client closed connection). 13:40:29 Arnaud and Jose discussing on slide 6: add a link to the section of the formal specification to which a test is related 13:43:04 https://github.com/w3c/data-shapes/blob/gh-pages/data-shapes-test-suite/tests/example/manifest.ttl 13:46:03 if both representations are equivalent? 13:46:37 Jose and Arnaud discussing on p.7 : what is the aim of tests for the conversion from one schema format to another 13:46:47 ericP [eric@public.cloak] entered the room. 13:46:53 Arnaud: how can we do the test ? is there a unique translation ? 13:49:06 q+ 13:50:16 q+ 13:50:26 ack aryman 13:51:58 queue=iovka 13:52:23 aryman: take a lesson from ??? testsuite. the first thing is to decide which of the syntaxes is "default" 13:52:33 ... the compact syntax might be evolving 13:53:15 ... there are 2 kinds of tests: the one testing against data 13:53:16 restarting bot to reconnect bridge 13:53:22 +q about well-formed shapes 13:53:43 ... the other is to check translation between the two syntaxes 13:54:06 Zakim has joined #shapes 13:54:11 ... I would prefer to decouple the two 13:54:13 q? 13:54:25 queue=iovka, dimitris 13:54:42 in SPARQL, we originally had a turtle syntax for result sets, but it fell by the way side pretty quickly 13:55:01 Jose: compact syntax is simpler, but I agree we might have one default syntax 13:55:10 q+ 13:55:35 Arnaud: I do not necessarily agree with arthur's claim that rdf syntax should be default 13:55:59 ... for instance sparql has 2 different test suites with different syntaxes 13:56:32 ack iovka 13:56:39 q+ to talk about SPARQL test development 13:57:05 iovka: checking against the data is different from checking against the syntax 13:57:31 ... either there is a default syntax, 13:57:44 ... .. or there is a provided conversion 13:57:45 ack Dimitris 13:58:06 three kinds of test case (at least) 1) check that a shape is well-formed, 2) check that a data graph satisfies a shape, 3) check that conversion between rdf and compact syntax is correct 13:58:25 Dimitris: in RDF we can write anything so i'm not sure how we can check the well-formedness 13:58:31 scribe doesn't hear well enough 13:58:39 q+ 13:59:13 ... we can check, e.g. a bad SPARQL syntax, but other things are not easy to check 13:59:33 ... we will need to do the graph isomorphism that Jose is doing to check the results 14:00:33 ack aryman 14:00:58 aryman: let me explain the default should be RDF 14:01:26 ... the semantics of the compact is defined in terms of the rdf 14:01:33 ... so the compact syntax might change 14:01:36 ack ericP 14:01:36 ericP, you wanted to talk about SPARQL test development 14:01:46 ... we do not want to change the test cases each time the compact syntax changes 14:02:12 q+ 14:02:43 ericP: in the sparql working group, the burden was that every implementer had to convert, or have systems that support parser for all the formats 14:02:56 ... we realized we didn't have good idea of the coverage 14:03:08 ... so we developped tools for measuring coverage 14:03:18 ... it would be better to do this from the start 14:03:23 q+ 14:04:29 ... also having description of what every test is about 14:05:51 ... in sparql we had positive/negative syntax and semantics 14:06:15 ... the negative examples were things beyound the grammar 14:07:05 Arnaud: did folders relate to sections of the spec ? 14:07:32 ericP: to features, combinations of operators 14:08:00 ... I would expect directory for testing the facets, the basic node types, 14:08:35 ... people were proposing tests, with an expected answer, other were verifying and the wg approved 14:08:53 ... sometimes people sumbitted 2 possible answers, the wg approved the one or the other 14:09:04 ack Labra 14:11:26 ack kcoyle 14:11:28 -> http://dvcs.w3.org/hg/rdf/raw-file/6f51ac509ff3/rdf-turtle/coverage/report-atomic-tests.html coverage report 14:11:37 (turtle coverage report) 14:11:54 kcoyle: we should be testing whether our standard meets the requirements 14:12:45 Arnaud: absolutely, and also that might help to define the coverage 14:12:52 ack aryman 14:13:48 aryman: in ??? wg we ensured that for every term in the vocabulary, there is a test that tests that term 14:13:55 q+ to talk about test case analysis 14:14:58 ... we automatically generated the lists of terms, I think that this would be easier to do with rdf syntax than with compact syntax 14:16:28 ack ericP 14:16:28 ericP, you wanted to talk about test case analysis 14:16:33 Arnaud: there are different ways in measuring coverage 14:16:37 http://dvcs.w3.org/hg/rdf/raw-file/6f51ac509ff3/rdf-turtle/coverage/report-atomic-tests.html 14:17:03 OSLC defines vocabularies for Requirements Management and Quality Management 14:17:19 Here is the Requirements Management Spec http://open-services.net/bin/view/Main/RmSpecificationV2 14:18:17 Here is the OSLC Requirements Management vocabulary: http://open-services.net/ns/rm# 14:18:39 -> https://dvcs.w3.org/hg/rdf/raw-file/default/rdf-turtle/reports/index.html Turtle implementation report 14:19:07 Here is the OSLC Quality Management spec: http://open-services.net/bin/view/Main/QmSpecificationV2 14:19:33 Arnaud: there are nice tools that allow to produce reports where one can see which implementation covered what 14:19:53 Here is the OSLC Quality Management vocabulary: http://open-services.net/ns/qm# 14:20:47 Arnaud: one of the questions we haven't discuss is about the process 14:21:02 ... most practical would be to do something similar to what we did to user stories and reqirements 14:21:26 -> http://www.w3.org/2001/sw/DataAccess/tests/implementations SPARQL implementation report 14:21:34 ... people submit whatever they want, we validate case by case 14:22:42 ... we want everybody to be able to submit, have it very open 14:23:40 Jose: it sounds reasonable to me 14:24:02 ... can I start adding tests ? 14:24:30 q+ 14:24:31 Arnaud: no reason to wait, except that the specification is still in progress 14:24:47 ... you have the burden to modify the tests whenever the specification changes 14:26:09 +1 to Arnaud, the difficulty of changing tests that cover unapproved things cannot be used as a reason to prefer one solution over another 14:26:30 ack aryman 14:26:58 q+ 14:27:02 aryman: it would be valuable that the data is treated independently on the shapes 14:27:30 ... people contributing with date, and with unformal description of what they want to test on these data sets 14:28:23 Arnaud: when testing that validation should fail, how do you catch the errors ? how do we test levels of severity ? 14:28:24 ack Labra 14:28:25 https://github.com/w3c/data-shapes/tree/gh-pages/data-shapes-test-suite/contrib 14:29:22 Jose: I planned having a folder for not approved 14:29:40 ... or with informal description of what we want to validate 14:30:00 kcoyle: there is a lot of test cases that I can produce and put in something like that 14:30:06 ... most of these test something specific 14:30:20 Arnaud: it should be in the right format, so that it could be part of the test suite 14:30:51 q+ 14:31:43 ack pfps 14:32:15 Jose: this folder would be used to put data and informal requrimenst, and then people trying to model this and add these as fully specified test cases 14:32:34 pfps: bizarre talking about tests whereas we do not have an api 14:33:41 ... for invoking shacl 14:33:45 q+ 14:34:58 Arnaud: with XMLschema they didn't define anything right this. 14:35:07 ack aryman 14:35:31 This is XML Schema test suite http://www.w3.org/XML/2004/xml-schema-test-suite/ 14:35:54 aryman: an api is an additional level of specification, we define the intended meaning of a shacl document using tests 14:36:04 ... defining an api would require to define an additional language 14:36:14 Well, I was referring to an abstract API. (Does an abstract API even make sense.) 14:37:12 Arnaud: to be able to run the tests, people would to need to develop a test harness that allows them to run tbe tests 14:37:19 s/tbe/the/ 14:38:01 we could define a standard test result format 14:38:51 Aside from not having an API, I don't think that we even have a good notion of what kinds of arguments are input to SHACL. 14:54:36 scribenick: pfps 14:54:45 topic: Issue 3 - Graph Shape Association 14:56:21 pfps: ISSUE-3 is how to relate shapes and graphs 14:56:23 https://www.w3.org/2014/data-shapes/wiki/ISSUE-3:_Graph_Shape_Association 14:56:51 Is this the current W3C standard for test results?: http://www.w3.org/2001/03/earl/ 14:57:26 pfps: several possible associations 14:58:04 pfps: shape in data graph, explicit links (like owl:import), implicit links (LD follow your nose), no links 15:01:01 pfps: in the first three there is only one input to validation, in the last there are two inputs 15:01:16 arnaud: SHACL could use several mechanisms 15:01:36 arnaud: which one to use has to be considered 15:02:26 pfps: two different kinds of invocations - one that is the no-linking one, and one that is one or more of the others 15:02:56 pfps: I'm strongly in favour of the no-linking one 15:03:31 arnaud: XML schema did this and there was a lot of push-back 15:03:39 q+ to ask how much is used 15:03:49 q+ 15:04:01 arnaud: to the effect that the data document should say which schema is in use 15:04:09 OSLC defines explicit linking from data to shape via oslc:instanceShape 15:04:13 q+ 15:04:15 ack ericP 15:04:15 ericP, you wanted to ask how much is used 15:04:18 I think that RDF is different from XML 15:04:49 ericp: how much is the XML linking mechanism actually used? 15:05:14 ack hsolbrig 15:05:52 hsolbrig: we use XML schema linking a lot 15:06:00 hsolbrig: but RDF is different from XML 15:06:31 ack aryman 15:06:56 hsolbrig: a given chunk of RDF can be advantageously used with multiple shapes 15:07:31 aryman: the interface to services might want to have a link between the data and the shapes 15:08:41 q+ 15:08:53 aryman: the link from a service is a claim that the document satisfies the shape information 15:09:32 scribe comment - the last scribing wasn't right 15:10:01 aryman: in a document produced by a service the link to a shape document is a claim that the data document satisfies the shape 15:10:08 ack kcoyle 15:11:08 kcoyle: one use - informational - the data-shape link is a claim of conformance 15:11:29 kcoyle: another use - verification - run extra shapes over a data graph 15:11:58 kcoyle: the first needs a link, the second can't have a link 15:12:09 +q 15:12:32 arnaud: so the question is whether to define a data-shape linking mechanism 15:12:40 ack Dimitris 15:13:19 q+ 15:13:27 dimitris: this has all the drawbacks that were ascribed to using rdf:type to link resources to shapes 15:13:46 ack aryman 15:14:33 aryman: I don't think that the analogy goes through - node-shape links are different from graph-shape links 15:16:57 A node (IRI) may appear in many different graphs with the same rdf:type, but with different shapes 15:17:20 q+ to sa that it seems like the use cases for linking range from "here are some shapes i might conform to" to "thou shalt always conform to X" 15:17:32 arnaud: is this about using rdf:type?? 15:17:34 but the same resource may different types in different graphs 15:17:35 Labra has joined #shapes 15:17:55 pfps 15:17:59 and as soon as the shape can be dereferences it will have the same implications as rdf:type 15:18:03 pfps: i don't think so 15:18:23 ... i was hesitant to have the type link, but i see two good use cases: 15:18:35 ... .. what control is or was applied to the document 15:18:41 no, this is not about the type link 15:18:43 q+ 15:18:55 and it is also information that would probably be included in closed shapes 15:18:59 s/ type link/ link/ 15:19:22 s/hesitant to have the type link,/hesitant to have a link,/ 15:19:35 ack ericP 15:19:35 ericP, you wanted to sa that it seems like the use cases for linking range from "here are some shapes i might conform to" to "thou shalt always conform to X" 15:19:35 I also pointed is that I woulddn't object to this but woudn't favour either 15:20:45 ericp: the linkage is saying either "I'm X otherwise I'm broken" or "there is something that I might conform to" 15:21:13 ack aryman 15:21:56 aryman: there is no "might" 15:22:24 aryman: but there is no obligation to actually go and check 15:23:30 aryman: applications can advertise what kind of data they want 15:23:32 q+ 15:24:23 aryman: the interface contract involves instanceshape 15:24:47 hsolbrig: is the claim coupled to the data or to the servce 15:25:06 aryman: on a get there is a document that points to the shapes 15:25:17 +q 15:25:33 aryman: for puts the shape is in a separate description document (or http header) 15:25:35 q- 15:25:53 ack Dimitris 15:26:14 q+ 15:26:48 dimitris: if I put shapes on DBpedia resources then these shapes cannot be overruled 15:27:09 ack aryman 15:27:31 hsolbrig has joined #shapes 15:29:58 aryman: the result of a service invocation includes a shape link that describes the resultant graph, that graph might be merged with other information, in which case the shape might be no longer correct 15:30:10 +q 15:30:44 http://w3c.github.io/data-shapes/semantics/#associations 15:30:50 ack Dimitris 15:30:51 arnaud: is there any proposal that includes graph-graph linking 15:30:53 -http://w3c.github.io/data-shapes/semantics/#associations 15:31:04 -> http://w3c.github.io/data-shapes/semantics/#associations Associating Data with Shapes 15:31:11 dimitris: I don't have any graph-graph linking 15:31:33 q+ 15:31:38 ack pfps 15:32:05 q+ to say that both Holger's and ShEx provide links 15:32:16 arnaud: does anyone do an embedding solution 15:32:25 pfps: yes, SPIN and I think Holger's proposal 15:33:23 q+ 15:33:50 pfps: if there graph-shape links then putting the graph in a different context could invalidate the constraints 15:34:01 ack ericP 15:34:01 ericP, you wanted to say that both Holger's and ShEx provide links 15:35:22 q+ 15:35:22 pfps: just because there is an instanceshape link doesn't mean that you have the embedding setup - you might ignore such links in the data graph 15:35:54 arnaud: the engine might only be sensitive to such links under certain circumstances 15:36:27 ack aryman 15:36:27 ericp: if the api is g1 is the data graph and g2 is the control graph then what happens if they are the same? 15:37:18 embedding can be a special case of no linking where data & shapes graph are the same 15:37:48 aryman: a frequent case is that the graph is in a system that has multiple graphs where closed shapes might no longer be correct for the union of the graphs 15:37:56 +1 to dimitris 15:38:57 aryman: user story 40 - use case 43 - inline vs remote - .... 15:39:17 Dimitris, why wouldn't the shape just point at itself with an instanceShape link? 15:39:52 ericP, the shape or the resource? 15:40:08 s/why wouldn't the shape/why wouldn't the resource/ 15:41:10 see user story 40, use case 43 15:41:46 ack kcoyle 15:42:09 there is a property oslc:representation, http://www.w3.org/Submission/shapes/#representation 15:42:11 ericP, as I said earlier, this has the same implications you had with the rdf:type predicate, it stays in the data and when the shape can be dereferenced is global. It also may create problem when merging data from different sources where you'd have to remove these triples 15:42:29 kcoyle: will a group of SHACL requirements be identified with an IRI 15:42:34 q+ 15:42:41 it has values oslc:Inline, oslc:Reference, oslc:Either 15:42:43 ack pfps 15:43:10 ericP. rdf:type has a different meaning (although people use it for validation) but sh:instanceShape is much stronger than this 15:44:04 s/ is much / will be much / 15:44:08 pfps: karen - you mean that SHACL requirements are collected into documents that are referenceable by IRI 15:44:22 kcoyle: more or less 15:44:34 pfps: yes 15:45:56 kcoyle: then you can decide to use different SHACL controls by pointing a different documents 15:45:59 pfps: yes 15:46:10 q+ 15:46:34 q+ 15:46:41 q- 15:46:57 arnaud: there is still work to be done here 15:47:09 arnaud: are there any other possibilities? 15:47:32 arnaud: should any of these be eliminated? 15:47:47 arthur: it doesn't cover service factories 15:48:08 arnaud: this appears to be outside the scope of the working group 15:48:39 q+ to say that the API validate X as Y invocation seems to sometimes be an internal call invoked by the linked use cases, as well as an extermal API that will be invoked by some tests 15:48:45 ack ericP 15:48:45 ericP, you wanted to say that the API validate X as Y invocation seems to sometimes be an internal call invoked by the linked use cases, as well as an extermal API that will be 15:48:48 ... invoked by some tests 15:49:38 ericp: LDP can build on what is done here 15:50:23 ericp: internal vs external use?? 15:51:31 ericp: sometimes validation triggers off a link in the data and sometimes validation is done from the outside 15:51:54 +q 15:52:21 aryman: the highest priority is to have an invocation where you have two arguments - control and data 15:52:56 arnaud: I don't expect the wg to provide an explicit API 15:53:40 arnaud: the question is whether there should be a way of indicating what validation is to be done based on data in the data graph that points to the control graph 15:55:13 arnaud: is there a standard way of linking from the data graph to shape graph 15:55:25 ack Dimitris 15:55:35 arnaud: even if the wg specifies a link it may not be automatically enforced 15:55:51 dimitris: is the triple counted? 15:58:27 I'm willing to produce a proposal, and add it to the wiki page 15:58:46 talked about the possibility to reverse the relation i.e. ex:shapeA sh:hasInstance ex:resource 15:58:48 arnaud: the wiki page is a good resource 15:59:15 arnaud: if you have a use case, please indicate which kind of linkage it needs 15:59:51 arnaud: the no-linking version seems like a given 16:00:05 arnaud: if someone wants something else, please speak up 16:00:50 arthur: should we add requirements to the wiki 16:00:53 kcoyle: yes 16:01:40 arnaud: if you see a gap, add something 16:01:57 arnaud: if you feel a need, speak up 16:02:06 arnaud: close 16:02:26 arnaud: next meeting *not* today 16:02:34 arnaud: next meeting is next week 16:03:13 arnaud: next week will have a vote on the way forward, so be prepared 16:03:41 bye 16:04:20 bye 16:04:45 bye 16:04:55 bye 16:05:15 meeting adjourned 16:05:21 trackbot, end meeting 16:05:21 Zakim, list attendees 16:05:21 sorry, trackbot, I don't know what conference this is 16:05:29 RRSAgent, please draft minutes 16:05:29 I have made the request to generate http://www.w3.org/2015/05/21-shapes-minutes.html trackbot 16:05:30 RRSAgent, bye 16:05:37 good bye everyone, I'm leaving now 16:05:40 iovka has left #shapes 16:05:51 good buy all 16:06:05 rrsagent, make logs rdf-data-shapes 16:06:18 RRSAgent, please draft minutes 16:06:18 I have made the request to generate http://www.w3.org/2015/05/21-shapes-minutes.html Arnaud chair: Arnaud agenda: https://www.w3.org/2014/data-shapes/wiki/F2F3#Day_3_-_Thursday_May_21 present: aryman, pfps, Labra, Dimitris, hsolbrig, iovka, kcoyle, simonstey, ericP, Arnaud