12:56:23 RRSAgent has joined #ldp 12:56:23 logging to http://www.w3.org/2014/04/17-ldp-irc 12:56:25 RRSAgent, make logs public 12:56:25 Zakim has joined #ldp 12:56:27 Zakim, this will be LDP 12:56:27 ok, trackbot; I see DATA_LDPWG()8:30AM scheduled to start 26 minutes ago 12:56:28 Meeting: Linked Data Platform (LDP) Working Group Teleconference 12:56:28 Date: 17 April 2014 13:01:51 DATA_LDPWG()8:30AM has now started 13:01:58 +MIT-F2F-group 13:03:18 Zakim, what's the code? 13:03:18 the conference code is 53794 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), nmihindu 13:03:33 Ashok has joined #ldp 13:03:46 +[IPcaller] 13:03:54 Zakim, IPcaller is me. 13:03:54 +codyburleson; got it 13:04:15 Zakim, who is talking? 13:04:15 +??P17 13:04:22 +??P16 13:04:24 Zakim, ??P17 is me 13:04:24 +BartvanLeeuwen; got it 13:04:26 codyburleson, listening for 11 seconds I could not identify any sounds 13:04:34 Zakim, ??P16 is me 13:04:34 +nmihindu; got it 13:04:39 Zakim, mute me 13:04:39 nmihindu should now be muted 13:05:45 scribenick: Ashok 13:05:48 JohnArwe has joined #ldp 13:06:47 Topic: Agenda 13:06:55 -BartvanLeeuwen 13:07:14 Arnaud: Access control and Patch format are on the agenda with testing in the afternoon. 13:07:18 +??P17 13:07:20 Zakim, ??P17 is me 13:07:20 +BartvanLeeuwen; got it 13:07:46 ... I think we need to talk about the spec again. Esp. about JSON-LD. 13:07:58 ... also talk about paging a bit more. 13:07:59 *has also the noise 13:08:29 Arnaud: We can delay testing 13:09:04 deiu has joined #ldp 13:09:13 ... start with Access Control Note now. Then spec and paging 13:09:23 ... and patch 13:09:24 Zakim, who is on the call? 13:09:24 On the phone I see MIT-F2F-group, codyburleson, nmihindu (muted), BartvanLeeuwen 13:09:52 Arnaud: I don't see a quick solution to PATCH. 13:10:01 Topic: Access Control 13:10:18 TallTed has joined #ldp 13:10:25 Zakim, MIT-F2F-group has Arnaud, Ashok, betehess, JohnArwe, roger, sandro, SteveS, TallTed, deiu 13:10:25 +Arnaud, Ashok, betehess, JohnArwe, roger, sandro, SteveS, TallTed, deiu; got it 13:10:30 Arnaud: This was a compromise we came to when we wrote the charter 13:11:12 ... did not want to put on charter because it's a hard issue. So we decided on a separate note. 13:11:48 Annoying noise just stopped 13:11:56 ... on yesterday's wish list discussion Access Control was high priority 13:12:10 ... we need agreement on usescases 13:13:01 Ashok: we started on this and we have 2 requirements 13:13:09 ... one: you need some form of authentication 13:13:29 ... however, we don't want to specify the authentication protocol 13:13:58 MiguelAraCo has joined #ldp 13:14:14 ... second: once you are authenticated (and say you get a token), then you can access various things, update them, etc., so there must be some way to specify what you can do 13:15:10 ... the question is: where do we specify that? In LDP, in HTTP? How do we specify what the ACL privileges are? 13:15:41 ... our wiki page has example we can build on 13:16:01 ... we haven't gotten further on this because there wasn't a lot of enthusiasm in the group 13:16:07 Arnaud: I agree with that part 13:16:40 ... but we should not get sidetracked into discussing the solutions, but instead try to figure out the questions we need to ask ourselves 13:17:12 Ashok: does fine-grained ACL means access to one attribute? 13:17:15 Arnaud: yes 13:17:31 Ashok: people also want access to a group of resources, and to specify that group is hard 13:17:45 Arnaud: that's not what we're trying to decide now 13:17:50 ... now we want to know what the requirements are 13:17:55 betehess has joined #ldp 13:18:09 ... let's look at the doc together and decide how we can improve it 13:18:50 ... why don't we go through the use-cases first? 13:20:59 Arnaud: do people agree that the use-case involving ACL for group is important? 13:22:02 roger has joined #ldp 13:22:25 Use Case: granting access to a (group of) resources to attendees of a particular session at a conference 13:24:24 Requirements: group entitites; grant permissions to the group; set permissions on a (group of) resources 13:26:17 Ted: Granularity of access control is important 13:33:50 Requirement: Grant permissions for (set restrictions on) individual (enumeration) entity/resource. 13:34:32 Requirement: Group entities/resources by enumeration (closed ended.) 13:34:32 Requirement: Group entities/resources by attribute (open ended.) 13:35:59 Arnaud: Do we need 3.3? 13:36:40 Ted: Disagrees 13:37:36 ... that is should be removed 13:38:02 s/is/it/ 13:40:31 s/Use Case: granting/generic requirement: granting/ 13:43:26 Usecase: Ted wants to access/update some resource ... he wants his friends to get acess ... he wants to acess related resources 13:44:08 Ted: Change title of 3.4 13:46:01 Andre: Do we need access control in LDP? 13:46:16 ... underlying store will have policies 13:46:29 ... how to expose these policies to client 13:47:49 Ted: Talks about distinction between usecases and requirements 13:49:14 Alexandre: Is there anyting special about access control for LDP? 13:49:32 Ted: Is there a system that satisfies these requirements? 13:49:46 ... there is no W3C spec that tells us 13:49:58 Question: Granularity. LDPC? LDPR? attribute within LDPR ("triple level")? 13:51:43 +ericP 13:53:43 Steve: We have application-specific access control 13:54:12 people who are doing similar things today with Linked Data without LDP (Victor from UPM, Serena from Inria) do it as dataset, graph, triple levels as far as I know 13:54:59 We should escape Identification and Authentication. We need only a URI to represent ANY Principal. Once we have that, we can focuse specifically on Authorization and make no claim about how the Principal URI is derived. 13:55:08 Andre: We use Wen Acess Control to specify policies ... LDP just uses them 13:55:25 Access Control == Identification (e.g., WebID, Username, OpenID) + Authentication (e.g., WebID+TLS, Password, Password+Token) + Authorization (permissions, policies) 13:57:57 s/Wen/Web/ 13:59:20 q+ to ask whether an LDP Resource can have different triples (or Container have different members) depending on the authentication 13:59:25 Ashok: The question is -- Is Access Control our problem 13:59:47 Steve: If we don't do it, who will do it? 14:00:43 if resources can look different, you enable fine-grained access control. 14:01:15 Ashok: Should we write this as a charter for a WG? 14:01:32 Andre: There is a lot of work to be done here 14:01:32 (i don't think there's anything that says that can't be different, though HTTP purists may argue that two representations with different triples can't represent the same resource at the same time) 14:04:59 Ashok: #.5 follows from 3.4 ... part of 3.4 actually 14:06:03 Problem Statement: Any platform for developing web applications would be incomplete without a mechanism for Authentication and Authorization. Without this functionality, the platform could serve only light, utilitarian purposes at best. Without security, it would not even be proper to call the system a "platform". 14:06:11 ack ericP 14:06:11 ericP, you wanted to ask whether an LDP Resource can have different triples (or Container have different members) depending on the authentication 14:07:10 Eric: Is there something in LDP that depends on auathentication? 14:07:39 Ted: Nothing says two user have to see the same thing 14:09:22 Andre: Let's ask folks who have implemented access control to send usecases 14:09:36 \Sandro: I like very specific usecases 14:10:40 Sandro: 3 paras that would define scope of work in a charter would be good 14:10:56 s/\sandro/sandro/ 14:11:31 s/\Sandro/Sandro/ 14:12:23 +q 14:12:51 -q 14:15:39 Move last usecase to intro section 14:16:02 Move 4.2 to section 5 14:17:57 Arnaud: Do we need section 5? 14:20:15 ... move to other document? 14:21:28 Sandro: Start another wiki page with the 3 paras that could go into a charter 14:21:41 Ted: make that the conclusion of this document 14:21:47 Arnaud: Yes 14:23:03 Nandana, do you have a comment? 14:23:28 Ashok, no I've just put my mind completely to the primer :) 14:24:03 Great! 14:24:54 break now ? 14:25:05 break until 10:35 local 14:26:18 -BartvanLeeuwen 14:35:45 topic; json 14:35:53 Topic: ISSUE-97 Should we use JSON in addition to Turtle? 14:36:07 issue-97 14:36:07 topic: JSON 14:36:07 issue-97 -- Json instead of (in addition to?) turtle -- raised 14:36:07 http://www.w3.org/2012/ldp/track/issues/97 14:36:25 Arnaud: We could put in Best Practices doc. 14:36:41 ... don't want to go to another Last Call. 14:37:34 ... We could put a SHOULD in the spec. We can do this w/o going to another Last Call 14:37:39 +1 "SHOULD" support JSON-LD 14:37:58 imo, that's n'th last call 14:38:13 q+ 14:38:16 PROPOSAL: Add SHOULd support JSON-LD in spec 14:38:39 bblfish_ has joined #ldp 14:38:57 ... we can also add "who supports JSON-LD" when we go to CR 14:39:19 Sandro: Are we saying need to convert formats? 14:39:37 ack betehess 14:39:41 ... need translation on output or store both formats 14:41:12 Steve: Or say you match the format of request 14:41:52 my take: MUST Turtle / SHOULD JSON-LD does not sound like a so great idea. not sure that it solves exactly 14:41:58 +??P4 14:42:04 Zakim, ??P4 is me 14:42:04 +BartvanLeeuwen; got it 14:42:18 Sandro: We should gather data to go into Director meeting 14:42:59 q+ 14:43:05 Sandro: We will put in spec ... if Director obejcts move to BP 14:43:27 Eric: Can we put into separate doc that put to REC 14:43:38 Sandro: One line ... too much hassle 14:45:16 Eric: There is mapping from JSON-LD to Turtle .... 1 to m mapping ... 14:45:29 ... need context 14:45:32 ack betehess 14:45:35 q+ 14:45:51 Sandro: We only support JSON-LD which has context embedded in ti 14:46:00 s/ti/it/ 14:46:40 right, but that's a mapping from json to one namespace unless you want to use the very ugly json-ld with no short names 14:46:46 Alexandre: Discussion about where SHOULD goes 14:47:03 (Sandro) 14:47:56 ack Steves 14:47:57 ... also SHOULD vs. MUST 14:48:10 ericP, no, the servers and the clients get to figure out the @context to use 14:48:46 Steve: We may have to go to another call if we get significant comments in CR. 14:49:03 ... so we can put in BP and then add to spec later 14:49:28 Sandro: Let's ask director. If he says NO we move to BP. 14:49:39 sandro, ahh, so we don't ahve a standard serialization in json 14:49:54 Arnaud: can we add to AT RISK 14:50:11 Sandro: Maybe 14:51:18 betehess: if there was no LC issue, I would like to see MUST implement JSON-LD (no Turtle mandatory) 14:51:26 +1 14:51:44 +1 14:52:57 Ashok: You are making a marketing asessment 14:53:33 Sandro: Clear that JSON has market ... not clear if JSON-LD has market 14:54:45 Arnaud: We are not forcing servers to convert ... it's a SHOULD 14:55:09 -nmihindu 14:55:50 Ted: MUST for both format is best 14:56:51 PROPOSED: Close issue-97 with adding JSON-LD as a SHOULD in the spec, if we can in W3C process without another Last Call; if it'll require another LC, then we advocate for it in BP. 14:56:55 Arnaud: We can put a SHOULD for JSON-LD in spec or put in BP 14:57:03 There is a marketing factor at play here that shouldn't be discounted. Turtle is meaningless to the "average" web developer. JSON-LD provides an option that is meaningful for them. If we want to successful, we need to appeal to the broader audience. So, I agree that is SHOULD be in the spec; not BPs. 14:57:19 +1 14:57:24 +1 14:57:33 +1 14:57:35 +1 14:57:37 +1 14:57:37 +1 14:57:42 roger_ has joined #ldp 14:57:44 +1 14:57:44 +1 (just to help with adoption, but I would rather see a MUST instead) 14:57:58 +1 14:58:03 +1 14:58:15 (I agree with deiu) 14:58:16 -.1 # i'm uncomfortable engouth with sneaking this in after LC to whine about it, but not uncomfortable do something else 14:58:21 +0 14:58:23 RESOLVED: Close issue-97 with adding JSON-LD as a SHOULD in the spec, if we can in W3C process without another Last Call; if it'll require another LC, then we advocate for it in BP. 14:58:28 Some leaning towards MUST 14:58:49 Topic: PATCH 14:59:40 Arnaud: There are different solutions but have no agreement on requirements 14:59:47 ... and usecases 15:00:48 Sandro: Need to be able to patch from any graph to any graph and you need every patch to be tractable 15:01:06 (those are my constraints, other people have others) 15:01:07 Some prior discussion: Use Cases http://lists.w3.org/Archives/Public/public-ldp-patch/2013Sep/0000.html 15:01:24 https://docs.google.com/presentation/d/1snLP7U97q7wgtsHznnP-RRuAndZNwFytU6q-lrO8U6A/ 15:01:37 Requirements: http://lists.w3.org/Archives/Public/public-ldp-patch/2013Sep/0016.html 15:01:48 Alexandre presents slides 15:02:09 https://www.w3.org/2012/ldp/wiki/LDP_PATCH_Proposals 15:04:34 SPARQL patch+skolemization, SPARQL patch w/o skolemization, RDF Patch 15:06:03 q+ 15:09:10 JSON Merge Patch http://tools.ietf.org/html/draft-ietf-appsawg-json-merge-patch-02 15:09:21 Ashok: Issue with patching large arrays 15:12:55 q- 15:13:48 q+ 15:15:12 Web Payments using JSON-LD and JSON patch 15:21:51 Arnaud: Are you agruing for RDF Patch? 15:21:59 Alexandre: Yes 15:22:46 ack sandro 15:24:15 Sandro: Easy if you don't have blank nodes. So I said use Skolemization. 15:24:32 ... Eric argues that Skolemization is expensive 15:25:36 Sandro: You could serialize triples to add and triples to delete in Turtle 15:25:42 q+ to ask if there really is a single universal solution for patch 15:27:42 ack steves 15:27:42 SteveS, you wanted to ask if there really is a single universal solution for patch 15:27:43 Discussion about blank nodes can be identified 15:28:52 Arnaud: Either we agree to something that's not perfect or we have no solution at all. 15:29:00 q+ 15:29:35 Pick your poison: blank-node-identifiers or worst-case-fails 15:30:08 q+ 15:30:30 q+ to say where LDP *needs* patch (huge containers) 15:30:33 Steve: My usecase is more towards a lightweight RDF Patch. Limited requirements. 15:31:00 ack ashok 15:32:33 Ashok: Alexandre, is there a document we can point to? 15:33:06 ack sandro 15:33:06 sandro, you wanted to say where LDP *needs* patch (huge containers) 15:33:50 Sandro: What do LDP users really need? 15:34:23 ... add/delete triple from huge graph ... no blank nodes 15:34:42 ... cannot use PUT 15:37:29 Arnaud, define "big" :-) 15:39:46 Discussion about Skolemization and how expensive it is 15:43:39 sandro: One could also do a nice, efficient streaming protocol for maintaining sync 15:43:50 Arnaud: This seems to be brainstorming. How to we make progress? Can we reach a compromise? 15:45:11 Sandro: Requirement: There is a big graph in a triple store and you want to change a few triples in it 15:45:52 ... must be able to patch any graph 15:46:19 also, remember that there will be a time to see what is supported in implementations... who is planning to implement one of the solutions? 15:48:42 question: do we want to be able to patch _any_ graph? or do we think "realistic" (define realistic) graphs are just ok 15:48:50 STRAWPOLL: a) I'd rather keep it simple and accept a limited solution, b) I want a general solution and am willing to accept the additional cost 15:49:18 strong a) 15:49:29 q+ 15:50:35 ack ashok 15:50:46 this puts universality and tractibility at odds 15:50:58 require universality; require tractability; require both; require neither... 15:52:58 STRAWPOLL: If we suggest one PATCH format, we make it (a) fail on certain pathological graphs, or (b) require the server to maintain Skolemization maps 15:54:19 sandro, that's not a strawpoll, that's a fact 15:54:30 :-) 15:54:52 my answer: yes :-) 15:55:06 STRAWPOLL: If we suggest one PATCH format, we make it (a) fail on certain pathological graphs, or (b) require the server to maintain Skolemization maps. Vote for which branch you'd rather live with; 15:55:38 STRAWPOLL: (Assuming we suggest one PATCH format) should it (a) fail on certain pathological graphs, or (b) require the server to maintain Skolemization maps. 15:56:21 nmihindu has joined #ldp 15:58:23 STRAWPOLL: I'd rather have a solution that (a) doesn't address certain pathological graphs, or (b) requires the server to maintain Skolemization maps 15:58:47 strong (a) 15:58:48 a) I don't want to pay a high price every time, regardless of case (while also maintaining skolemized versions), AND because I also want to do the PATCH operation in one request 15:58:49 a 15:58:55 -1 go to lunch :-) 15:59:17 a +1, b -0 [we do a) first and can do b) later if needed] 15:59:21 OBJECT 15:59:40 a) +1, b) +0 15:59:43 a -0, b +0 15:59:47 a +1, b -.5 15:59:48 a) +1 15:59:49 (a) +1 (b) -.9 16:00:32 a) +1 16:00:45 a +1, b (if needed as fallback) +0.5 ... I would prefer a better understanding of which graphs are considered pathological 16:01:03 (a) +1, (b) -0.5, but, mostly plan on using domain specific ways to do PATCH like things 16:01:37 a 16:01:41 general solution for all but pathological case; once that's recognized, fall back to Skolemnize 16:02:07 a) +1 16:02:36 Sandro: Still question on expressiveness 16:03:08 Alexandre: Do we want to handle blank nodes or not 16:04:26 Eric: Question is whether you have variables and xxx 16:06:39 Eric: Not hard to produce a spec on SPARQL patch 16:07:58 -codyburleson 16:08:03 lunch break until 12:45 local 16:08:06 enjoy lunch 16:08:11 -BartvanLeeuwen 16:08:12 zakim, mute ericp 16:08:13 ericP should now be muted 16:08:41 i'll see your mutation and raise you a departure 16:08:47 -ericP 16:09:00 BREAK UNTIL 1PM EASTERN 16:09:12 i.e. for ~51 mins 16:11:49 thats gone be a quick dinner for me ;) 16:24:05 jmvanel has joined #ldp 16:39:25 Arnaud has joined #ldp 16:50:50 scribenick: deiu 16:51:10 Arnaud: resuming meeting 16:51:26 ... we can spend 1h on PATCH and maybe another hour on paging 16:52:35 ... the poll was a useful exercise, so now we know what are the problems we need to solve 16:52:45 ... the question is: is there a solution? 16:53:01 ... what can we agree on to make progress? 16:53:23 betehess: we have two solutions: ericP's (with BGP) and Pierre-Antoine's solution 16:53:41 sandro: what about RDF patch? 16:53:47 betehess: it needs skolemization 16:54:05 +[IPcaller] 16:54:12 sandro: Tim's is not expressed in concrete terms... 16:54:41 betehess: that's basically ericP's solution, with additional constraints 16:54:55 Arnaud: let's have a straw poll on these two options 16:55:15 sandro: the big difference is that one feels like SPARQL and the other one doesn't 16:55:31 ... "feeling" like SPARQL is a negative point for LDP adoption 16:56:08 solutions are: ericP's SPARQL Update with constrained BGP vs Pierre-Antoine's RDF Patch + property path 16:56:15 STRAWPOLL: pursue a) ericP's (with BGP) or b) Pierre-Antoine's solution 16:56:59 a) 0 b) +1 16:57:02 a) -0.5, b) 0.5 16:57:04 a) +0 (not disagreeing with ericP's view) b) +1 16:57:19 a -0.5 b 0.5 16:57:30 a +0.5 b +0.25 16:58:02 a) +.1 b) +.9 16:58:10 0, 1 17:00:03 a) +0.5 b) -.5 17:00:56 +??P1 17:01:05 Zakim, ??P1 is me 17:01:05 +nmihindu; got it 17:01:12 Zakim, mute me 17:01:12 nmihindu should now be muted 17:01:53 +[IBM] 17:02:20 q+ to comment on syntax 17:02:35 ack betehess 17:02:35 betehess, you wanted to comment on syntax 17:03:07 -[IBM] 17:03:29 Arnaud: we are not married to this syntax, could be JSON 17:03:58 Arnaud: what do we take from this? 17:04:10 ... the majority seems to prefer b) 17:04:49 ... what's the status of PA's proposal? is it written somewhere? 17:05:00 betehess: no, it isn't, but I plan to do it 17:05:44 ... I can also provide a test suite and implementation 17:06:10 Arnaud: do we agree this is the next step? (start drafting the PATCH spec) 17:06:31 ... then we have consensus 17:06:53 sandro: we can make it a REC track 17:07:42 Arnaud: there's a big difference, not just in the outcome but in what we do towards it 17:07:42 +??P12 17:07:47 Zakim, ??P12 is me 17:07:47 +BartvanLeeuwen; got it 17:08:11 LD Patch 17:08:21 Arnaud: how do we name it? 17:09:11 betehess: the full name can be "LD patch format" and the short name can be "LD patch" 17:09:31 LD Patch Format, would live at http://www.w3.org/TR/ld-patch/ 17:09:42 Linked Data Patch Format 17:09:45 Linked Data Patch Format, would live at http://www.w3.org/TR/ld-patch/ 17:09:48 ldpatch 17:09:59 ld-patch 17:09:59 s/LD Patch Format/Linked Data Patch Format/g 17:11:10 PROPOSED: We encourage Alexandre to draft a Linked Data Patch Format, along the lines of Pierre-Antoine's proposal 17:12:10 +1 (encourage yes, require/mandate is even better ;) 17:12:42 +1 17:12:43 +1 17:12:45 +1 17:12:45 +1 17:12:46 +1 17:12:54 +1 17:12:57 +1 17:13:15 +0 17:13:19 /me feels encouraged 17:13:31 RESOLVED: We encourage Alexandre to draft a Linked Data Patch Format, along the lines of Pierre-Antoine's proposal 17:14:17 Arnaud: the resolution is that as a group we will start working on PA's proposal, while betehess will write it down in the document 17:15:11 s/We encourage Alexandre/We agree/ 17:15:32 Arnaud: now betehess can take an action to do it 17:16:29 ... then we're done with PATCH for today! 17:16:33 ACTION: betehess to draft a Linked Data Patch Format, along the lines of Pierre-Antoine's proposal 17:16:33 Created ACTION-139 - Draft a linked data patch format, along the lines of pierre-antoine's proposal [on Alexandre Bertails - due 2014-04-24]. 17:16:47 ... I think everyone's happy with this 17:17:08 Topic: paging 17:17:19 Arnaud: Ashok has a proposal for us 17:17:34 Ashok: it looks we're not agreeing on one solution right now 17:17:49 ... most solutions have caveats 17:18:18 ... so we could add a warning, saying that if you do paging, the collection may change 17:18:29 Arnaud: I think we have agreed that we can do better 17:18:49 ... today we're not providing any mechanisms in that regard 17:19:21 ... yesterday we were left with 2 options: what we have in the spec + notification (which doesn't stop the client from continuing); the second option was to pursue sandro's proposal 17:19:43 TallTed: adding this editorially to the existing spec makes it clear what you get 17:19:49 sandro: it's clear in the spec that it is lossy 17:20:08 ... the spec has the word "lossy" 17:21:10 Arnaud: so basically sandro wants to veto this 17:22:00 ... we've agreed that we will do the notification (which is supposed to be mandatory) so the clients know if there was a change during paging 17:22:07 sandro: ok, I can live with that 17:23:06 WARNING: YOU MIGHT NOT SEE INSERTIONS OR DELETTIONS THAT MIGHT HAPPEN DURING PAGING. 17:23:13 SteveS has joined #ldp 17:23:14 +1 that's all I've ever asked for. 17:23:58 we do also have -- 7.1.1 A LDP client SHOULD NOT present paged resources as coherent or complete, or make assumptions to that effect. [RFC5005]. 17:24:03 (because it implies you WILL see triples that are there the whole time) 17:24:12 Arnaud: triples that were there when you started and are still there when you end, are definitely seen by the client 17:26:47 ... this is a clarification of how lossy paging is 17:27:10