07:57:35 RRSAgent has joined #ldp 07:57:35 logging to http://www.w3.org/2012/11/01-ldp-irc 07:57:44 RRSAgent, please generate minutes 07:57:44 I have made the request to generate http://www.w3.org/2012/11/01-ldp-minutes.html betehess 07:57:53 tidoust has joined #ldp 07:58:05 chair: Arnaud 07:58:13 ivan has joined #ldp 07:58:23 agenda: http://www.w3.org/2012/ldp/wiki/F2F1#Day_1_-_November_1st 07:58:59 betehess has changed the topic to: agenda: http://www.w3.org/2012/ldp/wiki/F2F1#Day_1_-_November_1st -- please do add yourself [ present+ Alexandre_Bertails ] 07:59:08 present+ Alexandre_Bertails 07:59:13 svillata has joined #ldp 07:59:14 betehess has changed the topic to: agenda: http://www.w3.org/2012/ldp/wiki/F2F1#Day_1_-_November_1st -- please do add yourself [ present+ Alexandre_Bertails ] (no space) 07:59:26 betehess has changed the topic to: agenda: http://www.w3.org/2012/ldp/wiki/F2F1#Day_1_-_November_1st -- please do add yourself, eg. [ present+ Alexandre_Bertails ] (no space) 07:59:57 who said arrival, coffee in the program ? 08:00:48 chsiao_ has joined #ldp 08:01:16 FabGandon has joined #ldp 08:06:59 Ruben has joined #ldp 08:07:11 AndyS has joined #ldp 08:07:12 present+ Ruben_Verborgh 08:07:14 SteveBattle has joined #ldp 08:07:28 s|who said arrival, coffee in the program ?|| 08:07:29 present+ Olivier Berger 08:07:40 s/Olivier Berger/Olivier_Berger/ 08:07:46 jonathandray has joined #ldp 08:08:05 roger has joined #ldp 08:08:11 betehess has changed the topic to: agenda: http://www.w3.org/2012/ldp/wiki/F2F1#Day_1_-_November_1st -- please do add yourself, eg. [ present+ Alexandre_Bertails ] (NO_SPACE) 08:08:26 nmihindu has joined #ldp 08:08:41 present+ Jonathan Dray 08:08:52 s/Jonathan Dray/Jonathan_Dray/ 08:09:00 present+ Roger Menday 08:09:11 s/Roger Menday/Roger_Menday/ 08:09:13 Zakim, please dial St_Clair_3B 08:09:13 sorry, ericP, I don't know what conference this is 08:09:22 Do we have a hashtag? 08:09:43 Zakim, please this ldp 08:09:43 I don't understand 'please this ldp', ericP 08:09:44 Ashok_Malhotra has joined #ldp 08:09:50 Zakim, please this is ldp 08:09:50 I don't understand 'please this is ldp', ericP 08:09:55 Zakim, this is ldp 08:09:55 ericP, I see SW_LDP()2:30AM in the schedule but not yet started. Perhaps you mean "this will be ldp". 08:09:59 present+ SteveSpeicher 08:10:03 Zakim, please dial St_Clair_3B 08:10:03 sorry, ericP, I don't know what conference this is 08:10:05 present+ BartvanLeeuwen 08:10:13 Zakim, this will be ldp 08:10:13 ok, ericP; I see SW_LDP()2:30AM scheduled to start 100 minutes ago 08:10:14 Zakim, please dial St_Clair_3B 08:10:14 ok, ericP; the call is being made 08:10:15 SW_LDP()2:30AM has now started 08:10:16 +St_Clair_3B 08:10:21 present+ Arnaud_Le_Hors 08:10:26 RRSAgent, please make minutes 08:10:26 I have made the request to generate http://www.w3.org/2012/11/01-ldp-minutes.html betehess 08:10:30 antonis has joined #ldp 08:10:38 SteveBattle, https://twitter.com/LDPWG i.e. @LDPWG seems an option 08:10:40 Zakim, please dial St_Clair_3B 08:10:40 ok, ericP; the call is being made 08:10:41 +St_Clair_3B.a 08:10:50 -St_Clair_3B 08:11:15 Zakim, St_Clair_3B.a is St_Clair_3B 08:11:15 +St_Clair_3B; got it 08:11:29 ArnaudLH, are you the owner of @LDPWG ? 08:12:03 rgarcia has joined #ldp 08:13:00 davidwood has joined #ldp 08:13:39 oberger: Erik is 08:14:05 but #LDPWG may be an interesting hashtag 08:14:35 Zakim, who is here? 08:14:35 On the phone I see St_Clair_3B 08:14:36 On IRC I see davidwood, rgarcia, antonis, Ashok_Malhotra, nmihindu, roger, jonathandray, SteveBattle, AndyS, Ruben, FabGandon, chsiao_, svillata, ivan, tidoust, RRSAgent, 08:14:36 ... BartvanLeeuwen, Zakim, ArnaudLH, betehess, oberger, SteveS, ahaller2 08:14:37 can you avoid uppercase? 08:14:45 eg. ldpwg 08:15:07 betehess, I guess it doesn matter much for twitter web app 08:15:19 but yes lowercase if you will 08:16:29 Yes, twitter tags are case insensitive. 08:17:00 Where's the coffee? 08:17:40 SteveBattle, shouldn't we ask Zakim ? 08:17:53 crappy bots 08:18:03 zakim, where's the coffee? 08:18:03 I don't understand your question, SteveBattle. 08:18:46 *Hyper Text Coffee Pot Control Protocol http://tools.ietf.org/html/rfc2324* 08:19:45 Ruben, would it make a use case to control a coffee pot through REST and RDF ? 08:20:04 This could actually convince a lot of developers to turn to RDF. 08:20:38 using coffeescript ? 08:21:30 http://coffeescript.org/ 08:24:21 chong has joined #ldp 08:30:41 let's get it started 08:30:53 ArnaudLH, addressing us 08:31:03 topic: Welcome, logistics, short intro round, recap of meeting goals, agenda amendments 08:31:07 cygri has joined #ldp 08:31:09 scribenick: betehess 08:31:33 ArnaudLH: let's go around the table, introduce yourself 08:31:59 ivan: Ivan Herman, W3C semweb lead 08:32:05 ... here as an observer 08:32:46 davidwood: David Wood, RDF WG 08:32:53 +Yves 08:32:53 ... but also member of this group 08:33:34 chong 08:33:49 develD has joined #ldp 08:34:02 rgarcia: Raúl García-Castro, Ontology Engineering Group, Universidad Politécnica de Madrid 08:34:13 Nandana Mihindukulasooriya from Ontology Engineering Group, Universidad Politécnica de Madrid 08:34:15 Eric Prud'hommeaux 08:34:27 krp has joined #ldp 08:35:14 Richard Cyganiak, DERI 08:35:34 Ruben / Ghent University – iMinds / PhD student Semantic Web & Web APIs 08:35:36 Kevin Page, University of Oxford 08:35:41 Bart van Leeuwen netage.nl (Startup Member)/ Fire Fighter Amsterdam 08:35:51 Alexandre Bertails aka. betehess, W3C Systeam Team. Already working actively on LDP implementation at https://github.com/w3c/banana-rdf 08:36:05 I'm Steve Speicher from IBM 08:36:06 Serena Villata, INRIA Sophia Antipolis 08:36:16 Antonis Loizou, post-doc Vrije Universiteit Amsterdam 08:36:17 Armin Haller 08:36:50 Olivier Berger aka oberger/olberger/obergix from Institut Telecom / Tlcom SudParis 08:36:51 Francois Daoust from Joshfire. Working on JSON-LD within RDF WG. Observer. 08:37:10 Steve Battle 08:38:18 cgueret has joined #ldp 08:38:25 jonathandray: Jonathan Dray 08:39:06 Zakim, who is on the phone? 08:39:06 On the phone I see St_Clair_3B, Yves 08:39:16 Hey, i am Norman Richter from the univerity of Halle / Leipzig, Germany. I'm doing resarch on webid, web access control, pubsubhubbub. I'm still a student and planning to start with my final thesis on this subject within the next weeks/months. It's about delivering Linked Data as rdf over a PubHub with WebAccessControl / ACL to subscribers who should authentify with webid. I am here as an observer to check out how ldp is related to this subjects. 08:39:43 Jonathan Dray, I worked for a Company called Social Computing on "Just Map It", a data mapping solution. I also worked on a project called SPAR for the BNF on data preservation with Alexandre Bertails. I an here as an observer. 08:40:21 Andy Seaborne, Apache Software Foundation. Work with linked data building customer solutions. Also work on Apache Jena. 08:40:38 ArnaudLH: thanks all 08:40:49 ... the agenda was a bit of a challenge 08:41:03 ... still on the early days 08:41:16 ... two main topics 08:41:30 ... tried to split everything in chunks 08:41:41 ... also tried to take timezones into accounts 08:41:54 ... I'm flexible about these things 08:42:18 ... as AndyS was the only one to express specific interests in some topics, I'll try to honor them 08:42:24 ... no other constraint 08:42:41 ... so just tell me to "move on" 08:42:58 davidwood: how many people new to w3c? 08:43:23 [only a few] 08:44:04 ArnaudLH: any question about the process, then just ask 08:44:09 ... it's a nice place, don't worry 08:44:53 ArnaudLH is going through http://www.w3.org/2012/ldp/wiki/F2F1#Objectives 08:45:06 ArnaudLH: I went back to the charter 08:45:08 http://www.w3.org/2012/ldp/charter 08:45:25 ... we need to start speaking about some stuff 08:45:30 ... eg. test suite 08:45:34 ... and validator 08:45:50 ... lots of discussion during charter writing about ACLs 08:46:03 ... some wanted that as a MUST 08:46:21 ... could be a disaster for some, but for others, the platform may not make sense without it 08:46:31 ... the compromise was: a NOTE defining the requirements 08:46:34 cygri has joined #ldp 08:46:39 ... these are the main deliverables 08:46:48 ... also want to discuss next f2f meeting 08:47:24 ... the FPWD is basically the SUBMISSION annotated with issues 08:47:26 FPWD http://www.w3.org/TR/ldp/ 08:47:33 ... we'lll go through the list of issues 08:47:44 q+ 08:48:16 ... also I want to discuss the path forward to REC 08:48:34 ... glad to say that the group seems to have started doing good job 08:48:40 ... eg. the FPWD 08:49:09 ... again, we do have a charter, we need to try to stick to it as much of possible 08:49:28 ... regarding use case and requirements doc, it's a bit different 08:49:34 ... not published it yet 08:49:44 ... we need to decide what this doc is really about 08:49:51 cygri has joined #ldp 08:50:06 ... steeve did a great job to put it together 08:50:06 ... but some stuff does not belong there 08:50:08 http://www.w3.org/2012/ldp/wiki/Use_Cases_And_Requirements 08:50:21 ... but the plan was to put everything you wanted there first 08:50:37 Ashok_Malhotra: if you add a requirement 08:50:47 q+ to ask SteveS if we should be looking at the editor's draft while discussing the LDP draft 08:50:47 ... and the spec does not address it 08:50:53 ... then it can be a problem 08:51:21 ack eri 08:51:21 ericP, you wanted to ask SteveS if we should be looking at the editor's draft while discussing the LDP draft 08:51:39 ericP: is there something new in the ED since the FPWD? 08:51:43 ... where should be look at 08:51:57 steeve: not change much 08:51:59 ... only locally 08:52:17 s/steeve/SteveS/ 08:52:37 ack me 08:53:09 betehess: prioritize issues for people only present today 08:53:23 roger has joined #ldp 08:53:36 q+ 08:53:42 davidwood has joined #ldp 08:53:44 cygri has joined #ldp 08:54:03 oberger: would like to hear about implementations and validation 08:54:27 ... even if it's not mandatory in the charter 08:54:34 +1 08:54:40 SteveS: wanted to review the path of the spec 08:54:45 ... and the schedule 08:55:05 cygri has joined #ldp 08:55:06 davidwood: maybe a wiki page for listing implementations 08:55:13 ArnaudLH: good idea 08:55:52 ... the goal is to discuss the usecase and requirements this morning 08:55:54 q+ on which target audience we're seeking 08:56:02 ... and the spec this afternoon 08:56:23 cygri has joined #ldp 08:56:42 ArnaudLH: is this reasonable for now? 08:56:59 oberger: maybe would like to remind the target of this WG 08:57:13 ... eg, yesterday there was discussion about LD for devs 08:57:18 ... Javascript was important 08:57:25 q+ 08:57:36 ... just want to understand the objectives 08:57:57 ... would like to understand the stakeholders 08:58:09 ArnaudLH: what's your objective? 08:58:18 oberger: understand better what is out of scope 08:58:30 ... so fat, it's about resources and containers 08:58:44 ... so people mentioned some other datastructures 08:59:03 cygri has joined #ldp 08:59:15 ack betehess 08:59:47 ack oberger 08:59:47 oberger, you wanted to comment on which target audience we're seeking 09:00:01 cygri has joined #ldp 09:00:02 betehess: I believe that it is clearly out of scope if you look at the charter. We may revisit that later on but should focus on what's on the charter. The topic is very important for me, but we need to stay focused. 09:00:15 ArnaudLH: the first answer in the charter 09:00:24 ... defines the goals 09:00:30 ... then the usecase and requirement refine that 09:00:43 ... we may conclude that we need something else 09:00:57 cygri has joined #ldp 09:01:39 oberger: if you look at the usecase, there are plenty of them, some redundant 09:01:48 ... only a few requirements 09:02:10 ... maybe we'll see a whole range of other things? 09:02:24 ... lack of imagination or just people staying on focus? 09:02:43 cigry: we may be missing some stuff 09:03:03 ... if you see something like this, just say it 09:03:13 ... let's nto brainstorming here at the f2f 09:03:51 ArnaudLH: anybody can make a proposal at any point 09:03:52 New wiki page for implementations, as requested: http://www.w3.org/2012/ldp/wiki/Implementations 09:04:12 (linked from the main page under Ongoing Work) 09:04:15 SteveS: just make things as close as possible to what we have 09:04:31 ArnaudLH: let's speak about usecase and requirements 09:05:06 ... we already have something good 09:05:06 ... we may want to remove things that don't belong there 09:05:21 ... normally, you start with that, then you start the docs 09:05:37 ... here we started with the spec, we're still editing the UCR doc 09:05:44 topic : Use Cases and Requirements 09:05:52 q+ 09:06:02 ... there is a good reason for this situation 09:06:25 ack davidwood 09:06:36 davidwood: just wanted to mention I created the implementation page 09:06:43 ... we can use that to ground the use-case 09:07:30 ArnaudLH: I split the schedule in two 09:07:35 ... the steps 09:07:49 ... and what's in the doc today 09:08:11 ... also, what does it mean to have a requirement not addressed in the spec? 09:08:20 ... eg. security is out-of-scope IMO 09:08:46 SteveBattle: people started to collect stories together 09:08:51 ... two sections 09:08:57 ... existing user stories 09:09:03 cygri has joined #ldp 09:09:13 ... and the use cases 09:09:30 +q 09:09:35 ... you find here scienarios 09:09:45 ... making the use cases more concrete 09:09:53 ... there are 10 of them so far 09:10:08 ... there used to be plenty of examples 09:10:19 ... they are now somewhere else 09:11:06 [describing a scenario] 09:11:30 ... there are also pointers to the issues that were raised 09:11:42 http://www.w3.org/2012/ldp/wiki/Examples 09:11:45 ... focused on functional requirements 09:11:56 RRSAgent, make logs public 09:12:19 ... functional requirement == what do you expect the system to do 09:13:25 ... functional is the how 09:13:38 ack bart 09:13:38 BartvanLeeuwen: is it still open? 09:13:41 q+ 09:13:45 SteveBattle: it is still open 09:13:50 bblfish has joined #ldp 09:13:54 q+ 09:14:18 ... for user stories, just go ahead 09:14:19 ack steves 09:14:23 ... for requirements, just talk to me 09:14:24 q- 09:15:04 SteveS: when I look at user scenarios, looks like we're too restrictive 09:15:06 ... eg. imposing 303 09:15:06 ... should be in the spec 09:15:08 q+ 09:15:37 ... response codes are too much detail for example 09:16:15 Ashok_Malhotra: there are other possible solutions 09:17:06 ... just pointing out that this is quite open 09:17:14 q+ to propose that another doc capture the very helpful groundings of the use cases 09:17:21 ... so 303 may be too early 09:17:47 SteveBattle: it is quite useful to know some things here 09:17:56 ... so it's useful to document 09:17:57 rrsagent, draft minutes 09:17:57 I have made the request to generate http://www.w3.org/2012/11/01-ldp-minutes.html ivan 09:18:10 ... it's interesting to understand the sequence 09:18:22 SteveS: it's supposed to drive the spec 09:18:40 q? 09:18:46 betehess: i read the UC&R as painging ourselves in a corner 09:18:52 ack bete 09:19:16 ... there may be some recipes in the UC&R which we have yet to discuss 09:19:34 ack ericp 09:19:34 ericP, you wanted to propose that another doc capture the very helpful groundings of the use cases 09:19:49 ericP: when I read UCR, I usely don't know anything 09:19:54 ... here I find many details 09:20:14 ... maybe you can put that stuff to another page 09:20:14 q+ 09:20:24 ... and you link those 09:20:37 ... then the reader can ground things to examples 09:20:48 ... and we can compare different proposals 09:21:02 q+ 09:21:32 SteveBattle: use cases are requirements 09:21:44 cygri: this level of details can't be defined here 09:21:51 q+ to suggest the implementations page be used to record the "where" 09:21:57 ... there are specific deployment pattern that are used out there 09:21:59 +1 use case documents should not be a pre-spec, just general goals for the spec 09:22:16 ... some things are already using 303 for example 09:22:34 ... we may have to answer quesitons like to we support X? if not, why? 09:22:44 ... that's something I expect to see in the document 09:23:04 ... and at the end, we may just say that we recomment something else 09:23:09 +1 we need such level of details for existing deployment patterns 09:23:09 q+ 09:23:30 ... people want to say the way they expect this to work 09:23:42 I have made the request to generate http://www.w3.org/2012/11/01-ldp-minutes.html ericP 09:24:08 ... taking existing deployment into account is a valid point, should not be ignored 09:24:12 cygri has joined #ldp 09:24:16 SteveS: +1 to eric 09:24:20 ack steves 09:24:27 ... we may have another wiki page 09:24:36 q+ 09:24:46 ... where we can say how things match between the doc and the spec 09:25:06 ... would be bad to have to go back to UCR to change it 09:25:06 cygri_ has joined #ldp 09:25:18 ack bete 09:25:21 ArnaudLH: for me, it's too much about the solution, not defining the solution 09:25:43 q+ 09:25:46 betehess: I want to describe the problem, not the solution 09:25:55 betehess: i don't want to describe the solution, i want to describe the problem, and then tie that to existing solutions 09:27:01 ... when you speak of 303s (for folks who want to make a clear distinction between entity and page), some folks use #URIs 09:27:19 cygri: we don't want to throw it out based on the level of detail 09:27:50 betehess: if we don't end up matching the UC&R, do we delete UC&R? 09:28:05 ack david 09:28:05 davidwood, you wanted to suggest the implementations page be used to record the "where" 09:28:10 cygri: user stories give requirements; requirements give rise to features in the spec 09:28:11 davidwood: maybe a bit orthogonal 09:28:16 cygri has joined #ldp 09:28:18 ... trying to capture the what and the how 09:28:19 ... sometimes you have to go back. that's just how it is 09:28:25 ... the where may be missing 09:28:39 ... eg. to answer waht use-cases are implemented or not 09:28:53 ... we need a place to track those 09:29:18 ... I agree it's too detalied in term of the guidance 09:29:23 cygri has joined #ldp 09:29:24 ... we would like to say things only once 09:29:30 ... don't repeat yourself 09:29:44 ... we could change this page to respect the use stories (the why) 09:29:51 cygri has joined #ldp 09:30:04 ... and point to the spec to see where it's discussed 09:30:04 we should also map the spec sections to the use cases, that way we have a good mapping implementations to uc to spec sections 09:30:06 ack ahaller 09:30:13 ahaller2: I find this useful to the end-user 09:30:19 ... it says hwo to use the platform 09:30:25 cygri has joined #ldp 09:30:37 ArnaudLH: I think there is great material here 09:30:46 ... nobody is saying to throw it out 09:30:53 ... question is what's belong here 09:31:02 ... what is the spec going to address 09:31:18 ... we don't just want to delete any of these 09:31:36 s/waht/what/ 09:31:39 ... could be a note, or whatever, we decide that later 09:32:04 ... could a primer as well 09:32:09 s/could/could be/ 09:32:15 ack krp 09:32:24 krp: could be confusing 09:32:35 ... what don't people like here? 09:32:40 ... to many steps? 09:32:45 s/to/too/ 09:32:58 ... at least, this is a clear requirement 09:33:11 ... could also be a test case 09:33:16 q+ 09:33:23 ack steveb 09:34:07 SteveBattle: what do you want to move out? 09:34:23 q+ to propose that it may be most helpful to us to partition later and add an issue to say we plan to do so 09:34:26 ... it's conventional to speak about the steps 09:34:38 davidwood: the spec speaks about 303 in two places 09:34:47 ... also http verbs 09:35:03 ack bete 09:35:16 betehess: what's there is valuable 09:35:23 cygri has joined #ldp 09:35:28 ... it's not about the value itself 09:35:41 ... this material is excellent for when i'm implementing the test 09:35:55 oberger +1 09:35:55 ... i want to test the spec, not the user requirement 09:36:14 q+ to suggest starting a test page 09:36:17 q+ asking for a coffee break potentially short 09:36:21 q- 09:36:21 ... some folks say "just re-edit the page", but this is against @@1 09:36:32 ack eric 09:36:32 ericP, you wanted to propose that it may be most helpful to us to partition later and add an issue to say we plan to do so 09:36:47 ericP: when I said to split out in different document 09:36:57 ... for the time being, this is very useful 09:37:13 q+ 09:37:22 ... we'll need to re-edit something anyway 09:37:31 ... we can insert a note at the beginning 09:37:39 ... and use color code 09:37:59 ... that states what's to be considered 09:38:13 ... and gives fewer places to visit 09:38:23 cygri has joined #ldp 09:38:42 ack david 09:38:42 davidwood, you wanted to suggest starting a test page 09:38:58 q- asking 09:39:17 davidwood: we could move some of the stuff to a wiki page for tests 09:39:21 ack steveb 09:39:25 cygri has joined #ldp 09:39:34 SteveBattle: we'll propose something 09:39:40 +1 to convert examples into tests 09:39:47 ... still people need to review the scenarios 09:40:10 ArnaudLH: let me try to summarize 09:40:16 ... probably too much in the doc 09:40:22 ... not sure how to address the p 09:40:33 ... some wants to move stuff 09:40:45 ... just happy to give SteveBattle a chance to do another pass 09:41:01 cygri has joined #ldp 09:41:03 ... but I don't want to end up saying "this is not what we wanted" 09:41:05 q+ 09:41:25 ... any concrete proposal? 09:41:31 q+ 09:42:03 ... if there is too much, we'll need to sort it out 09:42:14 cygri has joined #ldp 09:42:20 zakim, who is on the call? 09:42:20 On the phone I see St_Clair_3B, Yves 09:42:22 oberger: maybe let's focus on the first 2 ones? 09:42:46 SteveBattle: don't want to loose the information, eg. the status code 09:42:49 cygri has joined #ldp 09:43:01 ack bete 09:43:28 cygri_ has joined #ldp 09:43:58 q+ 09:44:16 betehess: maybe we want to have everything for a given user story in one place 09:44:37 ack steves 09:44:46 HadleyBeeman has joined #ldp 09:44:50 SteveS: wanted to echo something similar 09:44:51 ... at the end we need to gather all the info one place and this document points to the appropriate places in all the specs 09:45:06 ... phrasing is important 09:45:28 ... then we can extract the things depending on what we need 09:46:02 q+ 09:46:02 cygri has joined #ldp 09:46:04 ack ashok 09:46:08 ArnaudLH: we have decided if we needed a primer yet 09:46:22 Ashok_Malhotra: would take all the stuff other than the 2 headers 09:46:32 q? 09:46:39 ... could use other colors, this is possible solution 09:46:45 cygri has joined #ldp 09:46:53 q+ 09:46:56 ... like davidwood's suggestion to move that to test 09:47:05 ... the spec could end up with something very different 09:47:19 davidwood: just said to put in a wiki page to start thing about it 09:47:22 Ashok_Malhotra: that's fine 09:47:23 q+ to say that tests are allowed to be controversial 09:47:25 q- 09:48:07 ArnaudLH: SHORT BREAK 09:48:13 q+ primer is needed 09:48:17 resume at 11:00 09:48:58 q+ to state that primer is needed as in ld-dev yesterday 09:49:20 +1 for a primer 09:55:35 Ruben has joined #ldp 09:55:53 chsiao has joined #ldp 09:56:44 BartvanLeeuwen has joined #ldp 09:58:37 cygri has joined #ldp 09:59:19 cygri has joined #ldp 10:00:11 cygri_ has joined #ldp 10:04:41 rgarcia has joined #ldp 10:07:40 nmihindu has joined #ldp 10:10:01 +1 10:10:48 cygri has joined #ldp 10:11:35 hi 10:11:44 again a short round of introductions 10:11:50 Henry Story 10:12:05 sandro's not here 10:12:28 Hadley Beeman 10:12:31 q? 10:12:41 ack me 10:12:41 BartvanLeeuwen, you wanted to state that primer is needed as in ld-dev yesterday 10:12:50 q+ 10:12:54 s/sandro's not here// 10:13:02 +1 for primer 10:13:04 Bart: a primer would be a good idea 10:13:05 q+ 10:14:26 ArnaudLH: Would be a note, so we are fine doing a primer 10:14:38 oberger: and bringing a bit more repeating of HTTP in the primer than in the specs would be greay 10:14:43 s/greay/great/ 10:14:57 +1 for primer, would be willing to help do 10:15:01 ack eric 10:15:01 ericP, you wanted to say that tests are allowed to be controversial 10:15:50 ack steveb 10:17:03 steveB: move specific error codes to a wiki, still talk about supporting redirections, but less detail 10:17:14 ack cygri 10:17:59 richard: caution with primers, not always effective, often rushed out, not covering the scope of the working group 10:18:30 ... could be done outside of the working group 10:18:57 http://patterns.dataincubator.org/book/ provides a nice example of what a primer could be 10:18:58 ArnaudLH: add primer issue to the agenda if we have time 10:19:03 jonathandray has joined #ldp 10:19:09 ... who is the audience of the primer 10:20:07 ArnaudLH: keep the timeline for the UCR document is more important 10:21:00 ... agree on the status of the document, what sections are in the document, mock the sections if necessary. 10:21:48 ... figure out nature of the content and the audience, don't have an explosion of documents 10:22:02 should be maintain a Linked Data index of the documents, their contents in a nice RDF graph ? ;) 10:22:25 kinda drinking our own champagne 10:22:50 nicely stated 10:22:57 ... the UCR document would have been different if Steve did not have the spec. The document should stand on its own. 10:23:09 oberger, VoID file? 10:23:09 q+ 10:23:23 ack bblfish 10:23:50 @oberger +1 10:24:13 some nice UC to add : specify a standard in a standardization body in a collaborative manner, etc ;) 10:24:27 s/UC/US/ User Story 10:24:47 q+ 10:25:07 RRSAgent, please make minutes 10:25:07 I have made the request to generate http://www.w3.org/2012/11/01-ldp-minutes.html betehess 10:25:25 ArnaudLH: easier to have everything in one document 10:25:39 ack oberger 10:25:47 oberger: should not be afraid of multiple documents 10:25:47 roger__ has joined #ldp 10:26:02 q+ 10:26:21 ack steveb 10:26:47 SteveB: use cases should not be vague 10:27:12 seating chart for the room today, as far as I can tell: http://www.w3.org/2012/ldp/meeting/2012-11-01#line0001 10:27:14 q+ 10:27:19 ArnaudLH: ericP proposed to annotate the document 10:27:23 ack cygri 10:27:24 can we add anchors inside a mediawiki page, that won't be renamed ? 10:27:35 what does it mean to publish the document? Is it not on the wiki? 10:27:38 so that we can nnotate ? 10:27:45 cygri: how to get certain use cases into the document? I have use cases which are not reflected. 10:28:04 ... what level are they, user stories vs. use cases 10:28:26 oberger, yes, should survive. 10:28:44 sandro, or maybe a less HTML way ? 10:28:59 oberger, I don't know a non-HTML way 10:29:41 ... if i have requirement like I have a graph with mio incoming and outgoing links, how would i document that in the UCR document 10:29:53 sandro,
optional text
in http://www.mediawiki.org/wiki/Help:Links 10:30:00 ericP: i feel this is more like an issue, not a use case 10:30:01 sandro, so that's similar 10:30:25 yes, oberger, same thing 10:30:48 q+ 10:31:34 cygri: i have this big graph, the question is should i put it in right now 10:32:33 steveB: examples has two issues, functional and non-functional, scale 10:33:25 ArnaudLH: it does not make sense to close the document, you can add use cases later, even though they are harder to be addressed 10:33:39 ack steveb 10:33:57 q+ to have a valuable position on the queue 10:34:01 q- 10:34:07 steveB: prototype primer for use case details 10:35:01 ArnaudLH: multiple ways to communicate with the public, we can publish notes, or a link 10:35:16 steveB: detailed scenarios is important for implementers 10:35:31 davidwood: where do we provide the details for implementers? 10:35:46 steveS: webplatform.org 10:35:59 q+ to talk about test cases 10:36:26 steveS: realise that we need to add more examples to spec 10:36:30 ack cygri 10:36:30 cygri, you wanted to talk about test cases 10:36:55 develD has joined #ldp 10:37:04 cygri: some of the details in the UCR would make good test cases 10:37:11 ack cygri 10:37:11 q+ 10:37:43 ArnaudLH: i would like to get a timeline. 10:38:30 q+ to suggest doing straw poll on publishing FPWD as is 10:38:48 ... how we are going to decide what will be in the UCR document 10:39:07 /me agrees with ArnaudLH as I disagree strongly with some of the current requirements 10:40:06 q+ 10:40:09 ... two possible approaches: 1) go through document and make decision 2) review the document, the default is everything stays in there, raise an issue 10:40:17 ack david 10:40:39 If anyone disagrees with the detail of the requirements please raise on the mailing list. 10:41:15 davidwood: UCR is up already 10:41:25 ArnaudLH: at the end it will be a note 10:41:26 q+ 10:41:31 ack cygri 10:41:31 cygri, you wanted to suggest doing straw poll on publishing FPWD as is 10:42:06 cygri: straw poll on publishing the content as we have it 10:42:20 ... surface concerns with straw poll 10:42:22 q+ 10:43:00 q+ to say that we have a choice about whether the FPWD includes all ratified use cases 10:43:02 ... going through document step by step is ok, but i am not sure what is a story and what is a use case 10:43:04 +1 to section-by-section review by the group 10:43:20 ack bete 10:43:25 ArnaudLH: it will be useful to identify the things that we agree on 10:43:48 s/agree/need to agree/ 10:43:54 q+ to say that we have a choice about whether the FPWD includes only ratified use cases 10:44:01 betehess: i have a problem with seeing solutions in the UCR document 10:44:43 q+ 10:44:52 ... want to know what we add later on 10:45:00 there is a difference between the wiki and the published document 10:45:02 ack oberger 10:45:06 why not going through an issue then? 10:45:09 ArnaudLH: controlled process on what will be added later 10:45:28 +1 for pingback 10:45:31 oberger: some concerns on the mailing list are not in the document 10:45:39 use case for ping back? 10:45:45 ... i have a problem to define a use case and/or user story 10:46:02 q+ 10:46:15 ... maybe others are in the same situation not knowing how to get something into the document 10:46:15 pingback relies on so many other things that are not even on scope 10:46:40 pingback is a use case 10:46:43 ArnaudLH: if enough in the group care, it should be in, but we need to define a process 10:47:04 davidwood: who else contributed to uses cases? 10:47:30 i can see a lot of uses for pingback! 10:47:45 ArnaudLH: if you think the working group is not caring, raise it as an issue 10:48:09 oberger: issue raised in the tracker not in the document 10:48:15 we also had feedback from the WG they many were pleased with current use cases and said it covered their cases 10:48:28 q? 10:48:29 davidwood: is there a product in tracker on UCR 10:48:51 ... group member wants a use case, raise an issue 10:48:55 +1 10:49:32 webr3 has joined #ldp 10:49:35 PROPOSAL: the process for adding new use cases is to raise a tracker issue against the UC&R product 10:49:37 +1 10:49:39 +1 10:49:41 +1 10:49:42 +1 10:49:43 +1 10:49:43 +1 10:49:44 +1 10:49:45 +1 10:49:46 +1 10:49:47 +1 10:49:47 davidwood has joined #ldp 10:49:47 +1 10:49:48 +1 10:49:48 +1 10:49:49 +1 10:49:50 +1 10:49:54 +1 10:49:56 +1 10:49:57 +1 10:49:59 APPROVED 10:50:16 APPROVED: the process for adding new use cases is to raise a tracker issue against the UC&R product 10:50:17 q? 10:50:38 ack nmihindu 10:51:20 that's why the wording is important! what do people expect to find in the UC&R document 10:51:28 nmihindu: i have been implementer of specs, these infos we have in the UCR right now, are useful for implementers, but I am not reading the use cases as a implementer. 10:51:30 ack me 10:51:30 +1 to the dev comment 10:51:31 ericP, you wanted to say that we have a choice about whether the FPWD includes all ratified use cases and to say that we have a choice about whether the FPWD includes only ratified 10:51:31 ... use cases 10:51:34 ack eric 10:51:58 FPWD of the UC&R 10:52:12 q? 10:52:20 ericP: we have a choice of stating what issues have been approved 10:52:36 q+ 10:52:47 ... for the 10 use cases in the UCR we can mark them as approved/not approved 10:52:47 ack cygri 10:53:31 cygri: we have a process of highlighting issues in the UCR document. i would like to see a deadline for these issues to be raised. 10:53:38 ack bblfish 10:54:08 bblfish: test this, raise pingback as an issue 10:54:15 ArnaudLH: not right now 10:54:18 ack bete 10:54:45 rrsagent, please draft minutes 10:54:45 I have made the request to generate http://www.w3.org/2012/11/01-ldp-minutes.html webr3 10:54:55 q+ 10:55:16 betehess: agree, implementer will never look at the UCR 10:55:43 ... if we put something in the document it will be hard to remove it. cautious with the first public draft. 10:55:45 q+ 10:56:18 ack steves 10:56:23 ArnaudLH: making sure to agree what is in there. big mistake for example to include access control if we are not 10:56:40 SteveS: 18 user stories, are we agree on those as well? 10:56:48 so do we just use tracker for that as well? 10:56:54 ... same process, with raising issue 10:57:03 we need a deadline then 10:57:05 develD has joined #ldp 10:57:12 cygri: use same process, raise an issue 10:57:23 q+ to ask about a deadline 10:57:57 q- 10:57:58 ArnaudLH: by default everything which is not questioned with an issue will be published 10:58:13 ack bete 10:58:13 betehess, you wanted to ask about a deadline 10:58:25 q+ 10:58:32 betehess: we need a timeline for when the chair will accept issues 10:58:42 q 10:58:46 ack cygri 10:58:51 ... after this point nobody should be allowed to edit the document 10:59:04 q+ 10:59:10 as a way to work, we could move to github and use pull-request 10:59:26 yaso has joined #ldp 11:00:00 cygri: one proposal, we set a date, against the first public draft of this document. Editor takes what is in the wiki, at least flags the issues (marker in the document). 11:00:41 ack nmihindu 11:00:53 q+ 11:01:01 nmihindu: some user stories are very detailed, some are vague ideas. in the document we have to make them consistent. 11:01:09 +1 to that 11:01:25 SteveB: i don't agree we need to make them consistent 11:01:36 ack steveb 11:02:12 q+ 11:02:38 ArnaudLH: do we agree with cygri's proposal, that we make sure that everything is at least mentioned in the document (ie. issues) 11:04:03 +1 for some consistency in user stories, think the readers will appreciate it 11:04:38 cygri: regarding the timeline. everything before that date will be at least acknowledged 11:04:52 PROPOSAL: Issues raised against the UC&R document before XX/YY will be acknowledged or addressed in the first WD of the published document. 11:05:38 suggest 1 December ? 11:05:54 ArnaudLH: agree with that, happy to make that official if people agree 11:06:02 too soon for me 11:07:09 oberger: can steveB still add issues? 11:07:26 ArnaudLH: SteveB should go through the same process 11:07:58 ArnaudLH: will come up with a deadline by tomorrow 11:08:44 q+ 11:08:56 ack me 11:09:06 ericP: are we picking something specific, like SemTech 11:09:22 ack cygri 11:09:31 ack bete 11:09:42 how many weekly meetings/calls do we need ? 11:09:50 q+ 11:09:57 betehess: if we have a deadline that is too early we will have no agreement on anything 11:10:04 betehess misunderstood cygri's proposal 11:10:24 ArnaudLH: we will have to be optimistic 11:10:25 ack cygri 11:10:43 cygri: deadline for raising issues, not for inclusions in the document 11:11:02 ... two separate deadlines 11:11:35 cygri: PROPOSAL: Issues raised against the UC&R document before XX/YY will be acknowledged or addressed in the first WD of the published document. 11:11:53 +1 11:12:03 +1 11:12:07 +1 11:12:07 +1 11:12:08 +1 11:12:09 +1 11:12:10 +1 11:12:11 +1 11:12:11 +1 11:12:11 ArnaudLH, to propose a timeline tomorow 11:12:13 +1 11:12:15 +1 11:12:19 +1 11:12:19 +1 11:12:32 +1 11:12:57 +1 to the general idea, noting that it has no date 11:13:09 +1 to eric's remark 11:13:16 +1 (and OK with Dec 1 date) 11:13:24 +1 to betehess's validation 11:13:57 q? 11:14:03 ArnaudLH: let's have lunch, get back in 45 minutes 11:14:04 APPROVED: Issues raised against the UC&R document before XX/YY will be acknowledged or addressed in the first WD of the published document. 11:14:33 present+ Nandana_Mihindukulasooriya 11:14:49 present+ Raul_Garcia-Castro 11:19:02 yaso has joined #ldp 11:33:18 tidoust has joined #ldp 11:34:23 tidoust has left #ldp 11:36:08 chsiao has left #ldp 11:48:03 JohnArwe has joined #ldp 11:48:20 +JohnArwe 12:07:26 rgarcia has joined #ldp 12:08:00 cygri has joined #ldp 12:08:01 bblfish has joined #ldp 12:08:08 nmihindu has joined #ldp 12:08:37 ahaller2 has joined #ldp 12:09:01 SteveBattle has joined #ldp 12:09:23 SteveS has joined #ldp 12:09:40 Ruben has joined #ldp 12:09:59 oberger has joined #ldp 12:10:49 JohnArwe on the phone 12:10:59 q+ what about the restaurant tonite ? 12:11:04 hi JohnArwe 12:11:29 oberger, check the agenda :-) 12:11:49 cygri, doesn't tell where 12:11:55 I will have to drop in 2 hours. GMs are so inconsiderate of my existing schedule. 12:12:04 oberger, there's a time slot for discussing that. 12:12:21 davidwood has joined #ldp 12:12:46 cygri, yes, but if we have to make a reservation, the sooner, the better... that said, dunno 12:13:21 scribe: cygri 12:13:42 topic: LDP Specification 12:13:58 http://www.w3.org/2012/ldp/hg/ldp.html 12:13:59 ArnaudLH: We could simply go down the issue list in order. 12:14:07 roger has joined #ldp 12:14:13 ... To warm up, we could start with some perhaps less controversial issues. 12:14:22 svillata has joined #ldp 12:14:33 http://www.w3.org/2012/ldp/track/issues 12:14:38 http://www.w3.org/2012/ldp/track/issues/open 12:14:53 ... Anyone wants to suggest a particular issue for discussion? 12:14:54 could we talk about 24 today sometime? (not here tomorrow) 12:15:09 HadleyBeeman has joined #ldp 12:16:39 [reconciling order of discussion with presence of various participants] 12:16:48 closest to my interest: http://www.w3.org/2012/ldp/track/issues/20 12:16:54 23 open according to the server (just above table) 12:17:15 zakim, code? 12:17:15 the conference code is 53794 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), AndyS 12:17:31 i have interest in issue 26 - and will (unfortunately) not be here tommorrow .... 12:17:40 +??P0 12:17:42 jonathandray has joined #ldp 12:17:48 zakim, ??P0 is me 12:17:48 +AndyS; got it 12:17:50 q+ 12:18:05 q- 12:18:17 q+ 12:18:44 FabGandon has joined #ldp 12:19:04 Present+FabGandon 12:19:36 q? 12:21:08 ack bete 12:21:26 q+ to propose a resolution for ISSUEs 22 and 23 12:21:48 timbl has joined #ldp 12:22:12 let's vote on 22 ! 12:22:34 on discussing 22 12:22:51 subtopic: ISSUE-22 and ISSUE-23 (RDF/XML and JSON-LD) 12:22:56 +1 12:23:05 PROPOSED: Resolve ISSUEs 22 and 23 by stating that LDP servers MUST support Turtle and MAY/SHOULD support any other RDF serialization format that is a W3C Recommendation. 12:23:05 +1 12:23:12 http://www.w3.org/2012/ldp/track/issues/22 12:23:17 +1 12:23:19 +1 12:23:22 q+ 12:23:36 ArnaudLH: Turtle is a MUST, we have resolved that already 12:23:47 davidwood: It should be separated from the other formats 12:23:58 does these format *have* to support relative URIs in their serializations? 12:24:06 q+ 12:24:27 q+ to ask if these formats MUST support relative URIs in their serializations 12:24:32 ... Point is to have a consistent policy 12:24:40 ... MAY or SHOULD would be consistent 12:24:46 ack davidwood 12:24:46 davidwood, you wanted to propose a resolution for ISSUEs 22 and 23 12:24:48 +1 for SHOULD 12:24:57 ack david 12:25:00 1+ 12:25:02 q+ 12:25:15 Ntriples would not work because of ISSUE-20 12:25:24 because it does not have relative URIs 12:25:39 cygri: re: david's proposal, I preferr to just say that Turtle MUST be supported and say nothing about other formats 12:25:49 ISSUE 20 isn't resolved yet :) 12:26:03 ... otherwise we end up in conneg and different representations of the same resource 12:26:06 ack cygri 12:26:11 I have no strong objection to cygri's proposal. 12:26:13 jonathandray has joined #ldp 12:26:21 bblfish - strictly, nor does Turtle. It encodes a graph and a graph has resolved absolute URIs. 12:26:22 +1 for no other formats than Turtle 12:26:33 +1 for only Turtle 12:26:34 q+ to suggest "May top connect o other formats" 12:26:40 oberger: shouldn't we discuss conneg? 12:26:46 q+ to suggest "May top conneg o other formats" 12:26:47 ack bete 12:26:47 betehess, you wanted to ask if these formats MUST support relative URIs in their serializations 12:26:54 cygri: HTTP already talks about conneg 12:27:13 oberger: in an informative section, we could say "of course you can use conneg" 12:27:15 krp has joined #ldp 12:27:20 ack bblfish 12:27:22 betehess: davidwood's proposal doesn't work because of relative URIs 12:27:48 q+ 12:27:51 bblfish: N-Triples doesn't work because of ISSUE-20 12:28:12 davidwood: N-Triples is likely to be a W3C recommendation 12:28:41 q+ to say it would have to be a restricted form of Turtle, not all Turtle. 12:28:57 ack timbl 12:28:57 timbl, you wanted to suggest "May top connect o other formats" and to suggest "May top conneg o other formats" 12:29:01 q- 12:29:03 bblfish: N-Triples only allows absolute URIs. ISSUE-20 proposal is to use relative URIs so that servers can fill in the URI after POST 12:29:35 +1 timbl 12:29:47 timbl: "MAY do conneg" may be worth stating to make clear that it's okay to support things beside Turtle 12:30:23 ... You may have to specify that Turtle MUST be returned dependent on q value 12:30:37 ... q values are an issue in conneg 12:30:40 ack steveb 12:30:47 ack andy 12:30:47 AndyS, you wanted to say it would have to be a restricted form of Turtle, not all Turtle. 12:31:07 AndyS: Depending on ISSUE-20 resolution, we may have to qualify what we mean by Turtle 12:31:08 andy's remark is right 12:31:10 ack me 12:31:14 q+ to suggest "issue-20 may be easier solved by handling the use case a different way, simply have a resource which provides or redirects to a "new" free uri on each request, like an auto inc, then PUT to it" 12:31:17 q- 12:31:18 Ashok_Malhotra has joined #ldp 12:31:25 what was the common misreading of conneg timbl was talking about? rapid-file syllables didn't make it so well across the pond. 12:31:40 q+ 12:31:42 -Yves 12:32:05 ... One of the ISSUE-20 proposals is that POSTing creates a new resource; the container decides on URI of the new resource and fills in <> with the address of the new resource 12:32:28 q- 12:32:32 ArnaudLH: Let's not talk about opening the resolution that turtle MUST be supported. 12:32:50 All my serializers do relative URIs by default and in systems I build that is a fundamentally important thing. 12:33:12 there are other ways to address issue-20 that do not have the relative URI issue and hence any RDF serialization works. 12:33:28 cygri: yes 12:33:49 +1 to AndyS 12:33:59 PROPOSAL: MUST use Turtle; MAY do content negotiation with other formats 12:34:06 +1 12:34:13 +1 12:34:22 +1 12:34:23 +1 12:34:27 +1 12:34:27 +1 12:34:28 +1 12:34:28 +1 12:34:28 +1 12:34:30 +1 12:34:34 +1 12:34:34 +1 12:34:35 +1 to mentioning conneg somewhere in docs 12:34:35 +1 12:34:38 +1 12:34:39 +1 12:34:40 +1 s/suse/support 12:34:41 q+ 12:34:46 +1 12:35:29 ack steveb 12:35:43 SteveBattle: If you don't send an accept header on a GET, will you get Turtle? 12:35:44 q? 12:36:28 (JohnArwe, the failure is that tabulator for example a s ffox extension can handle turtle and html both fine. And so send the same q value for each. When people serve both HTML and Turtle, then they have to ideally -- send HTML off the HTML is the master and the turtle is a degraded, information lost congestion from the HTML -- if the other way around, like here, that the turtle -- the data -- is the master and the HTML is generated from it, you should return the 12:36:29 turtle, otherwise you lose the semantics.) 12:36:58 q+ 12:37:01 yaso has joined #ldp 12:37:29 PROPOSAL: Servers MUST support Turtle; servers MAY deliver other formats using standard HTTP content negotiation; If the client doesn't indicate a preference, Turtle MUST be returned 12:37:44 q+ 12:37:58 +1 12:37:59 +1 12:38:02 +1 12:38:05 +1 12:38:09 +1 12:38:09 +1 12:38:10 +1 12:38:17 +1 12:38:32 +1 12:38:39 +1 12:38:41 +1 12:38:43 +1 12:38:47 +1 12:38:48 +1 12:38:49 +1 12:38:57 +1 12:39:03 +1 12:39:22 +1 but I believe that we must take into account the case the weights are equal (MUST return Turlte) 12:39:34 ericP: HTTP only says how to specify a header and how a server indicates its format choice; doesn't specify how the server makes the choice. Why should we change this? 12:39:38 betehess, I think the resolution is clear about that, as "no preference" 12:40:12 [scribe can't follow] 12:40:13 betehess, the proposal does handle that case because the client has not expressed a preference in that case. 12:40:14 sandro, I think it's cheap to speak about a "default" 12:40:35 ArnaudLH, is that RESOLVED, in your chair judgement? 12:40:44 davidwood, maybe a English issue on my side, but I disagree 12:41:02 RESOLVED: Servers MUST support Turtle; servers MAY deliver other formats using standard HTTP content negotiation; If the client doesn't indicate a preference, Turtle MUST be returned 12:41:15 close issue-22 12:41:15 Sorry... closing ISSUE-22 failed, please let sysreq know about it 12:41:22 ArnaudLH: Accordingly, we can close ISSUE-22 and ISSUE-23 12:42:35 guest: JohnArwe 12:42:41 q+ 12:42:45 q- 12:42:45 q- 12:42:47 guest: webr3 12:42:52 q? 12:42:59 http://www.w3.org/2012/ldp/track/issues/24 12:42:59 guest: FabGandon 12:43:05 guest: timbl 12:43:12 q+ to remind the WG on PURL's DELETE behavior 12:43:28 subtopic: ISSUE-24 12:43:38 ack ruben 12:43:43 q+ 12:43:45 ack david 12:43:45 davidwood, you wanted to remind the WG on PURL's DELETE behavior 12:43:45 +1 to not saying anything about re-use 12:44:06 davidwood: There are legitimate reasons why a server may not re-use a URL. 12:44:14 ... Example, pURLs. 12:44:31 ... I strongly recommend we close this issue by stating that servers decide. 12:44:38 q+ 12:44:58 q+ to offer dev perspective 12:45:08 q+ 12:45:09 ... I have a minor preference for including a sentence that states it's up to the server whether deleted URIs can be recycled. 12:45:15 ack steves 12:45:16 q+ 12:45:38 ack steves 12:45:40 SteveS: Agree, it's application-specific. I also agree it's not a best practice. 12:45:43 ack ashok 12:46:05 my main issue was the phrasing, which currently is "until another resource is created", as "another" seems to suggest that it can't be the same 12:46:10 Ashok_Malhotra: Reading 4.5.1 in the spec, it reads like you cannot re-use a URI 12:46:17 q+ to say that is a URI has been automatically allocated by the server then it should NEVER EVER be re-used after having been deleted, to avoid people following an old link to new bad data. 12:46:27 davidwood: [quotes offending spec text] 12:46:35 q+ to wonder about implications on containers and adding entries 12:46:52 ... When you create a resource in a container, the server assigns a URI. Server may decide to re-use an existing URI. 12:46:57 I agree with timbl that non-reuse should be that way to go… or we should at least suggest it 12:47:14 q- 12:47:17 q? 12:47:41 timbl: If a resource was deleted, it's URI should never ever be re-used. 12:47:54 q+ to disagree with Tim. 12:48:05 ack bete 12:48:05 betehess, you wanted to offer dev perspective 12:48:06 test -- what about re-PUTing the same content as before? 12:48:25 vulnerable to the lost-DELETE variant of the lost-UPDATE problem 12:48:25 q+ to discuss whether this is linked to issue 25 12:48:57 ack steveb 12:49:02 side-remark: can be reused for the same resource? (e.g., not 410) 12:49:07 party A GETs R1; party B DELETEs R1; party A PUTs R1. 12:49:17 SteveBattle: I agree we should delete 4.5.1 phrasing “until another resource is created” 12:49:21 (not a real issue if you are tracking ETags well) 12:49:30 when people say "application", is it server-side or client-side? 12:49:32 ack timbl 12:49:32 ... There may be valid reasons for restoring a deleted resource 12:49:32 timbl, you wanted to say that is a URI has been automatically allocated by the server then it should NEVER EVER be re-used after having been deleted, to avoid people following an 12:49:33 ericP: indeed, that should be possible for the *same* resource 12:49:35 ... old link to new bad data. 12:49:47 ack andy 12:49:47 AndyS, you wanted to wonder about implications on containers and adding entries 12:50:08 q+ 12:50:40 ack david 12:50:40 davidwood, you wanted to disagree with Tim. 12:50:44 q- 12:51:23 tpacbot has joined #ldp 12:51:25 timbl: [clarifies that *server*-assigned URIs should never be re-used after deleting] 12:51:33 Some resources e.g. "todays weather" can be reasonably deleted and then PUT. 12:51:36 q+ to say 4.5 HTTP DELETE should say something about If-Match ETags, and to +1 @ericP's suggestion to replace "until another resource is created or associated with the same Request-URI." with "The service SHOULD NOT permit the creation of a different resource with the same Request-URI." 12:51:37 I believe that timbl is restricting his definition to the case we POST to a Container, right? 12:51:59 agree with AndyS that corner cases ( such as undelete ) should be explained as a best practice 12:52:05 davidwood: I suggested earlier that clients should be able to request a certain URI 12:52:12 is there a way to stop clients from not reusing for different resoruces, in case POST is not used? 12:52:20 s/resoruces/resources/ 12:52:33 ... If the server needs to track what resources were allocated and deleted, this makes it harder to create a minimal compliant server 12:52:40 q+ 12:52:43 agree about server assigned URIs ... but rePUT the original content (it's called "restore" :-) or a correction. 12:52:59 q+ to say that recreating the *same* resource is not a problem 12:53:00 ivan has joined #ldp 12:53:11 ... Seen in the wild: create a resource, delete it, create it again; because deleting causes housekeeping in the server 12:53:30 ack cygri 12:53:35 +1 davidwood allow clients to DELETE and PUT again 12:53:45 cygri: we're defining a protocol between a client and a server 12:54:23 ... it's important to specify client expectations but not [other] server behavior 12:54:29 q+ 12:54:45 ... i see this as a best practice about server behavior 12:54:48 cygri: I agree with Tim that servers should not generate the same URI twice, but I don't think that's part of the protocol 12:54:49 +1 to ruben : *same* resource / *different* resource is the key point. Can't mandate in the protocol about such "sameness". Having advice in docs is *very* helpful. 12:54:59 as an implementor, I'd like to know the expected behaviour 12:55:09 timbl: I request a new URI, I want it to be never used before. That's part of the protocol 12:55:11 nathan? on the phone? 12:55:15 q- 12:55:17 webr3? 12:55:17 no phone 12:55:27 q? 12:55:33 s|webr3?|| 12:55:36 ack ruben 12:55:36 Ruben, you wanted to say that recreating the *same* resource is not a problem 12:55:41 s|no phone|| 12:55:42 timbl: I want part of the protocol to be that servers will generate new unique URIs each time 12:55:49 s|nathan? on the phone?|| 12:55:51 timbl: i disagree that this isn't in the protocol [i.e. client expecation] 12:55:58 q? 12:55:59 Ruben: There's a difference between using re-using a URI for the same resource, and using same URI for a different one 12:56:11 ack bblfish 12:56:20 @webr3, same #s we use for weekly calls 12:56:24 q+ to say this IS a portico issue: when the client adds a new resource and server end an id, it is a valuable property of the protocol that the client knows that URI will never be issued to her or anyone else, even if she gives it back. 12:56:28 q- 12:56:32 s|@webr3, same #s we use for weekly calls|| 12:56:40 develD has joined #ldp 12:56:43 bblfish: The container part of the spec should say that POST gives you a new URI. If it's not fresh, it's not a new one. 12:56:59 s/portico/protocol/ 12:57:12 q+ to say that webr appears had proposed text 12:57:17 +q to say I'm against just removing 12:57:19 q+ 12:57:45 ericP: [reads earlier webr3 comment] 12:57:46 +1 to Ruben. Removing the text is not sufficient. 12:58:03 PROPOSAL: delete "until another resource is created or associated with the same Request-URI." 12:58:26 -1 for just deleting, need to clarify what is possible 12:58:43 -1 agreed; I want a change proposal, not just to remove it 12:58:48 -1 to just removing 12:58:54 *wonders if this issue goes back to the old discussion about whether a URI refers to one and only one thing. 12:59:11 HadleyBeeman, yes. 12:59:16 q? 12:59:17 The server MUST never reallocate the same server-allocated URI twice. The client should nor use the same client-generated URI to refer to different things. 12:59:28 s/nor/not 12:59:37 ack me 12:59:38 do we need a "compare" primitive in the servers to be able to determine resource "sameness" ? 12:59:38 ericP, you wanted to say that webr appears had proposed text 12:59:40 Thanks, davidwood. Pieces falling together :) 12:59:48 in my experience, there is a very limited number of cases for using DELETE. once something exists, i think it is good to know later on that it did once exist 12:59:54 [scribe fail] 13:00:02 not that it changes the issue ... 13:00:26 ack eric 13:00:29 q+ 13:00:33 ack ruben 13:00:33 Ruben, you wanted to say I'm against just removing 13:00:49 q+ 13:00:52 q+ to say you can't PUT a resource 13:01:20 +1 cygri, you can't delete a resource 13:01:22 q- 13:01:22 ack antonis 13:01:27 q+ 13:01:32 q+ 13:01:55 antonis: Two separate cases. 1. Remove a resoruce from a container, forever. 2. We want to change a resource, e.g., weather 13:02:21 how could you know you'll never want to put a resource back into a container? 13:02:26 q+ 13:02:31 q? 13:02:37 ack steves 13:02:41 " a resource R is a temporally varying membership function MR(t), which for time t maps to a set of entities, or values, which are equivalent." 13:02:41 I'd be for voting on deleting. It's easier 13:03:01 "Some resources are static in the sense that, when examined at any time after their creation, they always correspond to the same value set. Others have a high degree of variance in their value over time. The only thing that is required to be static for a resource is the semantics of the mapping, since the semantics is what distinguishes one resource from another." 13:03:21 q? 13:03:30 +1 ruben 13:03:32 but how can you delete a methematical object? 13:03:39 ack sandro 13:03:51 timbl made a proposal that may have become lost. "The server MUST never reallocate the same server-allocated URI twice. The client SHOULD NOT use the same client-generated URI to refer to different things." 13:03:59 bblfish: you can delete it from a server 13:04:40 sandro: You delete a file in the file system, you can create a new one with the same name. Anything else would be absurd 13:04:48 yes, but the resource is the thing pointed by the URI. 13:05:01 oberger: A directory is a container. It's happening in the container. 13:05:08 q+ 13:05:12 ack cygri 13:05:13 cygri, you wanted to say you can't PUT a resource 13:05:14 sandro: Deleting in file system is same as HTTP delete 13:05:26 cygri: maybe we shouldn't be talking about identity of resource 13:05:31 ... rather what happens to the container 13:05:45 ... was URI assigned to the server? 13:05:50 cygri: we SHOULDn't be talking about DELETing a resource but instead POSTing to a container 13:05:50 oberger, I'm not thinking about containers here. 13:05:51 cygri: one should not talk about what one should do when one deletes a resource, but what should be done when one POSTs to a container 13:05:54 +1 13:05:57 +1 13:06:08 +1 13:06:08 ... what's the constraint on the server? 13:06:12 +1 13:06:12 verbs CREATE and ADD TO CONTAINER should really be distinguished 13:06:13 ... timbl asked about the constraint on the server and the server assigns the URI 13:06:20 q? 13:06:24 q? 13:06:31 The constraint is to not generate the same URI twice 13:06:31 ... that's the place were we can state more clearly what happens with these URIs 13:06:33 ack nmihindu 13:06:49 nmihindu: Putting in the spec that it must be the same entity/resource is practically infeasible. 13:06:50 q+ 13:06:55 Trying to establish a basic model if resource URI used to get, update, then if deleted, you would not expect to update a resource that does not exist. Semantics may be that put can be used to create resources of a known name, which is not update in my mind 13:06:55 ack bete 13:06:57 q? 13:07:25 …unless it's a 410, then you know it existed at some time 13:07:33 betehess: I would expect the invariant from the server that after I GET and get a 404, I can do a PUT and create the resource. 13:07:44 ... We don't know if the resource existed before or not. 13:07:56 ack bblfish 13:08:00 yaso has joined #ldp 13:08:30 bblfish: If you do a DELETE and the client gets a 404, shouldn't clients put this in an index of things they never should request again? 13:08:33 404 doesn't imply permanency… can be 404 before a resource was created 13:08:43 q+ security and debug considerations 13:08:48 bblfish is getting into the contentious space of negative directory caching 13:08:53 develD has joined #ldp 13:08:55 q+ 13:09:01 BartvanLeeuwen: Isn't there another code for that? 13:09:04 ericP: 410 13:09:05 ack antonis 13:09:09 (which was a bane of AFS) 13:09:24 http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.htmlhttp://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html 13:09:39 "10.4.11 410 Gone 13:09:39 The requested resource is no longer available at the server and no forwarding address is known. This condition is expected to be considered permanent." 13:09:40 the 404 can include a reason 13:09:44 antonis: There are two different modes for deletion. Sometimes there's scientific data that is invalid, we want to really delete it. 404 is not strong enough. 13:09:49 q+ 13:09:50 ack ahaller 13:09:53 yes, thanks. for the 410 13:10:13 zakim, who is on the call? 13:10:13 On the phone I see St_Clair_3B, JohnArwe, AndyS 13:10:13 410 looks like a difficult constraint to impose in the general case 13:10:33 probably good practice 13:11:42 q+ suggesting we should we discuss creation and ownership by containers 13:11:45 bad practice has a cost 13:12:04 q? 13:12:18 q+, suggesting we should we discuss creation and ownership by containers 13:12:24 wth 13:12:25 q+ 13:12:30 *oberger, say q+ to blabla* 13:12:41 *the "to" is important* 13:12:53 s|wth|| 13:13:02 s|q+, suggesting we should we discuss creation and ownership by containers|| 13:13:05 ahaller2: Example: server uses hash function to generate URI. Can't guarantee that you get a clash 13:13:06 s|q+ suggesting we should we discuss creation and ownership by containers|| 13:13:15 timbl: That server will be statistically conforming 13:13:16 ack john 13:13:59 JohnArwe: Whether today's weather can be deleted depends on the concept on the server. 13:14:04 q+ to suggest PROPOSED: Close issue-24, saying "No", after a resource is deleted it might come back, in some circumstances. If the URI was created by a client PUT, then it's reasonable for a client to DELETE it, then PUT again to re-create it. 13:14:32 ... In loosely coupled environment, 410 is useful 13:15:01 (cygri, yes the server operator of one which generates large random numbers can afford to buy everyone a round of drinks if they collide. But it is very easy to keep a little .nextid file in the directory and use it to track the next id to allocate.) 13:15:33 sandro: remember the title was a bit of a misnomer, the actual question is whether, after deletion, we should suggest to reuse the same URI for a different resource 13:15:48 thanks 13:15:52 ack cygri 13:16:14 q+ to say that sandro's discovery has pushed me to amend web3r's text 13:17:10 cygri: we seem to mostly agree that if a client doesn't know the server's DELETE policy, and the server returns a 404 or 410, the file MIGHT come back 13:17:13 LeeF has joined #ldp 13:17:22 ... the filesystem analogy is compelling to me 13:17:39 ... i agree that server-assigned IDs should only be assigned once 13:17:45 q? 13:17:59 cygri: I see that server-assigned IDs should not be re-assigned. that's likely to cause problems. let's address that in POST-to-Container text 13:18:03 ... POST->ID/1 ; POST->ID/1 will of course create problems 13:18:12 ... that's two issues to resolve 13:18:16 betehess: this is not REST, but Cool URIs 13:18:17 yaso has joined #ldp 13:18:27 q? 13:18:39 ... third issue: different expecations if the server returns a 404 or a 410 13:18:48 q? 13:19:12 ... the HTTP spec says that 410 is permanent, but doesn't say if the client is not supposed to do a PUT 13:19:22 ack ober 13:19:23 +[IPcaller] 13:19:25 roger has joined #ldp 13:19:54 oberger: If we haven't properly discussed creation, then we can't properly discuss deletion. We should discuss ISSUE-25 first. 13:20:01 q? 13:20:09 ack next 13:20:10 sandro, you wanted to suggest PROPOSED: Close issue-24, saying "No", after a resource is deleted it might come back, in some circumstances. If the URI was created by a client 13:20:10 ... PUT, then it's reasonable for a client to DELETE it, then PUT again to re-create it. 13:20:18 q? 13:20:46 -1 to say that much 13:21:02 we would overstep on the http spec 13:21:14 q? 13:21:23 - until another resource is created or associated with the same Request-URI. 13:21:23 + . The service SHOULD NOT permit the creation of a different resource with the same Request-URI. 13:21:26 + Note that HTTP considers any DELETEd resource for which the server returns a 410 Gone to be permanently removed. 13:21:29 + A server SHOULD (@@MUST?) NOT permit either a later PUT to a POST to re-create such a resource. 13:21:33 q+ 13:22:02 -AndyS 13:22:37 q? 13:22:42 q+ 13:22:44 + . The service SHOULD NOT create (as a response to a POST) of a different resource with the same Request-URI. 13:22:44 ack eric 13:22:44 ericP, you wanted to say that sandro's discovery has pushed me to amend web3r's text 13:22:49 + . The service SHOULD NOT create (as a response to a POST) a different resource with the same Request-URI. 13:23:13 You can't say "a different resource" 13:23:21 thinkiing: PROPOSED: Close issue-24, saying "No", after a resource is deleted it might come back, in some circumstances. For example, If the URI was allocated by a client PUT, then it's reasonable for a client to do a DELETE on that URI, then PUT again with the same URI to re-allocated it. 13:23:27 q+ 13:23:39 q- 13:23:39 + . The service SHOULD NOT create (as a response to a POST to the Request-URI's container) a different resource with the same Request-URI. 13:23:55 q+ 13:24:08 q- 13:24:14 The server should never allocate the same URI twice in response to a POST to a container. 13:24:25 thinkiing: PROPOSED: Close issue-24 (Should DELETED resources remain deleted?) saying "Not Necessaril", after a resource is deleted it might come back, in some circumstances. For example, If the URI was allocated by a client PUT, then it's reasonable for a client to do a DELETE on that URI, then PUT again with the same URI to re-allocated it. 13:24:29 jonathandray has joined #ldp 13:25:02 scribenick: ericP 13:25:09 q+ 13:25:14 seconded 13:25:43 q? 13:25:46 oberger: do we have a use case to refer to? 13:26:03 cygri: i think we all know the filesystem use case 13:26:09 q? 13:26:33 betehess: we have no authority over HTTP 13:26:42 oberger has joined #ldp 13:26:56 sandro: and you know that 404 isn't permanent in HTTP world, right? 13:26:56 ack bete 13:27:08 MacTed has joined #ldp 13:27:22 Yves, are you an HTTP expert? 13:27:31 betehess: we don't have people can tell us how HTTP is used out there 13:28:01 timbl: i perfer to treat 404 and 410 just the same 13:28:03 ack bete 13:28:22 PROPOSED: Close issue-24 (Should DELETED resources remain deleted?) saying "Not Necessaril", after a resource is deleted it might come back, in some circumstances. For example, If the URI was allocated by a client PUT, then it's reasonable for a client to do a DELETE on that URI, then PUT again with the same URI to re-allocated it. 13:28:24 ack sandro 13:28:36 sandro: i'd like to be done with issue 24 and record the fact that we all seem to agree 13:28:43 +1 13:28:58 +1 13:29:01 +1 13:29:02 +1 13:29:03 +1 13:29:05 +1 13:29:06 +1 13:29:07 +1 13:29:07 +1 13:29:08 +1 13:29:09 +1 13:29:09 +1 13:29:10 q? 13:29:11 +1 13:29:13 q+ 13:29:14 +1 13:29:14 s/Necessaril/necessarily/ 13:29:23 +1 13:29:24 +1 13:29:25 +1 13:29:40 cygri: i agree, but don't think our spec contains examples of what's already constrained by the HTTP spec 13:30:09 ack cygri 13:30:13 ... if it doesn't further constrain the HTTP spec, we shouldn't include it 13:30:23 would this is normative or informative? 13:30:30 s/this is/this be/ 13:31:06 cygri: per this resolution, the spec can remain the same 13:31:36 RESOLVED: Close issue-24 (Should DELETED resources remain deleted?) saying "Not Necessarily", after a resource is deleted it might come back, in some circumstances. For example, If the URI was allocated by a client PUT, then it's reasonable for a client to do a DELETE on that URI, then PUT again with the same URI to re-allocated it. 13:31:39 remove "until another resource is created or associated with the same Request-URI." replace with something else 13:31:40 The words "another" and "created" in combination imply something that isn't intende 13:31:59 s/until another resource is created or associated with the same Request-URI/until the state of the resource is changed again/ 13:32:09 q+ 13:32:15 q- 13:32:23 ack cygri 13:32:34 +q 13:32:43 q+ 13:32:55 cygri: PROPOSED: s/until another resource is created or associated with the same Request-URI/until the state of the resource is changed again/ 13:33:05 +1 on cygri's proposal 13:33:08 -1 13:33:16 bblfish: we can include text which describes some of the problems 13:33:34 ... there are all kinds of consequences about changing a 410 13:33:47 propose: s/until another resource is created or associated with the same Request-URI// then have informative text about 404+410 and not cha 13:33:57 .. changing the uri's usage 13:34:04 q- 13:34:15 ack rgarcia 13:34:16 ... e.g. if you check the logs and no one's gotten a 410, then no one knows it's gone 13:34:48 q+ to propose better use cases 13:34:54 SteveS, I propose removing the phrase and adding a sentence, "Clients should note that severs may reuse a Request-URI under some circumstances." 13:34:56 rgarcia: this should be part of the HTTP guide where we say the behavior of this HTTP verb is X 13:34:56 ack oberger 13:34:56 oberger, you wanted to propose better use cases 13:35:02 oberger: we need use cases 13:35:16 ... we have different interpretations of HTTP DELETE 13:35:29 q+ 13:35:49 +OpenLink_Software 13:35:56 Zakim, OpenLink_Software is temporarily me 13:35:56 +MacTed; got it 13:35:58 Zakim, mute me 13:35:58 MacTed should now be muted 13:35:59 q+ to talk about use cases being a sometimes-necessary expense 13:36:00 ack cygri 13:36:28 +1 cygri -- what HTTP spec says about DELETE is enough 13:36:28 cygri: i'm not convinced we need to go beyond the HTTP spec for DELETE 13:36:31 why am I hoping that this issue is already fully solved in HTTP spec? maybe in Fielding's thesis? 13:36:39 q+ 13:36:58 betehess: not in F's thesis 13:36:58 ... we are bound by HTTP, and we can add specific behavior that distinguishes an LDP server 13:37:04 Agree, you should only add constraints to the HTTP spec where you really need to for a special LDP-specific reason. 13:37:06 +1 cygri (from observer) 13:37:11 can somebody say for me (no mic): '''can the resolution just be to remove the text "until another resource is created or associated with the same Request-URI" and close the issue, then later if more text is needed write it''' 13:37:26 Can we put this issue to bed - pleeeeaaase? 13:37:31 +1 cygri 13:37:36 no webr3 some of us -1'd that 13:37:39 ... i haven't heard us proposing a stronger behavior than HTTP's DELETE 13:37:54 davidwood: doesn't 4.5.2 extend HTTP's DELETE? 13:38:08 *betehess, the text is online, too. I've read it, and it's not there* 13:38:21 q+ 13:38:22 cygri: it's a MAY and only talks about how it applies to our resources 13:38:59 q? 13:39:25 ... the resource to which we send the DELETE is a web resource which might have an associated RDF resource 13:39:53 q- 13:39:58 ArnaudLH: there's no reason for the text apart from stating what HTTP mandates 13:40:06 q? 13:40:10 q+ 13:40:15 ... we can remove the offending text or just defer to HTTP 13:40:29 +q 13:40:46 ack sandro 13:40:46 sandro, you wanted to talk about use cases being a sometimes-necessary expense 13:40:47 we just say that the server SHOULD "support" DELETE ? 13:40:48 is there a perceived problem with 4.5.2, or in how we relate it to http? atompub modifies other resources after a DELETE (e.g. deleting Media Link deletes Media Resource) 13:40:48 q+ to answer Arnaud's question 13:40:50 There is no "Web resource" or "RDF resource". There is only a "resource" associated with a URI. 13:41:03 ... we agree to do what HTTP says, but don't know how to state it 13:41:11 ack ashok 13:41:58 sandro: if someone expects a different behavior than HTTP, than we need to motivate that with a use case (which is an expensive process) 13:42:14 q+ to say as an editor, why not use the experience from other specs, and simply make it clear through some convention in the document when we are (informatively) summarizing implications from other specs like HTTP vs when we are imposing additional normative requirements of our own? 13:42:17 ack bblfish 13:42:29 q+ 13:42:38 Ashok_Malhotra: we could split removing "until another resource is created or associated with the same Request-URI" and the other text 13:42:44 *betehess: true, he deserved that* 13:42:53 +1 davidwood `There is no "Web resource" or "RDF resource". There is only a "resource" associated with a URI.` 13:42:56 sandro: some of us -1'd simply removing the text 13:43:06 ack ruben 13:43:06 Ruben, you wanted to answer Arnaud's question 13:43:11 MacTed, literals are RDF resources but not web resources 13:43:19 nonsense. 13:43:22 Ruben: removing is fine for me 13:43:28 ... the phrasing is fine 13:43:31 ack john 13:43:31 JohnArwe, you wanted to say as an editor, why not use the experience from other specs, and simply make it clear through some convention in the document when we are (informatively) 13:43:35 ... summarizing implications from other specs like HTTP vs when we are imposing additional normative requirements of our own? 13:43:52 sandro, out of scope of the current discussion at least 13:44:10 s/the phrasing is fine/it was just the phrasing that could be confusing/ 13:44:16 anything nameable and transmissible over the wire may be considered a web resource. literals are nameable and transmissible over the wire. 13:44:26 q? 13:44:26 JohnArwe: i worked on other specs and the convention for imposing normative requirements in addition to the base specs 13:44:37 ack timbl 13:45:00 timbl: i thought that "until another resource is created or associated with the same Request-URI" was gone by mow 13:45:36 ... if you put something in a collection, the collection gives you the list that includes that new element 13:45:50 s/mow/now/ 13:46:03 even if just a hyperlink to the container section 13:46:15 MacTed, refinement: REST resource != RDF resource 13:46:28 ... is it worth saying that DELETing a resource removes it from the container? 13:46:46 ... or is that clear to any spec reader? 13:47:02 As editor I might remove the last words and add something like: "Whether a resource is exposed again at the same URI, is implementation specific, this can happen based on HTTP PUTs that don't have server-assigned URIs" 13:47:06 [general agreement that it's the latter] 13:47:53 SteveS, I propose removing the phrase and adding a sentence, "Clients should note that severs may reuse a Request-URI under some circumstances." 13:48:21 +1 davidwood 13:48:28 request-Uri -> resource URI ? 13:48:40 +1 david's wording to replace the grey sentence 13:48:53 +1 13:48:59 cygri - I would like to see your definitions of each of those. I don't think I agree, but I'm not clear enough on what you mean to express my disagreement. 13:49:08 davidwood, request-Uri -> resource URI ? 13:49:28 MacTed, RDF resource as defined in RDF 1.1 concepts. REST resource as defined in Fielding's thesis. 13:49:48 can we not mention PUT or POST either at this point ? 13:50:10 PROPOSAL: Close Issue-24 with the following" Delete the phrase in 4.5.1 that nsays "until ...Request URI" and adding a sentence, "Clients should note that severs may reuse a Request-URI under some circumstances." 13:50:22 +1 13:50:22 +1 13:50:24 +1 13:50:26 +1 13:50:28 +1 13:50:29 +1 13:50:29 +1 13:50:30 +1 13:50:31 +1 13:50:31 +1 13:50:33 +1 13:50:34 +1 13:50:35 +1 13:50:36 +1 13:50:39 +1 13:50:42 -0 (the use of may kind of enourages bad form - sorry) 13:50:43 +1 13:50:43 there was a suggestion to change that to 'resource URI' 13:50:45 +1 13:50:50 Note that it shouldn't be "request URI" as per oberger 13:51:02 -0 I think it's ok. But it is too vague 13:51:06 +1 13:51:07 cygri - I'd like specific links and/or quotation. those kinds of handwaves don't serve anyone well. 13:51:24 q+ to ask if impact on 5.6.2 : 13:51:30 so I think the second sentence should go in non normative text 13:51:36 cygri - you seem to be suggesting that RDF resources and REST resources are disjoint, and I firmly disagree with that. 13:51:53 MacTed, I said "not equal" 13:52:06 MacTed: what about hash HTTP URIs then? 13:52:22 a URI is a URI is a URI 13:52:36 the handling of hash HTTP URIs is a client-side concern 13:53:17 RESOLVED: Close Issue-24 with the following" Delete the phrase in 4.5.1 that nsays "until ...Request URI" and adding a sentence, "Clients should note that severs may reuse a Request-URI under some circumstances." 13:53:31 ack oberger 13:53:31 oberger, you wanted to ask if impact on 5.6.2 : 13:53:52 ArnaudLH: imo, there's no impact on 5.6.2 13:54:04 ack oberger 13:54:21 suggets issue-6 13:54:37 ISSUE-6? 13:54:37 ISSUE-6 -- Should LDBP say that any kind of user-defined simple data type is disallowed? -- open 13:54:37 http://www.w3.org/2012/ldp/track/issues/6 13:56:23 q+ 13:56:53 q+ 13:57:01 SteveS: the current text says that user-defined simple datatypes are not allowed 13:57:11 q+ to mention that I'm already using new data types 13:57:21 Topic: ISSUE-6 -- Should LDBP say that any kind of user-defined simple data type is disallowed? 13:57:26 ... this is meant to coallesce on a growing set of (currently XSD) datatypes 13:57:29 *for tpacbot* 13:57:37 ... feedback is that it is too restrictive 13:57:37 ack ashok 13:57:45 ... proposal is to relax to SHOULD 13:58:04 spec says "LDPR representations must use only the following standard datatypes ..." set of only 9 types - this adds constraints to turtle and makes loads of rdf unusable with LDP - i personally have a big issue with that 13:58:04 Ashok_Malhotra: heard from folks saying "i'm using this special datatype" 13:58:07 q+ to ask whether the server could simply advertise if it has datatype restrictions. 13:58:22 ... how are people going to reference a user-defined datatype with a URI? 13:58:47 q+ 13:58:49 ... there's a doc by jjc telling you how to reference a user-defined datatype using a URI? 13:59:16 ack cygri 13:59:35 s/using a URI\?/using a URI/ 13:59:50 cygri: custom datatypes aren't often used in RDF 13:59:56 must drop for other calls 14:00:01 -JohnArwe 14:00:15 ... it's not very clear how to find the definition; what should be at the end of the datatype URI? 14:00:34 ... jjc's doc talks about how to restrict factets 14:00:51 q+ timblPointOfOrder on whether to do 20 because of relative URIs 14:01:21 ... if you sort on frequency of datatypes, you see XSD types, misspellings of XSD types, custom types 14:01:51 can somebody point out that the spec says: "LDPR representations MUST use **ONLY** the following standard datatypes." (xsd boolean,date,dateTime,decimal,double,float,integer,string + rdf:XMLLiteral) - that misses loads of very common xsd types, and rdf literal +html literal types etc - this is more of an issue than the non custom datatypes 14:01:53 q+ 14:02:03 ... if you use SPARQL doesn't recognize "330"^^xsd:feet as an integer 14:02:19 +1 to cygri 14:02:21 Use interpretaion properties not [ value 2; unit kg] form. 14:02:30 ... i don't think there's a large group who will be impacted by the MUST or SHOULD 14:02:33 Use [ is kg of 2 ] 14:02:43 q+ to ask how we increase interop 14:02:44 q+ 14:02:51 ack bete 14:02:51 betehess, you wanted to mention that I'm already using new data types 14:02:51 RRSAgent, pointer? 14:02:51 See http://www.w3.org/2012/11/01-ldp-irc#T14-02-51-2 14:03:13 betehess: i disagree that people don't use custom datatypes [2 negatives] 14:03:18 ... i use them a lot 14:03:24 MacTed has joined #ldp 14:03:27 cygri: you're in a tiny minority 14:03:49 betehess: people wnat to be able to say what something means in the domain application 14:04:11 ... i have types in e.g. java or scala and i want to restrict the permissible values for a string 14:04:12 I've also used custom datatypes 14:04:24 ... i'm not concearned about SPARQL in my app 14:04:31 ack david 14:04:31 davidwood, you wanted to ask whether the server could simply advertise if it has datatype restrictions. 14:04:38 q+ 14:04:42 ... i didn't know about this issue 'cause it seemed intrinsic to RDF 14:04:58 davidwood: i was surprised when i saw this in the spec 14:05:00 present+ MacTed 14:05:14 ... thinking through it, i can see why you'd want to do that in your compliant server 14:05:24 ... i don't think i'd want to do it in mine 14:05:55 ... if we can agree on this, we can say "if the server restricts datatypes, it SHOULD advertise those datatypes", e.g. by header, container attrs 14:05:59 a? 14:06:05 ack timbl 14:06:07 the issue is greater.. xsd hexBinary, long, int, short, unsignedlong etc are all made illegal by the spec 14:06:09 bhyland1 has joined #ldp 14:06:12 q+ to ask if this is still needed given that we're no longer discussing Basic Profile (vs Advanced Profiles) 14:06:13 that's interesting because in any case there will be all kinds of types of restrictions 14:06:30 timbl: i think you want to give a name to a system which uses a constrained set of datatypes 14:07:16 ... if i'm getting data from some hardware, the value lies in that datatype being transparent 14:07:37 ... if you're going to put datatypes in, it's nice to put it in with another arc 14:07:49 then please fix the datatype mess in RDF first 14:08:02 q+ 14:08:11 RRSAgent, pointer? 14:08:11 See http://www.w3.org/2012/11/01-ldp-irc#T14-08-11 14:08:22 +1 to timbl 14:08:38 q- 14:08:48 my proposal: don't say anything, it's just RDF! 14:08:51 ack timblPointOfOrder 14:08:51 timblPointOfOrder, you wanted to comment on whether to do 20 because of relative URIs 14:08:52 ack timbl 14:08:57 OWL2 lets you define your own datatypes - so they're not broken. 14:09:05 timbl: i'm excited to talk about relative URLs today 14:09:09 ISSUE-20? 14:09:09 ISSUE-20 -- Identifying and naming POSTed resources -- open 14:09:09 http://www.w3.org/2012/ldp/track/issues/20 14:09:12 an existing minority, tiny though it may be, using custom data types makes "MUST only use these data types" absolutely unacceptable to me here. 14:09:12 "SHOULD" could possibly be argued, in support of greater overall interoperability. 14:09:12 I generally like davidwood's suggested direction 14:09:29 ack ahaller 14:09:46 ack eric 14:09:46 ericP, you wanted to ask how we increase interop 14:10:00 ahaller: all ontologies i know solve with units of measure patterns 14:10:05 zakim, who is on the call? 14:10:05 On the phone I see St_Clair_3B, [IPcaller], MacTed (muted) 14:10:13 q? 14:10:57 ack bblfish 14:11:19 Striking it (4.1.9) out completely gets my vote 14:11:40 ericP: in my domain, we use more custom datatypes than most, and for stuff where the SPARQL computability isn't an issue, but i don't think we'd mind a SHOULD which we violated 14:11:48 q+ 14:12:39 bblfish: there's an assymetric pressure to use standard datatypes 14:12:42 ack antonis 14:12:53 ... [hexbinary example] 14:13:08 plust I need hexBinary, which is not on the list 14:13:33 ack bete 14:13:38 antonis: we could say that clients SHOULD NOT use custom datatypes, but if they do, they should be described per davidwood's proposal 14:13:42 JohnArwe has joined #ldp 14:14:02 ? 14:14:06 q? 14:14:07 betehess: i feel like this is like in the last conversation where we were restricting HTTP 14:14:09 q+ 14:14:21 ... why not restrict vocabularies, ...? 14:14:44 ... i'm not totally motivated by the current deployment 14:15:01 my point was the following: there is no need to put restrictions on datatypes, that will come from usage 14:15:04 ... i don't think that application manufacturers will get it right 14:15:21 ack cygri 14:15:25 q+ 14:15:30 agree w/ bblfish 14:15:32 q+ 14:15:42 I want to state that I was cut when wanted to discuss the "wrong reasons" 14:15:55 cygri: i think a good reason for restrictions is that there's value in mapping data from an LDP server into application data structures 14:16:10 antonis' proposal seems to be backward from mine. I suggest that servers that restrict must advertise the restriction. Antonis suggests that servers that do *not* restrict must advertise. 14:16:10 ... XSD types map naturally to language-native datatypes 14:16:17 ... others become complex objects 14:16:50 ... not that we must always do what JSON does, but one thing makes JSON easy is that you only get native datatypes 14:16:53 PRPOSAL1: Rewrite the first sentence in 4.1.9 to "It is recommended that LDPR repsenetations use the follwing datatypes" 14:16:54 ack bblfish 14:17:08 ... is this as a reason to encourage use of standard types 14:17:08 this statement just forgets the specific needs of domain specific applications 14:17:36 q+ 14:17:51 ack oberger 14:18:02 bblfish: there's no hexbinary in the sanctioned list, which rules out webid 14:18:07 q+ to suggest that the specification of limited types if you want to keep it, make it an appendix and give it a different name. 14:18:20 -1 to the proposal - I prefer the original proposal to delete 4.1.9 14:18:22 my answer: I believe in standards 14:18:24 q+ 14:18:37 oberger: i understand betehess's concearns, but what's it matter if you're not compliant with this aspect? 14:18:38 davidwood, agree on the difference between my proposal and yours 14:18:58 ack bart 14:18:59 ... i could object to dc:creator, but it's good for the larger goal 14:19:08 SteveBattle --- that was going to my PROPOSAL 2 ::-) 14:19:16 PROPOSAL: Change 4.1.9 to say that servers MAY restrict their datatypes. 14:19:23 BartvanLeeuwen: i jumped on RDF because of it's flexibility 14:19:23 antonis, thanks 14:19:35 ... we see geo datatypes, which get some use 14:19:35 ack steves 14:19:46 I think 4.1.9 send the wrong message entirely - kill it! 14:19:53 ... i don't think i've heard a good motivation 14:19:59 q+ 14:20:12 SteveS: true intent is "don't make up a new datatype where one of these suffices" 14:20:20 ack timbl 14:20:20 timbl, you wanted to suggest that the specification of limited types if you want to keep it, make it an appendix and give it a different name. and to 14:20:22 SteveBattle, +1 to what you said, it's a horrible section that makes a huge portion of wild rdf unusable 14:20:45 Agree that 4.1.9 says "don't fully use RDF". That's not good. 14:20:46 timbl: the only think i care about is the MUST 14:21:03 ... every time we make a constriant, you cut out users 14:21:07 s/think/thing/ 14:21:24 ... you could say "you can put anything in here with a PUT", which everyone can use 14:21:48 develD has joined #ldp 14:21:58 ... you can make a further restriction with interop optimization 14:22:30 q? 14:22:34 ack bete 14:22:47 q+ to repeat points 7, 24 and 282-306 14:22:50 q- 14:22:51 MUST 14:22:51 q+ 14:23:06 ack ashok 14:23:23 +1 to ashok's proposal 14:23:23 PROPOSAL: Delete 4.1.9 14:23:37 or soften it 14:23:44 davidwood 14:23:55 PROPOSAL: Soften 4.1.9 by removing it :) 14:24:00 The idea of constraining RDF datatypes to get interop between OO systems is a separate orthogonal protocol, independent of LDP. 14:24:03 I'm happy to put that in a "best practices document for LDP" 14:24:05 *lol @ davidwood* 14:24:09 -1 14:24:11 SteveS, you had a proposal ? 14:24:11 +1 to get rid of it 14:24:13 +1 14:24:16 +1 to delete 14:24:17 +1 die die die 14:24:20 -1 14:24:21 +1 14:24:22 +1 delete 14:24:25 +1 14:24:26 +1 14:24:27 ±0 14:24:29 +1 14:24:29 -0 14:24:31 +1 to delete 14:24:31 +1 14:24:34 -0,0 14:24:35 +1 14:24:36 +1 for removing 14:24:36 +1 14:24:40 +1 14:24:46 -0 14:25:00 davidwood: we can strike 4.1.9, soften to a SHOULD, change to language about "encouraging folks to use 14:25:03 -¹ 14:25:14 q+ 14:25:18 This kind of advice could go in the primer 14:25:42 s/encouraging folks to use/encouraging folks to use the following types when applicable/ 14:26:14 MacTed has joined #ldp 14:26:23 *that was my thought too, SteveBattle. It'd be useful for the implementations coming from the GLD WG too 14:26:31 cygri: non-normative best practice on the use of datatypes shouldn't be in this specification 14:26:33 sandro: maybe? PROPOSED: Replace 4.1.9 with non-normative text, describing which datatypes are widely used -- a best practice. 14:26:43 I'd propose (if it must be kept): swap MUST to SHOULD, remove the word "only" and expand the list to the same set as the union of rif + rdf, then it doesn't preclude anything 14:26:48 agree with cygri 14:27:06 +1 to avoid informative statements like that whenever possible 14:27:12 ... since it's a cross-cutting concearn, i'd be more comfortable making no statement at all" 14:27:26 PROPOSAL: Soften to SHOUD and explain use instead of inventing custom ones that do the same thing 14:27:42 +1 14:27:46 did we not just RESOLVE to delete it? 14:28:20 q+ to ask how clients can know what they can PUT if servers may restrict datatypes 14:29:25 ArnaudLH: -1 means "I cannot live with this proposal" -- expected to lead to a Formal Objection 14:30:25 that's an RDF issue to me 14:30:55 Q+ 14:31:15 antonis: i think it should be written somewhere. don't mean to formally object 14:31:19 q- 14:31:27 ack david 14:31:27 davidwood, you wanted to ask how clients can know what they can PUT if servers may restrict datatypes 14:32:02 davidwood, if this becomes a SHOULD, some servers will restrict your datatypes, and some won't 14:32:10 q+ 14:32:28 ... how does a client know what to expect? 14:33:01 ... we need a way to advertise the types 14:33:01 ack hadley 14:33:02 q+ 14:33:23 HadleyBeeman: we have this prob everywhere (gov LD, RDF Core) 14:33:35 ... doesn't belong in this group 14:33:46 PROPOSAL: Delete 4.1.9 and annoy RDF-WG about doing something about datatype best practice 14:33:55 ack bblfish 14:34:16 bblfish: agreeing that collections can be typed and restricted 14:34:29 ... +1 to davidwood 14:34:54 q- bete 14:34:54 "servers MAY restrict datatypes to this (or another) list, MAY exclude user-defined datatypes. if datatypes are so restricted, such restrictions MUST be advertised." 14:34:56 q- 14:35:05 SteveS: two reasons to object: 14:35:29 ... .. the issues around saying SHOULD (not reinvent) 14:35:47 ... .. would like to encourage best practices as much as can 14:36:15 atonis, are you 0 or +1 now? 14:36:18 0 14:36:20 a? 14:36:21 jonathandray has joined #ldp 14:36:22 q? 14:36:23 q+ 14:36:44 ArnaudLH: i think we understand adding constraints for interop 14:37:16 davidwood: sandro pointed out that somewhere it says that "if a client PUTs datatypes other than this, they are stripped"? 14:37:54 q+ 14:38:06 s/sandro pointed out that somewhere it says that "if a client PUTs datatypes other than this, they are stripped"?/sandro pointed out that the MUST/SHOULD is only about the representation, not about server behavior/ 14:38:13 ... the server has to construct a representation of these datatypes 14:38:17 q+ 14:38:34 yes MUST *ONLY* 14:38:38 server doesn't have to *strip* the datatype, but must figure out how to represent those other datatypes with the given short-list 14:38:42 *that*'s problematc 14:38:43 q? 14:38:52 q+ to point out that we're never going to convince a non-triplestore server to not strip unknown stuff 14:39:20 -0 14:39:26 0 14:39:29 +∞×ø 14:39:33 +1 14:39:41 "+1"^^xsd:short 14:40:23 APPROVED: Delete 4.1.9 14:40:37 ^^ This resolves ISSUE-6 14:40:45 RESOLVED: Delete 4.1.9 14:41:10 -[IPcaller] 14:41:22 RESOLVED: close issue-6 by DELETing LDP §4.1.9 14:41:22 close issue-6 with deleting section 4.1.9 and editing any related sections in the spec accordingly 14:41:56 -MacTed 14:42:03 MacTed, everypone is gone, no clue 14:46:59 Ruben has joined #ldp 15:03:18 rgarcia has joined #ldp 15:03:23 MacTed, we're slowly reconvening 15:03:59 svillata has joined #ldp 15:03:59 nmihindu has joined #ldp 15:05:35 develD has joined #ldp 15:05:51 tnx 15:08:07 +[OpenLink] 15:08:16 scribe: Ashok_Malhotra 15:08:16 Zakim, [OpenLink] is temporarily me 15:08:16 +MacTed; got it 15:08:19 Zakim, mute me 15:08:19 MacTed should now be muted 15:08:21 scribenick: Ashok_Malhotra 15:08:23 s/tnx// 15:08:30 s/MacTed, we're slowly reconvening// 15:08:40 s/MacTed, everypone is gone, no clue// 15:08:51 Arnaud: Let's discuss dinner then pick up issues again 15:09:01 ... also talk about f2f 15:09:19 jmvanel has joined #ldp 15:09:19 Topic: f2f 15:09:38 jonathandray has joined #ldp 15:09:44 Arnaud: Charter calls for a f2f in March 15:09:58 ... we have to announce 8 weeks ahead of time 15:10:07 W3C event calendar: http://www.w3.org/participate/eventscal.html 15:10:23 ... We also need a list of possible hosts 15:10:29 Sometimes ftf meetings can be in conjunction with another event. 15:10:29 q+ 15:10:34 q- 15:11:27 Ashok: Maybe Oracle can host in NYC 15:11:35 Sandro: We can host at MIT 15:11:46 ack me 15:11:47 q- timbl 15:12:04 queue= 15:12:20 bblfish has joined #ldp 15:12:34 Maybe a straw poll on general location? (US East, US West, Europe) 15:13:12 ahaller2 is offering to host 15:13:20 Arnaud: I'm not thinking about Europe 15:13:52 krp has joined #ldp 15:14:44 David: Most WGs I have been involved in alternate between Europe and US East Coast 15:16:19 Discussion about expensive lodging in NYC 15:16:25 -1 to sharing room with ericP 15:16:47 wuss 15:17:15 Lodging is cheaper in Cambridge 15:17:52 I can try and find rooms on the West Coast 15:18:36 +1 15:18:40 west coast? 15:18:42 0 15:18:48 -1 15:18:48 STRAWPOLL: Who could go to U.S. west coast 15:18:48 +1 15:18:49 +1 15:18:52 -0.2 15:18:54 0 15:18:56 0 15:18:57 0 15:19:03 +0.9 15:19:06 +0.5 15:19:10 +1 15:19:21 +1 15:19:33 25% chance of west coast attendance. 75% east coast. 90% proximal to Boston. 15:20:53 +0.5 15:20:53 can we co-locate it with some related conference, ac meeting? 15:20:53 +1 15:20:54 +0.75 15:20:57 STRAWPOLL: Who could go to U.S. east coast? 15:20:58 +1 15:20:59 +0.5 15:21:00 +1 15:21:00 +0.5 15:21:00 +0.5 15:21:01 +1 15:21:01 +1 15:21:01 +1 15:21:01 +0.2 15:21:03 +1 15:21:04 +1 15:21:05 +1 15:21:05 +0.5 15:21:05 +① 15:21:22 Topic: Next LDPWG meeting 15:21:26 *for tpacbot* 15:24:15 SteveS: I can look into Raleigh, NC 15:24:56 SteveS, do you have a cheap flight plan from london ? 15:25:01 Arnaud: can we narrow down timing 15:25:37 sandro: Suggest march 27/28 -- MIT Spring break 15:25:49 that week is Easter 15:25:53 at least in Spain 15:27:34 oberger, american airline flight is usually not bad LHR-RDU $1,200 USD atm 15:27:52 ouch 15:28:27 Arnaud: Week of March 12? 15:31:25 oberger: Asks about what we will discuss 15:32:13 for expenses reason 15:32:15 Bart: March 14/16 may work 15:33:05 Discussion about whether a Video Conferencing facility would be available 15:34:03 Nice at Eurecom maybe 15:34:09 Eric: I would book rooms for 14/15 March 15:34:21 Eric, Done. 15:34:27 I'll check for video conferencing facility in Nice 15:34:32 I mean, for a videoconference room 15:35:34 @davidwood, if you are after great weather, come to Australia in March 15:35:52 Arnaud: I will sort it out and put some proposals before the WG 15:36:05 ahaller2, maybe earlier for mango season. Yum! 15:36:21 Topic: Dinner 15:36:40 Arnaud: Who can join the group fro dinner 15:36:53 16 or 17 people 15:37:12 ... close to 20 people 15:38:04 ArnaudLH, Les Adrets maybe ? 15:38:14 dunno if as cheap (kinda) 15:38:22 Arnaud: Perhaps same restaurant as the RDF WG dinner 15:38:34 http://www.lyonresto.com/restaurant-Lyon/restaurant-Les-adrets-Lyon/restaurant-Les-adrets-Lyon-109.html 15:38:56 http://www.cityvox.fr/restaurants_lyon/le-comptoir-des-marronniers_22595/Profil-Lieu 15:39:21 actually http://lecomptoirdesmarronniers.fr/ 15:39:35 bhyland has joined #ldp 15:39:43 Arnaud: I see 17 hands ... add 1 for Henry Story 15:40:53 +1 15:40:57 ... 7:30 PM 15:41:36 ISSUE-20? 15:41:36 ISSUE-20 -- Identifying and naming POSTed resources -- open 15:41:36 http://www.w3.org/2012/ldp/track/issues/20 15:42:09 q+ 15:42:15 q- 15:42:23 Topic: Issue-20 15:42:51 http://www.w3.org/2012/ldp/track/issues/20 15:43:12 bhyland has joined #ldp 15:43:57 SteveBattle Introduces the issue 15:44:31 +q 15:44:35 q+ to comment on the use of RDF 15:44:49 q+ to ask if this needs to be part of the client contract 15:45:33 q+ 15:45:33 ack roger 15:45:37 q+ 15:45:44 ISSUE-26? 15:45:44 ISSUE-26 -- creation model for LDP -- open 15:45:44 http://www.w3.org/2012/ldp/track/issues/26 15:46:05 Roger: Issue-26 (above) is related 15:46:27 http://maps.google.fr/maps?q=8+Rue+des+Marronniers+-+69002+Lyon&hl=en&ie=UTF8&sll=45.317723,5.43724&sspn=4.557674,11.195068&hnear=8+Rue+des+Marronniers,+69002+Lyon,+Rh34ne,+Rh34ne-Alpes&t=m&z=16 15:46:55 ... JohnArwe said it was not a MUST, only a SHOULD 15:47:13 q+ 15:48:15 ack bete 15:48:15 betehess, you wanted to comment on the use of RDF 15:49:36 the model is distinct from its serializations... 15:49:36 zakim, who is there? 15:49:36 I don't understand your question, ArnaudLH. 15:49:41 Betehess: Cannot have relative URIs in RDF 15:49:52 Zakim, who is on the phone? 15:49:53 On the phone I see St_Clair_3B, MacTed (muted) 15:50:03 ... we may have to change the definition 15:50:05 s/RDF/RDF Abstract Syntax 15:50:09 q- 15:50:32 s/the model is distinct from its serializations/the RDF model is distinct from its serializations (Turtle, TriG, RDF/XML, etc.)/ 15:50:32 trackbot has joined #ldp 15:50:39 q+ 15:50:46 q+ 15:50:54 q+ 15:51:00 ack timbl 15:51:07 Betehess: Jena, for example, always gives you an absolute URIs 15:51:45 s/ always gives you an absolute URIs/ always gives you an absolute URIs when serializing or deserialising, but you can do it manually/ 15:51:56 timbl: I come to this, with using like N3 like a programming language. URIs are like variables, and I use their short names, by using relative URIs 15:52:01 bblfish has joined #ldp 15:52:12 back, sorry to be late 15:52:21 timbl: when I'm writing Turtle all the time, I define lots of URIs locally in the document, with relative URIs. 15:52:22 Tim: Use of relative URis are, in my view, crucial 15:52:45 timbl and I raised an issue a while ago re: jena https://issues.apache.org/jira/browse/JENA-132 15:53:09 timbl: When you're processing the document you don't worry/care about the absolute URI at all. cwm has always used relative URIs -- which may resolve at file: URIs when I'm running it in the filesystem 15:53:29 q+ to offer other use-cases 15:53:39 timbl: Then I can serve that from Apache without blinking, with the relateive URIs resolving to be http ones. 15:53:49 ArnaudLH, I have made a reservation giving your name and my phone number 15:53:57 timbl: sometimes it's proxied to another server, and comes out relative to that proxy address. 15:54:34 timbl: Sometimes there's a bug because there's a an absolute URI like localhost:5876 something 15:55:05 timbl: Someone makes a to-do list, and if it uses relative URIs they can move it around. 15:55:18 q? 15:55:54 Tim: Explains that he uses relative URIs as local vraibles in a programming language 15:56:00 ack david 15:56:01 timbl: It would give me a big pain on this, if LDP servers gave back relative URIs. Server should be able to store and server everything relative. 15:56:02 http://lecomptoirdesmarronniers.fr/ 15:56:21 ... would be a big problem if they were prophibited 15:56:46 Wasn't that "didn't serve relative URIs"? 15:56:48 s/prophibited/prophibited 15:56:52 lcpvrr has joined #ldp 15:57:09 s/prophibited/prohibited 15:57:47 DavidWood: Expalins how he uses URis in Callamachis 15:58:22 ... so you post to a container and provided a slug and you are good 15:58:38 ... slug is a header ... it's a hint 15:58:54 ack steves 15:58:59 SteveS: 15:59:17 davidwood, is a slug http://en.wikipedia.org/wiki/Slug ? 15:59:21 Question is what do you put in the RDF 15:59:41 DavidWood: We don't typically self reference 15:59:52 lcpvrr has left #ldp 16:01:10 http://en.wikipedia.org/wiki/Clean_URL#Slug 16:01:19 shame, but, have to go ... 16:01:24 slug: http://bitworking.org/projects/atom/draft-ietf-atompub-protocol-13.html#rfc.section.9.6 16:01:39 ack sandro 16:02:10 Callimachus documentation for creating resources: http://code.google.com/p/callimachus/wiki/REST_API#CRUD_Operatons_on_BLOB_Content 16:02:21 <#new> 16:02:33 Sandro: This is not a problem with the RDF model 16:02:45 q? 16:02:55 ack steveb 16:03:19 https://issues.apache.org/jira/browse/JENA-132 16:03:27 SteveBattle: With Turtle you can send t but not consume it 16:03:36 ... other situations work 16:04:05 s/ t /t / 16:04:48 [[ Tim - this is not a bug. A bug would be where it does something wrong and the writer writes something that can't be parsed or isn't the RDF given as input. 16:04:49 ]] 16:04:55 s/sendt /send/ 16:05:05 q? 16:05:08 q+ 16:05:59 ack cygri 16:06:03 SteveBattle: Even with the slug it is a NULL relative URI 16:07:00 Richard: You post a something and it has a relative URI ... waht do we say about turning it into an absolute URI 16:07:09 http://tools.ietf.org/html/rfc3986#page-26 16:07:15 http://tools.ietf.org/html/rfc3986#section-5.1 16:07:18 q+ 16:08:47 q+ 16:09:08 ... there are general rules about converting relative URI to absolute URis. We should not do anything against these rules but they do not 16:09:18 q+ to say that the only logical way is to make the base the newly created URI. 16:09:19 completelty specufy the behaviour 16:09:24 POST targets a service. *nothing* should be tied to that target URI thenceforth. 16:09:51 ack bete 16:09:51 betehess, you wanted to offer other use-cases 16:09:56 MacTed, reference? 16:09:57 ... there could be different ways of handling this 16:10:35 btw, http://www.w3.org/TR/turtle/#sec-iri ¶2 says a little about relative and basee IRIs. normative text in http://www.w3.org/TR/turtle/#sec-iri-references 16:11:18 q+ to ask what heppens if we don't speak about it (consider it container configuration) 16:12:33 Betehess: This question is the same for GET and PUT ... I use the Web as a database ... I go back and forth with relative URIs 16:12:35 disagree with betehess that it's teh same for GET and PUT. For those, the base URI *is* the request URI, full stop. 16:13:12 cygri, false, it's specified by content-location 16:13:23 webr3, reference? 16:13:26 http://tools.ietf.org/html/rfc2616#section-9.5 16:13:33 q+ 16:13:37 ack bblfish 16:13:43 I don't disagree with cygri the way he put it 16:14:24 cygri, when I say "it's the same", I realized that it's not exactly, based on your comments re: the URI spec 16:14:27 bblfish: I agree with Alex ... If you post to a collection and then cannot address what you created that's a bug 16:14:35 ack steveb 16:14:44 ``The action performed by the POST method might not result in a resource that can be identified by a URI. In this case, either 200 (OK) or 204 (No Content) is the appropriate response status, depending on whether or not the response includes an entity that describes the result.`` 16:14:58 SteveBattle: RFC 3096 is talking about retrieval context 16:15:13 +1 SteveBattle -- with POST there is no retreival context, so we drop through the onion 16:15:19 While cycgri's analysis of the HTTP RFC, that may seem to be a way to read the spec, but in that case th LDP has to claify and be logical here. 16:15:20 MacTed, but that's not applicable here. In our case, the POST results in a resource that can be identified by a URI. 16:15:42 SteveBattle: Base URI in content may still be there, ... then we skip to 5.1.4 to App-Dependent 16:15:50 BartvanLeeuwen has joined #ldp 16:15:56 s/3096/3986/ 16:16:03 Arnaud: We understand the issue and understand the different points of view 16:16:07 cygri - but there's *nothing* that says that the new resource's URI has any connection to the POST target URI. 16:16:31 Exactly - it's application dependent. 16:16:37 http://tools.ietf.org/html/rfc2616#section-14.30 16:16:48 MacTed, the question is about what's the base URI in a POST *request*, not what happens afterward 16:16:53 q? 16:16:58 PROPOSED: Close ISSUE-20 saying we're okay with the design in the FPWD 16:17:03 ack timbl 16:17:03 timbl, you wanted to say that the only logical way is to make the base the newly created URI. and to 16:17:20 +1 timbl "the only logical way is to make the base the newly created URI" 16:17:23 q+ 16:17:26 Tim: We have to make something that is consistent and logical 16:17:28 q+ 16:17:42 q- later 16:18:00 ... the base URI has to be the URI of the resource 16:18:35 timbl: Another reason for this relative-URI reading is that it saves the server having to parse and re-serialize the content 16:18:38 ... if the base URI is different when I Post and when I get you have to re-serialize the file 16:18:48 q+ 16:18:48 For reference: http://lists.w3.org/Archives/Public/ietf-http-wg/2012OctDec/0132.html 16:18:55 this came up on IETF a week or so ago 16:19:01 timbl: also, some versions of URI spec said <> always was self-references, regardless of any base 16:19:04 webr3, nice find 16:19:22 q? 16:19:34 ack eric 16:19:34 ericP, you wanted to ask what heppens if we don't speak about it (consider it container configuration) 16:19:40 "If Content-Location is included in a request message, then it MAY be interpreted by the origin server as an indication of where the user agent originall y obtained the content of the enclosed representation" ... "A Content-Location field received in a request message is transitory information that SHOULD NOT be saved with other representation metadata for use in later responses." 16:19:49 q+ 16:20:12 EricP: What happens if we do not specify this ... how much depends on this 16:20:30 ... leave the spec as is 16:20:32 SteveBattle: If we get rid of this, it's harder to do testing, for one thing. 16:20:58 yes 16:21:03 the current wording is missing the 201 Created 16:21:13 EricP: If we specify the rewrite rules do we lose interoperability 16:21:40 bblfish: If folks treat relative URIs differently there is going to me a mess 16:21:48 ... this is an important issue 16:22:05 q? 16:22:46 EricP: If two servers have different rules then is the client libraries as les usable ... 16:23:36 Zakim, unmute me 16:23:36 MacTed should no longer be muted 16:23:37 bblfish, Tim: You cannot be inconsistent 16:24:36 Ted: When you POST you have no control over what the server does 16:24:37 MacTed: When you POST, you have no real control over what the server does. 16:25:34 let's take an example where the semantics are clear 16:25:34 ... there is nothing that says what comes back has any relation to what you posted 16:25:45 timbl: With the spec, POST is well defined. 16:26:17 timbl: the only option the server has is to pick the location, with LDP. 16:26:27 http://tools.ietf.org/html/rfc2616#section-9.6 16:26:36 OBerger: Are we discussing creation or adding to a container 16:27:29 q+ 16:27:37 sandro: MacTed, we're refining HTTP, being more specific about the behavior of certain (LDP) resources. 16:27:44 jonathandray has joined #ldp 16:28:18 q? 16:28:19 ack cygri 16:28:34 Ted: The POST URI has no bearing on the resource ... 16:28:49 Zakim, mute me 16:28:49 MacTed should now be muted 16:28:52 cygri: I found tims argument about <> being always self-reference to be fairly compelling. 16:29:12 does the order of the triples matters as well? 16:29:17 q+ 16:29:24 cygri: but the URI spec isn't quite clear about this. 16:29:35 q+ 16:29:56 Cygri: We can escalate the issue 16:30:09 Tim: This spec uses HTTP in a special way 16:30:11 +1 for cygri's summary: The logical proof of the interpretation of the base URI is that if you POST to a server that returns byte-for-byte what you sent, and if we take the Location header in the 201 into account, then you need to interpret the base as the location, since GET is 16:30:14 Q+ 16:30:33 BartvanLeeuwen has joined #ldp 16:30:50 ack sandro 16:31:28 Arnaud: Not sure we are converging 16:31:32 q+ to ask whether a use of a Slug: header allows me to be compliant or not. Section 5.4 seems to be ambiguous on that... 16:31:44 PROPOSED: Close ISSUE-20 saying we're okay with the design in the FPWD. <> is self-reference within LDP operations, at least. 16:31:54 +1 16:31:57 Sandro: I'm hearing consensus in the room just questions about the larger implications 16:32:10 +1 16:32:11 +1 16:32:15 +1 16:32:18 +1 16:32:21 +1 16:32:21 +1 16:32:22 +1 16:32:24 +1 16:32:28 +1 16:32:35 +1 16:32:39 +1 16:32:46 Arnaud: We have other HTTP experts, they can comment on this and if they disagree we can reopen the issue 16:32:58 +0.5, modulo my question above 16:33:11 q- 16:33:12 +1, but there are still some issues with what's currently in the spec right now 16:33:28 I would like, ideally, for explicitly it to say that the base URI for the posted data is the URI of the new created resource. 16:33:28 q- 16:33:29 ack bblfish 16:33:40 if the server returns it byte-by-byte, it will still be relative! 16:33:45 +0.5. would still like to see confirmation that it's okay from the people directly involved with the HTTP/URI 16:33:51 bblfish: This is the ONLY consistently, logical interpretation, if the server sends back a location header. 16:35:04 <> should remain shorthand for base URI -- which *may* be self-reference, but may not, depending on serialization, etc. Availability of self-reference and other relative reference is vital 16:35:06 oberger: Not sure we know what we mean by POST ... create resoaurce or add to container 16:35:39 ISSUE-25? 16:35:39 ISSUE-25 -- Weak aggregation and strong composition in containers -- open 16:35:39 http://www.w3.org/2012/ldp/track/issues/25 16:36:05 RESOLVED: Close ISSUE-20 saying we're okay with the design in the FPWD. <> is self-reference within LDP operations, at least. 16:36:19 RESOLVED: Close ISSUE-20 saying we're okay with the design in the FPWD. <> is self-reference within LDP operations, at least. 16:36:29 q- 16:36:35 ack steveb 16:37:03 SteveBattle: I have raised the same issue on HHTPbis ... 16:37:11 Topic: Wrap-up for the day 16:37:16 that resolution breaks on Turtle, which allows <> to change from self-reference when base URI changes. if Turtle isn't usable in LDP operations, ... we have big trouble. 16:38:12 http://lecomptoirdesmarronniers.fr/ 16:38:16 This doesn't affect use of @base. This proposal just determines the default document base on POST to a container. 16:38:36 "<> is self-reference within LDP operations, at least." ? 16:39:41 MacTed, TimBL claimed <> is self-reference. We're saying that's definitely true within LDP, even if we're not sure about it elsewhere. 16:40:27 sandro, MacTed, we're just saying it about POST to a container, really. 16:40:36 I think the spec should additionally specify something like, "On POST to a container, the default document base is the URI of the created resource." 16:40:50 +1 SteveBattle 16:42:04 Or even clearer, "On POST to a container, the default document base of the POSTed RDF representation is the URI of the created resource." 16:42:05 and there were plenty of email on this subject 16:42:10 q+ 16:42:14 explaining why we close it is important as well 16:42:28 so... s/RESOLVED: Close ISSUE-20 saying we're okay with the design in the FPWD. <> is self-reference within LDP operations, at least./RESOLVED: Close ISSUE-20 saying we're okay with the design in the FPWD. <> is shorthand for base URI in LDP operations, and "On POST to a container, the default document base of the POSTed RDF representation is the URI of the created resource."/ 16:42:34 Arnaud: People that raise issue should argue why the issue is important 16:42:42 which may require another proposal round. 16:43:33 MacTed, I think that's consistent with the resolution we made, and good wording. SteveS, you okay with that change? 16:43:36 We're discussing the wording of the closure of issue-20. 16:43:44 Yes. 16:43:56 Yes - I agree with the wording. 16:44:10 jonathandray has joined #ldp 16:45:35 -MacTed 16:46:56 Ruben has left #ldp 16:47:38 RRSAgent, please draft minutes 16:47:38 I have made the request to generate http://www.w3.org/2012/11/01-ldp-minutes.html ericP 16:48:18 -St_Clair_3B 16:48:19 SW_LDP()2:30AM has ended 16:48:19 Attendees were St_Clair_3B, Yves, JohnArwe, AndyS, [IPcaller], MacTed 16:56:16 SteveBattle has joined #ldp 16:57:32 jonathandray has joined #ldp 16:59:02 roger__ has joined #ldp 17:06:05 jonathandray has joined #ldp 17:06:29 jonathandray has joined #ldp 17:06:36 jonathandray has joined #ldp 17:06:56 spiroid has joined #ldp 17:18:25 cgueret has joined #ldp 17:21:43 BartvanLeeuwen has joined #ldp 17:23:25 timbl_ has joined #ldp 17:26:32 Arnaud has joined #ldp 17:34:27 antonis has joined #ldp 17:41:50 SteveS has joined #ldp 17:44:17 krp has joined #ldp 17:49:38 Arnaud1 has joined #ldp 17:57:59 trackbot has joined #ldp 17:58:59 trackbot has joined #ldp 17:59:18 trackbot has joined #ldp 18:25:45 ahaller2 has joined #ldp