13:00:19 RRSAgent has joined #ldp 13:00:19 logging to http://www.w3.org/2014/04/15-ldp-irc 13:00:21 RRSAgent, make logs public 13:00:21 Zakim has joined #ldp 13:00:23 Zakim, this will be LDP 13:00:23 I do not see a conference matching that name scheduled within the next hour, trackbot 13:00:24 Meeting: Linked Data Platform (LDP) Working Group Teleconference 13:00:24 Date: 15 April 2014 13:00:52 zakim, room for 10 for 10 hours 13:00:52 I don't understand 'room for 10 for 10 hours', Arnaud 13:01:12 zakim, room for 10 for 10h 13:01:12 I don't understand 'room for 10 for 10h', Arnaud 13:01:20 deiu has joined #ldp 13:01:58 zakim, room for 10 for 600 minutes 13:01:58 I don't understand 'room for 10 for 600 minutes', Arnaud 13:03:32 sandro has joined #ldp 13:03:50 Zakim, room for 10 people for 600 minutes? 13:03:51 ok, sandro; conference Team_(ldp)13:03Z scheduled with code 26631 (CONF1) for 600 minutes until 2303Z 13:04:26 Team_(ldp)13:03Z has now started 13:04:33 + +1.617.715.aaaa 13:05:20 guys, I cannot be all time connected by phone, at least today 13:05:26 so ping me if you need somethign from me 13:05:43 hi everyone 13:05:44 I'll try to connect for tomorrow and the test cases slot 13:05:50 we're still getting set up here 13:06:23 ok 13:07:18 we forgot to reserve the phone bridge so the code is 26631 instead of the usual ldpwg 13:07:35 Ashok has joined #ldp 13:07:49 Arnaud has changed the topic to: Teleconference code is 26631 (CONF1)!! LDP WG: http://www.w3.org/2012/ldp - next agenda: https://www.w3.org/2012/ldp/wiki/F2F5#Agenda 13:10:20 betehess has joined #ldp 13:14:11 JohnArwe has joined #ldp 13:14:34 video link for meeting -- http://bit.ly/swa-hangout 13:16:24 scribenick: Alexandre 13:16:31 scribenick: betehess 13:16:37 scribe: Alexandre 13:16:56 roger has joined #ldp 13:19:00 roger has joined #ldp 13:19:46 Arnaud: got a request from nandana to move the Primer 13:20:06 ... so I swapped Primer and BP 13:20:26 ... let's get started 13:20:29 ... want to talk where we are 13:20:35 ... finished 2 LC period 13:20:41 ... few comments, not too many 13:20:48 ... we have to dispose of them properly 13:21:09 ... be prepared for the review w/ w3c management for later phases 13:21:15 ... comments are part of the review 13:21:26 ... good to have some comments: people have looked at it! 13:21:49 ... we do best effort to satisfy the comments 13:21:55 ... a bit confused with the tracker 13:22:10 ... I forward the comments to the list but they don't appear in the tracker 13:22:47 ... need a plan for addressing the comments before leaving the meeting 13:22:55 ... I was at WWW last week 13:23:06 ... *many* people came to me to ask me the status of the spec 13:23:15 ... the community is waiting for me 13:23:26 s/for me/for it/ 13:23:38 ... we split the spec 13:23:46 ... and make sure everybody wants it 13:24:07 ... UC&R was republished as a Notee 13:24:12 s/Notee/Note/ 13:24:26 ... we won't talk about it unless you ask 13:24:37 ... test suite and validator will be important for CR 13:24:42 ... so we'll spend time on it 13:24:51 ... we have to show the spec can be implemented 13:25:10 ... Access Control WG Note: there will be 1 hour 13:25:17 ... it was part of the Charter 13:25:27 ... we may not do it, just have to explain 13:25:54 ... BP&R was not in charter but we have moved some stuff there 13:26:01 ... Primer is important 13:26:15 ... part of the feedback I had was about readibility of spec 13:26:27 ... so the Primer is key 13:26:33 ... and then, what's next? 13:26:40 nmihindu has joined #ldp 13:26:56 ... we had a request from W3C to know if we'll meet at TPAC 13:27:05 ... end of WG supposed to be in June 13:27:12 ... don't we'll be done in June 13:27:18 ... at best, we're in PR 13:27:29 ... which means we're pretty much done 13:27:45 ... but we have to stick around, (like 2 months) just in case there are comments 13:27:53 ... extension would be under same charter 13:28:02 ... but the group may want to continue the work 13:28:10 ... then there would be a _new_ charter 13:28:32 ... we have a page for wishlist for LDP Next 13:28:32 TallTed has joined #ldp 13:28:42 ... so we'll discuss what we want 13:28:58 ... W3C needs to allocate resources, based on what's in the charter 13:29:12 ... succeeding with the first charter is the best way to get another one ;-) 13:29:36 ... last but not least: Patch format 13:29:37 Zakim, what's the code? 13:29:37 the conference code is 26631 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), nmihindu 13:29:46 ... the spec says you have to use Patch 13:29:51 ... but we don't say how 13:30:00 ... we created a separate ML 13:30:07 ... had some mails, but not much 13:30:17 ... hope we can have a resultion on that 13:30:28 +??P1 13:30:38 Zakim, ??P1 is me 13:30:38 +nmihindu; got it 13:30:59 thank you very much 13:31:02 SteveS: ericP will participate to the Patch conversation 13:31:04 if you're speaking nandana, we're not hearing you, fyi 13:31:12 from F2F5 wiki: “ericP (though I can attend occasionally, possibly for patch)” 13:31:39 JohnArwe, I am trying to fix the mic, please move on. 13:31:42 Arnaud: people were interested in interop testing 13:31:50 ... don't know how feasible it is 13:31:58 ... last afternoon is dedicated in doing that 13:32:08 ... not sure how I'll make it happen 13:32:23 ... if there is any prep before we do it, please let me know 13:32:51 codyburleson has joined #ldp 13:33:26 ... based on the discussions we'll have, I won't hesitate to shrink/extend time on some subjects 13:33:56 sandro: btw, the catering is provided by @@ 13:34:02 s/@@/QCRI/ 13:34:29 Arnaud: thank you 13:34:43 ... hard to know how much time we'll need 13:35:14 SteveS: was wondering haw many people we'll have implementations 13:35:26 Arnaud: around 4? 13:35:35 TallTed: all servers I guess 13:35:58 deiu: have a client as well 13:36:09 TallTed: curl is test suite, it's not interop 13:36:18 sandro: it's an alternative 13:36:25 Arnaud: ok I see the point 13:36:53 TallTed: I don't consider curl as an LDP client 13:37:14 Arnaud: ok, let's jsut call it "testing" 13:37:33 ... interop is reached when you can replace a component with another one 13:37:47 topic: LDP Specification 13:38:33 http://www.w3.org/TR/2014/WD-ldp-20140311/ 13:39:49 http://www.w3.org/2006/02/lc-comments-tracker/55082/ 13:40:02 http://www.w3.org/TR/2014/WD-ldp-20140311/ 13:40:32 Do we need to engage the teleconference bridge? Right now, +1-617-761-6200, conf. code 53794#, returns "This passcode is not valid." 13:41:00 codyburleson... 13:41:04 Zakim, what is the code? 13:41:04 the conference code is 26631 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), sandro 13:41:41 codyburleson, code is 26631 for today, and there's a video-only link http://bit.ly/swa-hangout 13:41:47 Arnaud: trying to figure out how the tracker works 13:42:09 sandro has changed the topic to: Teleconference code is 26631 (CONF1)!! LDP WG: http://www.w3.org/2012/ldp - next agenda: https://www.w3.org/2012/ldp/wiki/F2F5#Agenda VIDEO: http://bit.ly/swa-hangout 13:43:22 +[IPcaller] 13:43:32 Zakim, IPcaller is me. 13:43:32 +codyburleson; got it 13:47:07 Arnaud: there were 2 comments from reto 13:47:15 ... one about multiple named graphs 13:47:21 ... thanks betehess for one! 13:47:28 s/one/that one/ 13:47:35 http://lists.w3.org/Archives/Public/public-ldp-comments/2014Mar/ 13:47:51 ... and then the null relative URI "hack" 13:48:00 ... and then there is an extra one 13:48:05 ... an issue we have to fix 13:48:14 ... brought up by sergio 13:48:29 ... there is a problem with the use of the rel=describedBy header 13:48:34 ... for 2 different things 13:48:52 s/describedBy/describedby/ 13:49:06 MiguelAraCo has joined #ldp 13:52:14 http://lists.w3.org/Archives/Public/public-ldp-wg/2014Mar/0037.html 13:52:32 Zakim, MiguelAraCo is with codyburleson 13:52:32 +MiguelAraCo; got it 13:52:57 Arnaud: has anybody anything to add? 13:53:15 SteveS: had a comment about @@ needing more clarity 13:53:39 Arnaud: people need to forward comments to the list 13:53:43 s/@@/implementation feedback/ 13:53:43 ... so that we can track them 13:54:35 sandro: external comments are still important for reviews 13:54:56 Arnaud: let's agree we have 1 issue and 2 comments 13:55:10 ... and we need to make sure we have done the same for comments from 1st LC 13:55:48 ... timbl's comments are marked as ?? but we are in an ongoing discussion with him 13:56:17 ... mark baker said he's fine with the improvements we made 13:57:15 ... are we in good share re: comments? do we need to do more? 13:58:05 ... note that we haven't had a real answer from timbl 13:58:26 ... and there is a comment not really addressed 13:58:41 sandro: timbl may join us 1 hour, we can ask at this point 13:59:07 ... in good shape? would be good to have more feedbacks from implementers 13:59:14 ... having that by email is better 13:59:37 Arnaud: Q for editors: 13:59:43 http://www.w3.org/2006/02/lc-comments-tracker/55082/ldp/2840 14:00:26 [[ 4.1 "burden of constraints for resource creation" - I feel that phrase needs more explanation ]] 14:00:40 JohnArwe: still part of the spec 14:01:38 TallTed: the question is "what do you mean?" 14:01:47 ... not clear at first read 14:02:39 [ people discussing possible resolutions ] 14:05:22 sandro: how about: how can the server make it easy for the client to create resources? 14:05:32 Arnaud: sounds nice 14:05:40 ... do we agree? 14:05:51 ... with editorial change? 14:06:14 ... would allow us to dispose of that pending comment 14:06:15 +1 14:06:19 +1 14:06:23 +1 14:06:23 +1 14:06:26 ... I don't hear objections 14:06:33 +1 :-) 14:07:31 +1 14:10:16 Arnaud: now we start with the null relative URIs hack comment 14:10:45 +1 14:10:56 ... let's try restate what the issue is 14:11:01 ... when we create a resource 14:11:04 ... we send some RDF 14:11:07 action-137? 14:11:07 action-137 -- Sandro Hawke to Contact yves and erik to make confirm with them that http-wg is okay with this reading of the link context -- due 2014-04-07 -- OPEN 14:11:07 http://www.w3.org/2012/ldp/track/actions/137 14:11:18 ... at that time, we don't know what the url of the resource will be 14:11:23 topic: Null-relative-URI comment 14:11:24 ... so we use the null relative uri 14:11:30 ... and everything is relative to it 14:11:47 ... comment says: doesn't exist in RDF 14:11:57 ... as RDF does not support this notion 14:12:10 ... alternative is the client know the url before posting 14:12:19 ... so there are 2 steps 14:12:33 JohnArwe: there are other solutions 14:12:40 ... could have a placeholder 14:12:51 ... eg using a header to specify a place holder 14:13:16 Arnaud: this was presented as an alternative 14:13:58 sandro: it's not a bnode, it's a node uri 14:14:08 TallTed: it behaves like it 14:14:17 q+ 14:14:51 Ashok: RDF does not have the concept, can we fix it? 14:15:05 sandro: we can use relative graphs, not rdf graphs 14:15:16 Arnaud: hold on 14:15:27 ... this was proposed as alternatives 14:15:51 JohnArwe: you need to specify uri for the placeholder 14:16:26 betehess: then the graphs are not isomorphic 14:17:00 Arnaud: issues is coming from people using libraries without relative uris 14:17:31 ... people claim their tools don't support it 14:17:55 TallTed: if the problem is the library, go fix the library 14:18:03 q+ 14:18:06 RDF doesn't support it 14:18:21 i'd like it to, but RDF is all about absolute URIs 14:18:33 Arnaud: RDF does not support it, my tools don't support it, what can I do? 14:19:07 ... one possible response: LDP uses Turtle, which support rel uris 14:20:05 +ericP 14:20:12 ack betehess 14:20:41 betehess: I reported this issue a long time ago, saying that by changing from RDF mediatypes to something new (eg. application/ld) would help 14:21:07 ... we can add something to the recs, telling the RDF processor to use a special namespace for the relative URIs and then you do the interpretation 14:21:17 ... this is a way to deal with libs that don't support relative URIs 14:21:19 roger has joined #ldp 14:21:23 sandro: I don't understand 14:21:44 ... the client has no way to construct a turtle serialization 14:22:03 new URI scheme! 14:22:16 ... both problems exist, the server has the problem that it cannot properly parse turtle 14:22:24 client uses a uri scheme which is understood to be changed by the server 14:22:39 server, in the worst case, parses twice 14:23:36 Arnaud: several options: either we stick with what we have 14:23:37 could also say that ldp:foo is the base URI 14:23:38 betehess: if you want to actually tell people that it's not exactly RDF we're working with 14:23:44 ... we can create a note on relative graphs 14:23:48 ... or we just leave it as is 14:24:06 ... or we use some placeholder uris that the server can recognize 14:24:23 ... or we give some control to the client to choose their own rel uri 14:24:57 interesting, we could use the slug for that (or some transform for that) 14:26:33 deiu: can't we use the Slug as the placeholder? 14:26:37 OPTION 1: When the client wants to post a graph including self-reference, it MUST use the null-relative URI as the reference to itself. We clarify the spec, etc. 14:26:37 OPTION 2: When the client wants to post a graph including self-reference, it MUST use some magic URL we pick, eg http://www.w3.org/ns/ldp#self 14:26:37 OPTION 3: When the client wants to post a graph including self-reference, it MUST make up some placeholder URI, and tell the server which one it picked using Link: rel=selfReferencePlaceholder 14:26:43 TallTed: should not be an http uri 14:27:04 ... because you don't have control over it, it's a server side thing 14:27:53 the only requirement for the placeholder URI is that it have a sufficient number of '/'s 14:28:04 [discussing sandro's options] 14:30:23 sandro: the client doesn't know the future "this" uri, that's the issue 14:30:30 ... option 1 is what we have in LC right now 14:30:47 Arnaud: then we'd say "sorry, you have to make it work" 14:30:58 ... other options would require to change the spec 14:31:23 sandro: well processing is different 14:32:39 ... we'd need to ask every lib to fix that 14:34:04 TallTed: which side we're putting the burden on: client or server 14:34:24 POST /containers/PeopleAndMovies << { ../foo a foaf:Person } 14:34:38 sandro: we may need a Relative Graph Note 14:34:48 Ashok: would it be helpful to other people? 14:35:02 OPTION 1 is probably the easiest to optimize because the server doesn't ever have to crack potentially normalized IRIs 14:35:38 Arnaud: honestly, I am not really in favor in making new documents: too much effort 14:35:40 A "Relative RDF Graph" is hereby defined as being just like an RDF Graph except that IRIs are allowed to be Relative IRIs, not just Absolute IRIs. 14:36:45 SteveS: there is always a base 14:37:01 ... meaning the client can communicate the base it wanted 14:37:11 ... there is always some base 14:37:30 sandro: what you want is the Turtle serializer to make the graph relative to my own base 14:37:52 jmvanel has joined #ldp 14:38:05 And then we suggest tool makers include this concept in their APIs. EG Turtle serializers should have a way to serialize relative graphs. 14:38:37 sandro: OR, lets just say RDF serializers SHOULD include a base parameter 14:40:26 ericP: betehess and I tried to use Jena back then, had to do some hack 14:40:46 betehess: situation is much better now, a few lines of code to have a proper serializer 14:41:18 sandro: may not speak about the relative graph, just say that we don't know the base 14:41:21 "The POST or PATCH body may have relative IRIs. These IRIs are relative to the final document location. Note: Systems which parse the input document in order to determine the final document location may need to provide a temporary BASE (RFC3896) for parsing, determine the final document location, and parse the input again with that as the BASE 14:41:27 ." 14:41:28 Sandro: Let's NOT use "Relative RDF Graph", but instead use "Deferred-Base RDF Graph Serialization". 14:41:39 q+ 14:42:00 ericP, what are you quoting? 14:42:06 just proposing 14:42:06 ack bete 14:42:16 Arnaud: if we didn't have the LC already, I would push for option 3 14:42:26 but you probably have better text already, sandro 14:42:28 betehess: I think we're just trying to make Reto happy 14:42:37 ... I've always been thinking of relative graphs 14:42:53 ... there is a time when we don't know the URI of the graph 14:43:12 ... the LDP spec says the base URI will be chosen by the LDP container, so I don't see any issue 14:43:27 guys, not sure if you are still dicussing the issue, but rdflib (python has the base for serilizers: http://rdflib.readthedocs.org/en/latest/apidocs/rdflib.plugins.serializers.html, and probably sesame (java) too: 14:43:37 sandro: problem with rel graph as a concept, it means we have something new to be handled by libraries 14:44:15 @sergio are you unsure b/c you're having trouble hearing us/ 14:44:30 betehess: libraries can be fixed today, and we stand to gain a lot more from using relative URIs 14:44:39 JohnArwe: I'm not connected by phone, sorry 14:44:51 i wouldn't call that "fixed". i'd call it "extended". 14:45:09 pretending otherwise will irk the ire of RDF hackers 14:45:46 ah no worries - yes lots of discussion back and forth about value/not of "relative graph" definitions 14:46:38 sandro: the real question is being able to make a serialization to a certain base 14:46:43 sandro: I don't think defining Relative Graph is a good idea, because it will make Jena, etc, think they should define serializers and parsers for this, would be be a waste. 14:46:49 s/to a/relative to a/ 14:47:02 sandro: We want serializers to have a MakeRelativeToThis IRI parameter. 14:47:56 serialize(outputStream, graph, makeRelativeToThis) 14:48:23 and note that servers may need to parse zero, one, or two times, depending on their design. 14:48:24 Arnaud: we have to acknowledge the problem 14:48:32 ... for very reasonable designs. 14:48:54 ... other people said this is a practical way to handle this situation (cygri, dwoods) 14:49:02 TallTed: or rather, we need to be able to tell serializers to make serializations with relative IRIs which refer to that serialization... so s/makeRelativeToThis/makeRelative[ToOutputStream]/ 14:49:49 sandro: we can add the MakeRelativeToThis thing in best practices 14:49:55 stevebattle1112 has joined #ldp 14:50:00 Arnaud: then we don't do anything in the spec? 14:50:13 ... would be reasonable to add something 14:51:10 ... the remark was based on how tools work, based on RDF is defined 14:51:29 sandro: we could link from the spec to uc&r 14:51:46 not to uc&r, to best practices 14:51:47 Ashok: best practices is not normative 14:52:00 Arnaud: sounds like we're getting to an agreement 14:52:10 "For a discussion of implementation issues around the use of relative IRIs during POST operations, see [BP]" 14:52:19 +1 14:52:33 I'll try to provide some practical examples of different libs 14:52:47 great, sergio 14:52:53 PROPOSAL: we stick with the spec, add a pointer to Best Practices, and add an implementation issues relative to this 14:53:19 sandro: it'd be an informative dependency 14:54:04 BP https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp-bp/ldp-bp.html 14:54:25 Arnaud: errr, BP not published yet 14:54:44 sandro: or we can have a non-normative appendix in main LDP spec 14:55:26 PROPOSAL: We stick with the current null-relative design, and we add a non-normative explanation of how that works, how to do it in some tools, etc, in a footnote, appendix, or (hopefully) BP. 14:55:43 +1 14:55:45 +1 14:55:45 +1 14:55:47 +1 14:55:48 +1 14:55:50 +1 14:55:51 +1 14:55:53 +1 14:55:56 +1 14:55:59 +1 14:55:59 +1 (hope it works) 14:56:10 RESOLVED: We stick with the current null-relative design, and we add a non-normative explanation of how that works, how to do it in some tools, etc, in a footnote, appendix, or (hopefully) BP. 14:56:12 +1 14:56:17 (late xD) 14:56:32 :-) 14:56:33 @ericp, what part do you think might not work? 14:57:11 @JohnArwe, can we claim a media type of text/turtle if we don't know the base at the time of transmission? 14:57:39 i.e. should the client or an intermediary be able to know what graph was actually transmitted? 14:57:45 So using .. is a Wrost-Practice, UNLESS you know how the Server is assiging URIs. 14:59:02 JohnArwe, you see my issue? 14:59:41 could i, as a client, have an automagically filled cache of stuff-i've-told-the-world? 15:00:09 (probably not a show stopper use case, but does illustrate what goes wrong when you cheat on specs) 15:00:17 -ericP 15:11:07 Arnaud: resuming 15:11:33 ... during the discussion, somebody brought the ../ "problem" 15:11:42 ... do we want to allow it? prevent it? 15:12:17 ... what does it know? you don't know where the document will be 15:12:28 q+ 15:13:08 JohnArwe: it cannot be a reliable way to reference the container 15:13:18 Arnaud: or even another resource eg. a sibling 15:13:35 TallTed: sure 15:13:42 ... not necesseraly an issue 15:14:00 ... can have multiple container having multiple paths 15:16:02 zakim, who's talking? 15:16:14 Arnaud, listening for 10 seconds I heard sound from the following: nmihindu (45%), +1.617.715.aaaa (20%) 15:16:23 zakim, mute nmihindu 15:16:23 nmihindu should now be muted 15:16:51 Sorry. I thought I was already muted. 15:18:09 JohnArwe: interop could be limited 15:18:45 sandro: the ../ semantics is implied because of other specs 15:19:39 Arnaud: do we want to say something about it in the spec? 15:20:05 ... oh, the ../ issue was brought by cygri 15:20:16 http://lists.w3.org/Archives/Public/public-ldp/2014Mar/0051.html 15:20:47 ... (may be discussed elsewhere as well) 15:21:00 [[ 15:21:00 Because otherwise, it’ll be even less clear what “/“ or “/foo” or “..” refer to, as it’s unclear whether they will be resolved against your hack URI, or the container URI, or the new item URI. 15:21:00 ]] 15:23:02 JohnArwe: rel uris is application specific 15:24:04 sandro: so the question is about base uri, not just null uri 15:24:11 ... the spec is already good 15:24:27 4.2.1.5 LDP servers MUST assign the default base-URI for [RFC3987] relative-URI resolution to be the HTTP Request-URI when the resource already exists, and to the URI of the created resource when the request results in the creation of a new resource. 15:24:46 SteveS: the spec is clear 15:24:54 ... BP might help explaining further 15:25:07 Arnaud: so what are we doing? nothing to do? 15:25:15 ... add something in BP? 15:25:47 "It follows from this definition that use of /../ and other non-null relative URI constructs during POST has application-dependent results" 15:26:18 Ashok has joined #ldp 15:26:25 JohnArwe: it's not ill-defined but it may limit interop 15:26:32 betehess: I'd need an example where it limits interop 15:29:27 betehess: it's not application or implementation specific. the spec already says it's relative to the base uri, always defined in LDP, even during POST 15:29:29 "It follows from this definition that use of /../ and other non-null relative URI constructs during POST will cause the content to be referring to resources in a manner the client will not, in general, be able to predict." 15:29:42 ... but nobody can rely on it to refer to a parent or sibling 15:31:10 Arnaud: people presumed to know where the going to land in a POST and may use ../ in consequence 15:31:19 TallTed: why do we presume people will do that? 15:31:29 SteveS: we may handled that in BP 15:31:54 Arnaud: it's just somebody referred to that, would like to be able to point people at an good answer 15:32:02 q? 15:32:03 q- 15:32:49 roger: people will want to speak about hierarchy and may want to use ../ and stuff like that 15:32:57 "Other non-null relative URI constructs may not refer to the user's anticipated resource, due to variability in implementation and/or deployment. Tread with caution. Here be dragons." 15:33:00 Arnaud: let me make a proposal 15:33:13 roger, yes https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp-bp/ldp-bp.html#represent-container-membership-with-hierarchical-uris 15:33:25 "It follows from this definition /../ URLs should not be used in POSTed content unless the client has additional information about IRIs are assigned." 15:33:45