Chatlog 2013-03-13

See original RRSAgent log or preview nicely formatted version.

Please justify/explain all edits to this page, in your "edit summary" text.

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: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> scribenick: betehess
<betehess>chair: Arnaud
<betehess>Topic: Introduction
13:27:36 <betehess> 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> RRSAgent, please dreaft the minutes
13:27:53 <RRSAgent> I'm logging. I don't understand 'please dreaft the minutes', betehess.  Try /msg RRSAgent help
13:27:53 <sandro> Eric Prud'hommeaux
13:28:00 <betehess> 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
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> Arnaud: weclome everybody
13:29:00 <Zakim> Team_(ldp)13:28Z has now started
13:29:02 <betehess> ... 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> ... 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> ... 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> ... sometimes we need to take time to understand why the spec is the way it is
13:31:14 <betehess> ... let's have a look at the agenda
13:31:33 <betehess> ... the spec is the main item for us
13:31:58 <betehess> ... the list follows the deliverables from the charter
13:32:04 <betehess> ... plus some items we agreed to do
13:32:15 <betehess> ... we need to check where we are on these items
13:32:42 <Zakim> +bblfish
13:32:50 <betehess> ... some are just nice-to-have
13:33:00 <betehess> davidwood: but it would be better for adoption
13:33:23 <betehess> Arnaud: but we need to prioritize
13:33:38 <betehess> davidwood: can we go a bit meta some time during the next 3 days?
13:33:48 <betehess> ... to anticipate what can bite us during LC
13:34:12 <betehess> 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> ... I ask people to come up with proposals, much easier
13:34:33 <betehess> ... some issues may not be critical
13:34:50 <mesteban> mesteban has joined #ldp
13:34:55 <betehess> ... so I want to prioritize the issues, and we can have the discussion at that time
13:35:13 <betehess> ... we haven't talked about the UCR in a while
13:35:16 <betehess> ... may be fine
13:35:26 <betehess> ... want to make sure everybody knows where we are
13:36:26 <betehess> ... I didn't assign specific issues to specific timeslots, but I don't want to get stuck in some discussions
13:36:45 <betehess> ... 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> ... 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> ... also use normal breaks (eg. lunch) to discuss
<betehess> Topic: Use Cases & Requirements
13:38:13 <betehess> ... let's get started with UCR
13:38:19 <betehess> ... we had a FPWD
13:38:31 <betehess> ... then we went back to the spec
13:38:44 <betehess> ... SteveBattle, what's your opinion?
13:38:56 <betehess> SteveBattle: we invited people to comment, then we had silence
13:39:00 <betehess> ... not really surprised
13:39:07 <betehess> ... please look at the document
13:39:15 <cygri> q+ to ask about ED vs WD
13:39:19 <betehess> ... there will be a deadline for the second release
13:39:58 <betehess> ... only missing UC: can we use LDP to invoke services through RDF exchange?
13:41:04 <betehess> ... then we have the test cases
13:41:14 <betehess> ... 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> ... 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> cygri: I have to produce a UC on paging
13:41:50 <betehess> ... 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> SteveBattle: ED and WD are the same at the moment
13:42:39 <betehess> Arnaud: not all WDs follow the same schedule
13:42:59 <roger> roger has joined #ldp
13:43:04 <betehess> ... we should have published things at the same time, just didn't happen
13:43:16 <betehess> SteveBattle: not sure if we should rush it out
13:43:32 <betehess> Arnaud: so , we have new UC to be added
13:43:37 <betehess> ... and we didn't get comments
13:43:58 <betehess> ... so I don't know if people are satisfied, or if people didn't get the attention
13:44:24 <betehess> ... 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> SteveS: I think it's just in maintenance mode
13:44:56 <cygri> q+
13:45:05 <betehess> davidwood: we should ask for review
13:45:20 <betehess> ... I'll have to do that anyway
13:45:38 <betehess> s/do that/make a review/
13:45:38 <SteveBattle> Thank you 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> rgarcia: we can open issues for that, so that we can follow the status of reviews
13:46:22 <betehess> ... we can identify these actions
13:46:28 <betehess> ... it's a good way to progress
13:46:40 <davidwood> q+ to ask about the satisfaction of each UC
13:46:58 <betehess> Arnaud: usually, the UCR motivates what goes in the spec
13:47:43 <betehess> ... 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> cygri: there's different views of the purpose for UCR
13:48:39 <betehess> ... it should always be able to ask "what's the use case?"
13:49:04 <betehess> ... so in my view, the purpose is to be able to ask people a scenario that is not address
13:49:12 <betehess> ... examples that we can follow
13:50:00 <betehess> ... I have some issues to add UC with the current organization of the document
13:50:10 <sandro> q?
13:50:23 <betehess> ... I hope SteveBattle will be able to help people there
13:50:40 <betehess> 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> Arnaud: yes, it's the role of the editor to put things in the document, following requests
13:51:28 <betehess> davidwood: at some point, the status of the document shifts from what people want to what @@
13:51:47 <betehess> ... we may decide as a group that we cannot support some of them
13:52:09 <betehess> ... how do we make this transition? we could open issues
13:52:35 <betehess> ... in the rdfwg, we decided that we had too many UCs, and split the document
13:53:13 <betehess> 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> ... we never did that
13:54:00 <betehess> 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> ... 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> ... 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> sandro: would be fine to start with high/low priority
13:55:42 <betehess> ... people could explain to the editor and we decide together
13:55:51 <betehess> Arnaud: how much time would it require?
13:56:00 <roger> roger has joined #ldp
13:56:07 <betehess> sandro: we could save time instead of cycling if we don't do that
13:56:32 <betehess> Arnaud: another aspect: do we have a sense of if the spec *today* addresses the UCR
13:56:41 <betehess> ... what is addressed?
13:56:42 <betehess> q+
13:57:25 <betehess> 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> betehess: do we want to have links in the document to the UCR documents?
13:58:35 <betehess> 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> Arnaud: I want to make sure that we are good where we are with UCR, or not
13:59:59 <betehess> SteveBattle: I think it's in good shape at the moment, not concerned
14:00:09 <betehess> Arnaud: also davidwood is ok to have a closer look
14:00:17 <betehess> ... ok with others, just bring issues
14:00:27 <betehess> 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> 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> ... maybe this will happen in the case of paging for example
14:02:58 <betehess> ... but it's good to have captured that as a UC
14:03:35 <Zakim> +bblfish
14:03:37 <betehess> Arnaud: in terms of the schedule, we skip the 2nd WD
14:03:46 <betehess> ... I guess everybody is ok with that
14:04:09 <betehess> ... the end goal for UCR is a NOTE
14:04:33 <betehess> cygri: if nobody comes up with new TC, then we might be done with the document
14:04:40 <betehess> ... we can publish an updated WD
14:05:17 <betehess> sandro: there is just no normative content
14:05:41 <betehess> davidwood: REC needs approval
14:05:46 <gavinc> gavinc has joined #ldp
14:05:51 <betehess> Arnaud: LC target is May
14:06:46 <betehess> ... so UCR should be a NOTE by then
14:07:13 <betehess> ... I think that we have a plan for UCR at this point
14:07:17 <betehess> ... do we need more?
14:07:25 <Arnaud> q?
14:07:53 <betehess> cygri: there is a couple of features in the spec, would like to know if there are corresponding UC
14:08:09 <betehess> ... eg. metadata managed by the server rather that the client
14:08:27 <betehess> SteveBattle: metadata about the collection would be that, so it should be covered
14:08:38 <betehess> ... ordering in a container is not covered
14:08:55 <betehess> ... technically speaking I could ask these things to be removed
14:09:24 <betehess> SteveS: we covered a story, there may be no UC
14:09:51 <betehess> cygri: speaking about ordering in a container
14:10:20 <betehess> ... 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> sandro: also for people outside the group, for them to understand
14:10:47 <betehess> cygri: there may be other points in the spec
14:11:10 <rgarcia> q+
14:11:46 <Arnaud> ack rgarcia
14:11:48 <betehess> ... 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> Arnaud: now, I want to speak about the spec, and have a sense of where we are
14:17:08 <betehess> topic: LDP Specification
<betehess> subtopic: Steps towards LCWD
14:17:17 <betehess> Arnaud: looking at the isssues
14:17:26 <rgarcia> q+
14:17:26 <betehess> ... 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> ... 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> ... LC, in W3C process, is the stage when the WG says "I think we're done"
14:18:45 <betehess> ... and then we invite the rest of the world to look at it
14:18:51 <betehess> ... supposed to feature complte
14:19:02 <rgarcia> q-
14:19:08 <betehess> ... then there is a process to respond to comments
14:19:18 <betehess> ... everything has to be documented
14:19:48 <betehess> ... 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> ... after LC, we need to show implementations
14:20:24 <betehess> sandro: my sense is that implementing this is easy
14:20:39 <betehess> ... 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> Arnaud: happy to say that we're in good shape in that regard
14:22:10 <betehess> sandro: implementations should include test results
14:22:17 <betehess> ... cannot say that until we have the test suite
14:22:35 <betehess> ... we should really try to have the issues closes during this meeting
14:22:40 <betehess> s/closes/closed/
14:22:59 <betehess> Arnaud: I agree, but there are different ways to close issues
14:23:13 <betehess> ... we can decide that we don't do anything re: specific issue
14:23:18 <betehess> Ashok: you need agreement
14:23:38 <betehess> Arnaud: there is a process, we decide as a group
14:23:38 <betehess> ... then people can raise objections
14:24:14 <betehess> sandro: there is the deadline mode, where we realize that perfection can't be achieved
<betehess> subtopic: Identifying top priority issues, "must-haves"
14:24:38 <betehess> Arnaud: would like to take a pass on the list of iossues we have
14:24:42 <betehess> ... to get a sense of the priorities
14:24:50 <betehess> s/iossues/issues/
14:24:56 <betehess> ... is that reasonable?
14:25:23 <betehess> ... what are the MUST HAVE?
14:25:46 <roger> issue 37 : Model
14:25:50 <betehess> ... 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> 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> s/Hi//
14:33:13 <bblfish> yes, bad connection though from here.
14:33:37 <betehess> 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> 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> I'd be ok to close ISSUE-28 but I'd like the group to motivate the reason :-)
14:36:59 <betehess> and the spec could even state that transactions are not handled
14:38:25 <betehess> Arnaud: some of the issues are not very controversial
14:38:35 <betehess> ... maybe we can identify and close them?
14:39:36 <betehess> ... already identified issue-18 and issue-28
14:40:26 <betehess> 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
<betehess> subtopic: Issue-28: transaction/rollback when deleting resources from a LDPC 
14:41:18 <betehess> 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> Ashok: are etags enough?
14:41:48 <betehess> 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> betehess: it would be ok for updates, no longer when you delete
14:42:52 <betehess> davidwood: got this issue recently
14:43:03 <betehess> ... etags gives all information for rollback
14:43:13 <betehess> q+
14:43:27 <betehess> ... we don't put that in the API
14:43:54 <betehess> ... providing that level of information can be challenging
14:44:19 <betehess> ... that's a lot of burden
14:44:40 <betehess> ... 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> 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> Arnaud: the issue is specifically about DELETEing
14:47:07 <betehess> ... not about transaction in general
14:47:09 <Arnaud> ack steves
14:47:36 <betehess> SteveS: the way we do it, we never delete anything
14:47:56 <betehess> q+
14:48:44 <betehess> q-
14:48:53 <Arnaud> ack stevebattle
14:48:53 <betehess> Arnaud: in the spec today, we have a DELETE
14:49:35 <betehess> SteveBattle: nosql technologies achieve performance keeping ACID
14:49:52 <betehess> 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> 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> cygri: are we saying that by deleting a container, we also delete the resource?
14:52:50 <betehess> 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> davidwood: we can send 202 to say that process was not completed
14:54:03 <bblfish> makes sense
14:54:38 <betehess> sandro: should it be propafated to deleted resources?
14:54:42 <betehess> s/propafated/propagated/
14:54:52 <betehess> q+
14:55:06 <betehess> q- Error
14:55:11 <betehess> q- handling
14:55:27 <sandro> sandro: there could be deletions that take hours, for a massive recursive delete.
14:55:32 <betehess> mesteban: wanted to comment on error handler
14:55:51 <betehess> ... 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> 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> 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> cygri: there are concerns about the proposal
14:58:37 <betehess> ... 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> ... so the container has to be there
14:59:01 <betehess> Arnaud: cygri wants to amend the proposal
14:59:12 <betehess> ... by saying that the container is not gone
14:59:17 <davidwood> Can cygri write an amended proposal?
14:59:52 <betehess> cygri: can the server check if it can delete everything before doing so?
14:59:55 <betehess> ... 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> Arnaud: it's a refinement
15:00:41 <mesteban> 1+
15:01:02 <betehess> 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> ericP: not sure how to test this
15:01:53 <betehess> ... would go for SHOULD
15:02:12 <SteveS> +1
15:02:14 <davidwood> q+
15:02:15 <Arnaud> ack nmihindu
15:02:36 <betehess> nmihindu: agrees with cygri's idea
15:02:43 <betehess> ... container should be there
15:02:56 <davidwood> q-
15:02:57 <SteveBattle> I agree with nmhindu
15:03:10 <betehess> ... 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> ... 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> @@: with 202, you provide a URI to monitor the operation
15:04:28 <AndyS> AndyS has joined #ldp
15:04:28 <betehess> 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> +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> RESOLVED: Close Issue-28. 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,
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, 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
<mesteban> scribe: mesteban
15:24:11 <mesteban> subtopic: Issue-43: hint at naming a resource on creation
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> arnaud: 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> arnaud: 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> arnaud: 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/arnaud/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> 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> 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> arnaud: 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> 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, you wanted to suggest to be lax, so that we can support patterns later, eg. /MM/yy/dd-minutes.html
15:50:32 <betehess> 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> 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> -1 against anything will not give enough expectations to the client
15:56:44 <davidwood> perhaps
15:56:46 <mesteban> arnaud: there as agreement on what we want to do the points is in the way we write it down
15:57:03 <betehess> s/anything/anything which/
15:57:34 <nmihindu> s/arnaud/Arnaud
15:57:56 <betehess> q+
15:57:58 <ericP> betehess, 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> SteveS: 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> arnaud: 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> 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, 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 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> 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> 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: Use slug as is
16:21:41 <mesteban> Arnaud: there is consensus in using slug as is, there is still the issue whether this closes 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
<ericP> scribe: ericP
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> +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: LDP Specification - 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> subtopic: issue-39: HTTP status codes used for creation 201/202
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> why not make 2 scenarios: synchronous and asynchronous? the server would decide, but we would have to spec both methods
17:43:40 <betehess> q+
17:44:37 <SteveS> q+
17:44:55 <Arnaud> ack bete
17:45:27 <ericP> betehess: 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>  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: does 303 mean i was successful
17:52:45 <ericP> betehess: 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: 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> 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> 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: 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> 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> 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> 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> +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> 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, 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: 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> 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> q+
18:27:54 <betehess> 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> +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> subtopic: ISSUE-21: Reverse membership predicates
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> 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: 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> 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> PROPOSED: 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> 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> 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> 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> 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
<krp> subtopic: Issue-27: Should the PATCH method be used, as opposed to POST with a given mime type?
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> 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> 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> 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> +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> subTOPIC: issue-45: POSTing to an LDPR appends content to the resource
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> subtopic: Issue-17: changesets as a recommended PATCH format
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> does anybody have an example of a PATCH using TriG?
20:31:11 <sandro> q+
20:31:12 <betehess> 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>  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> 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> 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> 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> +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> q+
20:56:25 <betehess> 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
<krp> cygri: don't feel competent about Access control, would like to work on other issues on the side
<krp> (discussion about agenda and possibility of having breakout sessions to work on proposals)
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+
<krp> Arnaud: we will start with half an hour to identify breakout sessions people would be interested in
21:21:56 <krp> stevebattle: do we need to address meta issues tomorrow?
<krp> davidwood: no
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.
# SPECIAL MARKER FOR CHATSYNC.  DO NOT EDIT THIS LINE OR BELOW.  SRCLINESUSED=00001482