IRC log of ldp on 2013-03-13
Timestamps are in UTC.
- 13:21:29 [RRSAgent]
- RRSAgent has joined #ldp
- 13:21:29 [RRSAgent]
- logging to http://www.w3.org/2013/03/13-ldp-irc
- 13:21:32 [Zakim]
- Zakim has joined #ldp
- 13:22:10 [sandro]
- sandro has changed the topic to: Linked Data Platform WG -- http://www.w3.org/2012/ldp/ -- current agenda: http://www.w3.org/2012/ldp/wiki/F2F2
- 13:22:10 [sandro]
- sandro has changed the topic to: Linked Data Platform WG -- http://www.w3.org/2012/ldp/ -- current agenda: http://www.w3.org/2012/ldp/wiki/F2F2
- 13:23:24 [TallTed]
- TallTed has joined #ldp
- 13:25:17 [nmihindu]
- nmihindu has joined #ldp
- 13:26:39 [ericP]
- Zakim, space for 8 for 9 hours?
- 13:26:39 [Zakim]
- I don't understand your question, ericP.
- 13:26:46 [SteveS]
- SteveS has joined #ldp
- 13:26:59 [sandro]
- zakim, room for 8 for 9 hours?
- 13:26:59 [Zakim]
- I don't understand your question, sandro.
- 13:27:03 [betehess_laptop]
- scribenick: betehess_laptop
- 13:27:36 [betehess_laptop]
- Arnaud: let's go around the table
- 13:27:43 [sandro]
- Sandro Hawke
- 13:27:45 [cody]
- cody has joined #ldp
- 13:27:52 [JohnArwe]
- JohnArwe has joined #ldp
- 13:27:52 [ericP]
- i'm ericP
- 13:27:53 [betehess_laptop]
- RRSAgent, please dreaft the minutes
- 13:27:53 [RRSAgent]
- I'm logging. I don't understand 'please dreaft the minutes', betehess_laptop. Try /msg RRSAgent help
- 13:27:53 [sandro]
- Eric Prud'hommeaux
- 13:28:00 [betehess_laptop]
- RRSAgent, please draft the minutes
- 13:28:00 [RRSAgent]
- I have made the request to generate http://www.w3.org/2013/03/13-ldp-minutes.html betehess_laptop
- 13:28:04 [krp]
- krp has joined #ldp
- 13:28:05 [SteveS]
- Steve Speicher
- 13:28:06 [SteveBattle]
- SteveBattle has joined #ldp
- 13:28:06 [cygri]
- Richard Cyganiak
- 13:28:09 [JohnArwe]
- John Arwe
- 13:28:20 [nmihindu]
- Nandana Mihindukulasooriya
- 13:28:29 [rgarcia]
- Raúl García Castro
- 13:28:32 [Ashok]
- Ashok has joined #ldp
- 13:28:38 [krp]
- Kevin Page
- 13:28:39 [ericP]
- Zakim, space for 8 for 600 minutes?
- 13:28:40 [Zakim]
- ok, ericP; conference Team_(ldp)13:28Z scheduled with code 26632 (CONF2) for 600 minutes until 2328Z
- 13:28:40 [cody]
- Cody Burleson, Base22
- 13:28:44 [TallTed]
- Ted Thibodeau
- 13:28:51 [betehess_laptop]
- Arnaud: weclome everybody
- 13:29:00 [Zakim]
- Team_(ldp)13:28Z has now started
- 13:29:02 [betehess_laptop]
- ... I hope we can be as productive as the first f2f
- 13:29:07 [Zakim]
- + +1.617.715.aaaa
- 13:29:14 [SteveBattle]
- Hello all - this is Steve Battle from Sysemia, Bristol, UK
- 13:30:08 [betehess_laptop]
- ... lots of work to do
- 13:30:12 [Graham]
- Graham has joined #ldp
- 13:30:21 [ericP]
- Linked Data Platform WG -- http://www.w3.org/2012/ldp/ -- current agenda: http://www.w3.org/2012/ldp/wiki/F2F2 -- code: 26632
- 13:30:26 [betehess_laptop]
- ... I'll try to keep us on track, so that we can deliver a spec on schedule
- 13:30:30 [davidwood]
- davidwood has joined #ldp
- 13:30:57 [betehess_laptop]
- ... sometimes we need to take time to understand why the spec is the way it is
- 13:31:14 [betehess_laptop]
- ... let's have a look at the agenda
- 13:31:33 [betehess_laptop]
- ... the spec is the main item for us
- 13:31:58 [betehess_laptop]
- ... the list follows the deliverables from the charter
- 13:32:04 [betehess_laptop]
- ... plus some items we agreed to do
- 13:32:15 [betehess_laptop]
- ... we need to check where we are on these items
- 13:32:42 [Zakim]
- +bblfish
- 13:32:50 [betehess_laptop]
- ... some are just nice-to-have
- 13:33:00 [betehess_laptop]
- davidwood: but it would be better for adoption
- 13:33:23 [betehess_laptop]
- Arnaud: but we need to prioritize
- 13:33:38 [betehess_laptop]
- davidwood: can we go a bit meta some time during the next 3 days?
- 13:33:48 [betehess_laptop]
- ... to anticipate what can bite us during LC
- 13:34:12 [betehess_laptop]
- Arnaud: my goal is not to go directly down into the issues, but also to ask where we are with the spec
- 13:34:25 [betehess_laptop]
- ... I ask people to come up with proposals, much easier
- 13:34:33 [betehess_laptop]
- ... some issues may not be critical
- 13:34:50 [mesteban]
- mesteban has joined #ldp
- 13:34:55 [betehess_laptop]
- ... so I want to prioritize the issues, and we can have the discussion at that time
- 13:35:13 [betehess_laptop]
- ... we haven't talked about the UCR in a while
- 13:35:16 [betehess_laptop]
- ... may be fine
- 13:35:26 [betehess_laptop]
- ... want to make sure everybody knows where we are
- 13:36:26 [betehess_laptop]
- ... I didn't assign specific issues to specific timeslots, but I don't want to get stuck in some discussions
- 13:36:45 [betehess_laptop]
- ... eric wilde proposed we have breakout sessions: why not
- 13:37:02 [cygri]
- +1 to keeping the option of breakout sessions open. we have enough time for that
- 13:37:12 [betehess_laptop]
- ... we could then stop the meeting, people break up in groups, and come back with proposals
- 13:37:42 [bblfish]
- if there are breakout sessions I hope it will be possible to connect with specific groups over skype or some remote way
- 13:37:43 [betehess_laptop]
- ... also use normal breaks (eg. lunch) to discuss
- 13:38:13 [betehess_laptop]
- ... let's get started with UCR
- 13:38:19 [betehess_laptop]
- ... we had a FPWD
- 13:38:31 [betehess_laptop]
- ... then we went back to the spec
- 13:38:44 [betehess_laptop]
- ... SteveBattle, what's your opinion?
- 13:38:56 [betehess_laptop]
- SteveBattle: we invited people to comment, then we had silence
- 13:39:00 [betehess_laptop]
- ... not really surprised
- 13:39:07 [betehess_laptop]
- ... please look at the document
- 13:39:15 [cygri]
- q+ to ask about ED vs WD
- 13:39:19 [betehess_laptop]
- ... there will be a deadline for the second release
- 13:39:58 [betehess_laptop]
- ... only missing UC: can we use LDP to invoke services through RDF exchange?
- 13:41:04 [betehess_laptop]
- ... then we have the test cases
- 13:41:14 [betehess_laptop]
- ... so that we can point the UC to TC
- 13:41:14 [SteveS]
- SteveBattle referred to http://www.w3.org/TR/2013/WD-ldp-ucr-20130131/#cloud-infrastructure-management
- 13:41:18 [Arnaud]
- q?
- 13:41:20 [betehess_laptop]
- ... and achieve completeness
- 13:41:23 [Arnaud]
- ack cygri
- 13:41:23 [Zakim]
- cygri, you wanted to ask about ED vs WD
- 13:41:24 [SteveS]
- …that doesn't have use case for
- 13:41:38 [betehess_laptop]
- cygri: I have to produce a UC on paging
- 13:41:50 [betehess_laptop]
- ... so there will be one more thing there
- 13:42:07 [rgarcia]
- q+ to ask whether we should create actions for these new use cases
- 13:42:17 [betehess_laptop]
- SteveBattle: ED and WD are the same at the moment
- 13:42:39 [betehess_laptop]
- Arnaud: not all WDs follow the same schedule
- 13:42:59 [roger]
- roger has joined #ldp
- 13:43:04 [betehess_laptop]
- ... we should have published things at the same time, just didn't happen
- 13:43:16 [betehess_laptop]
- SteveBattle: not sure if we should rush it out
- 13:43:32 [betehess_laptop]
- Arnaud: so , we have new UC to be added
- 13:43:37 [betehess_laptop]
- ... and we didn't get comments
- 13:43:58 [betehess_laptop]
- ... so I don't know if people are satisfied, or if people didn't get the attention
- 13:44:24 [betehess_laptop]
- ... for the people here: what's the status of this document according to you?
- 13:44:43 [roger]
- roger has joined #ldp
- 13:44:47 [betehess_laptop]
- SteveS: I think it's just in maintenance mode
- 13:44:56 [cygri]
- q+
- 13:45:05 [betehess_laptop]
- davidwood: we should ask for review
- 13:45:20 [betehess_laptop]
- ... I'll have to do that anyway
- 13:45:38 [betehess_laptop]
- s/do that/make a review/
- 13:45:38 [SteveBattle]
- Thankyou David
- 13:45:45 [Arnaud]
- ack rgarcia
- 13:45:45 [Zakim]
- rgarcia, you wanted to ask whether we should create actions for these new use cases
- 13:46:09 [betehess_laptop]
- rgarcia: we can open issues for that, so that we can follow the status of reviews
- 13:46:22 [betehess_laptop]
- ... we can identify these actions
- 13:46:28 [betehess_laptop]
- ... it's a good way to progress
- 13:46:40 [davidwood]
- q+ to ask about the satisfaction of each UC
- 13:46:58 [betehess_laptop]
- Arnaud: usually, the UCR motivates what goes in the spec
- 13:47:43 [betehess_laptop]
- ... sometime people are not even sure about the UC is when we discuss a feature
- 13:47:46 [Arnaud]
- ack cygri
- 13:48:12 [betehess_laptop]
- cygri: there's different views of the purpose for UCR
- 13:48:39 [betehess_laptop]
- ... it should always be able to ask "what's the use case?"
- 13:49:04 [betehess_laptop]
- ... so in my view, the purpose is to be able to ask people a scenario that is not address
- 13:49:12 [betehess_laptop]
- ... examples that we can follow
- 13:50:00 [betehess_laptop]
- ... I have some issues to add UC with the current organization of the document
- 13:50:10 [sandro]
- q?
- 13:50:23 [betehess_laptop]
- ... I hope SteveBattle will be able to help people there
- 13:50:40 [betehess_laptop]
- SteveBattle: every UC should be given a URI
- 13:50:42 [sandro]
- q+
- 13:50:53 [Arnaud]
- ack davidwood
- 13:50:53 [Zakim]
- davidwood, you wanted to ask about the satisfaction of each UC
- 13:50:59 [betehess_laptop]
- Arnaud: yes, it's the role of the editor to put things in the document, following requests
- 13:51:28 [betehess_laptop]
- davidwood: at some point, the status of the document shifts from what people want to what @@
- 13:51:47 [betehess_laptop]
- ... we may decide as a group that we cannot support some of them
- 13:52:09 [betehess_laptop]
- ... how do we make this transition? we could open issues
- 13:52:35 [betehess_laptop]
- ... in the rdfwg, we decided that we had too many UCs, and split the document
- 13:53:13 [betehess_laptop]
- Arnaud: when we started the work on this document, we started by accepting everything, then we wanted to decide as a group
- 13:53:21 [betehess_laptop]
- ... we never did that
- 13:54:00 [betehess_laptop]
- cygri: a UC that we decide to address will also depend on the time available
- 13:54:04 [davidwood]
- +1 to cygri
- 13:54:07 [rgarcia]
- +1
- 13:54:26 [betehess_laptop]
- ... if we say yes or no, we loose the possibility to drop UC on this basis
- 13:54:34 [davidwood]
- s/@@/the spec will support/
- 13:54:52 [betehess_laptop]
- ... can be out of scope, and there are things that we cannot address in time
- 13:54:57 [Arnaud]
- ack sandro
- 13:55:13 [betehess_laptop]
- sandro: would be fine to start with high/low priority
- 13:55:42 [betehess_laptop]
- ... people could explain to the editor and we decide together
- 13:55:51 [betehess_laptop]
- Arnaud: how much time would it require?
- 13:56:00 [roger]
- roger has joined #ldp
- 13:56:07 [betehess_laptop]
- sandro: we could save time instead of cycling if we don't do that
- 13:56:32 [betehess_laptop]
- Arnaud: another aspect: do we have a sense of if the spec *today* addresses the UCR
- 13:56:41 [betehess_laptop]
- ... what is addressed?
- 13:56:42 [betehess_laptop]
- q+
- 13:57:25 [betehess_laptop]
- cygri: if people think that we put things in the spec that are not addressing a UC, people should shout out
- 13:57:27 [Arnaud]
- ack betehess
- 13:58:21 [betehess_laptop]
- betehess: do we want to have links in the document to the UCR documents?
- 13:58:35 [betehess_laptop]
- s/in the document/in the spec/
- 13:58:41 [SteveBattle]
- As we create test-cases (that explicitly refer to supporting use-cases) we will be able to check if any use-cases are unused - these may be de-scoped.
- 13:58:46 [jmvanel]
- jmvanel has joined #ldp
- 13:59:45 [betehess_laptop]
- Arnaud: I want to make sure that we are good where we are with UCR, or not
- 13:59:59 [betehess_laptop]
- SteveBattle: I think it's in good shape at the moment, not concerned
- 14:00:09 [betehess_laptop]
- Arnaud: also davidwood is ok to have a closer look
- 14:00:17 [betehess_laptop]
- ... ok with others, just bring issues
- 14:00:27 [betehess_laptop]
- davidwood: we need formal actions
- 14:01:14 [davidwood]
- ACTION: davidwood to review the UCR document
- 14:01:15 [trackbot]
- Created ACTION-41 - Review the UCR document [on David Wood - due 2013-03-20].
- 14:01:34 [mesteban]
- So I'll do the other review of the UCR.
- 14:01:53 [davidwood]
- ACTION: mesteban to review the UCR document
- 14:01:53 [trackbot]
- Created ACTION-42 - Review the UCR document [on Miguel Esteban Gutiérrez - due 2013-03-20].
- 14:02:20 [betehess_laptop]
- cygri: if we capture more advanced UC, it would be good to decide as gorup to postpone
- 14:02:36 [Zakim]
- -bblfish
- 14:02:45 [betehess_laptop]
- ... maybe this will happen in the case of paging for example
- 14:02:58 [betehess_laptop]
- ... but it's good to have captured that as a UC
- 14:03:35 [Zakim]
- +bblfish
- 14:03:37 [betehess_laptop]
- Arnaud: in terms of the schedule, we skip the 2nd WD
- 14:03:46 [betehess_laptop]
- ... I guess everybody is ok with that
- 14:04:09 [betehess_laptop]
- ... the end goal for UCR is a NOTE
- 14:04:33 [betehess_laptop]
- cygri: if nobody comes up with new TC, then we might be done with the document
- 14:04:40 [betehess_laptop]
- ... we can publish an updated WD
- 14:05:17 [betehess_laptop]
- sandro: there is just no normative content
- 14:05:41 [betehess_laptop]
- davidwood: REC needs approval
- 14:05:46 [gavinc]
- gavinc has joined #ldp
- 14:05:51 [betehess_laptop]
- Arnaud: LC target is May
- 14:06:46 [betehess_laptop]
- ... so UCR should be a NOTE by then
- 14:07:13 [betehess_laptop]
- ... I think that we have a plan for UCR at this point
- 14:07:17 [betehess_laptop]
- ... do we need more?
- 14:07:25 [Arnaud]
- q?
- 14:07:53 [betehess_laptop]
- cygri: there is a couple of features in the spec, would like to know if there are corresponding UC
- 14:08:09 [betehess_laptop]
- ... eg. metadata managed by the server rather that the client
- 14:08:27 [betehess_laptop]
- SteveBattle: metadata about the collection would be that, so it should be covered
- 14:08:38 [betehess_laptop]
- ... ordering in a container is not covered
- 14:08:55 [betehess_laptop]
- ... technically speaking I could ask these things to be removed
- 14:09:24 [betehess_laptop]
- SteveS: we covered a story, there may be no UC
- 14:09:51 [betehess_laptop]
- cygri: speaking about ordering in a container
- 14:10:20 [betehess_laptop]
- ... we need the UC, even we need to have this thing in the spec
- 14:10:21 [davidwood]
- We also don't have anything in the UCR about paging, which has caused a lot of discussion.
- 14:10:34 [betehess_laptop]
- sandro: also for people outside the group, for them to understand
- 14:10:47 [betehess_laptop]
- cygri: there may be other points in the spec
- 14:11:10 [rgarcia]
- q+
- 14:11:46 [Arnaud]
- ack rgarcia
- 14:11:48 [betehess_laptop]
- ... if we are asked "are there a UC", it's always better to give the pointer
- 14:13:22 [Arnaud]
- action: steves to draft a use case for container ordering
- 14:13:22 [trackbot]
- Created ACTION-43 - Draft a use case for container ordering [on Steve Speicher - due 2013-03-20].
- 14:14:28 [Arnaud]
- q?
- 14:15:20 [SteveBattle]
- I think that <http://www.w3.org/TR/2013/WD-ldp-ucr-20130131/#primary-scenario-retrieve-collection-level-description> covers the use of server-managed properties (about a collection).
- 14:16:33 [betehess_laptop]
- Arnaud: now, I want to speak about the spec, and have a sense of where we are
- 14:17:08 [betehess_laptop]
- topic: discussing the status of the spec
- 14:17:17 [betehess_laptop]
- Arnaud: looking at the isssues
- 14:17:26 [rgarcia]
- q+
- 14:17:26 [betehess_laptop]
- ... some are similar, related to others
- 14:17:30 [cygri]
- SteveBattle, I'm thinking of point 4.4.1 in the spec: "BPR servers may ignore server managed properties such as dcterms:modified and dcterms:creator if they are not under client control."
- 14:17:43 [betehess_laptop]
- ... some dissidents want to re-open issues that we decided to close
- 14:18:20 [cygri]
- SteveBattle, I'm not sure that this is really addressed in the UC you pointed out
- 14:18:27 [betehess_laptop]
- ... LC, in W3C process, is the stage when the WG says "I think we're done"
- 14:18:45 [betehess_laptop]
- ... and then we invite the rest of the world to look at it
- 14:18:51 [betehess_laptop]
- ... supposed to feature complte
- 14:19:02 [rgarcia]
- q-
- 14:19:08 [betehess_laptop]
- ... then there is a process to respond to comments
- 14:19:18 [betehess_laptop]
- ... everything has to be documented
- 14:19:48 [betehess_laptop]
- ... we'll have to explain to the director the status of the spec, and that we did our homeworks, and say why things could not be resolved
- 14:19:59 [betehess_laptop]
- ... after LC, we need to show implementations
- 14:20:24 [betehess_laptop]
- sandro: my sense is that implementing this is easy
- 14:20:39 [betehess_laptop]
- ... it's better to implemented earlier, then we can skip CR
- 14:20:55 [SteveS]
- http://www.w3.org/wiki/LDP_Implementations
- 14:20:55 [betehess_laptop]
- Arnaud: happy to say that we're in good shape in that regard
- 14:22:10 [betehess_laptop]
- sandro: implementations should include test results
- 14:22:17 [betehess_laptop]
- ... cannot say that until we have the test suite
- 14:22:35 [betehess_laptop]
- ... we should really try to have the issues closes during this meeting
- 14:22:40 [betehess_laptop]
- s/closes/closed/
- 14:22:59 [betehess_laptop]
- Arnaud: I agree, but there are different ways to close issues
- 14:23:13 [betehess_laptop]
- ... we can decide that we don't do anything re: specific issue
- 14:23:18 [betehess_laptop]
- Ashok: you need agreement
- 14:23:38 [betehess_laptop]
- Arnaud: there is a process, we decide as a group
- 14:23:38 [betehess_laptop]
- ... then people can raise objections
- 14:24:14 [betehess_laptop]
- sandro: there is the deadline mode, where we realize that perfection can't be achieved
- 14:24:38 [betehess_laptop]
- Arnaud: would like to take a pass on the list of iossues we have
- 14:24:42 [betehess_laptop]
- ... to get a sense of the priorities
- 14:24:50 [betehess_laptop]
- s/iossues/issues/
- 14:24:56 [betehess_laptop]
- ... is that reasonable?
- 14:25:23 [betehess_laptop]
- ... what are the MUST HAVE?
- 14:25:46 [roger]
- issue 37 : Model
- 14:25:50 [betehess_laptop]
- ... put in IRC what issue NEEDs to be addressed?
- 14:26:08 [JohnArwe]
- must have: pagination
- 14:26:57 [bblfish]
- Issue-37?
- 14:26:57 [trackbot]
- ISSUE-37 -- What is the LDP data model and the LDP interaction model? -- open
- 14:26:57 [trackbot]
- http://www.w3.org/2012/ldp/track/issues/37
- 14:27:25 [bblfish]
- I don't think ISSUE-37 is a must have. That is just done by the ontology anyway.
- 14:28:39 [bblfish]
- Me trying to work out what people are saying?
- 14:28:53 [SteveBattle]
- I deeply care about issue-21
- 14:28:59 [bblfish]
- Issue-21?
- 14:28:59 [trackbot]
- ISSUE-21 -- container affordances -- open
- 14:28:59 [trackbot]
- http://www.w3.org/2012/ldp/track/issues/21
- 14:29:05 [SteveS]
- ISSUE-15 for me
- 14:29:22 [bblfish]
- Issue-15?
- 14:29:22 [trackbot]
- ISSUE-15 -- sharing binary resources and metadata -- open
- 14:29:22 [trackbot]
- http://www.w3.org/2012/ldp/track/issues/15
- 14:29:44 [sandro]
- issue-33?
- 14:29:44 [trackbot]
- ISSUE-33 -- Pagination for non-container resources -- open
- 14:29:44 [trackbot]
- http://www.w3.org/2012/ldp/track/issues/33
- 14:30:13 [nmihindu]
- +1 ISSUE-15
- 14:30:38 [betehess_laptop]
- I care about issue-15 issue-33 and PATCH-related issues
- 14:30:44 [sandro]
- Patch, Pagination, IntuitiveContainers, BinaryResources
- 14:31:04 [bblfish]
- +1 for me for Patch related issues.
- 14:31:44 [cygri]
- My top issues from the second page: 32, 33, 37, 38 and 39
- 14:31:54 [bblfish]
- Issue-39?
- 14:31:54 [trackbot]
- ISSUE-39 -- HTTP status codes used for creation -- open
- 14:31:54 [trackbot]
- http://www.w3.org/2012/ldp/track/issues/39
- 14:32:01 [bblfish]
- Issue-38?
- 14:32:01 [trackbot]
- ISSUE-38 -- filtered representations and inlining -- open
- 14:32:01 [trackbot]
- http://www.w3.org/2012/ldp/track/issues/38
- 14:32:16 [bblfish]
- Issue-37?
- 14:32:16 [trackbot]
- ISSUE-37 -- What is the LDP data model and the LDP interaction model? -- open
- 14:32:16 [trackbot]
- http://www.w3.org/2012/ldp/track/issues/37
- 14:32:23 [bblfish]
- Issue-33?
- 14:32:23 [trackbot]
- ISSUE-33 -- Pagination for non-container resources -- open
- 14:32:23 [trackbot]
- http://www.w3.org/2012/ldp/track/issues/33
- 14:32:29 [bblfish]
- Issue-32?
- 14:32:29 [trackbot]
- ISSUE-32 -- How can clients discover that a resource is an LDPR or LDPC, and what features are supported? -- open
- 14:32:29 [trackbot]
- http://www.w3.org/2012/ldp/track/issues/32
- 14:33:02 [bblfish]
- Hi
- 14:33:05 [cygri]
- zakim, who is on the phone?
- 14:33:05 [Zakim]
- On the phone I see +1.617.715.aaaa, bblfish
- 14:33:06 [betehess_laptop]
- s/Hi//
- 14:33:13 [bblfish]
- yes, bad connection though from here.
- 14:33:37 [betehess_laptop]
- s/yes, bad connection though from here.//
- 14:33:49 [sandro]
- Zakim, who is on the call?
- 14:33:49 [Zakim]
- On the phone I see +1.617.715.aaaa, bblfish
- 14:34:06 [SteveS]
- I'm for ISSUE-27 if it is generalized for just patch
- 14:34:12 [bblfish]
- I can't say that I have a bad connection to the group, and that it's a bit choppy?
- 14:34:36 [bblfish]
- Issue-43?
- 14:34:36 [trackbot]
- ISSUE-43 -- hint at naming a resource on creation -- open
- 14:34:36 [trackbot]
- http://www.w3.org/2012/ldp/track/issues/43
- 14:34:43 [bblfish]
- +1 for +43
- 14:35:06 [betehess_laptop]
- s/I can't say that I have a bad connection to the group, and that it's a bit choppy?//
- 14:35:08 [SteveS]
- +1 for 43
- 14:35:09 [bblfish]
- I want it to be archived that I have a choppy connection.
- 14:35:49 [bblfish]
- what issues are you speaking of?
- 14:35:58 [betehess_laptop]
- I'd be ok to close ISSUE-28 but I'd like the group to motivate the reason :-)
- 14:36:59 [betehess_laptop]
- and the spec could even state that transactions are not handled
- 14:38:25 [betehess_laptop]
- Arnaud: some of the issues are not very controversial
- 14:38:35 [betehess_laptop]
- ... maybe we can identify and close them?
- 14:39:36 [betehess_laptop]
- ... already identified issue-18 and issue-28
- 14:40:26 [betehess_laptop]
- SteveS: issue-44 may be difficult to solve
- 14:40:38 [bblfish]
- Issue-44?
- 14:40:38 [trackbot]
- ISSUE-44 -- 4.1.9. is obscure or too restrictive -- open
- 14:40:38 [trackbot]
- http://www.w3.org/2012/ldp/track/issues/44
- 14:41:00 [SteveS]
- …maybe not difficult, just a little discussion may be needed
- 14:41:08 [cygri]
- ISSUE-28?
- 14:41:08 [trackbot]
- ISSUE-28 -- transaction/rollback when deleting resources from a LDPC -- open
- 14:41:08 [trackbot]
- http://www.w3.org/2012/ldp/track/issues/28
- 14:41:18 [betehess_laptop]
- Arnaud: ok, let's talk about the rollback one (issue-28)
- 14:41:40 [bblfish]
- yes, Issue-28 seems that it should be easy to solve
- 14:41:45 [betehess_laptop]
- Ashok: are etags enough?
- 14:41:48 [betehess_laptop]
- q+
- 14:41:57 [Arnaud]
- ack bete
- 14:41:57 [bblfish]
- s/issue-28/issue-44/
- 14:42:17 [davidwood]
- q+
- 14:42:33 [Arnaud]
- ack davidwood
- 14:42:45 [betehess_laptop]
- betehess: it would be ok for updates, no longer when you delete
- 14:42:52 [betehess_laptop]
- davidwood: got this issue recently
- 14:43:03 [betehess_laptop]
- ... etags gives all information for rollback
- 14:43:13 [betehess_laptop]
- q+
- 14:43:27 [betehess_laptop]
- ... we don't put that in the API
- 14:43:54 [betehess_laptop]
- ... providing that level of information can be challenging
- 14:44:19 [betehess_laptop]
- ... that's a lot of burden
- 14:44:40 [betehess_laptop]
- ... to figure out how to do the roll-back
- 14:44:42 [Arnaud]
- ack betehess
- 14:44:52 [SteveS]
- q+
- 14:45:36 [SteveBattle]
- q+
- 14:46:16 [betehess_laptop]
- cygri: if I think about transaction, this is different from DELETEing
- 14:46:21 [davidwood]
- s/etags gives all information for rollback/etags do not give all information necessary for rollback, especially for containers or complex resources/
- 14:47:00 [betehess_laptop]
- Arnaud: the issue is specifically about DELETEing
- 14:47:07 [betehess_laptop]
- ... not about transaction in general
- 14:47:09 [Arnaud]
- ack steves
- 14:47:36 [betehess_laptop]
- SteveS: the way we do it, we never delete anything
- 14:47:56 [betehess_laptop]
- q+
- 14:48:44 [betehess_laptop]
- q-
- 14:48:53 [Arnaud]
- ack stevebattle
- 14:48:53 [betehess_laptop]
- Arnaud: in the spec today, we have a DELETE
- 14:49:35 [betehess_laptop]
- SteveBattle: nosql technologies achieve performance keeping ACID
- 14:49:52 [betehess_laptop]
- s/achieve/do not achieve/
- 14:49:57 [bblfish]
- ? I think SteveBattle used the word "jettisoning" ... ok
- 14:50:08 [SteveBattle]
- yes I did
- 14:50:51 [SteveBattle]
- s/keeping/jettisoning/
- 14:50:52 [davidwood]
- Steve's point is well taken; we don't want to standardize LDP in a way that makes it difficult for new databases to comply. I suggest rejecting ISSUE-28.
- 14:51:00 [sandro]
- +1 saying DELETE isn't atomic
- 14:51:07 [sandro]
- +1 saying DELETE isn't NECESARILY atomic
- 14:51:25 [davidwood]
- yes, DELETE isn't NECESSARILY atomic
- 14:51:27 [SteveBattle]
- +1
- 14:51:41 [betehess_laptop]
- PROPOSAL: close issue-28 by adding in the spec: no guarantee that DELETE is atomic
- 14:51:50 [sandro]
- +1
- 14:51:52 [bblfish]
- makes sense to me
- 14:52:20 [mesteban]
- q+ Error handling
- 14:52:35 [betehess_laptop]
- cygri: are we saying that by deleting a container, we also delete the resource?
- 14:52:50 [betehess_laptop]
- sandro: would still report an error
- 14:53:01 [bblfish]
- you can't have an error with http status code if the DELETE of an LDPC fails
- 14:53:10 [Arnaud]
- q?
- 14:53:49 [SteveBattle]
- The HTTP spec says, of DELETE "This method MAY be overridden by human intervention (or other means) on the origin server. The client cannot be guaranteed that the operation has been carried out, even if the status code returned from the origin server indicates that the action has been completed successfully. "
- 14:53:55 [betehess_laptop]
- davidwood: we can send 202 to say that process was not completed
- 14:54:03 [bblfish]
- makes sense
- 14:54:38 [betehess_laptop]
- sandro: should it be propafated to deleted resources?
- 14:54:42 [betehess_laptop]
- s/propafated/propagated/
- 14:54:52 [betehess_laptop]
- q+
- 14:55:06 [betehess_laptop]
- q- Error
- 14:55:11 [betehess_laptop]
- q- handling
- 14:55:27 [sandro]
- sandro: there could be deletions that take hours, for a massive recursive delete.
- 14:55:32 [betehess_laptop]
- mesteban: wanted to comment on error handler
- 14:55:51 [betehess_laptop]
- ... if there is something that fails, we don't know what happens
- 14:55:57 [sandro]
- sandro: what happens to people who try to GET some of those resources, during the recursive deletion
- 14:56:11 [SteveS]
- This was decided at first F2F in ISSUE-25 with composition, where delete of the container delete's its members
- 14:56:45 [betehess_laptop]
- davidwood: if the error code goes in the spec, there is risk of duplication, if we don't we have other issues
- 14:56:55 [Arnaud]
- ack bete
- 14:57:37 [betehess_laptop]
- Arnaud: just remembered we have an issue about error codes ISSUE-19
- 14:57:37 [davidwood]
- s/we have other issues/we risk LDP compliant servers returning different HTTP status codes for the same situation/
- 14:58:17 [betehess_laptop]
- cygri: there are concerns about the proposal
- 14:58:37 [betehess_laptop]
- ... if some people are gone, other not, but the container is gone, that's bad
- 14:58:43 [bblfish]
- Issue-19?
- 14:58:43 [trackbot]
- ISSUE-19 -- Adressing more error cases -- open
- 14:58:43 [trackbot]
- http://www.w3.org/2012/ldp/track/issues/19
- 14:58:48 [betehess_laptop]
- ... so the container has to be there
- 14:59:01 [betehess_laptop]
- Arnaud: cygri wants to amend the proposal
- 14:59:12 [betehess_laptop]
- ... by saying that the container is not gone
- 14:59:17 [davidwood]
- Can cygri write an amended proposal?
- 14:59:52 [betehess_laptop]
- cygri: can the server check if it can delete everything before doing so?
- 14:59:55 [betehess_laptop]
- ... not always possible
- 15:00:01 [cygri]
- PROPOSAL: Server MUST NOT report with 200 to DELETEing a container unless deleting all members succeeded.
- 15:00:06 [JohnArwe]
- strawman: if the container is unable to delete all contained members, then the response to the delete requestion MUST NOT be a 2xx
- 15:00:09 [davidwood]
- +1
- 15:00:14 [sandro]
- +1
- 15:00:38 [betehess_laptop]
- Arnaud: it's a refinement
- 15:00:41 [mesteban]
- 1+
- 15:01:02 [betehess_laptop]
- cygri: what do clients see? that's the question
- 15:01:20 [SteveBattle]
- +0 (this seems to imply that the deletion occurs synchronously with the DELETE)
- 15:01:35 [nmihindu]
- +q
- 15:01:39 [Arnaud]
- ack ericp
- 15:01:42 [sandro]
- cygri: I hadn't meant to talk about atomicity really, in just the above. This isn't about one client seeing something in mid-delete from another client.
- 15:01:42 [betehess_laptop]
- ericP: not sure how to test this
- 15:01:53 [betehess_laptop]
- ... would go for SHOULD
- 15:02:12 [SteveS]
- +1
- 15:02:14 [davidwood]
- q+
- 15:02:15 [Arnaud]
- ack nmihindu
- 15:02:36 [betehess_laptop]
- nmihindu: agrees with cygri's idea
- 15:02:43 [betehess_laptop]
- ... container should be there
- 15:02:56 [davidwood]
- q-
- 15:02:57 [SteveBattle]
- I agree with nmhindu
- 15:03:10 [betehess_laptop]
- ... there are issues with 202
- 15:03:12 [JohnArwe]
- @stevebattle, was thinking similarly ... might need arnaud's original qualification as a note
- 15:03:15 [sandro]
- q?
- 15:03:16 [betehess_laptop]
- ... should be 2xx
- 15:03:34 [sandro]
- The key thing is that a container must exist if any of its elements exists.
- 15:04:04 [betehess_laptop]
- @@: with 202, you provide a URI to monitor the operation
- 15:04:28 [AndyS]
- AndyS has joined #ldp
- 15:04:28 [betehess_laptop]
- Arnaud: we all agree, we just need the proper wording
- 15:04:30 [davidwood]
- The problem with 2XX is that a server may not know whether resources can be deleted at the time it responds to a client. It could fail later!
- 15:05:43 [cygri]
- PROPOSAL: A server MUST NOT delete a container unless it could delete all members. A server MUST NOT respond 200 unless deleting the container and all members succeeded
- 15:05:58 [sandro]
- PROPOSED: A server MUST NOT consider a contain deleted unless all its elements have been deleted. A server MUST NOT report that the container has been deleted until it has been. For example, it could use a 202.
- 15:06:10 [roger]
- roger has joined #ldp
- 15:06:38 [SteveBattle]
- q+
- 15:06:48 [sandro]
- no real conflict between these.
- 15:07:08 [Arnaud]
- ack steveb
- 15:07:33 [sandro]
- SteveBattle: Note we're being stronger than HTTP, which allows server to report deletion and not delete it.
- 15:07:43 [sandro]
- (agreed)
- 15:07:51 [cygri]
- PROPOSAL: A server MUST NOT delete a container unless all members have been successfully deleted. A server MUST NOT respond 200 unless deleting the container and all members succeeded.
- 15:07:58 [sandro]
- +1
- 15:08:01 [davidwood]
- +1
- 15:08:03 [rgarcia]
- +1
- 15:08:06 [SteveBattle]
- +1
- 15:08:06 [TallTed]
- TallTed has joined #ldp
- 15:08:07 [krp]
- 1
- 15:08:07 [betehess_laptop]
- +1
- 15:08:08 [bblfish]
- +1
- 15:08:08 [krp]
- 1+1
- 15:08:10 [Arnaud]
- +1
- 15:08:11 [JohnArwe]
- +1
- 15:08:12 [nmihindu]
- +1
- 15:08:12 [SteveS]
- +1
- 15:08:14 [roger]
- +1
- 15:08:14 [Ashok]
- +1
- 15:08:16 [mesteban]
- +1
- 15:08:21 [cody]
- +1
- 15:08:25 [ericP]
- +1
- 15:08:40 [sandro]
- RRSAgent, pointer?
- 15:08:40 [RRSAgent]
- See http://www.w3.org/2013/03/13-ldp-irc#T15-08-40
- 15:08:48 [betehess_laptop]
- RESOLVED: A server MUST NOT delete a container unless all members have been successfully deleted. A server MUST NOT respond 200 unless deleting the container and all members succeeded.
- 15:08:58 [Arnaud]
- that was RESOLVED: Issue-28
- 15:09:00 [sandro]
- close issue-28
- 15:09:00 [trackbot]
- Closed ISSUE-28 transaction/rollback when deleting resources from a LDPC.
- 15:09:08 [sandro]
- issue-28?
- 15:09:08 [trackbot]
- ISSUE-28 -- transaction/rollback when deleting resources from a LDPC -- closed
- 15:09:08 [trackbot]
- http://www.w3.org/2012/ldp/track/issues/28
- 15:09:21 [bblfish]
- Issue-12?
- 15:09:21 [trackbot]
- ISSUE-12 -- Can HTTP PATCH be used for resource creation? -- closed
- 15:09:21 [trackbot]
- http://www.w3.org/2012/ldp/track/issues/12
- 15:09:24 [ericP]
- Zakim, who is here?
- 15:09:24 [Zakim]
- On the phone I see +1.617.715.aaaa, bblfish
- 15:09:25 [Zakim]
- On IRC I see TallTed, roger, AndyS, gavinc, mesteban, davidwood, Ashok, SteveBattle, krp, JohnArwe, cody, SteveS, nmihindu, Zakim, RRSAgent, cygri, rgarcia, betehess_laptop,
- 15:09:26 [Zakim]
- ... Arnaud, bblfish, sandro, ericP, Yves, thschee, betehess, trackbot
- 15:09:30 [roger]
- issue-39?
- 15:09:30 [trackbot]
- ISSUE-39 -- HTTP status codes used for creation -- open
- 15:09:30 [trackbot]
- http://www.w3.org/2012/ldp/track/issues/39
- 15:09:44 [bblfish]
- ok
- 15:09:51 [Zakim]
- -bblfish
- 15:12:00 [Zakim]
- - +1.617.715.aaaa
- 15:12:01 [Zakim]
- Team_(ldp)13:28Z has ended
- 15:12:01 [Zakim]
- Attendees were +1.617.715.aaaa, bblfish
- 15:12:58 [ericP]
- Zakim, move 53794 to here
- 15:12:59 [Zakim]
- ok, ericP; that matches SW_LDP(F2F)10:45AM
- 15:13:06 [ericP]
- Zakim, who is here?
- 15:13:06 [Zakim]
- On the phone I see +1.617.715.aaaa
- 15:13:07 [Zakim]
- On IRC I see TallTed, roger, AndyS, gavinc, mesteban, davidwood, Ashok, SteveBattle, krp, JohnArwe, cody, SteveS, nmihindu, Zakim, RRSAgent, cygri, betehess_laptop, Arnaud,
- 15:13:07 [Zakim]
- ... bblfish, sandro, ericP, Yves, thschee, betehess, trackbot
- 15:21:40 [rgarcia]
- rgarcia has joined #ldp
- 15:22:36 [SteveS]
- SteveS has joined #ldp
- 15:22:53 [ericP]
- Zakim, aaaa is WG-meeting
- 15:22:53 [Zakim]
- +WG-meeting; got it
- 15:24:11 [mesteban]
- arnaud:
- 15:24:23 [AndyS]
- AndyS has left #ldp
- 15:24:39 [SteveS]
- ISSUE-43
- 15:24:39 [trackbot]
- ISSUE-43 -- hint at naming a resource on creation -- open
- 15:24:39 [trackbot]
- http://www.w3.org/2012/ldp/track/issues/43
- 15:25:13 [SteveS]
- PROPOSAL: Support Slug header hint per Atom https://tools.ietf.org/html/rfc5023#section-9.7
- 15:25:50 [SteveBattle]
- q+
- 15:26:04 [mesteban]
- arnoud: steve's proposal consistent with the other proposal
- 15:26:12 [roger]
- roger has joined #ldp
- 15:26:15 [roger]
- roger has left #ldp
- 15:26:24 [mesteban]
- arnoud: the proposal is to use the slug header
- 15:26:30 [sandro]
- +0 (seems fine, even if annoyingly named)
- 15:26:43 [SteveBattle]
- +1 (I like the name)
- 15:26:55 [roger]
- roger has joined #ldp
- 15:26:58 [mesteban]
- arnoud: does it need to be clarified?
- 15:27:21 [cygri]
- q+
- 15:27:25 [bhyland]
- bhyland has joined #ldp
- 15:27:36 [ericP]
- https://tools.ietf.org/html/rfc5023#section-9.7.2
- 15:27:45 [nmihindu]
- s/arnoud/Arnaud
- 15:29:15 [mesteban]
- cygri: the proposal is about part of the URI (final part) or full URI?
- 15:30:21 [SteveS]
- q+
- 15:30:38 [mesteban]
- ericP: we can constrain the way it works
- 15:30:39 [roger]
- +q
- 15:30:47 [betehess_laptop]
- q+
- 15:31:12 [mesteban]
- cygri: much better if what the user provides is a ui
- 15:31:30 [mesteban]
- rgarcia: the spec just says that the values are for the fragment
- 15:31:32 [Arnaud]
- ack steveb
- 15:32:03 [cygri]
- ack me
- 15:32:10 [rgarcia]
- s/for the fragment/for the last URI segment/
- 15:32:24 [mesteban]
- SteveBattle: WE ARE NOT LImited to use slug headers. Could use the other as well.
- 15:32:36 [Arnaud]
- ack steves
- 15:32:47 [TallTed]
- s/WE ARE NOT LImited/We are not limited/
- 15:33:26 [cygri]
- q+
- 15:33:27 [Arnaud]
- ack roger
- 15:34:24 [mesteban]
- roger: the slug could be generilized and the have a general way for parsing names in the server
- 15:35:05 [Arnaud]
- ack bete
- 15:35:22 [mesteban]
- krp: but slug is specific for resource names
- 15:36:13 [Arnaud]
- ack cygri
- 15:36:37 [mesteban]
- betehess: slug is enoguh in terms that can be used for complex scenarios.
- 15:36:55 [sandro]
- "slug" could be a retronym for suggested-location-uri-guess :-)
- 15:37:09 [mesteban]
- cygri: there is no harm in having this in the spec
- 15:38:11 [mesteban]
- cygri: no difference it is normative of informative as it is optional.
- 15:38:13 [SteveBattle]
- Is this expressed as MAY or SHOULD?
- 15:38:18 [sandro]
- or Suggested Location URI Guide
- 15:38:44 [mesteban]
- rgarcia: could go to the deployment
- 15:39:26 [mesteban]
- krp: the spec says that the server may ignore slug headers
- 15:40:05 [betehess_laptop]
- q+
- 15:40:16 [Arnaud]
- ack bete
- 15:40:32 [bblfish]
- bblfish has joined #ldp
- 15:40:48 [mesteban]
- betehess: do I have as a developer a way to know if I can use slug or not?
- 15:41:12 [SteveS]
- PROPOSAL: LDP server MAY use Slug header hint per Atom https://tools.ietf.org/html/rfc5023#section-9.7 for naming resources on creation
- 15:41:25 [mesteban]
- arnoud: think there is value in having it in the spec
- 15:41:39 [SteveBattle]
- +1
- 15:41:51 [mesteban]
- sandro: suggest to use slug instead of having to do something custom to solve the issue
- 15:42:14 [Zakim]
- +bblfish
- 15:42:15 [rgarcia]
- q+
- 15:42:53 [bblfish]
- +1 for Slug
- 15:42:59 [mesteban]
- cygri: people can use the mechanism regardless what we say in the spec, so there is no problem on having a note pointing to it in the spec
- 15:43:32 [Arnaud]
- ack rgarcia
- 15:43:45 [ericP]
- q+ to suggest "RFC5023 defines a Slug: header with which the client can request a name for the created resource. The requested name may be an absolute URL to a resource or directory, or a relative URL which is relative to the container creating the resource."
- 15:43:46 [mesteban]
- rgarcia: slug description is enough, but as all of the spec is about MAYs, there is not point to include it as part of the spec.
- 15:43:58 [mesteban]
- rgarcia: better move it to the deployment guide.
- 15:44:17 [TallTed]
- ericP - inaccurate representation of the definition in 5023...
- 15:44:19 [mesteban]
- cygri: deployment guide is more about best practicas, spec about features.
- 15:44:22 [Arnaud]
- ack eric
- 15:44:22 [Zakim]
- ericP, you wanted to suggest "RFC5023 defines a Slug: header with which the client can request a name for the created resource. The requested name may be an absolute URL to a
- 15:44:25 [Zakim]
- ... resource or directory, or a relative URL which is relative to the container creating the resource."
- 15:45:20 [mesteban]
- cygri: slug is about values/words not URLs.
- 15:45:35 [mesteban]
- ericP: but we could constraint a little bit more
- 15:45:38 [bblfish]
- I am not sure about full URLs as slug headers
- 15:45:54 [bblfish]
- it seems that slug headers are just a way to give a name to the final part of a resource
- 15:46:11 [nmihindu]
- +q
- 15:46:33 [nmihindu]
- -q
- 15:46:36 [bblfish]
- me can hear voiced on phone from here ( goes up and down ) but I just moved to a café.
- 15:47:01 [mesteban]
- cygri: restricting is a bad idea because it poses extra problems onto the server
- 15:47:45 [bblfish]
- yes, agree the slug header is not a relative URL
- 15:47:52 [cygri]
- PROPOSAL: Close ISSUE-43 by adding to our spec along these lines: "Note: Atom defines a Slug header that clients can use to provide a hint for naming the POSTed resource."
- 15:48:09 [SteveBattle]
- q+
- 15:48:23 [betehess_laptop]
- q+ to suggest to be lax, so that we can support patterns later, eg. /MM/yy/dd-minutes.html
- 15:48:23 [JohnArwe]
- Henry - "is not" ?= cannot (ever) be, or is ordinarily not
- 15:48:34 [mesteban]
- krp: could have different means to deal with the URL scenario and dealing just with a bunch of words.
- 15:48:46 [bblfish]
- In Atom it is not. That's not the type of tool it is. It's a very light weight tool
- 15:48:50 [rgarcia]
- +1 (changing "can use" for "MAY use")
- 15:48:56 [bblfish]
- to just hint at the name
- 15:49:19 [bblfish]
- doing more than Atom should be a different issue.
- 15:49:38 [rgarcia]
- +q
- 15:50:11 [bblfish]
- initial slugs: initial .. and / are not relative urls in the slug. They would get encoded I think.
- 15:50:11 [Arnaud]
- ack steveb
- 15:50:20 [mesteban]
- ericP: the idea is enable users to have clear expectations about the naming of new resources.
- 15:50:30 [Arnaud]
- ack bete
- 15:50:30 [Zakim]
- betehess_laptop, you wanted to suggest to be lax, so that we can support patterns later, eg. /MM/yy/dd-minutes.html
- 15:50:32 [betehess_laptop]
- q-
- 15:50:41 [Arnaud]
- ack rgarcia
- 15:51:27 [mesteban]
- rgarcia: Richard proposal might need rewording to clarify whether the user has to stick to it or not.
- 15:51:54 [Ashok]
- q+
- 15:52:17 [Arnaud]
- ack ashok
- 15:52:17 [mesteban]
- cygri: making a normative statement raises the bar regarding requirements
- 15:52:20 [betehess_laptop]
- q+
- 15:52:36 [bblfish]
- q+
- 15:52:43 [Arnaud]
- ack bete
- 15:53:23 [mesteban]
- Ashok: better to point them to the slug spec and let them refer to it.
- 15:53:28 [TallTed]
- PROPOSAL: Servers MAY support the Slug header defined within the Atom spec in minting the new resource URI, MAY mint the new resource URI based on RDF content, MAY mint the new resource URI based on internal mechanisms... or MAY do anything it likes.
- 15:53:41 [JohnArwe]
- @ericp: 5023 9.7.1 does say that the slugtext (field value) is a percent-encoded value. which (looking at 3986 2.1 and 2.2 pretty much says that any / would NOT be interpreted as a relative URI (since it would be encoded), which makes .. and . irrelevant too
- 15:54:19 [mesteban]
- betehess: regardless what we say now we can later go back and constraint its usage in LDP.
- 15:54:58 [Arnaud]
- ack bblfish
- 15:55:21 [JohnArwe]
- we're not hearing you yet
- 15:55:29 [mesteban]
- TallTed: there are many options regarding how the server may implement the naming scheme
- 15:56:19 [davidwood]
- It seems to me that LDP servers should just decode the percent-encoding when received.
- 15:56:35 [ericP]
- @JohnArwe, I agree with that interpretation. Do we need text so that no one makes the mistake I made?
- 15:56:37 [betehess_laptop]
- -1 against anything will not give enough expectations to the client
- 15:56:44 [davidwood]
- perhaps
- 15:56:46 [mesteban]
- arnoud: there as agreement on what we want to do the points is in the way we write it down
- 15:57:03 [betehess_laptop]
- s/anything/anything which/
- 15:57:34 [nmihindu]
- s/arnoud/Arnaud
- 15:57:56 [betehess_laptop]
- q+
- 15:57:58 [ericP]
- betehess_laptop, i think that if we want stronger semantics, we can't use Slug: anyways
- 15:58:01 [TallTed]
- more seriously --
- 15:58:01 [TallTed]
- PROPOSAL: LDP Server SHOULD advertise whether it will arbitrarily mint new resource URIs or will accept hints from clients; if the latter, Server should advertise whether it supports the Slug header defined within the Atom spec, or will try to use resource content (whether RDF or otherwise), or otherwise.
- 15:58:19 [mesteban]
- cygri: argument against writing as a MAY is the possibility of misunderstanding.
- 15:58:29 [SteveS]
- For context the spec current says: "5.4.9 LDPC servers should assign the subject URI for the resource to be created using server application specific rules.", my proposal would be adding a new section here 5.4.9.1
- 15:58:31 [sandro]
- Ted, does LDP have a service description system?
- 15:58:36 [davidwood]
- q+ to suggest that servers MUST create a resource URI but SHOULD respect the slug header if present
- 15:59:16 [TallTed]
- sandro - good question. if not, the more MAY or even SHOULD we have, the more troublesome for interop.
- 15:59:21 [sandro]
- davidwood, I think it's 100% for a server to just number its resources.
- 15:59:23 [Arnaud]
- ack bete
- 15:59:27 [bblfish]
- the atom Slug spec was debated for weeks if not more on the Atom mailing list, so one should be wary of going beyond it
- 15:59:38 [mesteban]
- SteveP: in the end it is just a recommendation but the server is the one that makes up the decission and may ignore the request from the user.
- 15:59:49 [sandro]
- q?
- 16:00:07 [ericP]
- davidwood, attempted friendly ammendment: s/SHOULD/MAY/ as a server shouldn't be held in minor contempt if it follows its own naming scheme
- 16:00:19 [sandro]
- q+ to say this is just for human readability, so there is no interop question.
- 16:00:26 [mesteban]
- betehess: better to stick with one and make it clear in the spec, regardles we need to extend it semantics/usage later to better fit our requirments.
- 16:00:29 [bblfish]
- kind of ok, to move from MAY to SHOULD.
- 16:01:16 [Arnaud]
- ack david
- 16:01:16 [Zakim]
- davidwood, you wanted to suggest that servers MUST create a resource URI but SHOULD respect the slug header if present
- 16:01:37 [SteveBattle]
- I agree with the 'strengthening' of MAY to SHOULD of SteveS proposal. This gives the right signal to developers.
- 16:02:27 [mesteban]
- davidwood: if the client provides the slug header the server should respect the header.
- 16:02:42 [mesteban]
- arnoud: but the spec says the opposite
- 16:02:49 [ericP]
- q+ to say that we really shouldn't add semantics to the Slug header on our implementation 'cause the existing text says that e.g. {date}-foo would be %-encoded instead of intpreted as a URL template
- 16:02:57 [mesteban]
- davidwood: it is just looking it from the positive side
- 16:03:28 [mesteban]
- cygri: that is ambiguous, the LDP spec should be clear with this respect
- 16:03:54 [Arnaud]
- ack sandro
- 16:03:54 [Zakim]
- sandro, you wanted to say this is just for human readability, so there is no interop question.
- 16:04:02 [betehess_laptop]
- q+ to say that for me, it should be a MUST, with a section on what hints must be supported, with the semantics
- 16:04:41 [Arnaud]
- ack eric
- 16:04:41 [Zakim]
- ericP, you wanted to say that we really shouldn't add semantics to the Slug header on our implementation 'cause the existing text says that e.g. {date}-foo would be %-encoded
- 16:04:45 [Zakim]
- ... instead of intpreted as a URL template
- 16:04:50 [bblfish]
- yes. there could also be servers that don't want semantics in the names for security reasons
- 16:05:17 [cygri]
- q+
- 16:05:20 [bblfish]
- ( so I think I am agreeing with Sandro there )
- 16:05:26 [davidwood]
- PROPOSAL: An LDP server SHOULD use the decoded value of a Slug header to construct a URI for a resource, if present.
- 16:05:41 [mesteban]
- sandro: we should not mix interoperability specific features with human readability issues.
- 16:05:43 [davidwood]
- or maybe:
- 16:05:55 [Arnaud]
- ack bete
- 16:05:55 [Zakim]
- betehess_laptop, you wanted to say that for me, it should be a MUST, with a section on what hints must be supported, with the semantics
- 16:06:12 [davidwood]
- PROPOSAL: An LDP server SHOULD append the decoded value of a Slug header to the container URI to construct a URI for a resource, if present.
- 16:06:30 [ericP]
- +1
- 16:07:36 [JohnArwe]
- q+
- 16:07:39 [mesteban]
- betehess: we can be clear in the spec about using slug LDP because the server has the option to ignore it
- 16:07:40 [Arnaud]
- ack cygri
- 16:08:00 [SteveBattle]
- Should we say that the server makes a 'best attempt to append the decoded value'. ie. what if the resource already exists, does the decoded value include additional disambiguation characters?
- 16:08:10 [sandro]
- +1 cygri: if you want something stronger than MAY, then propose a new header.
- 16:08:17 [ericP]
- +1
- 16:08:20 [rgarcia]
- +1 cygri
- 16:08:27 [davidwood]
- A new header is OK by me
- 16:08:30 [mesteban]
- cygri: if anybody requires some more restricted semantics they should come up with an specific mechanism a not rely on slug headers.
- 16:08:49 [sandro]
- q?
- 16:09:15 [ericP]
- but there remains the question of whether we adopt davidwood's text which tells you that MAY be interpted by decoding and appening to the container URI
- 16:09:16 [sandro]
- q+ to ask about use case - PUT into a container?
- 16:09:24 [mesteban]
- cygri: the norm is that the server decides, not the client, but that a client may provide a hint.
- 16:10:08 [Arnaud]
- ack john
- 16:10:34 [bblfish]
- q+
- 16:11:03 [Arnaud]
- ack sandro
- 16:11:03 [Zakim]
- sandro, you wanted to ask about use case - PUT into a container?
- 16:11:19 [davidwood]
- PROPOSAL: LDP will define a new HTTP header called LDP-Slug. An LDP server SHOULD append the decoded value of a LDP-Slug header to the container URI to construct a URI for a resource, if present.
- 16:11:54 [ericP]
- i'm not sure we need anything other than Slug: for that header
- 16:12:09 [davidwood]
- I agree, but others seem to be
- 16:12:11 [Arnaud]
- ack bblfish
- 16:12:11 [ericP]
- i think betehess_laptop wants LDP-Tmplate:
- 16:12:16 [mesteban]
- sandro: if there is an special need that does not align with slug then a new proposal is to be maked backed by use cases, etc.
- 16:12:30 [sandro]
- davidwood, what's the use case?
- 16:12:47 [bblfish]
- thats it
- 16:12:54 [davidwood]
- Clients wish to have input into what resources become named.
- 16:13:19 [ericP]
- q+
- 16:13:27 [rgarcia]
- -1
- 16:13:35 [Arnaud]
- ack eric
- 16:14:13 [SteveBattle]
- q+
- 16:14:31 [cody]
- +1 percent encode and append to container URI
- 16:14:44 [sandro]
- q+ to suggest a process
- 16:15:00 [Arnaud]
- ack steveb
- 16:15:02 [cygri]
- q+
- 16:15:12 [Arnaud]
- ack sandro
- 16:15:12 [Zakim]
- sandro, you wanted to suggest a process
- 16:15:17 [mesteban]
- ericP: cygri's point is just to let users know about the slug header, davidwood's point to let them know how this is interpreted within LDP and betehess's proposals is an extension that requires a new header
- 16:16:05 [Arnaud]
- ack cygri
- 16:16:23 [SteveS]
- q+
- 16:16:46 [betehess_laptop]
- I disagree with the statement that what I'm saying is in contradiction with the Slug spec, because the server might still interpret the hint. we can always build on top of that
- 16:16:51 [Arnaud]
- ack steves
- 16:16:54 [mesteban]
- cygri: davidwood proposal needs some additional details to be provided that might be tricky
- 16:17:15 [SteveBattle]
- I'm not sure David's proposal works straightforwardly with weak aggregation (if we allow that - I'm happy to outlaw weak aggregation).
- 16:17:51 [sandro]
- arnaud: (1) use slug as is, (2) use slug and add to it, (3) create some new header
- 16:18:23 [mesteban]
- SteveS: we can have a mix of cygri and davidwood proposals in which we say that slug is an option and that the LDP spec still has to decide how it is to be interpreted.
- 16:18:56 [ericP]
- 0, +1, -1
- 16:19:05 [bblfish]
- +1, +1, -1
- 16:19:08 [davidwood]
- 0, +1, 0
- 16:19:13 [Ashok]
- +1,-1,-1
- 16:19:22 [SteveS]
- 0, +1, 0
- 16:19:24 [rgarcia]
- +1, -1, -1
- 16:19:24 [SteveBattle]
- +1,0,-1
- 16:19:26 [mesteban]
- +1, 0, +1
- 16:19:27 [sandro]
- +1, 0, 0
- 16:19:32 [betehess_laptop]
- 0, +1, 0
- 16:19:38 [krp]
- +1, 0, -1
- 16:19:42 [cygri]
- +1, -0.25, -1
- 16:19:42 [nmihindu]
- +1, -0, -1
- 16:19:42 [TallTed]
- 0, -1, 0
- 16:19:47 [JohnArwe]
- +0, -1, -1
- 16:20:06 [roger]
- +1, -1, -1
- 16:21:17 [Arnaud]
- resolved: user slug as is
- 16:21:22 [Arnaud]
- s/user/use/
- 16:21:41 [mesteban]
- Arnaud: there is consensus in using slug as is, there is still the issue if this solves issue 43.
- 16:21:59 [sandro]
- issue-43?
- 16:21:59 [trackbot]
- ISSUE-43 -- hint at naming a resource on creation -- open
- 16:21:59 [trackbot]
- http://www.w3.org/2012/ldp/track/issues/43
- 16:22:10 [bblfish]
- when are you back?
- 16:22:34 [Zakim]
- -bblfish
- 16:24:23 [JohnArwe]
- lunch for 35 mins henry
- 16:37:21 [TallTed]
- TallTed has joined #ldp
- 16:55:37 [jmvanel]
- jmvanel has joined #ldp
- 17:02:19 [davidwood]
- davidwood has joined #ldp
- 17:03:46 [rgarcia]
- rgarcia has joined #ldp
- 17:04:42 [SteveS]
- SteveS has joined #ldp
- 17:10:53 [cygri]
- q+
- 17:11:45 [Arnaud]
- ack cygri
- 17:11:47 [ericP]
- SteveBattle: callimachus and others use e.g. rdfs:label or skos:prefLabel
- 17:11:52 [ericP]
- ... content to just use Slug:
- 17:12:06 [ericP]
- cygri: as written, the spec says the server is in charge of inventing the URIs
- 17:12:27 [ericP]
- ... we've said that the client can provide a hint (via Slug:)
- 17:12:47 [ericP]
- ... server still at liberty to use the e.g. rdfs:label
- 17:13:05 [ericP]
- SteveBattle: do we want to tell folks "if you use anything, use Slug:"?
- 17:13:19 [mesteban]
- 1+
- 17:13:24 [ericP]
- Arnaud: i propose we don't further specifiy
- 17:13:36 [mesteban]
- +1
- 17:13:37 [rgarcia]
- +1
- 17:13:38 [cygri]
- PROPOSAL: Close ISSUE-43
- 17:13:44 [cody]
- +1
- 17:13:44 [SteveBattle]
- +1
- 17:13:48 [rgarcia]
- +1
- 17:13:49 [roger]
- roger has joined #ldp
- 17:13:51 [nmihindu]
- +1
- 17:13:56 [TallTed]
- ... with no further comment.
- 17:14:05 [roger]
- +1
- 17:14:10 [TallTed]
- +1
- 17:14:11 [SteveS]
- +1.0
- 17:14:15 [ericP]
- APPROVED
- 17:14:17 [JohnArwe]
- +1 to close with pre-lunch resolution only
- 17:14:26 [ericP]
- RESOLVED: Close ISSUE-43
- 17:14:28 [sandro]
- (with no action except as resolved before lunch, to use slug)
- 17:14:31 [betehess_laptop]
- +1 even if I still don't know the form it will take
- 17:14:34 [krp]
- +1
- 17:14:41 [sandro]
- close issue-43
- 17:14:41 [trackbot]
- Closed ISSUE-43 hint at naming a resource on creation.
- 17:14:44 [sandro]
- RRSAgent, pointer?
- 17:14:44 [RRSAgent]
- See http://www.w3.org/2013/03/13-ldp-irc#T17-14-44
- 17:14:49 [ericP]
- topic: Primer
- 17:14:59 [sandro]
- issue-43?
- 17:14:59 [trackbot]
- ISSUE-43 -- hint at naming a resource on creation -- closed
- 17:14:59 [trackbot]
- http://www.w3.org/2012/ldp/track/issues/43
- 17:15:20 [ericP]
- Arnaud: the Primer isn't required by the charter, but at F2F1, we decided to do a deployment guide
- 17:15:37 [ericP]
- ... we've since moved best practice text out of the spec.
- 17:15:56 [ericP]
- ... since then, we've decided that the audience of the deployment guide is implementors of the spec
- 17:16:04 [ericP]
- ... the Primer would be for users of the spec
- 17:16:05 [sandro]
- RRSAgent, make records public
- 17:16:44 [ericP]
- ... so more educational material goes into the Primer
- 17:17:32 [ericP]
- ... who writes this Primer?
- 17:18:11 [ericP]
- JohnArwe: i think there's an 85% chance that i'll have to write one anyways
- 17:18:40 [ericP]
- SteveS: Primer is 4th on my priority list. once they're done...
- 17:21:03 [davidwood]
- davidwood has joined #ldp
- 17:21:14 [ericP]
- Arnaud: work on the spec will take cycles from the WG
- 17:21:22 [ericP]
- ... my priority is the spec
- 17:22:17 [ericP]
- davidwood: i'll volunteer to work on the Primer after may
- 17:23:14 [ericP]
- topic: closing issues
- 17:24:41 [nmihindu]
- Arnaud, the issues that were mentioned important in the morning - 15, 21, 27, 32, 33, 37, 38, 39
- 17:25:49 [Arnaud]
- thanks Nandana
- 17:26:10 [ericP]
- roger: in issue-39, sometimes you don't can't instantly create resources
- 17:26:36 [Arnaud]
- topic: issue-39
- 17:26:56 [ericP]
- JohnArwe: if you return 202, you have to return a monitor to the client
- 17:27:55 [ericP]
- ... 2616 says that the server can return the monitor in the response body
- 17:28:50 [ericP]
- roger: if you POST to create a resource, you don't need a monitor 'cause the client can GET the location header
- 17:29:16 [ericP]
- JohnArwe: 202 doesn't specifically mention a Location: header
- 17:30:00 [ericP]
- tallted: can I GET the resource being created and see 202s until it's ready?
- 17:30:40 [ericP]
- JohnArwe: i don't believe it's prohibited, but also not suggested
- 17:30:51 [ericP]
- ... who uses 202s?
- 17:31:05 [ericP]
- davidwood: i've seen it in the wild and we use it
- 17:32:03 [ericP]
- tallted: when 202 is used, does the server provide a polling address?
- 17:32:20 [TallTed]
- TallTed has joined #ldp
- 17:32:20 [ericP]
- davidwood: we give the same address as the polling address
- 17:32:28 [ericP]
- ericP: but you could de-couple that in the future
- 17:32:29 [SteveS]
- q+
- 17:33:14 [ericP]
- SteveS: currently, it must return a 201 when it's created a resource
- 17:33:33 [ericP]
- ... we don't need to weaken it, but we can provide more guidance when you can't create the resource
- 17:33:42 [SteveS]
- q-
- 17:34:17 [ericP]
- cygri: one pattern is that a POST returns a redirect (303) to the created resource
- 17:34:40 [ericP]
- ... normal web browsers don't know not to render the body of a 201
- 17:35:20 [ericP]
- ... current text prohibits this pattern
- 17:36:34 [JohnArwe]
- 2616 section 9.5 (POST) says, wrt to 303s: Responses to this method are not cacheable, unless the response
- 17:36:34 [JohnArwe]
- includes appropriate Cache-Control or Expires header fields. However,
- 17:36:34 [JohnArwe]
- the 303 (See Other) response can be used to direct the user agent to
- 17:36:34 [JohnArwe]
- retrieve a cacheable resource.
- 17:36:40 [ericP]
- ... we want to make it easy for clients to find the created resource
- 17:37:00 [ericP]
- ... saying 201, Location:, no body makes that easy
- 17:37:21 [ericP]
- ... but it forbids deferred creation and redirect to cachable resource patterns
- 17:38:56 [ericP]
- ... maybe we can generalize to "the Location: header must have the location of the created resource. the response code may be any successful value"
- 17:39:28 [ericP]
- Arnaud: we could just not mention the response code, just lean on HTTP
- 17:39:41 [ericP]
- JohnArwe: Location: is defined only for 303 and 201
- 17:43:14 [betehess_laptop]
- why not make 2 scenarios: synchronous and asynchronous? the server would decide, but we would have to spec both methods
- 17:43:40 [betehess_laptop]
- q+
- 17:44:37 [SteveS]
- q+
- 17:44:55 [Arnaud]
- ack bete
- 17:45:27 [ericP]
- betehess_laptop: since we have only two scenarios, should we just specify both the asynch and synch scenarios?
- 17:45:53 [ericP]
- ... 303 and 201 are pretty similar
- 17:46:25 [ericP]
- cygri: 303 explicity tells the client to dereference the Location: header and 201 does not
- 17:46:34 [ericP]
- ... normal web browsers observe 303
- 17:46:53 [ericP]
- ... HTTP says that 201 SHOULD include an entity body
- 17:47:20 [ericP]
- ... and we're saying that one MUST NOT include a body with a 201
- 17:47:30 [Arnaud]
- ack steves
- 17:48:43 [betehess_laptop]
- 201: the resource is synchronously created - 202: the resource is asynchronously created - 303: the resource is synchronously created and the server tells the client to go there
- 17:49:55 [ericP]
- scribenick: ericP
- 17:51:44 [ericP]
- cody: why would i expect a moved in response to a POST?
- 17:52:04 [ericP]
- cygri: it's more that the POST creates soemthing and then says "see this other thing"
- 17:52:23 [ericP]
- betehess_laptop: does 303 mean i was successful
- 17:52:45 [ericP]
- betehess_laptop: does 303 mean i was successful?
- 17:53:06 [ericP]
- cygri: it's a pattern you see in normal web apps
- 17:53:24 [ericP]
- sandro: that's all 303 was used for before the SemWeb [httprange14] hack
- 17:54:03 [ericP]
- betehess_laptop: are we conflating "creation" and "see other"?
- 17:54:24 [ericP]
- cygri: there's nothing in the 303 that tells you that the creation succeeded
- 17:54:25 [gavinc]
- No, the TAG did that :P
- 17:56:04 [ericP]
- ... with conventional browsers, our mandated 201 with no body means that a human user sees an empty page
- 17:56:16 [mesteban]
- q+
- 17:56:33 [ericP]
- ... use case: i'm building a browser tool for testing LDP services.
- 17:56:50 [ericP]
- ... .. i can build the POST request with a conventional HTML form
- 17:57:06 [betehess_laptop]
- so to be clear: 303 is a hack for browsers not handling 201 properly
- 17:57:33 [ericP]
- ... .. it'd be nice if the server were allowed to provide a body for the user to see
- 17:58:05 [betehess_laptop]
- q+
- 17:58:07 [Arnaud]
- ack mesteban
- 17:58:31 [ericP]
- mesteban: does the 201 with a no body mean the same thing as a 204?
- 17:58:55 [ericP]
- JohnArwe: that's probably the common interpretation but i don't think you'd see that in the HTTP spec
- 17:59:21 [ericP]
- cygri: 201 mentions the Location: header explicitly. 204 does not
- 17:59:50 [ericP]
- JohnArwe: if the request was successful and there was no body, return a 204
- 18:00:19 [Arnaud]
- ack bete
- 18:00:30 [ericP]
- ... it's not clear in HTTP whether 303 is a valid response to a creation
- 18:01:23 [Zakim]
- +bblfish
- 18:01:54 [bblfish]
- Issue-39?
- 18:01:54 [trackbot]
- ISSUE-39 -- HTTP status codes used for creation -- open
- 18:01:54 [trackbot]
- http://www.w3.org/2012/ldp/track/issues/39
- 18:02:28 [ericP]
- betehess_laptop: 303 seems to be a hack to work around clients failing to handle 201
- 18:02:42 [ericP]
- ... if we just want to say it was created, we should use the 201
- 18:03:15 [betehess_laptop]
- modern browsers can do the redirect with javascript anyway
- 18:03:41 [ericP]
- Arnaud: in order to improve interop, we should restrict the number of response codes
- 18:04:15 [ericP]
- ... roger's point was about 202
- 18:04:29 [ericP]
- ... then cygri said "what about 303?"
- 18:04:44 [ericP]
- ... what if we go back to just 201 and 202?
- 18:04:54 [ericP]
- ... do we want to add 303?
- 18:05:06 [JohnArwe]
- httpbis on 303 says: If the result of processing a POST would be equivalent to a
- 18:05:06 [JohnArwe]
- representation of an existing resource, an origin server MAY redirect
- 18:05:06 [JohnArwe]
- the user agent to that resource by sending a 303 (See Other) response
- 18:05:06 [JohnArwe]
- with the existing resource's identifier in the Location field. This
- 18:05:06 [JohnArwe]
- has the benefits of providing the user agent a resource identifier
- 18:05:06 [JohnArwe]
- and transferring the representation via a method more amenable to
- 18:05:07 [JohnArwe]
- shared caching, though at the cost of an extra request if the user
- 18:05:07 [JohnArwe]
- agent does not already have the representation cached.
- 18:05:23 [ericP]
- cygri: i'd like either 303 or 201+body
- 18:05:30 [JohnArwe]
- ...which is different than 2616's POST-303 text
- 18:05:39 [JohnArwe]
- ...and it explicitly mentions Location
- 18:05:44 [JohnArwe]
- q+
- 18:07:02 [ericP]
- ... i'd like to say "this spec doesn't restrict the body of the 201. the safe way to see the created entity is to GET the Location: header"
- 18:08:31 [Arnaud]
- ack john
- 18:08:57 [ericP]
- JohnArwe: i pasted about the 303 case. it explicitly mentions the Location: headers
- 18:09:04 [betehess_laptop]
- if we remove 5.4.5, we're just back to the HTTP spec, so I'm not against it
- 18:09:15 [Arnaud]
- proposal: delete section 5.4.5, allow servers to have an entity body in the response
- 18:09:30 [davidwood]
- +1 to removing 5.4.5
- 18:10:36 [betehess_laptop]
- 0+
- 18:10:37 [sandro]
- ericP, yes --- there's the semantic-web-303 hack. that might apply here.
- 18:10:40 [TallTed]
- +1
- 18:10:53 [mesteban]
- +1
- 18:11:08 [cygri]
- +1 to removing 5.4.5
- 18:11:11 [nmihindu]
- +1
- 18:11:13 [rgarcia]
- +1
- 18:11:14 [roger]
- +1
- 18:11:17 [krp]
- +1
- 18:11:20 [cody]
- +1 to removing 5.4.5
- 18:11:41 [SteveBattle]
- +1
- 18:12:36 [ericP]
- SteveS: the 5.4.5 "no body" text came from our need to clarify our client expections.
- 18:12:59 [ericP]
- ... some servers were responding with the clients and the clients were depending on it.
- 18:13:04 [sandro]
- SteveS: we found it easier/better to say just use the location header. the 201 body wasn't always good.
- 18:13:10 [cody]
- It sounds useful (helpful) to include somewhere that the client should not expect response. But we don't need to say that the server SHOULD NOT include it.
- 18:13:24 [ericP]
- cygri: "a client must not expect that the body of a 201 is the contents of a created resources"
- 18:13:32 [ericP]
- ... HTTP says that
- 18:14:12 [SteveS]
- +.99 plug give guidance to clients to not expect it
- 18:15:59 [Arnaud]
- PROPOSAL: delete 1st sentence of section 4.5.5, and reword the second one as informative
- 18:16:04 [bblfish]
- +1
- 18:16:04 [ericP]
- +1
- 18:16:06 [krp]
- +1
- 18:16:07 [betehess_laptop]
- +1
- 18:16:07 [rgarcia]
- +1
- 18:16:09 [nmihindu]
- +1
- 18:16:15 [cody]
- 5.4.5
- 18:16:15 [cygri]
- +1
- 18:16:20 [mesteban]
- +1
- 18:16:25 [cody]
- +1
- 18:16:26 [Arnaud]
- s/4.5.5/5.4.5/
- 18:16:33 [TallTed]
- +1
- 18:16:56 [ericP]
- RESOLVED: delete 1st sentence of section 5.4.5, and reword the second one as informative
- 18:17:20 [ericP]
- cygri: the 303 doesn't explicitly say that creation was successful
- 18:17:39 [ericP]
- ... if we say that 303 DOES imply successful creation, we're extending HTTP
- 18:18:58 [betehess_laptop]
- q+ to ask if we have to specify the monitor
- 18:19:07 [ericP]
- ... client says "please create X for me".
- 18:19:40 [ericP]
- ... server says "i've accepted your request (but i may not be successful)"
- 18:19:44 [bblfish]
- 202: http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.2.3
- 18:19:54 [ericP]
- ... so 202 doesn't as such say where the new resource might be
- 18:20:07 [SteveBattle]
- q+
- 18:20:11 [ericP]
- ... we said we could use Location:
- 18:20:21 [Arnaud]
- ack bete
- 18:20:21 [Zakim]
- betehess_laptop, you wanted to ask if we have to specify the monitor
- 18:20:27 [ericP]
- roger: yeah, Location: usually used with 201
- 18:20:52 [ericP]
- betehess_laptop: we can use the Location: header and have the client poll
- 18:21:08 [ericP]
- ... or we can use the monitor, which we need to document
- 18:21:38 [bblfish]
- Is there a use case for 202?
- 18:23:12 [SteveS]
- q+
- 18:23:24 [Arnaud]
- bblfish, yes, roger has one
- 18:23:36 [Arnaud]
- ack steveb
- 18:23:42 [ericP]
- cygri: i've never seen use of 202 on a (created) resource
- 18:23:51 [nmihindu]
- q+
- 18:24:08 [ericP]
- ericP: we may have to define the behavior of a GET on a not-yet-created resource anyways
- 18:24:19 [Arnaud]
- ack steves
- 18:24:35 [ericP]
- SteveBattle: i'm not comfortable with conflating the monitor with the created resource
- 18:24:38 [ericP]
- SteveS
- 18:25:20 [ericP]
- SteveS: in the typical case of creation, it's maybe seconds to create a resource
- 18:25:26 [Arnaud]
- ack nmihindu
- 18:26:02 [ericP]
- nmihindu: the server could return a 404 on a deferred creation.
- 18:26:32 [cygri]
- q+ to make a proposal
- 18:27:00 [ericP]
- ... the client can know that it's asking for a resource that's being created
- 18:27:03 [betehess_laptop]
- PROPOSAL: LDPC servers MUST respond with status code 201 (Created) if the resource was successfully created synchronously
- 18:27:18 [ericP]
- ... i know it's not ideal, but the client could timeout after 5 mins and decide it's not being created
- 18:27:35 [betehess_laptop]
- q+
- 18:27:54 [betehess_laptop]
- q-
- 18:27:58 [cygri]
- PROPOSAL: If the resource was created successfully, the server MUST respond with 201.
- 18:28:18 [Arnaud]
- ack cygri
- 18:28:18 [Zakim]
- cygri, you wanted to make a proposal
- 18:28:20 [SteveBattle]
- q+
- 18:28:48 [SteveS]
- +1, +1
- 18:29:02 [Arnaud]
- ack steveb
- 18:29:38 [nmihindu]
- +1
- 18:29:40 [betehess_laptop]
- +1
- 18:29:40 [rgarcia]
- +1
- 18:29:41 [krp]
- +1
- 18:29:42 [bblfish]
- +1
- 18:29:42 [mesteban]
- +1
- 18:29:43 [roger]
- +1
- 18:29:52 [ericP]
- +1
- 18:30:01 [davidwood]
- +1
- 18:30:06 [TallTed]
- +1
- 18:30:06 [cody]
- +1
- 18:30:10 [ericP]
- RESOLVED: If the resource was created successfully, the server MUST respond with 201.
- 18:31:08 [ericP]
- RESOLVED: close ISSUE-39
- 18:31:30 [SteveBattle]
- My suggestion for the status monitor is to use the container itself as the monitor, specifically a hash uri within the container that has metadata for a specific request.
- 18:32:08 [Arnaud]
- "must-haves": 15, 21, 27, 32, 33, 37, 38
- 18:33:07 [ericP]
- topic: ISSUE-21
- 18:33:29 [ericP]
- Arnaud: today we have a member predicate which specifies how you indicate membership
- 18:33:42 [ericP]
- ... sometimes i want to turn that relationship around
- 18:34:42 [ericP]
- SteveBattle: exactly, if i wanted to say that the container is linked by skos:conceptScheme, the container is used as the subject
- 18:34:46 [bblfish]
- Issue-21
- 18:34:46 [trackbot]
- ISSUE-21 -- container affordances -- open
- 18:34:46 [trackbot]
- http://www.w3.org/2012/ldp/track/issues/21
- 18:34:56 [ericP]
- s/used as the subject/used as the object/
- 18:35:24 [betehess_laptop]
- q+
- 18:35:35 [nmihindu]
- example - http://lists.w3.org/Archives/Public/public-ldp-wg/2013Mar/0057.html
- 18:35:49 [ericP]
- davidwood: seems reasonable, but why do you *prefer* this?
- 18:35:58 [ericP]
- SteveBattle: to use the skos vocab
- 18:36:10 [cygri]
- q+
- 18:37:32 [ericP]
- Arnaud: following up that email, you've made a proposal
- 18:37:38 [Arnaud]
- ack bete
- 18:38:06 [ericP]
- betehess_laptop: Q: do we have to choose either membershipPredicate or reverseMembershipPredicate?
- 18:38:27 [JohnArwe]
- ...said choice being _on a single LDPC_
- 18:38:39 [sandro]
- q+ to suggest the name be MembershipPredicateInverse (since OWL calls it "inverse" not "reverse", and "InverseMembershipPredicate" doesn't sound right.)
- 18:38:47 [ericP]
- ... i've implemented a client that just follows links and it can't follow this reversal
- 18:38:49 [Arnaud]
- ack cygri
- 18:39:04 [ericP]
- SteveBattle: that's confusing navigability with arc direction
- 18:39:26 [ericP]
- cygri: you shouldn't be restricted to only following links from subject to object
- 18:41:03 [ericP]
- ericP: i think this assumes that arc direction prescribes authority
- 18:41:43 [Ashok]
- q+
- 18:43:18 [Arnaud]
- ack sandro
- 18:43:18 [Zakim]
- sandro, you wanted to suggest the name be MembershipPredicateInverse (since OWL calls it "inverse" not "reverse", and "InverseMembershipPredicate" doesn't sound right.)
- 18:43:33 [ericP]
- sounds like access-limited logic to me
- 18:43:37 [ericP]
- -> http://www.cs.utexas.edu/users/qr/algernon.html Access-Limited Logic
- 18:43:51 [cygri]
- sandro, how about: <> ldp:membershipPredicate [ owl:inverseOf skos:inScheme ]
- 18:44:19 [Arnaud]
- ack ashok
- 18:44:33 [ericP]
- sandro: for RDF properties, OWL follows the mathmatical convention to call this "inverse"
- 18:44:43 [sandro]
- cute cygri ... yeah.....
- 18:45:00 [cygri]
- sandro, we use that pattern in data cube
- 18:45:11 [cody]
- In OWL, for example, inverse is the terms (owl:inverseOf)
- 18:46:06 [sandro]
- cygri, do you think that's a viable alternative? I'm not sure.
- 18:46:28 [ericP]
- SteveBattle: this is mostly motivated by using skos:inScheme
- 18:47:08 [ericP]
- Arnaud: dret already expressed concearns about the membershipPredicate
- 18:47:09 [sandro]
- q?
- 18:47:21 [ericP]
- ... this adds another layer to that
- 18:47:51 [bblfish]
- inventing inverse properties is not a good idea
- 18:48:16 [ericP]
- sandro: cygri said that you can do get around ldp:reverseMembershipPredicate with ldp:membershipPredicate [ owl:inverseOf skos:inScheme ]
- 18:49:46 [ericP]
- cygri: instead of inventing a new property, we documenting an existing possible practice
- 18:49:46 [bblfish]
- that looks good. But it needs to be documented if we want clients to be able to rely on this.
- 18:50:09 [sandro]
- +1 cygri: This isn't pulling in magic OWL reasoning, it's just a bit of syntax to say the same thing.
- 18:50:52 [ericP]
- tallted: if you embed ontology in your data, i can't replace the ontolgy and still consume your data
- 18:51:38 [SteveBattle]
- There is no inverse of skis:inScheme defined in skos
- 18:51:44 [SteveBattle]
- s/skis/skos/
- 18:52:11 [sandro]
- +1 eric: this is the same code you'd need for SteveBattle's proposal
- 18:52:15 [bblfish]
- "you have to write exactly the same code" well not exactly the same code, rather the same complexity of code
- 18:53:31 [sandro]
- bblfish, the first part, where you find out what the inverse membership predicate is, would be different. It's a different graph pattern your matching. THEN it's exactly the same code.
- 18:53:41 [betehess_laptop]
- q+
- 18:54:01 [ericP]
- cygri, in SteveBattle's proposal, you must look for ldp:membershipPredicate or ldp:reverseMembershipPredicate
- 18:54:06 [ericP]
- cygri: in SteveBattle's proposal, you must look for ldp:membershipPredicate or ldp:reverseMembershipPredicate
- 18:54:39 [ericP]
- ... in my proposal you must look for ldp:membershipPredicate x or ldp:membershipPredicate [ owl:inverseOf x ] .
- 18:55:06 [Arnaud]
- ack bete
- 18:55:30 [SteveS]
- q+
- 18:56:00 [Arnaud]
- ack steves
- 18:56:09 [ericP]
- PROPOSE: a container can have exactly one ldp:membershipPredicate. if the object is a URI, it's treated as a conventional ldp:membershipPredicate. if it's a bnode with a bnode with an owl:inverseOf property, it's the object of that.
- 18:56:23 [SteveBattle]
- q+
- 18:56:46 [TallTed]
- s/if it's a bnode with a bnode with an/if it's a bnode with an/
- 18:57:16 [TallTed]
- the bnode serves as inverseMembershipPredicate
- 18:57:38 [betehess_laptop]
- that looks important, but I'm still lost with the use-case and the implications of proposals...
- 18:57:48 [bblfish]
- I like the owl:inverseFunctionalProperty solution
- 18:57:49 [Arnaud]
- ack steveb
- 18:58:24 [bblfish]
- q+
- 18:58:36 [Arnaud]
- ack bblfish
- 18:58:55 [sandro]
- bblfish, too much background noise;
- 18:58:58 [JohnArwe]
- your bckgrnd noise is bad
- 18:58:58 [bblfish]
- ok
- 18:59:09 [JohnArwe]
- IRC maybe?
- 18:59:09 [ericP]
- bblfish: i'll have fries and a pint of pilsner
- 18:59:12 [bblfish]
- I am just saying that the bnode cannot be put in relation position,
- 18:59:29 [bblfish]
- so therefore the owl:inverseFunctionalProperty works correctly
- 18:59:41 [bblfish]
- since you cannot do a bnode c
- 19:00:09 [bblfish]
- using a bnode as the object of the ldp:membershipPredicate means you have to use the owl:inverseFunctionalProperty
- 19:00:13 [rgarcia]
- q+
- 19:00:13 [bblfish]
- q+
- 19:00:19 [cygri]
- q+
- 19:00:25 [bblfish]
- I wrote my argument above
- 19:00:53 [ericP]
- rgarcia: this is the first time that OWL is mentioned in this spec
- 19:01:00 [Arnaud]
- ack rgarcia
- 19:01:08 [bblfish]
- I wrote my question above
- 19:01:15 [bblfish]
- s/question/point/
- 19:01:44 [bblfish]
- owl is not such a big deal
- 19:01:47 [ericP]
- bblfish, i think that's in the proposal at 2013-03-13T18:56:09Z
- 19:02:03 [SteveBattle]
- Can we squeeze owl:sameAs in somewhere?
- 19:02:19 [bblfish]
- owl:sameAs is useful all the time
- 19:02:35 [bblfish]
- Ok. So I am arguing that the parsing is not a problem!!!!
- 19:02:51 [Arnaud]
- ack bblfish
- 19:02:58 [cygri]
- ack me
- 19:03:50 [bblfish]
- yes, the point is that you cannot put the bnode in relation position
- 19:03:59 [bblfish]
- I am not complaining
- 19:04:34 [bblfish]
- dp:membershipPredicate [ owl:inverseOf x ]
- 19:04:48 [bblfish]
- dp:membershipPredicate bnode. bnode owl:inverseOf x .
- 19:05:09 [bblfish]
- so the question was how do we know that we should use x for the property
- 19:05:17 [bblfish]
- my answer is that you cannot use the bnode as the property
- 19:05:21 [bblfish]
- therefore you must use x
- 19:05:29 [sandro]
- :-) cygri: It sounds like you don't want to use an existing URI that happens to have the right semantics because it's in the OWL namespace
- 19:06:13 [ericP]
- bblfish, i read this as you saying that you support (or at least don't shudder at) the proposal at 2013-03-13T18:56:09Z
- 19:06:20 [bblfish]
- you guys were arguing that owl semantics means that you don't know if x should be used in a relation rather than the bnode.
- 19:06:32 [bblfish]
- yes, I am supporting the approach of cygri :-)
- 19:06:37 [bblfish]
- thanks
- 19:06:44 [SteveBattle]
- We've got it
- 19:06:53 [bblfish]
- Am in a restaurant here. Got stuck in Amsterdam because of snow in Paris
- 19:08:45 [Zakim]
- -bblfish
- 19:15:15 [mesteban]
- mesteban has joined #ldp
- 19:25:16 [bblfish]
- bblfish has joined #ldp
- 19:31:27 [rgarcia]
- rgarcia has joined #ldp
- 19:31:50 [cygri]
- cygri has joined #ldp
- 19:32:03 [cygri]
- q+
- 19:32:23 [SteveS]
- SteveS has joined #ldp
- 19:33:41 [Zakim]
- +bblfish
- 19:33:55 [Arnaud]
- ack cygri
- 19:34:00 [cygri]
- cygri: how about steve's proposal with the property called ldp:membershipPredicateInverse?
- 19:34:21 [Arnaud]
- scribe: kevin
- 19:35:19 [krp]
- cygri: surprised by controversy in my proposal. is this just about owl use
- 19:35:26 [krp]
- ... or are there objections to both proposals?
- 19:35:31 [TallTed]
- so something like...
- 19:35:31 [TallTed]
- <>
- 19:35:31 [TallTed]
- dp:membershipPredicate
- 19:35:31 [TallTed]
- rdfs:member
- 19:35:31 [TallTed]
- .
- 19:35:32 [TallTed]
- <>
- 19:35:34 [TallTed]
- dp:membershipPredicateInverse
- 19:35:36 [TallTed]
- rdfs:memberOf
- 19:35:38 [TallTed]
- .
- 19:36:10 [SteveBattle]
- Yes
- 19:36:30 [cygri]
- (1) <> ldp:membershipPredicateInverse skos:inScheme .
- 19:36:47 [cygri]
- (2) <> ldp:membershipPredicate [ owl:inverseOf skos:inScheme ].
- 19:37:18 [cygri]
- (3) do nothing
- 19:37:22 [krp]
- cygri: other than the options (syntax) above the two proposals are identical
- 19:37:59 [bblfish]
- the two proposals cygri refers to are (1) and (2)
- 19:38:27 [krp]
- steves: to clarify, you can only have one property, so a predicate and an inverse predicate
- 19:39:06 [krp]
- tallted: (1) allows both a membershipPredicate and an inverse. (2) allows one or the other
- 19:39:36 [krp]
- cygri: I would expect that even for (1) we would spec that you can only have a single membership predicate
- 19:40:15 [SteveBattle]
- They're logically equivalent, but not necessarily functionally equivalent.
- 19:40:16 [krp]
- cygri: why would we allow having a forward and a reverse, but not two forwards
- 19:40:44 [cygri]
- +0 +1 -1
- 19:40:46 [SteveBattle]
- +1,0,0
- 19:40:53 [TallTed]
- +1, -1, -1
- 19:40:56 [SteveS]
- +1, +0, -0
- 19:41:03 [mesteban]
- +1,-1,0
- 19:41:06 [betehess_laptop]
- 0, 0, 1
- 19:41:07 [roger]
- 0,1,1
- 19:41:10 [rgarcia]
- +1, -1, -1
- 19:41:11 [sandro]
- 0, 0, +1
- 19:41:12 [JohnArwe]
- +0, +0, +0
- 19:41:16 [nmihindu]
- +1 -0 0
- 19:41:25 [Ashok]
- 0,0,1
- 19:41:30 [bblfish]
- I have not implemented anything with membership predicates yet, but given that people find this useful and looking at the proposal on the table I'd say +0,+1,+0
- 19:41:30 [krp]
- 0,0,0
- 19:41:45 [ericP]
- 0,1,0
- 19:41:47 [davidwood]
- -0.5, −0, +1
- 19:42:24 [cody]
- 0,0,0
- 19:42:46 [bblfish]
- Ok I'll say -0.5,_1,+0
- 19:42:54 [bblfish]
- Ok I'll say -0.5,_1,+0
- 19:43:16 [bblfish]
- Ok I'll say -0.5,+1,+0
- 19:43:21 [sandro]
- issue-21?
- 19:43:21 [trackbot]
- ISSUE-21 -- container affordances -- open
- 19:43:21 [trackbot]
- http://www.w3.org/2012/ldp/track/issues/21
- 19:43:42 [betehess_laptop]
- what was the use-case?
- 19:44:00 [TallTed]
- part 2: do we allow declaration of both membershipPredicate and membershipPredicateInverse (but each only once), or mandate that only one may be declared (with the other available from externally defined inverseOf relations!)
- 19:44:34 [cygri]
- PROPOSAL: Close ISSUE-21 by adopting http://lists.w3.org/Archives/Public/public-ldp-wg/2013Mar/0089.html with the property name ldp:membershipPredicateInverse
- 19:44:43 [SteveBattle]
- +1
- 19:44:46 [rgarcia]
- +1
- 19:44:47 [sandro]
- +1 just to be done with this
- 19:44:49 [SteveS]
- +1
- 19:44:51 [mesteban]
- +1
- 19:44:52 [betehess_laptop]
- 0
- 19:44:55 [cygri]
- 0
- 19:44:55 [nmihindu]
- +1
- 19:45:01 [cody]
- +1
- 19:45:01 [roger]
- +1
- 19:45:05 [davidwood]
- 0
- 19:45:09 [sandro]
- 0 really
- 19:45:10 [JohnArwe]
- +0
- 19:45:17 [bblfish]
- 0 I thought cygri's arguments were good, but anyway
- 19:45:20 [TallTed]
- +0
- 19:45:26 [Ashok]
- 0
- 19:45:32 [cygri]
- (voting 0 because it unnecessarily introduces a new property where an existing term from OWL could have been use)
- 19:45:42 [sandro]
- (I also liked cygri's argument, but whatever.)
- 19:45:44 [Arnaud]
- RESOLVED: Close ISSUE-21 by adopting http://lists.w3.org/Archives/Public/public-ldp-wg/2013Mar/0089.html with the property name ldp:membershipPredicateInverse
- 19:46:12 [nmihindu]
- +q
- 19:46:24 [Arnaud]
- ack nmihindu
- 19:47:50 [bblfish]
- Arnaud is saying for the record that the spec can be updated but that later issues can be reconsidered
- 19:47:53 [Arnaud]
- "must-haves": 15, 27, 32, 33, 37, 38
- 19:48:31 [krp]
- krp has joined #ldp
- 19:48:33 [sandro]
- issue-27?
- 19:48:33 [trackbot]
- ISSUE-27 -- Should the PATCH method be used, as opposed to POST with a given mime type? -- open
- 19:48:33 [trackbot]
- http://www.w3.org/2012/ldp/track/issues/27
- 19:48:40 [sandro]
- Yes
- 19:49:07 [cody]
- I worry about the OWL form possibly creating confusion. Some people may make inaccurate assumptions about LDP support for OWL just because one part of it exists there - less we explicitly spell it out. This is different than using vocabularies like dc because OWL is a vocab for expressing ontologies, not just simple properties.
- 19:50:47 [krp]
- SteveS: problems with servers and clients using PATCH, so timbl suggested (at last f2f) using POST as a substitute
- 19:50:59 [krp]
- ... for modification
- 19:51:14 [betehess_laptop]
- q+
- 19:51:22 [Ashok]
- q+
- 19:51:36 [krp]
- Arnaud: for sending changes rather then resending the all the triples
- 19:52:15 [Arnaud]
- ack bete
- 19:52:17 [krp]
- davidwood: how can you legitimately use POST for this?
- 19:52:46 [krp]
- betehess: from the conversations on the mailing list, not so much problems with the clients with PATCH
- 19:53:14 [krp]
- ... if we want to consider LDP as a SPARQL endpoint we would want to use POST with a sparql-update
- 19:54:00 [krp]
- sandro: sparql things will be doing something extra anyway, so isn't compelling for all cases ldp
- 19:54:32 [ericP]
- q+
- 19:54:33 [krp]
- betehess: one thing we have been implementing is an ldpr as its own sparql endpoint
- 19:54:49 [krp]
- sandro: but that isn't part of the ldp spec
- 19:55:16 [krp]
- sandro: the issue is which http verb(s) we should use for patch
- 19:55:56 [krp]
- johnarwe: implicit proposal is either we remove patch and put post in its place; or add post and accept either
- 19:56:12 [krp]
- betehess: this doesn't make sense without knowing what is in the body
- 19:56:37 [Arnaud]
- ack ashok
- 19:56:38 [krp]
- cygri: limited options. sparql update is one
- 19:57:14 [krp]
- ashok: when you speak about patch not being implemented, is this just for RDF? Other wg have indicated they will use patch
- 19:57:17 [sandro]
- q?
- 19:57:21 [cygri]
- cygri: options for patch formats: some subset of sparql update; talis changesets; TriG with two magic graphs
- 19:57:22 [sandro]
- q+
- 19:57:42 [krp]
- steves: recollection was this this was essentially tunnelling through post
- 19:58:30 [krp]
- davidwood: is there any mainstream software having problems with patch?
- 19:58:32 [cygri]
- q?
- 19:58:33 [cygri]
- q+
- 19:58:38 [krp]
- betehess: apache?
- 19:59:22 [Arnaud]
- ack eric
- 19:59:32 [bblfish]
- Is there a problem with doing POST doing two different things depending on the mime type?
- 19:59:48 [cygri]
- betehess: HTML forms can do POST but not PATCH
- 19:59:49 [krp]
- davidwood: we shouldn't resolve a wg issue because of a systems support issue
- 20:00:19 [Arnaud]
- ack sandro
- 20:00:23 [cygri]
- q-
- 20:00:26 [krp]
- ericP: we have to decide on our patch format.
- 20:00:31 [cygri]
- q+
- 20:00:44 [bblfish]
- eric was arguing that PATCH would allow intermediate caching servers to do the right thing
- 20:01:00 [Arnaud]
- ack cygri
- 20:01:11 [krp]
- ericP: patch is the right stanard to send the format through
- 20:01:31 [krp]
- sandro: we definitely have to do patch. servers may implement other mechanisms such as post and we can allow that.
- 20:01:58 [bblfish]
- +1 on cygri's point
- 20:02:23 [krp]
- cygri: it would be odd to say posting a sparql update has one behaviour but post in another situation behaves differently
- 20:02:35 [SteveBattle]
- q+
- 20:02:46 [krp]
- betehess: for post you always have to state the mimetype
- 20:02:51 [JohnArwe]
- I'm skeptical that servers will drop support for POST-as-PATCH once it's there originally... for product implns at least, clients expect their code to work unchanged with a newer server version. We drop capability very reluctantly. True that brand new implns might skip P-a-P after a few years.
- 20:02:55 [Arnaud]
- ack steveb
- 20:03:12 [krp]
- SteveBattle: don't see need to support post in the spec as implementations will (tend to) support sparql update anyway
- 20:03:42 [krp]
- arnaud: noone is disputing doing patch, the question is whether we do post
- 20:04:02 [krp]
- ericP: do we no the consequences of not doing post? how many clients do we break?
- 20:04:21 [sandro]
- PROPOSED: Close ISSUE-27 leaving the PATCH verb as the only way patch operations are done on standard LDP servers. (Don't use POST for patching.)
- 20:04:34 [bblfish]
- +1
- 20:04:45 [roger]
- roger has joined #ldp
- 20:04:49 [nmihindu]
- s/do we no/do we know
- 20:05:12 [krp]
- cygri: there is this notion that there are these problems with PATCH. Without knowing the specifics it's hard to judge.
- 20:05:52 [betehess_laptop]
- it's important, but it's not a big deal to move forward
- 20:06:18 [krp]
- sandro: procedurally we should put it in the spec as at risk to get maximum visibility whether they is a problem with patch and we need to support post
- 20:06:53 [SteveS]
- q+
- 20:06:54 [krp]
- ericP: put in at risk for post saying this will be removed without responses
- 20:06:59 [Arnaud]
- ack steves
- 20:07:03 [sandro]
- sandro: and maximum flexibility.
- 20:07:40 [krp]
- steves: can we just say, closing as is, with an action to investigate incompatibilities with patch
- 20:08:12 [cody]
- q+
- 20:08:13 [krp]
- davidwood: close as considered, if we get further enquiries they need to provide evidence
- 20:09:30 [krp]
- arnaud: perhaps put an at risk on "no additional requirements on http post"? flagging that this might be amended to include patch-through-post?
- 20:09:44 [Arnaud]
- ack cody
- 20:09:57 [krp]
- ... the at risk pre-empts having to go back to last call if objections are raised
- 20:10:32 [bblfish]
- q+
- 20:10:36 [krp]
- cody: if we have an implementation and one single client doesn't support PATCH we'll have to implement POST... but we'd keep PATCH to be spec compliant
- 20:10:49 [Arnaud]
- ack bblfish
- 20:10:57 [krp]
- ... so the question is where do we get spec for implementing the POST method
- 20:11:29 [ericP]
- HTTP-over-POST ?
- 20:11:54 [roger]
- +q
- 20:12:03 [betehess_laptop]
- what is this workaround?
- 20:12:04 [Arnaud]
- ack roger
- 20:12:07 [krp]
- bblfish: do we have problems with PUT, DELETE? There are factory(?) mechanisms in Atom to work around these situations that might be applicable
- 20:12:33 [bblfish]
- so the idea would be that if these issues come up one could develop a general process to do that
- 20:12:36 [krp]
- roger: doesn't this happen with some firewalls. use some x-http-method to work around?
- 20:13:04 [cygri]
- PROPOSAL: Close ISSUE-27, as PATCH is the appropriate HTTP verb, and we don't have sufficient evidence for the easier implementability of POST
- 20:13:14 [davidwood]
- +1
- 20:13:19 [rgarcia]
- +1
- 20:13:19 [krp]
- arnaud: we should just take the risk and stick with PATCH
- 20:13:20 [JohnArwe]
- +1
- 20:13:21 [bblfish]
- +1
- 20:13:21 [SteveBattle]
- +1
- 20:13:22 [krp]
- +1
- 20:13:22 [betehess_laptop]
- +1
- 20:13:23 [SteveS]
- +1
- 20:13:25 [roger]
- +1
- 20:13:26 [mesteban]
- +1
- 20:13:28 [nmihindu]
- +1
- 20:13:29 [TallTed]
- s/the easier/any easier/
- 20:13:29 [TallTed]
- +1
- 20:13:29 [ericP]
- +1
- 20:13:31 [cody]
- +1
- 20:13:31 [cygri]
- +1
- 20:13:35 [sandro]
- +1
- 20:13:49 [Arnaud]
- RESOLVED: Close ISSUE-27, as PATCH is the appropriate HTTP verb, and we don't have sufficient evidence for the easier implementability of POST
- 20:14:34 [krp]
- SteveS: editorial changes for issue-27: none
- 20:14:34 [cygri]
- X-HTTP-Method-Override header: http://www.endurasoft.com/Blog/post/X-HTTP-Method-Override.aspx
- 20:14:34 [Arnaud]
- "must-haves": 15, 32, 33, 37, 38
- 20:15:14 [cygri]
- ISSUE-17?
- 20:15:14 [trackbot]
- ISSUE-17 -- changesets as a recommended PATCH format -- open
- 20:15:14 [trackbot]
- http://www.w3.org/2012/ldp/track/issues/17
- 20:15:53 [krp]
- issue-45?
- 20:15:53 [trackbot]
- ISSUE-45 -- POSTing to an LDPR appends content to the resource -- open
- 20:15:53 [trackbot]
- http://www.w3.org/2012/ldp/track/issues/45
- 20:16:12 [SteveBattle]
- q+
- 20:16:18 [cygri]
- q+
- 20:16:22 [krp]
- TOPIC: issue-45
- 20:16:31 [bblfish]
- Issue-45
- 20:16:31 [trackbot]
- ISSUE-45 -- POSTing to an LDPR appends content to the resource -- open
- 20:16:31 [trackbot]
- http://www.w3.org/2012/ldp/track/issues/45
- 20:16:34 [Arnaud]
- ack steveb
- 20:17:03 [SteveS]
- q+
- 20:17:17 [davidwood]
- q+ to ask whether POST fails if the resource already exists.
- 20:17:20 [krp]
- stevebattle: distinguish between posting triples to an ldpc, or posting to a container to add a member
- 20:17:42 [Arnaud]
- ack cygri
- 20:17:45 [Zakim]
- -bblfish
- 20:18:10 [Arnaud]
- ack steves
- 20:18:19 [krp]
- cygri: if I have this easy way to add triple, what about an easy mechanism for delete...
- 20:18:20 [Arnaud]
- ack david
- 20:18:20 [Zakim]
- davidwood, you wanted to ask whether POST fails if the resource already exists.
- 20:18:46 [ericP]
- -> http://www.w3.org/2012/Talks/1211-egp-ldp/#%2814%29 comparison of LDP and GSP
- 20:18:47 [Zakim]
- +bblfish
- 20:18:50 [krp]
- steves: we already have a mechanism to append triples, so seems sensible to maintain consistency for containters
- 20:19:43 [cygri]
- PROPOSAL: Close ISSUE-45 without change to the spec. Rationale: (1) We'd rather have people use PATCH; (2) there is danger that we overload POST; (3) we don't want to provide multiple ways of doing the same thing
- 20:19:52 [krp]
- davidwood: do we want to fail on a post if a resource already exists and only accept a patch (strong), or only accept a put replacement (weaker). to accept a post seems odd.
- 20:19:55 [sandro]
- +1
- 20:19:56 [rgarcia]
- +1
- 20:19:57 [mesteban]
- +1
- 20:19:58 [ericP]
- q+
- 20:20:06 [krp]
- arnaud: consensus seems to be to close this issue
- 20:20:11 [nmihindu]
- +1
- 20:20:12 [TallTed]
- +1 reject POST on existing resource, advising PUT or PATCH as appropriate
- 20:20:13 [SteveBattle]
- +1
- 20:20:13 [krp]
- ... and not do anything
- 20:20:15 [SteveS]
- +1
- 20:20:19 [TallTed]
- which is not the PROPOSAL...
- 20:20:20 [krp]
- +1
- 20:20:21 [davidwood]
- arnaud: slow down :)
- 20:20:23 [Arnaud]
- ack eric
- 20:20:27 [JohnArwe]
- +1
- 20:20:32 [cygri]
- +1
- 20:21:30 [krp]
- ericP: on a post to a container I had to behave differently to any other resource, after that I could use graph store protocol for operations
- 20:21:53 [krp]
- ... if we prohibit post this is incompatible. if we don't say anything then an LDPC can also be a GSP
- 20:22:19 [SteveBattle]
- q+
- 20:22:37 [bblfish]
- GSP http://www.w3.org/TR/sparql11-http-rdf-update/
- 20:22:48 [ericP]
- +1
- 20:22:53 [Arnaud]
- ack steveb
- 20:22:55 [davidwood]
- +1
- 20:23:06 [krp]
- stevebattle: if I post to a resource does it become a container?
- 20:23:34 [krp]
- SteveS: unspecified
- 20:23:42 [davidwood]
- I hope not :)
- 20:23:52 [Arnaud]
- RESOLVED: Close ISSUE-45 without change to the spec. Rationale: (1) We'd rather have people use PATCH; (2) there is danger that we overload POST; (3) we don't want to provide multiple ways of doing the same thing
- 20:23:55 [cygri]
- ISSUE-17?
- 20:23:55 [trackbot]
- ISSUE-17 -- changesets as a recommended PATCH format -- open
- 20:23:55 [trackbot]
- http://www.w3.org/2012/ldp/track/issues/17
- 20:24:19 [Arnaud]
- "must-haves": 15, 32, 33, 37, 38
- 20:25:00 [sandro]
- issue-17?
- 20:25:00 [trackbot]
- ISSUE-17 -- changesets as a recommended PATCH format -- open
- 20:25:00 [trackbot]
- http://www.w3.org/2012/ldp/track/issues/17
- 20:25:19 [krp]
- Issue-17
- 20:25:19 [trackbot]
- ISSUE-17 -- changesets as a recommended PATCH format -- open
- 20:25:19 [trackbot]
- http://www.w3.org/2012/ldp/track/issues/17
- 20:25:19 [sandro]
- q+
- 20:25:36 [Arnaud]
- "must-haves": 15, 17, 32, 33, 37, 38
- 20:25:48 [Arnaud]
- topic: issue-17
- 20:26:03 [bblfish]
- Agree if one could do this just with RDF that would be cool.
- 20:26:07 [SteveS]
- q+
- 20:26:08 [ericP]
- q?
- 20:26:16 [krp]
- stevebattle: currently the spec doesn't specify a patch format. my view is that ldp should be a sparql free zone, at the time the issue was written tallis changeset seemed possible
- 20:26:18 [bblfish]
- there was this: http://lists.w3.org/Archives/Public/public-ldp-wg/2013Mar/0070.html
- 20:26:22 [Arnaud]
- ack sandro
- 20:26:48 [roger]
- +q
- 20:27:28 [krp]
- sandro: a subset of sparql update. standardise this? (turtle update). I now think TriG with special predicates.
- 20:27:52 [bblfish]
- So the pitty is that without something like a SPARQL update one cannot do pattern matches
- 20:27:53 [krp]
- ... I like the idea that you can use these things outside of PATCH
- 20:27:56 [SteveBattle]
- q+
- 20:27:57 [Arnaud]
- ack steves
- 20:28:16 [bblfish]
- q+
- 20:28:44 [davidwood]
- +1 to TriG. The RDF WG is standardizing TriG as a dataset format.
- 20:29:05 [krp]
- steves: defining the patch model for rdf, then the patch document format
- 20:29:15 [Arnaud]
- ack roger
- 20:29:24 [roger]
- q-
- 20:29:26 [Arnaud]
- ack steveb
- 20:29:46 [krp]
- stevebattle: the problem with tallis changeset was bnodes in lists?
- 20:30:30 [sandro]
- "These issues and ones like them should be discussed by the group and guidance provided in the delivered Recommendation when practical..... Defining small new languages, such as Turtle Patch"
- 20:30:32 [cygri]
- andy's proposed TriG-based format: http://lists.w3.org/Archives/Public/public-ldp-wg/2013Mar/0058.html
- 20:30:39 [Arnaud]
- ack bblfish
- 20:30:46 [krp]
- ericP: lists are just painful. but we could do something like this is a list patch then typing it in the default graph. anything to do with lists will probably be unpleasant
- 20:30:48 [betehess_laptop]
- does anybody have an example of a PATCH using TriG?
- 20:31:11 [sandro]
- q+
- 20:31:12 [betehess_laptop]
- q+
- 20:31:21 [SteveBattle]
- Isn't that SPARQL update?
- 20:31:30 [krp]
- bblfish: like TriG as simple. advantage of minimal sparql update type thing is pattern matching
- 20:31:46 [cygri]
- q+
- 20:31:48 [davidwood]
- …but that ties LDP to SPARQL
- 20:31:52 [Arnaud]
- ack sandro
- 20:32:20 [roger]
- +q
- 20:32:48 [JohnArwe]
- is http://wifo5-03.informatik.uni-mannheim.de/bizer/trig/ the syntax spec we're talking about?
- 20:32:51 [SteveS]
- q+
- 20:33:00 [krp]
- sandro: what to do about bnodes, variables, etc. if you allow this you can do anything with rdf but you potentially have an np-complete patch format (scoped by patch size)
- 20:33:08 [ericP]
- sounds like caution: calculating large primes may be kinda of slow
- 20:33:11 [sandro]
- http://lists.w3.org/Archives/Public/public-ldp-wg/2013Mar/0058.html
- 20:33:20 [krp]
- ... that might scare people off
- 20:33:49 [cygri]
- JohnArwe, that's outdated. W3C version: https://dvcs.w3.org/hg/rdf/raw-file/default/trig/index.html
- 20:34:11 [Arnaud]
- ack bete
- 20:34:28 [ericP]
- q+ to answer bblfish's q about how to specify a subset of SPARQL
- 20:34:50 [krp]
- betehess: bnodes are important to me, understand the problem because of lists. perhaps we have something specific for lists?
- 20:35:13 [krp]
- sandro: yes, could potentially have extensions for lists etc.
- 20:35:37 [krp]
- ericP: thats a wg worth of work
- 20:36:09 [SteveBattle]
- q+
- 20:36:12 [Arnaud]
- ack cygri
- 20:36:24 [Arnaud]
- ack roger
- 20:36:44 [betehess_laptop]
- rdf:list are really important for a lot of people
- 20:37:01 [krp]
- roger: the things that make up a PATCH is the assembly of change operations at the http level... so more like a batch
- 20:37:05 [bblfish]
- q?
- 20:37:26 [krp]
- ... of http api operations
- 20:37:46 [krp]
- sandro: does this solve the problem of deleting the triple from the middle of a resource
- 20:38:02 [krp]
- roger: we should support such operations
- 20:38:07 [Arnaud]
- ack steves
- 20:39:00 [Arnaud]
- ack eric
- 20:39:00 [Zakim]
- ericP, you wanted to answer bblfish's q about how to specify a subset of SPARQL
- 20:39:08 [krp]
- steves: in the sample s I gave the example predicates match(??)
- 20:39:12 [SteveS]
- Here's my example that works http://open-services.net/wiki/core/OSLC-Core-Partial-Update/#Example-update-blank-nodes-link-label with this approach
- 20:39:33 [sandro]
- http://www.w3.org/2001/sw/wiki/TurtlePatch
- 20:39:35 [krp]
- ericP: how would we use a subset of sparql? quite easily defined in terms of grammar.
- 20:39:46 [krp]
- davidwood: wouldn't that look a lot like turtle patch?
- 20:40:03 [betehess_laptop]
- this still does not handle rdf:list or shapeless graphs
- 20:40:24 [sandro]
- shapeless graphs?
- 20:40:30 [krp]
- ericP: yes. grammatically define it as subgraph of sparql, and reuse the existing sparql semantics
- 20:40:42 [davidwood]
- I think we should be optimizing for developer/user time, not bytes on the wire.
- 20:40:48 [betehess_laptop]
- sandro, something that does not have a pattern that you can use in sparql for example
- 20:41:01 [krp]
- ... if there were bnodes in the WHERE
- 20:41:10 [betehess_laptop]
- rdf-list is an example
- 20:41:14 [sandro]
- how is that possible? isn't every subgraph a pattern that matches itself?
- 20:41:15 [krp]
- .. the question is whether we want to match a pattern and do things to it
- 20:41:20 [cygri]
- q+
- 20:41:59 [krp]
- arnaud: what modification do we need to spec section 4.7?
- 20:42:35 [krp]
- ... although it is optional, the may says if you're going to do it, do it this way
- 20:42:55 [krp]
- cygri: if I want to add support for PATCH, I need to know the format I should go for
- 20:43:04 [Arnaud]
- ack steveb
- 20:43:28 [sandro]
- q?
- 20:43:29 [bblfish]
- yes, clearly the changeset in rdf/xml is not nice
- 20:43:40 [krp]
- stevebattle: I think TriG over changesets. we should choose one format so we can write tests
- 20:43:50 [krp]
- arnaud: useful to specify minimum set
- 20:44:26 [krp]
- sandro: concern that the speed of resolving the patch format spec might run longer than the ldp spec
- 20:44:46 [krp]
- cygri: make a recommendation for a particular format and mark at risk?
- 20:45:11 [Arnaud]
- ack cygri
- 20:45:49 [krp]
- ... whatever option we go for it would mean another rec track document for the wg?
- 20:46:14 [krp]
- ... except changeset which already exists. but would need writing for sparql subset or trig
- 20:46:19 [sandro]
- STRAWPOLL: (1) sparql subset (turtle patch) ; (2) use of TriG; (3) some other patch format; (4) no std patch format
- 20:46:49 [cygri]
- sandro, can you add Talis Changesets
- 20:46:53 [krp]
- davidwood: if you create a non-standard format for this, we will need to somehow bless it by ldp
- 20:47:11 [sandro]
- STRAWPOLL: (1) sparql subset (turtle patch) ; (2) use of TriG; (3) Talis changesets; (4) some other patch format; (5) no std patch format
- 20:47:22 [davidwood]
- 2
- 20:47:28 [krp]
- ... rec or note. or adopt an existing format and explain how we would adapt it to this use. so TriG would be easier.
- 20:47:50 [cygri]
- 0 +1 -1 0
- 20:48:17 [roger]
- does 4). cover BATCH-AS-PATCH ?
- 20:48:28 [krp]
- sandro: we would have to define the two predicates for trig.
- 20:48:28 [bblfish]
- +1 +0.2 -1 -1 -1
- 20:48:29 [davidwood]
- -0.5, +1, −1, −1, +0
- 20:48:47 [cygri]
- 0 +1 -1 0 0
- 20:49:06 [TallTed]
- +1, +1, +0, +0, -1
- 20:49:10 [betehess_laptop]
- +1 +1 0 -1 -1
- 20:49:11 [SteveBattle]
- (0, +1, 0.5, 0, -1)
- 20:49:18 [sandro]
- +0 +1 -1 -0 -1
- 20:49:21 [mesteban]
- +1 +1 0 1 -1
- 20:49:29 [krp]
- 0 +1 -1 -1 -1
- 20:49:30 [rgarcia]
- 0, +1, 0, -1, 0
- 20:49:34 [ericP]
- +1, +0, +0, +0, +0
- 20:49:36 [nmihindu]
- +1 +1 0 0 -1
- 20:49:36 [roger]
- -1, -1, -1, +1, +1
- 20:49:39 [SteveS]
- +0, +1, +0, -1, -1
- 20:50:00 [JohnArwe]
- +0, +1, -0.5, +0, -1
- 20:50:34 [TallTed]
- s/+1, +1, +0, +0, -1/+1, +1, +1, +0, -1/
- 20:51:30 [mesteban]
- s/+1 +1 0 1 -1/+1 +1 0 +1 -1/
- 20:51:38 [krp]
- sandro: roger should produce a concrete proposal for batch as patch. someone else produces a more concrete proposal for TriG
- 20:52:10 [Arnaud]
- q?
- 20:52:14 [bblfish]
- Agree: two concrete proposals for (1) and (2) and we compare. Also we can see then how difficult it is to implement.
- 20:52:17 [krp]
- arnaud: (5) is the status quo, so even though there are -1 it stands until there is an approved alternative
- 20:52:31 [ericP]
- s/s\/\+1, \+1, \+0, \+0, -1\/\+1, \+1, \+1, \+0, \-1\//s/\\+1, \\+1, \\+0, \\+0, -1\\\/\\\+1, \\\+1, \\\+1, \\\+0, \\\-1\\//
- 20:52:50 [krp]
- roger: objection to (5) is that it's not batch for patch
- 20:53:17 [krp]
- steves: isn't that a separate issue? do you want to block trig patch?
- 20:53:34 [TallTed]
- RRSAgent, pointer?
- 20:53:34 [RRSAgent]
- See http://www.w3.org/2013/03/13-ldp-irc#T20-53-34
- 20:53:41 [krp]
- sandro: I don't think there's a smaller granularity than trig?
- 20:53:59 [bblfish]
- Trig is just Turtle with named graphs
- 20:54:39 [bblfish]
- But it does not have a notion of variables. So it is N3 withouth the { ?a ?r ?b }
- 20:55:11 [betehess_laptop]
- q+
- 20:56:25 [betehess_laptop]
- q-
- 20:56:32 [krp]
- sandro: I think it there's a blank node that occurs in both the insert and delete in Andy's example, I think they need to be identified and operated on as the same bnode
- 20:57:14 [TallTed]
- TallTed: order of operations needs to be clearly specified (e.g., delete before insert, etc.)
- 20:58:40 [SteveS]
- q+
- 20:59:01 [krp]
- roger: if all operations have to be boiled down to trig patch formats, it's not as simple as I want it to be
- 20:59:32 [SteveBattle]
- What would the mime type for the trig be?
- 20:59:58 [SteveBattle]
- application/x-trig
- 20:59:58 [sandro]
- sandro: let's define the semantics of trig-based-patch in terms of sparlql-update semantics which are nicely defined.
- 21:00:20 [SteveBattle]
- q+
- 21:00:27 [cygri]
- SteveBattle, application/trig as per https://dvcs.w3.org/hg/rdf/raw-file/default/trig/index.html#sec-mediaReg
- 21:00:47 [krp]
- arnaud: I would propose we accept trig as the way forward, and roger sends proposal to the list of how we should proceed; we can then revisit the trig decision in light of it if needed
- 21:00:53 [sandro]
- SteveBattle, I *think* we need to have a different mime type from TriG, so you know it's a patch.
- 21:01:16 [sandro]
- so text/rdf-patch or something
- 21:01:31 [rgarcia]
- or something with ldp-patch
- 21:01:36 [cygri]
- sandro, don't you know that by inspecting the default graph?
- 21:02:09 [sandro]
- cygri, maybe.... I haven't thought about this enough.
- 21:02:09 [JohnArwe]
- cygri, I suspect the counter-example is "my LDPC contains TriG documents"
- 21:02:30 [Arnaud]
- ack steves
- 21:02:35 [sandro]
- JohnArwe, but this is being transmitted via PATCH.
- 21:02:40 [cygri]
- JohnArwe, but we only talk about payload to the PATCH method
- 21:03:34 [Arnaud]
- ack steveb
- 21:03:36 [sandro]
- btw, I gather it's application/trig https://dvcs.w3.org/hg/rdf/raw-file/default/trig/index.html#sec-mime
- 21:03:36 [krp]
- steves: I think the aspect of batching a lot of http requests has scenarios where it would add a lot of complexity, a single patch/trig format seems to meet my needs more simply (but can see value in breaking it down, just heavyweight)
- 21:03:50 [JohnArwe]
- I'd like to say we need nothing new (simpler) ... thinking out loud here.
- 21:04:08 [krp]
- stevebattle: simple case where we just to assert a small number of triples. distinguish with different mimetypes?
- 21:04:25 [krp]
- ... to allow both atomic ops and patch trig
- 21:05:12 [krp]
- arnaud: does this bring in transactions, atomicity etc. as discussed earlier?
- 21:05:16 [krp]
- roger: no
- 21:06:04 [krp]
- cygri: can we characterise the problem as our operations being too coarse? you want an http operation to manipulate ~a single triple
- 21:06:13 [krp]
- roger: yes
- 21:06:46 [krp]
- cygri: so the problem is that if you want to modify fine grained triples, not a whole ldpr, you want something more fine grained than the trig format
- 21:08:04 [krp]
- ... can we avoid blocking this patch issue if we can raise another issue to address this granularity problem?
- 21:08:08 [cygri]
- ISSUE-43?
- 21:08:08 [trackbot]
- ISSUE-43 -- hint at naming a resource on creation -- closed
- 21:08:08 [trackbot]
- http://www.w3.org/2012/ldp/track/issues/43
- 21:08:34 [cygri]
- ISSUE-34?
- 21:08:34 [trackbot]
- ISSUE-34 -- Adding and removing arcs in weak aggregation -- closed
- 21:08:34 [trackbot]
- http://www.w3.org/2012/ldp/track/issues/34
- 21:08:42 [krp]
- roger: always thought issue-34 addresses this, thought the resolution didn't
- 21:08:52 [krp]
- ... drifted off into other areas
- 21:10:48 [cygri]
- ACTION: cygri to work with Roger to raise an issue on using standard HTTP verbs for fineer-grained graph manipulations
- 21:10:48 [trackbot]
- Created ACTION-46 - Work with Roger to raise an issue on using standard HTTP verbs for fineer-grained graph manipulations [on Richard Cyganiak - due 2013-03-20].
- 21:10:59 [cygri]
- s/fineer/finer
- 21:11:04 [cygri]
- s/fineer/finer/
- 21:11:05 [krp]
- topic: agenda for tomorrow
- 21:19:51 [krp]
- arnaud: the access control deliverable was a compromise to those who said we can't consider ldp protocol without it
- 21:20:08 [krp]
- davidwood: what are the charter requirements for this?
- 21:20:20 [davidwood]
- It turns out there are some :)
- 21:20:31 [cygri]
- did I hear davidwood volunteering to edit a Note on Access Control? :-)
- 21:20:34 [bblfish]
- q+
- 21:21:06 [Arnaud]
- ack bblfish
- 21:21:15 [SteveBattle]
- q+
- 21:21:28 [Arnaud]
- ack steveb
- 21:21:49 [SteveS]
- q+
- 21:21:56 [krp]
- stevebattle: do we need to address meta issues tomorrow?
- 21:22:00 [Arnaud]
- ack steves
- 21:22:24 [krp]
- steves: what time will people need to leave on Friday?
- 21:22:28 [Zakim]
- -bblfish
- 21:22:45 [krp]
- ... anyone before 4pm?
- 21:22:58 [krp]
- arnaud: we will meet until 4pm on Friday.
- 21:23:10 [SteveBattle]
- SteveBattle has left #ldp
- 21:23:11 [krp]
- ... meeting adjourned for the day.
- 21:38:32 [Zakim]
- -WG-meeting
- 21:38:33 [Zakim]
- SW_LDP(F2F)10:45AM has ended
- 21:38:33 [Zakim]
- Attendees were +1.617.715.aaaa, WG-meeting, bblfish
- 21:49:58 [roger]
- roger has joined #ldp
- 21:50:06 [roger]
- roger has left #ldp
- 21:55:56 [roger]
- roger has joined #ldp
- 22:03:03 [cygri]
- cygri has joined #ldp
- 22:14:29 [roger]
- roger has left #ldp