13:21:29 <RRSAgent> logging to http://www.w3.org/2013/03/13-ldp-irc
RRSAgent IRC Bot: logging to http://www.w3.org/2013/03/13-ldp-irc ←
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
Sandro Hawke: 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:26:39 <ericP> Zakim, space for 8 for 9 hours?
Eric Prud'hommeaux: Zakim, space for 8 for 9 hours? ←
13:26:39 <Zakim> I don't understand your question, ericP.
Zakim IRC Bot: I don't understand your question, ericP. ←
13:26:59 <sandro> zakim, room for 8 for 9 hours?
Sandro Hawke: zakim, room for 8 for 9 hours? ←
13:26:59 <Zakim> I don't understand your question, sandro.
Zakim IRC Bot: I don't understand your question, sandro. ←
13:27:03 <betehess> scribenick: betehess
(Scribe set to Alexandre Bertails)
<betehess>chair: Arnaud
<betehess>Topic: Introduction
13:27:36 <betehess> Arnaud: let's go around the table
Arnaud Le Hors: let's go around the table ←
13:27:43 <sandro> Sandro Hawke
Sandro Hawke: Sandro Hawke ←
13:27:52 <ericP> i'm ericP
Eric Prud'hommeaux: i'm ericP ←
13:27:53 <betehess> RRSAgent, please dreaft the minutes
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
RRSAgent IRC Bot: I'm logging. I don't understand 'please dreaft the minutes', betehess. Try /msg RRSAgent help ←
13:27:53 <sandro> Eric Prud'hommeaux
Sandro Hawke: Eric Prud'hommeaux ←
13:28:00 <betehess> RRSAgent, please draft the minutes
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
RRSAgent IRC Bot: I have made the request to generate http://www.w3.org/2013/03/13-ldp-minutes.html betehess ←
13:28:05 <SteveS> Steve Speicher
Steve Speicher: Steve Speicher ←
13:28:06 <cygri> Richard Cyganiak
Richard Cyganiak: Richard Cyganiak ←
13:28:09 <JohnArwe> John Arwe
13:28:20 <nmihindu> Nandana Mihindukulasooriya
Nandana Mihindukulasooriya: Nandana Mihindukulasooriya ←
13:28:29 <rgarcia> Raúl García Castro
Raúl García Castro: Raúl García Castro ←
13:28:38 <krp> Kevin Page
Kevin Page: Kevin Page ←
13:28:39 <ericP> Zakim, space for 8 for 600 minutes?
Eric Prud'hommeaux: 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
Zakim IRC Bot: ok, ericP; conference Team_(ldp)13:28Z scheduled with code 26632 (CONF2) for 600 minutes until 2328Z ←
13:28:40 <cody> Cody Burleson, Base22
Cody Burleson: Cody Burleson, Base22 ←
13:28:44 <TallTed> Ted Thibodeau
Ted Thibodeau: Ted Thibodeau ←
13:28:51 <betehess> Arnaud: weclome everybody
Arnaud Le Hors: weclome everybody ←
13:29:00 <Zakim> Team_(ldp)13:28Z has now started
Zakim IRC Bot: Team_(ldp)13:28Z has now started ←
13:29:02 <betehess> ... I hope we can be as productive as the first f2f
... I hope we can be as productive as the first f2f ←
13:29:07 <Zakim> + +1.617.715.aaaa
Zakim IRC Bot: + +1.617.715.aaaa ←
13:29:14 <SteveBattle> Hello all - this is Steve Battle from Sysemia, Bristol, UK
Steve Battle: Hello all - this is Steve Battle from Sysemia, Bristol, UK ←
13:30:08 <betehess> ... lots of work to do
... lots of work to do ←
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
Eric Prud'hommeaux: 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
... I'll try to keep us on track, so that we can deliver a spec on schedule ←
13:30:57 <betehess> ... sometimes we need to take time to understand why the spec is the way it is
... 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
... let's have a look at the agenda ←
13:31:33 <betehess> ... the spec is the main item for us
... the spec is the main item for us ←
13:31:58 <betehess> ... the list follows the deliverables from the charter
... the list follows the deliverables from the charter ←
13:32:04 <betehess> ... plus some items we agreed to do
... plus some items we agreed to do ←
13:32:15 <betehess> ... we need to check where we are on these items
... we need to check where we are on these items ←
13:32:42 <Zakim> +bblfish
Zakim IRC Bot: +bblfish ←
13:32:50 <betehess> ... some are just nice-to-have
... some are just nice-to-have ←
13:33:00 <betehess> davidwood: but it would be better for adoption
David Wood: but it would be better for adoption ←
13:33:23 <betehess> Arnaud: but we need to prioritize
Arnaud Le Hors: but we need to prioritize ←
13:33:38 <betehess> davidwood: can we go a bit meta some time during the next 3 days?
David Wood: 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
... 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
Arnaud Le Hors: 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
... I ask people to come up with proposals, much easier ←
13:34:33 <betehess> ... some issues may not be critical
... some issues may not be critical ←
13:34:55 <betehess> ... so I want to prioritize the issues, and we can have the discussion at that time
... 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
... we haven't talked about the UCR in a while ←
13:35:16 <betehess> ... may be fine
... may be fine ←
13:35:26 <betehess> ... want to make sure everybody knows where we are
... 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
... 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
... 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
Richard Cyganiak: +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
... 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
Henry Story: 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
... also use normal breaks (eg. lunch) to discuss ←
<betehess> Topic: Use Cases & Requirements
13:38:13 <betehess> ... let's get started with UCR
... let's get started with UCR ←
13:38:19 <betehess> ... we had a FPWD
... we had a FPWD ←
13:38:31 <betehess> ... then we went back to the spec
... then we went back to the spec ←
13:38:44 <betehess> ... SteveBattle, what's your opinion?
... SteveBattle, what's your opinion? ←
13:38:56 <betehess> SteveBattle: we invited people to comment, then we had silence
Steve Battle: we invited people to comment, then we had silence ←
13:39:00 <betehess> ... not really surprised
... not really surprised ←
13:39:07 <betehess> ... please look at the document
... please look at the document ←
13:39:15 <cygri> q+ to ask about ED vs WD
Richard Cyganiak: q+ to ask about ED vs WD ←
13:39:19 <betehess> ... there will be a deadline for the second release
... 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?
... only missing UC: can we use LDP to invoke services through RDF exchange? ←
13:41:04 <betehess> ... then we have the test cases
... then we have the test cases ←
13:41:14 <betehess> ... so that we can point the UC to TC
... 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
Steve Speicher: SteveBattle referred to http://www.w3.org/TR/2013/WD-ldp-ucr-20130131/#cloud-infrastructure-management ←
13:41:18 <Arnaud> q?
Arnaud Le Hors: q? ←
13:41:20 <betehess> ... and achieve completeness
... and achieve completeness ←
13:41:23 <Arnaud> ack cygri
Arnaud Le Hors: ack cygri ←
13:41:23 <Zakim> cygri, you wanted to ask about ED vs WD
Zakim IRC Bot: cygri, you wanted to ask about ED vs WD ←
13:41:24 <SteveS> …that doesn't have use case for
Steve Speicher: …that doesn't have use case for ←
13:41:38 <betehess> cygri: I have to produce a UC on paging
Richard Cyganiak: I have to produce a UC on paging ←
13:41:50 <betehess> ... so there will be one more thing there
... 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
Raúl García Castro: 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
Steve Battle: ED and WD are the same at the moment ←
13:42:39 <betehess> Arnaud: not all WDs follow the same schedule
Arnaud Le Hors: not all WDs follow the same schedule ←
13:43:04 <betehess> ... we should have published things at the same time, just didn't happen
... 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
Steve Battle: not sure if we should rush it out ←
13:43:32 <betehess> Arnaud: so , we have new UC to be added
Arnaud Le Hors: so , we have new UC to be added ←
13:43:37 <betehess> ... and we didn't get comments
... 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
... 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?
... for the people here: what's the status of this document according to you? ←
13:44:47 <betehess> SteveS: I think it's just in maintenance mode
Steve Speicher: I think it's just in maintenance mode ←
13:44:56 <cygri> q+
Richard Cyganiak: q+ ←
13:45:05 <betehess> davidwood: we should ask for review
David Wood: we should ask for review ←
13:45:20 <betehess> ... I'll have to do that anyway
... I'll have to make a review anyway ←
13:45:38 <betehess> s/do that/make a review/
13:45:38 <SteveBattle> Thank you David
Steve Battle: Thank you David ←
13:45:45 <Arnaud> ack rgarcia
Arnaud Le Hors: ack rgarcia ←
13:45:45 <Zakim> rgarcia, you wanted to ask whether we should create actions for these new use cases
Zakim IRC Bot: 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
Raúl García Castro: we can open issues for that, so that we can follow the status of reviews ←
13:46:22 <betehess> ... we can identify these actions
... we can identify these actions ←
13:46:28 <betehess> ... it's a good way to progress
... it's a good way to progress ←
13:46:40 <davidwood> q+ to ask about the satisfaction of each UC
David Wood: q+ to ask about the satisfaction of each UC ←
13:46:58 <betehess> Arnaud: usually, the UCR motivates what goes in the spec
Arnaud Le Hors: 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
... sometime people are not even sure about the UC is when we discuss a feature ←
13:47:46 <Arnaud> ack cygri
Arnaud Le Hors: ack cygri ←
13:48:12 <betehess> cygri: there's different views of the purpose for UCR
Richard Cyganiak: 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?"
... 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
... 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
... examples that we can follow ←
13:50:00 <betehess> ... I have some issues to add UC with the current organization of the document
... I have some issues to add UC with the current organization of the document ←
13:50:10 <sandro> q?
Sandro Hawke: q? ←
13:50:23 <betehess> ... I hope SteveBattle will be able to help people there
... I hope SteveBattle will be able to help people there ←
13:50:40 <betehess> SteveBattle: every UC should be given a URI
Steve Battle: every UC should be given a URI ←
13:50:42 <sandro> q+
Sandro Hawke: q+ ←
13:50:53 <Arnaud> ack davidwood
Arnaud Le Hors: ack davidwood ←
13:50:53 <Zakim> davidwood, you wanted to ask about the satisfaction of each UC
Zakim IRC Bot: 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
Arnaud Le Hors: 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 @@
David Wood: at some point, the status of the document shifts from what people want to what the spec will support ←
13:51:47 <betehess> ... we may decide as a group that we cannot support some of them
... 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
... 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
... 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
Arnaud Le Hors: 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
... we never did that ←
13:54:00 <betehess> cygri: a UC that we decide to address will also depend on the time available
Richard Cyganiak: a UC that we decide to address will also depend on the time available ←
13:54:04 <davidwood> +1 to cygri
David Wood: +1 to cygri ←
13:54:07 <rgarcia> +1
Raúl García Castro: +1 ←
13:54:26 <betehess> ... if we say yes or no, we loose the possibility to drop UC on this basis
... 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
... can be out of scope, and there are things that we cannot address in time ←
13:54:57 <Arnaud> ack sandro
Arnaud Le Hors: ack sandro ←
13:55:13 <betehess> sandro: would be fine to start with high/low priority
Sandro Hawke: would be fine to start with high/low priority ←
13:55:42 <betehess> ... people could explain to the editor and we decide together
... people could explain to the editor and we decide together ←
13:55:51 <betehess> Arnaud: how much time would it require?
Arnaud Le Hors: how much time would it require? ←
13:56:07 <betehess> sandro: we could save time instead of cycling if we don't do that
Sandro Hawke: 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
Arnaud Le Hors: another aspect: do we have a sense of if the spec *today* addresses the UCR ←
13:56:41 <betehess> ... what is addressed?
... what is addressed? ←
13:56:42 <betehess> q+
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
Richard Cyganiak: 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
Arnaud Le Hors: ack betehess ←
13:58:21 <betehess> betehess: do we want to have links in the document to the UCR documents?
Alexandre Bertails: do we want to have links in the spec 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.
Steve Battle: 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:59:45 <betehess> Arnaud: I want to make sure that we are good where we are with UCR, or not
Arnaud Le Hors: 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
Steve Battle: 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
Arnaud Le Hors: also davidwood is ok to have a closer look ←
14:00:17 <betehess> ... ok with others, just bring issues
... ok with others, just bring issues ←
14:00:27 <betehess> davidwood: we need formal actions
David Wood: we need formal actions ←
14:01:14 <davidwood> ACTION: davidwood to review the UCR document
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].
Trackbot IRC Bot: 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.
Miguel Esteban Gutiérrez: So I'll do the other review of the UCR. ←
14:01:53 <davidwood> ACTION: mesteban to review the UCR document
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].
Trackbot IRC Bot: 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
Richard Cyganiak: if we capture more advanced UC, it would be good to decide as gorup to postpone ←
14:02:36 <Zakim> -bblfish
Zakim IRC Bot: -bblfish ←
14:02:45 <betehess> ... maybe this will happen in the case of paging for example
... 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
... but it's good to have captured that as a UC ←
14:03:35 <Zakim> +bblfish
Zakim IRC Bot: +bblfish ←
14:03:37 <betehess> Arnaud: in terms of the schedule, we skip the 2nd WD
Arnaud Le Hors: in terms of the schedule, we skip the 2nd WD ←
14:03:46 <betehess> ... I guess everybody is ok with that
... I guess everybody is ok with that ←
14:04:09 <betehess> ... the end goal for UCR is a NOTE
... 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
Richard Cyganiak: 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
... we can publish an updated WD ←
14:05:17 <betehess> sandro: there is just no normative content
Sandro Hawke: there is just no normative content ←
14:05:41 <betehess> davidwood: REC needs approval
David Wood: REC needs approval ←
14:05:51 <betehess> Arnaud: LC target is May
Arnaud Le Hors: LC target is May ←
14:06:46 <betehess> ... so UCR should be a NOTE by then
... so UCR should be a NOTE by then ←
14:07:13 <betehess> ... I think that we have a plan for UCR at this point
... I think that we have a plan for UCR at this point ←
14:07:17 <betehess> ... do we need more?
... do we need more? ←
14:07:25 <Arnaud> q?
Arnaud Le Hors: q? ←
14:07:53 <betehess> cygri: there is a couple of features in the spec, would like to know if there are corresponding UC
Richard Cyganiak: 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
... 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
Steve Battle: metadata about the collection would be that, so it should be covered ←
14:08:38 <betehess> ... ordering in a container is not covered
... ordering in a container is not covered ←
14:08:55 <betehess> ... technically speaking I could ask these things to be removed
... technically speaking I could ask these things to be removed ←
14:09:24 <betehess> SteveS: we covered a story, there may be no UC
Steve Speicher: we covered a story, there may be no UC ←
14:09:51 <betehess> cygri: speaking about ordering in a container
Richard Cyganiak: speaking about ordering in a container ←
14:10:20 <betehess> ... we need the UC, even we need to have this thing in the spec
... 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.
David Wood: 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
Sandro Hawke: also for people outside the group, for them to understand ←
14:10:47 <betehess> cygri: there may be other points in the spec
Richard Cyganiak: there may be other points in the spec ←
14:11:10 <rgarcia> q+
Raúl García Castro: q+ ←
14:11:46 <Arnaud> ack rgarcia
Arnaud Le Hors: ack rgarcia ←
14:11:48 <betehess> ... if we are asked "are there a UC", it's always better to give the pointer
... 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
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].
Trackbot IRC Bot: Created ACTION-43 - Draft a use case for container ordering [on Steve Speicher - due 2013-03-20]. ←
14:14:28 <Arnaud> q?
Arnaud Le Hors: 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).
Steve Battle: 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
Arnaud Le Hors: 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
Arnaud Le Hors: looking at the isssues ←
14:17:26 <rgarcia> q+
Raúl García Castro: q+ ←
14:17:26 <betehess> ... some are similar, related to others
... 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."
Richard Cyganiak: 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
... 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
Richard Cyganiak: 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"
... 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
... and then we invite the rest of the world to look at it ←
14:18:51 <betehess> ... supposed to feature complte
... supposed to feature complte ←
14:19:02 <rgarcia> q-
Raúl García Castro: q- ←
14:19:08 <betehess> ... then there is a process to respond to comments
... then there is a process to respond to comments ←
14:19:18 <betehess> ... everything has to be documented
... 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
... 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
... after LC, we need to show implementations ←
14:20:24 <betehess> sandro: my sense is that implementing this is easy
Sandro Hawke: my sense is that implementing this is easy ←
14:20:39 <betehess> ... it's better to implemented earlier, then we can skip CR
... it's better to implemented earlier, then we can skip CR ←
14:20:55 <SteveS> http://www.w3.org/wiki/LDP_Implementations
Steve Speicher: http://www.w3.org/wiki/LDP_Implementations ←
14:20:55 <betehess> Arnaud: happy to say that we're in good shape in that regard
Arnaud Le Hors: happy to say that we're in good shape in that regard ←
14:22:10 <betehess> sandro: implementations should include test results
Sandro Hawke: implementations should include test results ←
14:22:17 <betehess> ... cannot say that until we have the test suite
... 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
... we should really try to have the issues closed 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
Arnaud Le Hors: 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
... we can decide that we don't do anything re: specific issue ←
14:23:18 <betehess> Ashok: you need agreement
Ashok Malhotra: you need agreement ←
14:23:38 <betehess> Arnaud: there is a process, we decide as a group
Arnaud Le Hors: there is a process, we decide as a group ←
14:23:38 <betehess> ... then people can raise objections
... then people can raise objections ←
14:24:14 <betehess> sandro: there is the deadline mode, where we realize that perfection can't be achieved
Sandro Hawke: 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
Arnaud Le Hors: would like to take a pass on the list of issues we have ←
14:24:42 <betehess> ... to get a sense of the priorities
... to get a sense of the priorities ←
14:24:50 <betehess> s/iossues/issues/
14:24:56 <betehess> ... is that reasonable?
... is that reasonable? ←
14:25:23 <betehess> ... what are the MUST HAVE?
... what are the MUST HAVE? ←
14:25:46 <roger> issue 37 : Model
Roger Menday: ISSUE-37 : Model ←
14:25:50 <betehess> ... put in IRC what issue NEEDs to be addressed?
... put in IRC what issue NEEDs to be addressed? ←
14:26:08 <JohnArwe> must have: pagination
John Arwe: 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
Trackbot IRC Bot: 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
Trackbot IRC Bot: 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.
Henry Story: 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?
Henry Story: Me trying to work out what people are saying? ←
14:28:53 <SteveBattle> I deeply care about issue-21
Steve Battle: I deeply care about ISSUE-21 ←
14:28:59 <bblfish> Issue-21?
14:28:59 <trackbot> ISSUE-21 -- container affordances -- open
Trackbot IRC Bot: ISSUE-21 -- container affordances -- open ←
14:28:59 <trackbot> http://www.w3.org/2012/ldp/track/issues/21
Trackbot IRC Bot: http://www.w3.org/2012/ldp/track/issues/21 ←
14:29:05 <SteveS> ISSUE-15 for me
Steve Speicher: ISSUE-15 for me ←
14:29:22 <bblfish> Issue-15?
14:29:22 <trackbot> ISSUE-15 -- sharing binary resources and metadata -- open
Trackbot IRC Bot: ISSUE-15 -- sharing binary resources and metadata -- open ←
14:29:22 <trackbot> http://www.w3.org/2012/ldp/track/issues/15
Trackbot IRC Bot: 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
Trackbot IRC Bot: ISSUE-33 -- Pagination for non-container resources -- open ←
14:29:44 <trackbot> http://www.w3.org/2012/ldp/track/issues/33
Trackbot IRC Bot: http://www.w3.org/2012/ldp/track/issues/33 ←
14:30:13 <nmihindu> +1 ISSUE-15
Nandana Mihindukulasooriya: +1 ISSUE-15 ←
14:30:38 <betehess> I care about issue-15 issue-33 and PATCH-related issues
I care about ISSUE-15 ISSUE-33 and PATCH-related issues ←
14:30:44 <sandro> Patch, Pagination, IntuitiveContainers, BinaryResources
Sandro Hawke: Patch, Pagination, IntuitiveContainers, BinaryResources ←
14:31:04 <bblfish> +1 for me for Patch related issues.
Henry Story: +1 for me for Patch related issues. ←
14:31:44 <cygri> My top issues from the second page: 32, 33, 37, 38 and 39
Richard Cyganiak: 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
Trackbot IRC Bot: ISSUE-39 -- HTTP status codes used for creation -- open ←
14:31:54 <trackbot> http://www.w3.org/2012/ldp/track/issues/39
Trackbot IRC Bot: 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
Trackbot IRC Bot: ISSUE-38 -- filtered representations and inlining -- open ←
14:32:01 <trackbot> http://www.w3.org/2012/ldp/track/issues/38
Trackbot IRC Bot: 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
Trackbot IRC Bot: 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
Trackbot IRC Bot: 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
Trackbot IRC Bot: ISSUE-33 -- Pagination for non-container resources -- open ←
14:32:23 <trackbot> http://www.w3.org/2012/ldp/track/issues/33
Trackbot IRC Bot: 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
Trackbot IRC Bot: 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
Trackbot IRC Bot: http://www.w3.org/2012/ldp/track/issues/32 ←
14:33:02 <bblfish> Hi
14:33:05 <cygri> zakim, who is on the phone?
Richard Cyganiak: zakim, who is on the phone? ←
14:33:05 <Zakim> On the phone I see +1.617.715.aaaa, bblfish
Zakim IRC Bot: 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?
Sandro Hawke: Zakim, who is on the call? ←
14:33:49 <Zakim> On the phone I see +1.617.715.aaaa, bblfish
Zakim IRC Bot: 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
Steve Speicher: 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
Trackbot IRC Bot: ISSUE-43 -- hint at naming a resource on creation -- open ←
14:34:36 <trackbot> http://www.w3.org/2012/ldp/track/issues/43
Trackbot IRC Bot: http://www.w3.org/2012/ldp/track/issues/43 ←
14:34:43 <bblfish> +1 for +43
Henry Story: +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
Steve Speicher: +1 for 43 ←
14:35:09 <bblfish> I want it to be archived that I have a choppy connection.
Henry Story: I want it to be archived that I have a choppy connection. ←
14:35:49 <bblfish> what issues are you speaking of?
Henry Story: 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 :-)
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
and the spec could even state that transactions are not handled ←
14:38:25 <betehess> Arnaud: some of the issues are not very controversial
Arnaud Le Hors: some of the issues are not very controversial ←
14:38:35 <betehess> ... maybe we can identify and close them?
... maybe we can identify and close them? ←
14:39:36 <betehess> ... already identified issue-18 and issue-28
... already identified ISSUE-18 and ISSUE-28 ←
14:40:26 <betehess> SteveS: issue-44 may be difficult to solve
Steve Speicher: 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
Trackbot IRC Bot: ISSUE-44 -- 4.1.9. is obscure or too restrictive -- open ←
14:40:38 <trackbot> http://www.w3.org/2012/ldp/track/issues/44
Trackbot IRC Bot: http://www.w3.org/2012/ldp/track/issues/44 ←
14:41:00 <SteveS> …maybe not difficult, just a little discussion may be needed
Steve Speicher: …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
Trackbot IRC Bot: ISSUE-28 -- transaction/rollback when deleting resources from a LDPC -- open ←
14:41:08 <trackbot> http://www.w3.org/2012/ldp/track/issues/28
Trackbot IRC Bot: 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)
Arnaud Le Hors: 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
Henry Story: yes, ISSUE-28 seems that it should be easy to solve ←
14:41:45 <betehess> Ashok: are etags enough?
Ashok Malhotra: are etags enough? ←
14:41:48 <betehess> q+
q+ ←
14:41:57 <Arnaud> ack bete
Arnaud Le Hors: ack bete ←
14:42:17 <davidwood> q+
David Wood: q+ ←
14:42:33 <Arnaud> ack davidwood
Arnaud Le Hors: ack davidwood ←
14:42:45 <betehess> betehess: it would be ok for updates, no longer when you delete
Alexandre Bertails: it would be ok for updates, no longer when you delete ←
14:42:52 <betehess> davidwood: got this issue recently
David Wood: got this issue recently ←
14:43:03 <betehess> ... etags gives all information for rollback
... etags do not give all information necessary for rollback, especially for containers or complex resources ←
14:43:13 <betehess> q+
q+ ←
14:43:27 <betehess> ... we don't put that in the API
... we don't put that in the API ←
14:43:54 <betehess> ... providing that level of information can be challenging
... providing that level of information can be challenging ←
14:44:19 <betehess> ... that's a lot of burden
... that's a lot of burden ←
14:44:40 <betehess> ... to figure out how to do the roll-back
... to figure out how to do the roll-back ←
14:44:42 <Arnaud> ack betehess
Arnaud Le Hors: ack betehess ←
14:44:52 <SteveS> q+
Steve Speicher: q+ ←
14:45:36 <SteveBattle> q+
Steve Battle: q+ ←
14:46:16 <betehess> cygri: if I think about transaction, this is different from DELETEing
Richard Cyganiak: 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
Arnaud Le Hors: the issue is specifically about DELETEing ←
14:47:07 <betehess> ... not about transaction in general
... not about transaction in general ←
14:47:09 <Arnaud> ack steves
Arnaud Le Hors: ack steves ←
14:47:36 <betehess> SteveS: the way we do it, we never delete anything
Steve Speicher: the way we do it, we never delete anything ←
14:47:56 <betehess> q+
q+ ←
14:48:44 <betehess> q-
q- ←
14:48:53 <Arnaud> ack stevebattle
Arnaud Le Hors: ack stevebattle ←
14:48:53 <betehess> Arnaud: in the spec today, we have a DELETE
Arnaud Le Hors: in the spec today, we have a DELETE ←
14:49:35 <betehess> SteveBattle: nosql technologies achieve performance keeping ACID
Steve Battle: nosql technologies do not achieve performance jettisoning ACID ←
14:49:52 <betehess> s/achieve/do not achieve/
14:49:57 <bblfish> ? I think SteveBattle used the word "jettisoning" ... ok
Henry Story: ? I think SteveBattle used the word "jettisoning" ... ok ←
14:50:08 <SteveBattle> yes I did
Steve Battle: 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.
David Wood: 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
Sandro Hawke: +1 saying DELETE isn't atomic ←
14:51:07 <sandro> +1 saying DELETE isn't NECESARILY atomic
Sandro Hawke: +1 saying DELETE isn't NECESARILY atomic ←
14:51:25 <davidwood> yes, DELETE isn't NECESSARILY atomic
David Wood: yes, DELETE isn't NECESSARILY atomic ←
14:51:27 <SteveBattle> +1
Steve Battle: +1 ←
14:51:41 <betehess> PROPOSAL: close issue-28 by adding in the spec: no guarantee that DELETE is atomic
PROPOSED: close ISSUE-28 by adding in the spec: no guarantee that DELETE is atomic ←
14:51:50 <sandro> +1
Sandro Hawke: +1 ←
14:51:52 <bblfish> makes sense to me
Henry Story: makes sense to me ←
14:52:20 <mesteban> q+ Error handling
Miguel Esteban Gutiérrez: q+ Error handling ←
14:52:35 <betehess> cygri: are we saying that by deleting a container, we also delete the resource?
Richard Cyganiak: are we saying that by deleting a container, we also delete the resource? ←
14:52:50 <betehess> sandro: would still report an error
Sandro Hawke: 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
Henry Story: you can't have an error with http status code if the DELETE of an LDPC fails ←
14:53:10 <Arnaud> q?
Arnaud Le Hors: 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. "
Steve Battle: 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
David Wood: we can send 202 to say that process was not completed ←
14:54:03 <bblfish> makes sense
Henry Story: makes sense ←
14:54:38 <betehess> sandro: should it be propafated to deleted resources?
Sandro Hawke: should it be propagated to deleted resources? ←
14:54:42 <betehess> s/propafated/propagated/
14:54:52 <betehess> q+
q+ ←
14:55:06 <betehess> q- Error
q- Error ←
14:55:11 <betehess> q- handling
q- handling ←
14:55:27 <sandro> sandro: there could be deletions that take hours, for a massive recursive delete.
Sandro Hawke: there could be deletions that take hours, for a massive recursive delete. [ Scribe Assist by Sandro Hawke ] ←
14:55:32 <betehess> mesteban: wanted to comment on error handler
Miguel Esteban Gutiérrez: wanted to comment on error handler ←
14:55:51 <betehess> ... if there is something that fails, we don't know what happens
... 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
Sandro Hawke: what happens to people who try to GET some of those resources, during the recursive deletion [ Scribe Assist by Sandro Hawke ] ←
14:56:11 <SteveS> This was decided at first F2F in ISSUE-25 with composition, where delete of the container delete's its members
Steve Speicher: 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
David Wood: if the error code goes in the spec, there is risk of duplication, if we don't we risk LDP compliant servers returning different HTTP status codes for the same situation ←
14:56:55 <Arnaud> ack bete
Arnaud Le Hors: ack bete ←
14:57:37 <betehess> Arnaud: just remembered we have an issue about error codes ISSUE-19
Arnaud Le Hors: 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
Richard Cyganiak: 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
... 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
Trackbot IRC Bot: ISSUE-19 -- Adressing more error cases -- open ←
14:58:43 <trackbot> http://www.w3.org/2012/ldp/track/issues/19
Trackbot IRC Bot: http://www.w3.org/2012/ldp/track/issues/19 ←
14:58:48 <betehess> ... so the container has to be there
... so the container has to be there ←
14:59:01 <betehess> Arnaud: cygri wants to amend the proposal
Arnaud Le Hors: cygri wants to amend the proposal ←
14:59:12 <betehess> ... by saying that the container is not gone
... by saying that the container is not gone ←
14:59:17 <davidwood> Can cygri write an amended proposal?
David Wood: Can cygri write an amended proposal? ←
14:59:52 <betehess> cygri: can the server check if it can delete everything before doing so?
Richard Cyganiak: can the server check if it can delete everything before doing so? ←
14:59:55 <betehess> ... not always possible
... not always possible ←
15:00:01 <cygri> PROPOSAL: Server MUST NOT report with 200 to DELETEing a container unless deleting all members succeeded.
PROPOSED: 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
John Arwe: 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
David Wood: +1 ←
15:00:14 <sandro> +1
Sandro Hawke: +1 ←
15:00:38 <betehess> Arnaud: it's a refinement
Arnaud Le Hors: it's a refinement ←
15:00:41 <mesteban> 1+
Miguel Esteban Gutiérrez: 1+ ←
15:01:02 <betehess> cygri: what do clients see? that's the question
Richard Cyganiak: 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)
Steve Battle: +0 (this seems to imply that the deletion occurs synchronously with the DELETE) ←
15:01:35 <nmihindu> +q
Nandana Mihindukulasooriya: +q ←
15:01:39 <Arnaud> ack ericp
Arnaud Le Hors: 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.
Richard Cyganiak: 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. [ Scribe Assist by Sandro Hawke ] ←
15:01:42 <betehess> ericP: not sure how to test this
Eric Prud'hommeaux: not sure how to test this ←
15:01:53 <betehess> ... would go for SHOULD
... would go for SHOULD ←
15:02:12 <SteveS> +1
Steve Speicher: +1 ←
15:02:14 <davidwood> q+
David Wood: q+ ←
15:02:15 <Arnaud> ack nmihindu
Arnaud Le Hors: ack nmihindu ←
15:02:36 <betehess> nmihindu: agrees with cygri's idea
Nandana Mihindukulasooriya: agrees with cygri's idea ←
15:02:43 <betehess> ... container should be there
... container should be there ←
15:02:56 <davidwood> q-
David Wood: q- ←
15:02:57 <SteveBattle> I agree with nmhindu
Steve Battle: I agree with nmhindu ←
15:03:10 <betehess> ... there are issues with 202
... there are issues with 202 ←
15:03:12 <JohnArwe> @stevebattle, was thinking similarly ... might need arnaud's original qualification as a note
John Arwe: @stevebattle, was thinking similarly ... might need arnaud's original qualification as a note ←
15:03:15 <sandro> q?
Sandro Hawke: q? ←
15:03:16 <betehess> ... should be 2xx
... should be 2xx ←
15:03:34 <sandro> The key thing is that a container must exist if any of its elements exists.
Sandro Hawke: 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
@@: with 202, you provide a URI to monitor the operation ←
15:04:28 <betehess> Arnaud: we all agree, we just need the proper wording
Arnaud Le Hors: 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!
David Wood: 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
PROPOSED: 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.
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:38 <SteveBattle> q+
Steve Battle: q+ ←
15:06:48 <sandro> no real conflict between these.
Sandro Hawke: no real conflict between these. ←
15:07:08 <Arnaud> ack steveb
Arnaud Le Hors: ack steveb ←
15:07:33 <sandro> SteveBattle: Note we're being stronger than HTTP, which allows server to report deletion and not delete it.
Steve Battle: Note we're being stronger than HTTP, which allows server to report deletion and not delete it. [ Scribe Assist by Sandro Hawke ] ←
15:07:43 <sandro> (agreed)
Sandro Hawke: (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.
PROPOSED: 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
Sandro Hawke: +1 ←
15:08:01 <davidwood> +1
David Wood: +1 ←
15:08:03 <rgarcia> +1
Raúl García Castro: +1 ←
15:08:06 <SteveBattle> +1
Steve Battle: +1 ←
15:08:07 <krp> 1
Kevin Page: 1 ←
15:08:07 <betehess> +1
+1 ←
15:08:08 <bblfish> +1
Henry Story: +1 ←
15:08:08 <krp> 1+1
Kevin Page: 1+1 ←
15:08:10 <Arnaud> +1
Arnaud Le Hors: +1 ←
15:08:11 <JohnArwe> +1
15:08:12 <nmihindu> +1
Nandana Mihindukulasooriya: +1 ←
15:08:12 <SteveS> +1
Steve Speicher: +1 ←
15:08:14 <roger> +1
Roger Menday: +1 ←
15:08:14 <Ashok> +1
Ashok Malhotra: +1 ←
15:08:16 <mesteban> +1
Miguel Esteban Gutiérrez: +1 ←
15:08:21 <cody> +1
Cody Burleson: +1 ←
15:08:25 <ericP> +1
Eric Prud'hommeaux: +1 ←
15:08:40 <sandro> RRSAgent, pointer?
Sandro Hawke: RRSAgent, pointer? ←
15:08:40 <RRSAgent> See http://www.w3.org/2013/03/13-ldp-irc#T15-08-40
RRSAgent IRC Bot: 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.
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
Arnaud Le Hors: that was RESOLVED: ISSUE-28 ←
15:09:00 <sandro> close issue-28
Sandro Hawke: close ISSUE-28 ←
15:09:00 <trackbot> Closed ISSUE-28 transaction/rollback when deleting resources from a LDPC.
Trackbot IRC Bot: 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
Trackbot IRC Bot: ISSUE-28 -- transaction/rollback when deleting resources from a LDPC -- closed ←
15:09:08 <trackbot> http://www.w3.org/2012/ldp/track/issues/28
Trackbot IRC Bot: 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
Trackbot IRC Bot: ISSUE-12 -- Can HTTP PATCH be used for resource creation? -- closed ←
15:09:21 <trackbot> http://www.w3.org/2012/ldp/track/issues/12
Trackbot IRC Bot: http://www.w3.org/2012/ldp/track/issues/12 ←
15:09:24 <ericP> Zakim, who is here?
Eric Prud'hommeaux: Zakim, who is here? ←
15:09:24 <Zakim> On the phone I see +1.617.715.aaaa, bblfish
Zakim IRC Bot: 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,
Zakim IRC Bot: 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
Zakim IRC Bot: ... 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
Trackbot IRC Bot: ISSUE-39 -- HTTP status codes used for creation -- open ←
15:09:30 <trackbot> http://www.w3.org/2012/ldp/track/issues/39
Trackbot IRC Bot: http://www.w3.org/2012/ldp/track/issues/39 ←
15:09:44 <bblfish> ok
Henry Story: ok ←
15:09:51 <Zakim> -bblfish
Zakim IRC Bot: -bblfish ←
15:12:00 <Zakim> - +1.617.715.aaaa
Zakim IRC Bot: - +1.617.715.aaaa ←
15:12:01 <Zakim> Team_(ldp)13:28Z has ended
Zakim IRC Bot: Team_(ldp)13:28Z has ended ←
15:12:01 <Zakim> Attendees were +1.617.715.aaaa, bblfish
Zakim IRC Bot: Attendees were +1.617.715.aaaa, bblfish ←
15:12:58 <ericP> Zakim, move 53794 to here
Eric Prud'hommeaux: Zakim, move 53794 to here ←
15:12:59 <Zakim> ok, ericP; that matches SW_LDP(F2F)10:45AM
Zakim IRC Bot: ok, ericP; that matches SW_LDP(F2F)10:45AM ←
15:13:06 <ericP> Zakim, who is here?
Eric Prud'hommeaux: Zakim, who is here? ←
15:13:06 <Zakim> On the phone I see +1.617.715.aaaa
Zakim IRC Bot: 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,
Zakim IRC Bot: 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
Zakim IRC Bot: ... bblfish, sandro, ericP, Yves, thschee, betehess, trackbot ←
15:22:53 <ericP> Zakim, aaaa is WG-meeting
(No events recorded for 9 minutes)
Eric Prud'hommeaux: Zakim, aaaa is WG-meeting ←
15:22:53 <Zakim> +WG-meeting; got it
Zakim IRC Bot: +WG-meeting; got it ←
<mesteban> scribe: mesteban
(Scribe set to Miguel Esteban Gutiérrez)
15:24:11 <mesteban> subtopic: Issue-43: hint at naming a resource on creation
15:24:39 <SteveS> ISSUE-43
15:24:39 <trackbot> ISSUE-43 -- hint at naming a resource on creation -- open
Trackbot IRC Bot: ISSUE-43 -- hint at naming a resource on creation -- open ←
15:24:39 <trackbot> http://www.w3.org/2012/ldp/track/issues/43
Trackbot IRC Bot: 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
PROPOSED: Support Slug header hint per Atom https://tools.ietf.org/html/rfc5023#section-9.7 ←
15:25:50 <SteveBattle> q+
Steve Battle: q+ ←
15:26:04 <mesteban> arnaud: steve's proposal consistent with the other proposal
Arnaud Le Hors: steve's proposal consistent with the other proposal ←
15:26:24 <mesteban> arnaud: the proposal is to use the slug header
Arnaud Le Hors: the proposal is to use the slug header ←
15:26:30 <sandro> +0 (seems fine, even if annoyingly named)
Sandro Hawke: +0 (seems fine, even if annoyingly named) ←
15:26:43 <SteveBattle> +1 (I like the name)
Steve Battle: +1 (I like the name) ←
15:26:58 <mesteban> arnaud: does it need to be clarified?
Arnaud Le Hors: does it need to be clarified? ←
15:27:21 <cygri> q+
Richard Cyganiak: q+ ←
15:27:36 <ericP> https://tools.ietf.org/html/rfc5023#section-9.7.2
Eric Prud'hommeaux: 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?
Richard Cyganiak: the proposal is about part of the URI (final part) or full URI? ←
15:30:21 <SteveS> q+
Steve Speicher: q+ ←
15:30:38 <mesteban> ericP: we can constrain the way it works
Eric Prud'hommeaux: we can constrain the way it works ←
15:30:39 <roger> +q
Roger Menday: +q ←
15:30:47 <betehess> q+
Alexandre Bertails: q+ ←
15:31:12 <mesteban> cygri: much better if what the user provides is a ui
Richard Cyganiak: 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
Raúl García Castro: the spec just says that the values are for the last URI segment ←
15:31:32 <Arnaud> ack steveb
Arnaud Le Hors: ack steveb ←
15:32:03 <cygri> ack me
Richard Cyganiak: 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.
Steve Battle: We are not limited to use slug headers. Could use the other as well. ←
15:32:36 <Arnaud> ack steves
Arnaud Le Hors: ack steves ←
15:32:47 <TallTed> s/WE ARE NOT LImited/We are not limited/
15:33:26 <cygri> q+
Richard Cyganiak: q+ ←
15:33:27 <Arnaud> ack roger
Arnaud Le Hors: ack roger ←
15:34:24 <mesteban> roger: the slug could be generilized and the have a general way for parsing names in the server
Roger Menday: the slug could be generilized and the have a general way for parsing names in the server ←
15:35:05 <Arnaud> ack bete
Arnaud Le Hors: ack bete ←
15:35:22 <mesteban> krp: but slug is specific for resource names
Kevin Page: but slug is specific for resource names ←
15:36:13 <Arnaud> ack cygri
Arnaud Le Hors: ack cygri ←
15:36:37 <mesteban> betehess: slug is enoguh in terms that can be used for complex scenarios.
Alexandre Bertails: 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 :-)
Sandro Hawke: "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
Richard Cyganiak: 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.
Richard Cyganiak: no difference it is normative of informative as it is optional. ←
15:38:13 <SteveBattle> Is this expressed as MAY or SHOULD?
Steve Battle: Is this expressed as MAY or SHOULD? ←
15:38:18 <sandro> or Suggested Location URI Guide
Sandro Hawke: or Suggested Location URI Guide ←
15:38:44 <mesteban> rgarcia: could go to the deployment
Raúl García Castro: could go to the deployment ←
15:39:26 <mesteban> krp: the spec says that the server may ignore slug headers
Kevin Page: the spec says that the server may ignore slug headers ←
15:40:05 <betehess> q+
Alexandre Bertails: q+ ←
15:40:16 <Arnaud> ack bete
Arnaud Le Hors: ack bete ←
15:40:48 <mesteban> betehess: do I have as a developer a way to know if I can use slug or not?
Alexandre Bertails: 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
PROPOSED: 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
Arnaud Le Hors: think there is value in having it in the spec ←
15:41:39 <SteveBattle> +1
Steve Battle: +1 ←
15:41:51 <mesteban> sandro: suggest to use slug instead of having to do something custom to solve the issue
Sandro Hawke: suggest to use slug instead of having to do something custom to solve the issue ←
15:42:14 <Zakim> +bblfish
Zakim IRC Bot: +bblfish ←
15:42:15 <rgarcia> q+
Raúl García Castro: q+ ←
15:42:53 <bblfish> +1 for Slug
Henry Story: +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
Richard Cyganiak: 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
Arnaud Le Hors: 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."
Eric Prud'hommeaux: 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.
Raúl García Castro: 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.
Raúl García Castro: better move it to the deployment guide. ←
15:44:17 <TallTed> ericP - inaccurate representation of the definition in 5023...
Ted Thibodeau: ericP - inaccurate representation of the definition in 5023... ←
15:44:19 <mesteban> cygri: deployment guide is more about best practicas, spec about features.
Richard Cyganiak: deployment guide is more about best practicas, spec about features. ←
15:44:22 <Arnaud> ack eric
Arnaud Le Hors: 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
Zakim IRC Bot: 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."
Zakim IRC Bot: ... 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.
Richard Cyganiak: slug is about values/words not URLs. ←
15:45:35 <mesteban> ericP: but we could constraint a little bit more
Eric Prud'hommeaux: but we could constraint a little bit more ←
15:45:38 <bblfish> I am not sure about full URLs as slug headers
Henry Story: 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
Henry Story: 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
Nandana Mihindukulasooriya: +q ←
15:46:33 <nmihindu> -q
Nandana Mihindukulasooriya: -q ←
15:46:36 <bblfish> me can hear voiced on phone from here ( goes up and down ) but I just moved to a café.
Henry Story: 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
Richard Cyganiak: 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
Henry Story: 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."
PROPOSED: 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+
Steve Battle: q+ ←
15:48:23 <betehess> q+ to suggest to be lax, so that we can support patterns later, eg. /MM/yy/dd-minutes.html
Alexandre Bertails: 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
John Arwe: 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.
Kevin Page: 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
Henry Story: 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")
Raúl García Castro: +1 (changing "can use" for "MAY use") ←
15:48:56 <bblfish> to just hint at the name
Henry Story: to just hint at the name ←
15:49:19 <bblfish> doing more than Atom should be a different issue.
Henry Story: doing more than Atom should be a different issue. ←
15:49:38 <rgarcia> +q
Raúl García Castro: +q ←
15:50:11 <bblfish> initial slugs: initial .. and / are not relative urls in the slug. They would get encoded I think.
Henry Story: initial slugs: initial .. and / are not relative urls in the slug. They would get encoded I think. ←
15:50:11 <Arnaud> ack steveb
Arnaud Le Hors: ack steveb ←
15:50:20 <mesteban> ericP: the idea is enable users to have clear expectations about the naming of new resources.
Eric Prud'hommeaux: the idea is enable users to have clear expectations about the naming of new resources. ←
15:50:30 <Arnaud> ack bete
Arnaud Le Hors: 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
Zakim IRC Bot: 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-
Alexandre Bertails: q- ←
15:50:41 <Arnaud> ack rgarcia
Arnaud Le Hors: ack rgarcia ←
15:51:27 <mesteban> rgarcia: Richard proposal might need rewording to clarify whether the user has to stick to it or not.
Raúl García Castro: Richard proposal might need rewording to clarify whether the user has to stick to it or not. ←
15:51:54 <Ashok> q+
Ashok Malhotra: q+ ←
15:52:17 <Arnaud> ack ashok
Arnaud Le Hors: ack ashok ←
15:52:17 <mesteban> cygri: making a normative statement raises the bar regarding requirements
Richard Cyganiak: making a normative statement raises the bar regarding requirements ←
15:52:20 <betehess> q+
Alexandre Bertails: q+ ←
15:52:36 <bblfish> q+
Henry Story: q+ ←
15:52:43 <Arnaud> ack bete
Arnaud Le Hors: ack bete ←
15:53:23 <mesteban> Ashok: better to point them to the slug spec and let them refer to it.
Ashok Malhotra: 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.
PROPOSED: 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
John Arwe: @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.
Alexandre Bertails: regardless what we say now we can later go back and constraint its usage in LDP. ←
15:54:58 <Arnaud> ack bblfish
Arnaud Le Hors: ack bblfish ←
15:55:21 <JohnArwe> we're not hearing you yet
John Arwe: we're not hearing you yet ←
15:55:29 <mesteban> TallTed: there are many options regarding how the server may implement the naming scheme
Ted Thibodeau: 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.
David Wood: 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?
Eric Prud'hommeaux: @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
Alexandre Bertails: -1 against anything which will not give enough expectations to the client ←
15:56:44 <davidwood> perhaps
David Wood: 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
Arnaud Le Hors: 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+
Alexandre Bertails: q+ ←
15:57:58 <ericP> betehess, i think that if we want stronger semantics, we can't use Slug: anyways
Eric Prud'hommeaux: betehess, i think that if we want stronger semantics, we can't use Slug: anyways ←
15:58:01 <TallTed> more seriously --
Ted Thibodeau: 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.
PROPOSED: 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.
Richard Cyganiak: 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
Steve Speicher: 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?
Sandro Hawke: 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
David Wood: 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.
Ted Thibodeau: 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.
Sandro Hawke: davidwood, I think it's 100% for a server to just number its resources. ←
15:59:23 <Arnaud> ack bete
Arnaud Le Hors: 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
Henry Story: 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.
Steve Speicher: 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?
Sandro Hawke: 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
Eric Prud'hommeaux: 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.
Sandro Hawke: 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.
Alexandre Bertails: 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.
Henry Story: kind of ok, to move from MAY to SHOULD. ←
16:01:16 <Arnaud> ack david
Arnaud Le Hors: 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
Zakim IRC Bot: 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.
Steve Battle: 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.
David Wood: if the client provides the slug header the server should respect the header. ←
16:02:42 <mesteban> arnaud: but the spec says the opposite
Arnaud Le Hors: 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
Eric Prud'hommeaux: 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
David Wood: 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
Richard Cyganiak: that is ambiguous, the LDP spec should be clear with this respect ←
16:03:54 <Arnaud> ack sandro
Arnaud Le Hors: ack sandro ←
16:03:54 <Zakim> sandro, you wanted to say this is just for human readability, so there is no interop question.
Zakim IRC Bot: 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
Alexandre Bertails: 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
Arnaud Le Hors: 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
Zakim IRC Bot: 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
Zakim IRC Bot: ... 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
Henry Story: yes. there could also be servers that don't want semantics in the names for security reasons ←
16:05:17 <cygri> q+
Richard Cyganiak: q+ ←
16:05:20 <bblfish> ( so I think I am agreeing with Sandro there )
Henry Story: ( 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.
PROPOSED: 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.
Sandro Hawke: we should not mix interoperability specific features with human readability issues. ←
16:05:43 <davidwood> or maybe:
David Wood: or maybe: ←
16:05:55 <Arnaud> ack bete
Arnaud Le Hors: 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
Zakim IRC Bot: 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.
PROPOSED: 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
Eric Prud'hommeaux: +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
Alexandre Bertails: 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
Arnaud Le Hors: 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?
Steve Battle: 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.
Sandro Hawke: +1 cygri: if you want something stronger than MAY, then propose a new header. ←
16:08:17 <ericP> +1
Eric Prud'hommeaux: +1 ←
16:08:20 <rgarcia> +1 cygri
Raúl García Castro: +1 cygri ←
16:08:27 <davidwood> A new header is OK by me
David Wood: 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.
Richard Cyganiak: 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?
Sandro Hawke: 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
Eric Prud'hommeaux: 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?
Sandro Hawke: 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.
Richard Cyganiak: the norm is that the server decides, not the client, but that a client may provide a hint. ←
16:10:08 <Arnaud> ack john
Arnaud Le Hors: ack john ←
16:10:34 <bblfish> q+
Henry Story: q+ ←
16:11:03 <Arnaud> ack sandro
Arnaud Le Hors: ack sandro ←
16:11:03 <Zakim> sandro, you wanted to ask about use case - PUT into a container?
Zakim IRC Bot: 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.
PROPOSED: 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
Eric Prud'hommeaux: i'm not sure we need anything other than Slug: for that header ←
16:12:09 <davidwood> I agree, but others seem to be
David Wood: I agree, but others seem to be ←
16:12:11 <Arnaud> ack bblfish
Arnaud Le Hors: ack bblfish ←
16:12:11 <ericP> i think betehess wants LDP-Tmplate:
Eric Prud'hommeaux: 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.
Sandro Hawke: 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?
Sandro Hawke: davidwood, what's the use case? ←
16:12:47 <bblfish> thats it
Henry Story: thats it ←
16:12:54 <davidwood> Clients wish to have input into what resources become named.
David Wood: Clients wish to have input into what resources become named. ←
16:13:19 <ericP> q+
Eric Prud'hommeaux: q+ ←
16:13:27 <rgarcia> -1
Raúl García Castro: -1 ←
16:13:35 <Arnaud> ack eric
Arnaud Le Hors: ack eric ←
16:14:13 <SteveBattle> q+
Steve Battle: q+ ←
16:14:31 <cody> +1 percent encode and append to container URI
Cody Burleson: +1 percent encode and append to container URI ←
16:14:44 <sandro> q+ to suggest a process
Sandro Hawke: q+ to suggest a process ←
16:15:00 <Arnaud> ack steveb
Arnaud Le Hors: ack steveb ←
16:15:02 <cygri> q+
Richard Cyganiak: q+ ←
16:15:12 <Arnaud> ack sandro
Arnaud Le Hors: ack sandro ←
16:15:12 <Zakim> sandro, you wanted to suggest a process
Zakim IRC Bot: 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
Eric Prud'hommeaux: 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
Arnaud Le Hors: ack cygri ←
16:16:23 <SteveS> q+
Steve Speicher: 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
Alexandre Bertails: 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
Arnaud Le Hors: ack steves ←
16:16:54 <mesteban> cygri: davidwood proposal needs some additional details to be provided that might be tricky
Richard Cyganiak: 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).
Steve Battle: 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
Arnaud Le Hors: (1) use slug as is, (2) use slug and add to it, (3) create some new header [ Scribe Assist by Sandro Hawke ] ←
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.
Steve Speicher: 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
Eric Prud'hommeaux: 0, +1, -1 ←
16:19:05 <bblfish> +1, +1, -1
Henry Story: +1, +1, -1 ←
16:19:08 <davidwood> 0, +1, 0
David Wood: 0, +1, 0 ←
16:19:13 <Ashok> +1,-1,-1
Ashok Malhotra: +1,-1,-1 ←
16:19:22 <SteveS> 0, +1, 0
Steve Speicher: 0, +1, 0 ←
16:19:24 <rgarcia> +1, -1, -1
Raúl García Castro: +1, -1, -1 ←
16:19:24 <SteveBattle> +1,0,-1
Steve Battle: +1,0,-1 ←
16:19:26 <mesteban> +1, 0, +1
+1, 0, +1 ←
16:19:27 <sandro> +1, 0, 0
Sandro Hawke: +1, 0, 0 ←
16:19:32 <betehess> 0, +1, 0
Alexandre Bertails: 0, +1, 0 ←
16:19:38 <krp> +1, 0, -1
Kevin Page: +1, 0, -1 ←
16:19:42 <cygri> +1, -0.25, -1
Richard Cyganiak: +1, -0.25, -1 ←
16:19:42 <nmihindu> +1, -0, -1
Nandana Mihindukulasooriya: +1, -0, -1 ←
16:19:42 <TallTed> 0, -1, 0
Ted Thibodeau: 0, -1, 0 ←
16:19:47 <JohnArwe> +0, -1, -1
16:20:06 <roger> +1, -1, -1
Roger Menday: +1, -1, -1 ←
16:21:17 <Arnaud> resolved: Use slug as is
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.
Arnaud Le Hors: 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
Trackbot IRC Bot: ISSUE-43 -- hint at naming a resource on creation -- open ←
16:21:59 <trackbot> http://www.w3.org/2012/ldp/track/issues/43
Trackbot IRC Bot: http://www.w3.org/2012/ldp/track/issues/43 ←
16:22:10 <bblfish> when are you back?
Henry Story: when are you back? ←
16:22:34 <Zakim> -bblfish
Zakim IRC Bot: -bblfish ←
16:24:23 <JohnArwe> lunch for 35 mins henry
John Arwe: lunch for 35 mins henry ←
17:10:53 <cygri> q+
(No events recorded for 46 minutes)
Richard Cyganiak: q+ ←
17:11:45 <Arnaud> ack cygri
Arnaud Le Hors: ack cygri ←
<ericP> scribe: ericP
(Scribe set to Eric Prud'hommeaux)
17:11:47 <ericP> SteveBattle: callimachus and others use e.g. rdfs:label or skos:prefLabel
Steve Battle: callimachus and others use e.g. rdfs:label or skos:prefLabel ←
17:11:52 <ericP> ... content to just use Slug:
... content to just use Slug: ←
17:12:06 <ericP> cygri: as written, the spec says the server is in charge of inventing the URIs
Richard Cyganiak: 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:)
... 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
... 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:"?
Steve Battle: do we want to tell folks "if you use anything, use Slug:"? ←
17:13:19 <mesteban> 1+
Miguel Esteban Gutiérrez: 1+ ←
17:13:24 <ericP> Arnaud: i propose we don't further specifiy
Arnaud Le Hors: i propose we don't further specifiy ←
17:13:36 <mesteban> +1
Miguel Esteban Gutiérrez: +1 ←
17:13:37 <rgarcia> +1
Raúl García Castro: +1 ←
17:13:38 <cygri> PROPOSAL: Close ISSUE-43
17:13:44 <cody> +1
Cody Burleson: +1 ←
17:13:44 <SteveBattle> +1
Steve Battle: +1 ←
17:13:48 <rgarcia> +1
Raúl García Castro: +1 ←
17:13:51 <nmihindu> +1
Nandana Mihindukulasooriya: +1 ←
17:13:56 <TallTed> ... with no further comment.
Ted Thibodeau: ... with no further comment. ←
17:14:05 <roger> +1
Roger Menday: +1 ←
17:14:10 <TallTed> +1
Ted Thibodeau: +1 ←
17:14:11 <SteveS> +1.0
Steve Speicher: +1.0 ←
17:14:15 <ericP> APPROVED
APPROVED ←
17:14:17 <JohnArwe> +1 to close with pre-lunch resolution only
John Arwe: +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)
Sandro Hawke: (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
Alexandre Bertails: +1 even if I still don't know the form it will take ←
17:14:34 <krp> +1
Kevin Page: +1 ←
17:14:41 <sandro> close issue-43
Sandro Hawke: close ISSUE-43 ←
17:14:41 <trackbot> Closed ISSUE-43 hint at naming a resource on creation.
Trackbot IRC Bot: Closed ISSUE-43 hint at naming a resource on creation. ←
17:14:44 <sandro> RRSAgent, pointer?
Sandro Hawke: RRSAgent, pointer? ←
17:14:44 <RRSAgent> See http://www.w3.org/2013/03/13-ldp-irc#T17-14-44
RRSAgent IRC Bot: See http://www.w3.org/2013/03/13-ldp-irc#T17-14-44 ←
17:14:49 <ericP> topic: Primer
17:14:59 <trackbot> ISSUE-43 -- hint at naming a resource on creation -- closed
Trackbot IRC Bot: ISSUE-43 -- hint at naming a resource on creation -- closed ←
17:14:59 <trackbot> http://www.w3.org/2012/ldp/track/issues/43
Trackbot IRC Bot: 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
Arnaud Le Hors: 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.
... 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
... 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
... the Primer would be for users of the spec ←
17:16:05 <sandro> RRSAgent, make records public
Sandro Hawke: RRSAgent, make records public ←
17:16:44 <ericP> ... so more educational material goes into the Primer
... so more educational material goes into the Primer ←
17:17:32 <ericP> ... who writes this Primer?
... who writes this Primer? ←
17:18:11 <ericP> JohnArwe: i think there's an 85% chance that i'll have to write one anyways
John Arwe: 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...
Steve Speicher: Primer is 4th on my priority list. once they're done... ←
17:21:14 <ericP> Arnaud: work on the spec will take cycles from the WG
Arnaud Le Hors: work on the spec will take cycles from the WG ←
17:21:22 <ericP> ... my priority is the spec
... my priority is the spec ←
17:22:17 <ericP> davidwood: i'll volunteer to work on the Primer after May
David Wood: 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
Nandana Mihindukulasooriya: Arnaud, the issues that were mentioned important in the morning - 15, 21, 27, 32, 33, 37, 38, 39 ←
17:25:49 <Arnaud> thanks Nandana
Arnaud Le Hors: thanks Nandana ←
17:26:10 <ericP> roger: in issue-39, sometimes you don't can't instantly create resources
Roger Menday: 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
John Arwe: 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
... 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
Roger Menday: 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
John Arwe: 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?
Ted Thibodeau: 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
John Arwe: i don't believe it's prohibited, but also not suggested ←
17:30:51 <ericP> ... who uses 202s?
... who uses 202s? ←
17:31:05 <ericP> davidwood: i've seen it in the wild and we use it
David Wood: 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?
Ted Thibodeau: when 202 is used, does the server provide a polling address? ←
17:32:20 <ericP> davidwood: we give the same address as the polling address
David Wood: we give the same address as the polling address ←
17:32:28 <ericP> ericP: but you could de-couple that in the future
Eric Prud'hommeaux: but you could de-couple that in the future ←
17:32:29 <SteveS> q+
Steve Speicher: q+ ←
17:33:14 <ericP> SteveS: currently, it must return a 201 when it's created a resource
Steve Speicher: 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
... 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-
Steve Speicher: q- ←
17:34:17 <ericP> cygri: one pattern is that a POST returns a redirect (303) to the created resource
Richard Cyganiak: 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
... normal web browsers don't know not to render the body of a 201 ←
17:35:20 <ericP> ... current text prohibits this pattern
... 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
John Arwe: 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,
John Arwe: 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
John Arwe: the 303 (See Other) response can be used to direct the user agent to ←
17:36:34 <JohnArwe> retrieve a cacheable resource.
John Arwe: retrieve a cacheable resource. ←
17:36:40 <ericP> ... we want to make it easy for clients to find the created resource
... 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
... saying 201, Location:, no body makes that easy ←
17:37:21 <ericP> ... but it forbids deferred creation and redirect to cachable resource patterns
... 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"
... 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
Arnaud Le Hors: 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
John Arwe: 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
Alexandre Bertails: 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+
Alexandre Bertails: q+ ←
17:44:37 <SteveS> q+
Steve Speicher: q+ ←
17:44:55 <Arnaud> ack bete
Arnaud Le Hors: ack bete ←
17:45:27 <ericP> betehess: since we have only two scenarios, should we just specify both the asynch and synch scenarios?
Alexandre Bertails: 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
... 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
Richard Cyganiak: 303 explicity tells the client to dereference the Location: header and 201 does not ←
17:46:34 <ericP> ... normal web browsers observe 303
... normal web browsers observe 303 ←
17:46:53 <ericP> ... HTTP says that 201 SHOULD include an entity body
... 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
... and we're saying that one MUST NOT include a body with a 201 ←
17:47:30 <Arnaud> ack steves
Arnaud Le Hors: 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
Alexandre Bertails: 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?
Cody Burleson: 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"
Richard Cyganiak: 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
Alexandre Bertails: does 303 mean i was successful ←
17:52:45 <ericP> betehess: does 303 mean i was successful?
Alexandre Bertails: does 303 mean i was successful? ←
17:53:06 <ericP> cygri: it's a pattern you see in normal web apps
Richard Cyganiak: 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
Sandro Hawke: that's all 303 was used for before the SemWeb [httprange14] hack ←
17:54:03 <ericP> betehess: are we conflating "creation" and "see other"?
Alexandre Bertails: 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
Richard Cyganiak: there's nothing in the 303 that tells you that the creation succeeded ←
17:54:25 <gavinc> No, the TAG did that :P
Gavin Carothers: 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
... with conventional browsers, our mandated 201 with no body means that a human user sees an empty page ←
17:56:16 <mesteban> q+
Miguel Esteban Gutiérrez: q+ ←
17:56:33 <ericP> ... use case: i'm building a browser tool for testing LDP services.
... 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
... .. 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
Alexandre Bertails: 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
... .. it'd be nice if the server were allowed to provide a body for the user to see ←
17:58:05 <betehess> q+
Alexandre Bertails: q+ ←
17:58:07 <Arnaud> ack mesteban
Arnaud Le Hors: ack mesteban ←
17:58:31 <ericP> mesteban: does the 201 with a no body mean the same thing as a 204?
Miguel Esteban Gutiérrez: 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
John Arwe: 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
Richard Cyganiak: 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
John Arwe: if the request was successful and there was no body, return a 204 ←
18:00:19 <Arnaud> ack bete
Arnaud Le Hors: ack bete ←
18:00:30 <ericP> ... it's not clear in HTTP whether 303 is a valid response to a creation
... it's not clear in HTTP whether 303 is a valid response to a creation ←
18:01:23 <Zakim> +bblfish
Zakim IRC Bot: +bblfish ←
18:01:54 <bblfish> Issue-39?
18:01:54 <trackbot> ISSUE-39 -- HTTP status codes used for creation -- open
Trackbot IRC Bot: ISSUE-39 -- HTTP status codes used for creation -- open ←
18:01:54 <trackbot> http://www.w3.org/2012/ldp/track/issues/39
Trackbot IRC Bot: 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
Alexandre Bertails: 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
... 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
Alexandre Bertails: 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
Arnaud Le Hors: in order to improve interop, we should restrict the number of response codes ←
18:04:15 <ericP> ... roger's point was about 202
... roger's point was about 202 ←
18:04:29 <ericP> ... then cygri said "what about 303?"
... then cygri said "what about 303?" ←
18:04:44 <ericP> ... what if we go back to just 201 and 202?
... what if we go back to just 201 and 202? ←
18:04:54 <ericP> ... do we want to add 303?
... 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
John Arwe: 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
John Arwe: 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
John Arwe: 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
John Arwe: 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
John Arwe: 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
John Arwe: 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
John Arwe: 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.
John Arwe: agent does not already have the representation cached. ←
18:05:23 <ericP> cygri: i'd like either 303 or 201+body
Richard Cyganiak: i'd like either 303 or 201+body ←
18:05:30 <JohnArwe> ...which is different than 2616's POST-303 text
John Arwe: ...which is different than 2616's POST-303 text ←
18:05:39 <JohnArwe> ...and it explicitly mentions Location
John Arwe: ...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"
... 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
Arnaud Le Hors: ack john ←
18:08:57 <ericP> JohnArwe: i pasted about the 303 case. it explicitly mentions the Location: headers
John Arwe: 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
Alexandre Bertails: 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
PROPOSED: 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
David Wood: +1 to removing 5.4.5 ←
18:10:36 <betehess> 0+
Alexandre Bertails: 0+ ←
18:10:37 <sandro> ericP, yes --- there's the semantic-web-303 hack. that might apply here.
Sandro Hawke: ericP, yes --- there's the semantic-web-303 hack. that might apply here. ←
18:10:40 <TallTed> +1
Ted Thibodeau: +1 ←
18:10:53 <mesteban> +1
Miguel Esteban Gutiérrez: +1 ←
18:11:08 <cygri> +1 to removing 5.4.5
Richard Cyganiak: +1 to removing 5.4.5 ←
18:11:11 <nmihindu> +1
Nandana Mihindukulasooriya: +1 ←
18:11:13 <rgarcia> +1
Raúl García Castro: +1 ←
18:11:14 <roger> +1
Roger Menday: +1 ←
18:11:17 <krp> +1
Kevin Page: +1 ←
18:11:20 <cody> +1 to removing 5.4.5
Cody Burleson: +1 to removing 5.4.5 ←
18:11:41 <SteveBattle> +1
Steve Battle: +1 ←
18:12:36 <ericP> SteveS: the 5.4.5 "no body" text came from our need to clarify our client expections.
Steve Speicher: 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.
... 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.
Steve Speicher: we found it easier/better to say just use the location header. the 201 body wasn't always good. [ Scribe Assist by Sandro Hawke ] ←
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.
Cody Burleson: 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"
Richard Cyganiak: "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
... HTTP says that ←
18:14:12 <SteveS> +.99 plug give guidance to clients to not expect it
Steve Speicher: +.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
PROPOSED: Delete 1st sentence of section 5.4.5, and reword the second one as informative ←
18:16:04 <bblfish> +1
Henry Story: +1 ←
18:16:04 <ericP> +1
+1 ←
18:16:06 <krp> +1
Kevin Page: +1 ←
18:16:07 <betehess> +1
Alexandre Bertails: +1 ←
18:16:07 <rgarcia> +1
Raúl García Castro: +1 ←
18:16:09 <nmihindu> +1
Nandana Mihindukulasooriya: +1 ←
18:16:15 <cody> 5.4.5
Cody Burleson: 5.4.5 ←
18:16:15 <cygri> +1
Richard Cyganiak: +1 ←
18:16:20 <mesteban> +1
Miguel Esteban Gutiérrez: +1 ←
18:16:25 <cody> +1
Cody Burleson: +1 ←
18:16:26 <Arnaud> s/4.5.5/5.4.5/
18:16:33 <TallTed> +1
Ted Thibodeau: +1 ←
18:16:56 <ericP> RESOLVED: Delete 1st sentence of section 5.4.5, and reword the second one as informative
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
Richard Cyganiak: 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
... 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
Alexandre Bertails: q+ to ask if we have to specify the monitor ←
18:19:07 <ericP> ... client says "please create X for me".
... client says "please create X for me". ←
18:19:40 <ericP> ... server says "i've accepted your request (but i may not be successful)"
... 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
Henry Story: 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
... so 202 doesn't as such say where the new resource might be ←
18:20:07 <SteveBattle> q+
Steve Battle: q+ ←
18:20:11 <ericP> ... we said we could use Location:
... we said we could use Location: ←
18:20:21 <Arnaud> ack bete
Arnaud Le Hors: ack bete ←
18:20:21 <Zakim> betehess, you wanted to ask if we have to specify the monitor
Zakim IRC Bot: betehess, you wanted to ask if we have to specify the monitor ←
18:20:27 <ericP> roger: yeah, Location: usually used with 201
Roger Menday: yeah, Location: usually used with 201 ←
18:20:52 <ericP> betehess: we can use the Location: header and have the client poll
Alexandre Bertails: 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
... or we can use the monitor, which we need to document ←
18:21:38 <bblfish> Is there a use case for 202?
Henry Story: Is there a use case for 202? ←
18:23:12 <SteveS> q+
Steve Speicher: q+ ←
18:23:24 <Arnaud> bblfish, yes, roger has one
Arnaud Le Hors: bblfish, yes, roger has one ←
18:23:36 <Arnaud> ack steveb
Arnaud Le Hors: ack steveb ←
18:23:42 <ericP> cygri: i've never seen use of 202 on a (created) resource
Richard Cyganiak: i've never seen use of 202 on a (created) resource ←
18:23:51 <nmihindu> q+
Nandana Mihindukulasooriya: q+ ←
18:24:08 <ericP> ericP: we may have to define the behavior of a GET on a not-yet-created resource anyways
Eric Prud'hommeaux: we may have to define the behavior of a GET on a not-yet-created resource anyways ←
18:24:19 <Arnaud> ack steves
Arnaud Le Hors: ack steves ←
18:24:35 <ericP> SteveBattle: i'm not comfortable with conflating the monitor with the created resource
Steve Battle: i'm not comfortable with conflating the monitor with the created resource ←
18:24:38 <ericP> SteveS
SteveS ←
18:25:20 <ericP> SteveS: in the typical case of creation, it's maybe seconds to create a resource
Steve Speicher: in the typical case of creation, it's maybe seconds to create a resource ←
18:25:26 <Arnaud> ack nmihindu
Arnaud Le Hors: ack nmihindu ←
18:26:02 <ericP> nmihindu: the server could return a 404 on a deferred creation.
Nandana Mihindukulasooriya: the server could return a 404 on a deferred creation. ←
18:26:32 <cygri> q+ to make a proposal
Richard Cyganiak: q+ to make a proposal ←
18:27:00 <ericP> ... the client can know that it's asking for a resource that's being created
... 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
PROPOSED: 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
... 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+
Alexandre Bertails: q+ ←
18:27:54 <betehess> q-
Alexandre Bertails: q- ←
18:27:58 <cygri> PROPOSAL: If the resource was created successfully, the server MUST respond with 201.
PROPOSED: If the resource was created successfully, the server MUST respond with 201. ←
18:28:18 <Arnaud> ack cygri
Arnaud Le Hors: ack cygri ←
18:28:18 <Zakim> cygri, you wanted to make a proposal
Zakim IRC Bot: cygri, you wanted to make a proposal ←
18:28:20 <SteveBattle> q+
Steve Battle: q+ ←
18:28:48 <SteveS> +1, +1
Steve Speicher: +1, +1 ←
18:29:02 <Arnaud> ack steveb
Arnaud Le Hors: ack steveb ←
18:29:38 <nmihindu> +1
Nandana Mihindukulasooriya: +1 ←
18:29:40 <betehess> +1
Alexandre Bertails: +1 ←
18:29:40 <rgarcia> +1
Raúl García Castro: +1 ←
18:29:41 <krp> +1
Kevin Page: +1 ←
18:29:42 <bblfish> +1
Henry Story: +1 ←
18:29:42 <mesteban> +1
Miguel Esteban Gutiérrez: +1 ←
18:29:43 <roger> +1
Roger Menday: +1 ←
18:29:52 <ericP> +1
+1 ←
18:30:01 <davidwood> +1
David Wood: +1 ←
18:30:06 <TallTed> +1
Ted Thibodeau: +1 ←
18:30:06 <cody> +1
Cody Burleson: +1 ←
18:30:10 <ericP> RESOLVED: If the resource was created successfully, the server MUST respond with 201.
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.
Steve Battle: 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
Arnaud Le Hors: "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
Arnaud Le Hors: today we have a member predicate which specifies how you indicate membership ←
18:33:42 <ericP> ... sometimes i want to turn that relationship around
... 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
Steve Battle: exactly, if i wanted to say that the container is linked by skos:conceptScheme, the container is used as the object ←
18:34:46 <bblfish> Issue-21
18:34:46 <trackbot> ISSUE-21 -- container affordances -- open
Trackbot IRC Bot: ISSUE-21 -- container affordances -- open ←
18:34:46 <trackbot> http://www.w3.org/2012/ldp/track/issues/21
Trackbot IRC Bot: 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+
Alexandre Bertails: q+ ←
18:35:35 <nmihindu> example - http://lists.w3.org/Archives/Public/public-ldp-wg/2013Mar/0057.html
Nandana Mihindukulasooriya: 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?
David Wood: seems reasonable, but why do you *prefer* this? ←
18:35:58 <ericP> SteveBattle: to use the skos vocab
Steve Battle: to use the skos vocab ←
18:36:10 <cygri> q+
Richard Cyganiak: q+ ←
18:37:32 <ericP> Arnaud: following up that email, you've made a proposal
Arnaud Le Hors: following up that email, you've made a proposal ←
18:37:38 <Arnaud> ack bete
Arnaud Le Hors: ack bete ←
18:38:06 <ericP> betehess: Q: do we have to choose either membershipPredicate or reverseMembershipPredicate?
Alexandre Bertails: Q: do we have to choose either membershipPredicate or reverseMembershipPredicate? ←
18:38:27 <JohnArwe> ...said choice being _on a single LDPC_
John Arwe: ...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.)
Sandro Hawke: 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
... i've implemented a client that just follows links and it can't follow this reversal ←
18:38:49 <Arnaud> ack cygri
Arnaud Le Hors: ack cygri ←
18:39:04 <ericP> SteveBattle: that's confusing navigability with arc direction
Steve Battle: 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
Richard Cyganiak: 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
Eric Prud'hommeaux: i think this assumes that arc direction prescribes authority ←
18:41:43 <Ashok> q+
Ashok Malhotra: q+ ←
18:43:18 <Arnaud> ack sandro
Arnaud Le Hors: 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.)
Zakim IRC Bot: 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
sounds like access-limited logic to me ←
18:43:37 <ericP> -> http://www.cs.utexas.edu/users/qr/algernon.html Access-Limited Logic
-> 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 ]
Richard Cyganiak: sandro, how about: <> ldp:membershipPredicate [ owl:inverseOf skos:inScheme ] ←
18:44:19 <Arnaud> ack ashok
Arnaud Le Hors: ack ashok ←
18:44:33 <ericP> sandro: for RDF properties, OWL follows the mathmatical convention to call this "inverse"
Sandro Hawke: for RDF properties, OWL follows the mathmatical convention to call this "inverse" ←
18:44:43 <sandro> cute cygri ... yeah.....
Sandro Hawke: cute cygri ... yeah..... ←
18:45:00 <cygri> sandro, we use that pattern in data cube
Richard Cyganiak: sandro, we use that pattern in data cube ←
18:45:11 <cody> In OWL, for example, inverse is the terms (owl:inverseOf)
Cody Burleson: 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.
Sandro Hawke: 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
Steve Battle: this is mostly motivated by using skos:inScheme ←
18:47:08 <ericP> Arnaud: dret already expressed concearns about the membershipPredicate
Arnaud Le Hors: dret already expressed concearns about the membershipPredicate ←
18:47:09 <sandro> q?
Sandro Hawke: q? ←
18:47:21 <ericP> ... this adds another layer to that
... this adds another layer to that ←
18:47:51 <bblfish> inventing inverse properties is not a good idea
Henry Story: 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 ]
Sandro Hawke: 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
Richard Cyganiak: 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.
Henry Story: 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.
Sandro Hawke: +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
Ted Thibodeau: 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
Steve Battle: There is no inverse of skos: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
Sandro Hawke: +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
Henry Story: "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.
Sandro Hawke: 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+
Alexandre Bertails: q+ ←
18:54:01 <ericP> cygri, in SteveBattle's proposal, you must look for ldp:membershipPredicate or ldp:reverseMembershipPredicate
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
Richard Cyganiak: 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 ] .
... in my proposal you must look for ldp:membershipPredicate x or ldp:membershipPredicate [ owl:inverseOf x ] . ←
18:55:06 <Arnaud> ack bete
Arnaud Le Hors: ack bete ←
18:55:30 <SteveS> q+
Steve Speicher: q+ ←
18:56:00 <Arnaud> ack steves
Arnaud Le Hors: 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.
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 an owl:inverseOf property, it's the object of that. ←
18:56:23 <SteveBattle> q+
Steve Battle: 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
Ted Thibodeau: 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...
Alexandre Bertails: 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
Henry Story: I like the owl:inverseFunctionalProperty solution ←
18:57:49 <Arnaud> ack steveb
Arnaud Le Hors: ack steveb ←
18:58:24 <bblfish> q+
Henry Story: q+ ←
18:58:36 <Arnaud> ack bblfish
Arnaud Le Hors: ack bblfish ←
18:58:55 <sandro> bblfish, too much background noise;
Sandro Hawke: bblfish, too much background noise; ←
18:58:58 <JohnArwe> your bckgrnd noise is bad
John Arwe: your bckgrnd noise is bad ←
18:58:58 <bblfish> ok
Henry Story: ok ←
18:59:09 <JohnArwe> IRC maybe?
18:59:09 <ericP> bblfish: i'll have fries and a pint of pilsner
Henry Story: 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,
Henry Story: I am just saying that the bnode cannot be put in relation position, ←
18:59:29 <bblfish> so therefore the owl:inverseFunctionalProperty works correctly
Henry Story: so therefore the owl:inverseFunctionalProperty works correctly ←
18:59:41 <bblfish> since you cannot do a bnode c
Henry Story: 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
Henry Story: using a bnode as the object of the ldp:membershipPredicate means you have to use the owl:inverseFunctionalProperty ←
19:00:13 <rgarcia> q+
Raúl García Castro: q+ ←
19:00:13 <bblfish> q+
Henry Story: q+ ←
19:00:19 <cygri> q+
Richard Cyganiak: q+ ←
19:00:25 <bblfish> I wrote my argument above
Henry Story: I wrote my argument above ←
19:00:53 <ericP> rgarcia: this is the first time that OWL is mentioned in this spec
Raúl García Castro: this is the first time that OWL is mentioned in this spec ←
19:01:00 <Arnaud> ack rgarcia
Arnaud Le Hors: ack rgarcia ←
19:01:08 <bblfish> I wrote my question above
Henry Story: I wrote my point above ←
19:01:15 <bblfish> s/question/point/
19:01:44 <bblfish> owl is not such a big deal
Henry Story: 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
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?
Steve Battle: Can we squeeze owl:sameAs in somewhere? ←
19:02:19 <bblfish> owl:sameAs is useful all the time
Henry Story: owl:sameAs is useful all the time ←
19:02:35 <bblfish> Ok. So I am arguing that the parsing is not a problem!!!!
Henry Story: Ok. So I am arguing that the parsing is not a problem!!!! ←
19:02:51 <Arnaud> ack bblfish
Arnaud Le Hors: ack bblfish ←
19:02:58 <cygri> ack me
Richard Cyganiak: ack me ←
19:03:50 <bblfish> yes, the point is that you cannot put the bnode in relation position
Henry Story: yes, the point is that you cannot put the bnode in relation position ←
19:03:59 <bblfish> I am not complaining
Henry Story: I am not complaining ←
19:04:34 <bblfish> dp:membershipPredicate [ owl:inverseOf x ]
Henry Story: dp:membershipPredicate [ owl:inverseOf x ] ←
19:04:48 <bblfish> dp:membershipPredicate bnode. bnode owl:inverseOf x .
Henry Story: 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
Henry Story: 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
Henry Story: my answer is that you cannot use the bnode as the property ←
19:05:21 <bblfish> therefore you must use x
Henry Story: 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
Sandro Hawke: :-) 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
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.
Henry Story: 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 :-)
Henry Story: yes, I am supporting the approach of cygri :-) ←
19:06:37 <bblfish> thanks
Henry Story: thanks ←
19:06:44 <SteveBattle> We've got it
Steve Battle: We've got it ←
19:06:53 <bblfish> Am in a restaurant here. Got stuck in Amsterdam because of snow in Paris
Henry Story: Am in a restaurant here. Got stuck in Amsterdam because of snow in Paris ←
19:08:45 <Zakim> -bblfish
Zakim IRC Bot: -bblfish ←
19:32:03 <cygri> q+
(No events recorded for 23 minutes)
Richard Cyganiak: q+ ←
19:33:41 <Zakim> +bblfish
Zakim IRC Bot: +bblfish ←
19:33:55 <Arnaud> ack cygri
Arnaud Le Hors: ack cygri ←
19:34:00 <cygri> cygri: how about steve's proposal with the property called ldp:membershipPredicateInverse?
Richard Cyganiak: how about steve's proposal with the property called ldp:membershipPredicateInverse? [ Scribe Assist by Richard Cyganiak ] ←
19:34:21 <Arnaud> scribe: kevin
(Scribe set to Kevin Page)
19:35:19 <krp> cygri: surprised by controversy in my proposal. is this just about owl use
Richard Cyganiak: surprised by controversy in my proposal. is this just about owl use ←
19:35:26 <krp> ... or are there objections to both proposals?
... or are there objections to both proposals? ←
19:35:31 <TallTed> so something like...
Ted Thibodeau: so something like... ←
19:35:31 <TallTed> <>
Ted Thibodeau: <> ←
19:35:31 <TallTed> dp:membershipPredicate
Ted Thibodeau: dp:membershipPredicate ←
19:35:31 <TallTed> rdfs:member
Ted Thibodeau: rdfs:member ←
19:35:31 <TallTed> .
Ted Thibodeau: . ←
19:35:32 <TallTed> <>
Ted Thibodeau: <> ←
19:35:34 <TallTed> dp:membershipPredicateInverse
Ted Thibodeau: dp:membershipPredicateInverse ←
19:35:36 <TallTed> rdfs:memberOf
Ted Thibodeau: rdfs:memberOf ←
19:35:38 <TallTed> .
Ted Thibodeau: . ←
19:36:10 <SteveBattle> Yes
Steve Battle: Yes ←
19:36:30 <cygri> (1) <> ldp:membershipPredicateInverse skos:inScheme .
Richard Cyganiak: (1) <> ldp:membershipPredicateInverse skos:inScheme . ←
19:36:47 <cygri> (2) <> ldp:membershipPredicate [ owl:inverseOf skos:inScheme ].
Richard Cyganiak: (2) <> ldp:membershipPredicate [ owl:inverseOf skos:inScheme ]. ←
19:37:18 <cygri> (3) do nothing
Richard Cyganiak: (3) do nothing ←
19:37:22 <krp> cygri: other than the options (syntax) above the two proposals are identical
Richard Cyganiak: 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)
Henry Story: 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
Steve Speicher: 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
Ted Thibodeau: (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
Richard Cyganiak: 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.
Steve Battle: 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
Richard Cyganiak: why would we allow having a forward and a reverse, but not two forwards ←
19:40:44 <cygri> +0 +1 -1
Richard Cyganiak: +0 +1 -1 ←
19:40:46 <SteveBattle> +1,0,0
Steve Battle: +1,0,0 ←
19:40:53 <TallTed> +1, -1, -1
Ted Thibodeau: +1, -1, -1 ←
19:40:56 <SteveS> +1, +0, -0
Steve Speicher: +1, +0, -0 ←
19:41:03 <mesteban> +1,-1,0
Miguel Esteban Gutiérrez: +1,-1,0 ←
19:41:06 <betehess> 0, 0, 1
Alexandre Bertails: 0, 0, 1 ←
19:41:07 <roger> 0,1,1
Roger Menday: 0,1,1 ←
19:41:10 <rgarcia> +1, -1, -1
Raúl García Castro: +1, -1, -1 ←
19:41:11 <sandro> 0, 0, +1
Sandro Hawke: 0, 0, +1 ←
19:41:12 <JohnArwe> +0, +0, +0
19:41:16 <nmihindu> +1 -0 0
Nandana Mihindukulasooriya: +1 -0 0 ←
19:41:25 <Ashok> 0,0,1
Ashok Malhotra: 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
Henry Story: 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
0,0,0 ←
19:41:45 <ericP> 0,1,0
Eric Prud'hommeaux: 0,1,0 ←
19:41:47 <davidwood> -0.5, -0, +1
David Wood: -0.5, -0, +1 ←
19:42:24 <cody> 0,0,0
Cody Burleson: 0,0,0 ←
19:42:46 <bblfish> Ok I'll say -0.5,_1,+0
Henry Story: Ok I'll say -0.5,_1,+0 ←
19:42:54 <bblfish> Ok I'll say -0.5,_1,+0
Henry Story: Ok I'll say -0.5,_1,+0 ←
19:43:16 <bblfish> Ok I'll say -0.5,+1,+0
Henry Story: Ok I'll say -0.5,+1,+0 ←
19:43:21 <sandro> issue-21?
19:43:21 <trackbot> ISSUE-21 -- container affordances -- open
Trackbot IRC Bot: ISSUE-21 -- container affordances -- open ←
19:43:21 <trackbot> http://www.w3.org/2012/ldp/track/issues/21
Trackbot IRC Bot: http://www.w3.org/2012/ldp/track/issues/21 ←
19:43:42 <betehess> what was the use-case?
Alexandre Bertails: 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!)
Ted Thibodeau: 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
PROPOSED: 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
Steve Battle: +1 ←
19:44:46 <rgarcia> +1
Raúl García Castro: +1 ←
19:44:47 <sandro> +1 just to be done with this
Sandro Hawke: +1 just to be done with this ←
19:44:49 <SteveS> +1
Steve Speicher: +1 ←
19:44:51 <mesteban> +1
Miguel Esteban Gutiérrez: +1 ←
19:44:52 <betehess> 0
19:44:55 <cygri> 0
19:44:55 <nmihindu> +1
Nandana Mihindukulasooriya: +1 ←
19:45:01 <cody> +1
Cody Burleson: +1 ←
19:45:01 <roger> +1
Roger Menday: +1 ←
19:45:05 <davidwood> 0
David Wood: 0 ←
19:45:09 <sandro> 0 really
Sandro Hawke: 0 really ←
19:45:10 <JohnArwe> +0
19:45:17 <bblfish> 0 I thought cygri's arguments were good, but anyway
Henry Story: 0 I thought cygri's arguments were good, but anyway ←
19:45:20 <TallTed> +0
Ted Thibodeau: +0 ←
19:45:26 <Ashok> 0
Ashok Malhotra: 0 ←
19:45:32 <cygri> (voting 0 because it unnecessarily introduces a new property where an existing term from OWL could have been use)
Richard Cyganiak: (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.)
Sandro Hawke: (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
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
Nandana Mihindukulasooriya: +q ←
19:46:24 <Arnaud> ack nmihindu
Arnaud Le Hors: 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
Henry Story: 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
Arnaud Le Hors: "must-haves": 15, 27, 32, 33, 37, 38 ←
<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
Trackbot IRC Bot: 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
Trackbot IRC Bot: http://www.w3.org/2012/ldp/track/issues/27 ←
19:48:40 <sandro> Yes
Sandro Hawke: 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.
Cody Burleson: 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
Steve Speicher: problems with servers and clients using PATCH, so timbl suggested (at last f2f) using POST as a substitute ←
19:50:59 <krp> ... for modification
... for modification ←
19:51:14 <betehess> q+
Alexandre Bertails: q+ ←
19:51:22 <Ashok> q+
Ashok Malhotra: q+ ←
19:51:36 <krp> Arnaud: for sending changes rather then resending the all the triples
Arnaud Le Hors: for sending changes rather then resending the all the triples ←
19:52:15 <Arnaud> ack bete
Arnaud Le Hors: ack bete ←
19:52:17 <krp> davidwood: how can you legitimately use POST for this?
David Wood: 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
Alexandre Bertails: 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
... 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
Sandro Hawke: sparql things will be doing something extra anyway, so isn't compelling for all cases ldp ←
19:54:32 <ericP> q+
Eric Prud'hommeaux: q+ ←
19:54:33 <krp> betehess: one thing we have been implementing is an ldpr as its own sparql endpoint
Alexandre Bertails: 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
Sandro Hawke: 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
Sandro Hawke: 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
John Arwe: 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
Alexandre Bertails: this doesn't make sense without knowing what is in the body ←
19:56:37 <Arnaud> ack ashok
Arnaud Le Hors: ack ashok ←
19:56:38 <krp> cygri: limited options. sparql update is one
Richard Cyganiak: 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
Ashok Malhotra: 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?
Sandro Hawke: q? ←
19:57:21 <cygri> cygri: options for patch formats: some subset of sparql update; talis changesets; TriG with two magic graphs
Richard Cyganiak: options for patch formats: some subset of sparql update; talis changesets; TriG with two magic graphs [ Scribe Assist by Richard Cyganiak ] ←
19:57:22 <sandro> q+
Sandro Hawke: q+ ←
19:57:42 <krp> steves: recollection was this this was essentially tunnelling through post
Steve Speicher: recollection was this this was essentially tunnelling through post ←
19:58:30 <krp> davidwood: is there any mainstream software having problems with patch?
David Wood: is there any mainstream software having problems with patch? ←
19:58:32 <cygri> q?
Richard Cyganiak: q? ←
19:58:33 <cygri> q+
Richard Cyganiak: q+ ←
19:58:38 <krp> betehess: apache?
Alexandre Bertails: apache? ←
19:59:22 <Arnaud> ack eric
Arnaud Le Hors: ack eric ←
19:59:32 <bblfish> Is there a problem with doing POST doing two different things depending on the mime type?
Henry Story: 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
Alexandre Bertails: HTML forms can do POST but not PATCH [ Scribe Assist by Richard Cyganiak ] ←
19:59:49 <krp> davidwood: we shouldn't resolve a wg issue because of a systems support issue
David Wood: we shouldn't resolve a wg issue because of a systems support issue ←
20:00:19 <Arnaud> ack sandro
Arnaud Le Hors: ack sandro ←
20:00:23 <cygri> q-
Richard Cyganiak: q- ←
20:00:26 <krp> ericP: we have to decide on our patch format.
Eric Prud'hommeaux: we have to decide on our patch format. ←
20:00:31 <cygri> q+
Richard Cyganiak: q+ ←
20:00:44 <bblfish> eric was arguing that PATCH would allow intermediate caching servers to do the right thing
Henry Story: eric was arguing that PATCH would allow intermediate caching servers to do the right thing ←
20:01:00 <Arnaud> ack cygri
Arnaud Le Hors: ack cygri ←
20:01:11 <krp> ericP: patch is the right stanard to send the format through
Eric Prud'hommeaux: 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.
Sandro Hawke: 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
Henry Story: +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
Richard Cyganiak: 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+
Steve Battle: q+ ←
20:02:46 <krp> betehess: for post you always have to state the mimetype
Alexandre Bertails: 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.
John Arwe: 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
Arnaud Le Hors: 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
Steve Battle: 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
Arnaud Le Hors: 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?
Eric Prud'hommeaux: do we know 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.)
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
Henry Story: +1 ←
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.
Richard Cyganiak: 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
Alexandre Bertails: 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
Sandro Hawke: 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+
Steve Speicher: q+ ←
20:06:54 <krp> ericP: put in at risk for post saying this will be removed without responses
Eric Prud'hommeaux: put in at risk for post saying this will be removed without responses ←
20:06:59 <Arnaud> ack steves
Arnaud Le Hors: ack steves ←
20:07:03 <sandro> sandro: and maximum flexibility.
Sandro Hawke: and maximum flexibility. [ Scribe Assist by Sandro Hawke ] ←
20:07:40 <krp> steves: can we just say, closing as is, with an action to investigate incompatibilities with patch
Steve Speicher: can we just say, closing as is, with an action to investigate incompatibilities with patch ←
20:08:12 <cody> q+
Cody Burleson: q+ ←
20:08:13 <krp> davidwood: close as considered, if we get further enquiries they need to provide evidence
David Wood: 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?
Arnaud Le Hors: 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
Arnaud Le Hors: ack cody ←
20:09:57 <krp> ... the at risk pre-empts having to go back to last call if objections are raised
... the at risk pre-empts having to go back to last call if objections are raised ←
20:10:32 <bblfish> q+
Henry Story: 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
Cody Burleson: 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
Arnaud Le Hors: ack bblfish ←
20:10:57 <krp> ... so the question is where do we get spec for implementing the POST method
... so the question is where do we get spec for implementing the POST method ←
20:11:29 <ericP> HTTP-over-POST ?
Eric Prud'hommeaux: HTTP-over-POST ? ←
20:11:54 <roger> +q
Roger Menday: +q ←
20:12:03 <betehess> what is this workaround?
Alexandre Bertails: what is this workaround? ←
20:12:04 <Arnaud> ack roger
Arnaud Le Hors: 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
Henry Story: 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
Henry Story: 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?
Roger Menday: 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
PROPOSED: Close ISSUE-27, as PATCH is the appropriate HTTP verb, and we don't have sufficient evidence for any easier implementability of POST ←
20:13:14 <davidwood> +1
David Wood: +1 ←
20:13:19 <rgarcia> +1
Raúl García Castro: +1 ←
20:13:19 <krp> arnaud: we should just take the risk and stick with PATCH
Arnaud Le Hors: we should just take the risk and stick with PATCH ←
20:13:20 <JohnArwe> +1
20:13:21 <bblfish> +1
Henry Story: +1 ←
20:13:21 <SteveBattle> +1
Steve Battle: +1 ←
20:13:22 <krp> +1
+1 ←
20:13:22 <betehess> +1
Alexandre Bertails: +1 ←
20:13:23 <SteveS> +1
Steve Speicher: +1 ←
20:13:25 <roger> +1
Roger Menday: +1 ←
20:13:26 <mesteban> +1
Miguel Esteban Gutiérrez: +1 ←
20:13:28 <nmihindu> +1
Nandana Mihindukulasooriya: +1 ←
20:13:29 <TallTed> s/the easier/any easier/
20:13:29 <TallTed> +1
Ted Thibodeau: +1 ←
20:13:29 <ericP> +1
Eric Prud'hommeaux: +1 ←
20:13:31 <cody> +1
Cody Burleson: +1 ←
20:13:31 <cygri> +1
Richard Cyganiak: +1 ←
20:13:35 <sandro> +1
Sandro Hawke: +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
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
Steve Speicher: 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
Richard Cyganiak: 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
Arnaud Le Hors: "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
Trackbot IRC Bot: ISSUE-17 -- changesets as a recommended PATCH format -- open ←
20:15:14 <trackbot> http://www.w3.org/2012/ldp/track/issues/17
Trackbot IRC Bot: 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
Trackbot IRC Bot: 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
Trackbot IRC Bot: http://www.w3.org/2012/ldp/track/issues/45 ←
20:16:12 <SteveBattle> q+
Steve Battle: q+ ←
20:16:18 <cygri> q+
Richard Cyganiak: 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
Trackbot IRC Bot: 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
Trackbot IRC Bot: http://www.w3.org/2012/ldp/track/issues/45 ←
20:16:34 <Arnaud> ack steveb
Arnaud Le Hors: ack steveb ←
20:17:03 <SteveS> q+
Steve Speicher: q+ ←
20:17:17 <davidwood> q+ to ask whether POST fails if the resource already exists.
David Wood: 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
Steve Battle: distinguish between posting triples to an ldpc, or posting to a container to add a member ←
20:17:42 <Arnaud> ack cygri
Arnaud Le Hors: ack cygri ←
20:17:45 <Zakim> -bblfish
Zakim IRC Bot: -bblfish ←
20:18:10 <Arnaud> ack steves
Arnaud Le Hors: ack steves ←
20:18:19 <krp> cygri: if I have this easy way to add triple, what about an easy mechanism for delete...
Richard Cyganiak: if I have this easy way to add triple, what about an easy mechanism for delete... ←
20:18:20 <Arnaud> ack david
Arnaud Le Hors: ack david ←
20:18:20 <Zakim> davidwood, you wanted to ask whether POST fails if the resource already exists.
Zakim IRC Bot: 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
Eric Prud'hommeaux: -> http://www.w3.org/2012/Talks/1211-egp-ldp/#%2814%29 comparison of LDP and GSP ←
20:18:47 <Zakim> +bblfish
Zakim IRC Bot: +bblfish ←
20:18:50 <krp> steves: we already have a mechanism to append triples, so seems sensible to maintain consistency for containters
Steve Speicher: 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
PROPOSED: 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.
David Wood: 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
Sandro Hawke: +1 ←
20:19:56 <rgarcia> +1
Raúl García Castro: +1 ←
20:19:57 <mesteban> +1
Miguel Esteban Gutiérrez: +1 ←
20:19:58 <ericP> q+
Eric Prud'hommeaux: q+ ←
20:20:06 <krp> arnaud: consensus seems to be to close this issue
Arnaud Le Hors: consensus seems to be to close this issue ←
20:20:11 <nmihindu> +1
Nandana Mihindukulasooriya: +1 ←
20:20:12 <TallTed> +1 reject POST on existing resource, advising PUT or PATCH as appropriate
Ted Thibodeau: +1 reject POST on existing resource, advising PUT or PATCH as appropriate ←
20:20:13 <SteveBattle> +1
Steve Battle: +1 ←
20:20:13 <krp> ... and not do anything
... and not do anything ←
20:20:15 <SteveS> +1
Steve Speicher: +1 ←
20:20:19 <TallTed> which is not the PROPOSAL...
Ted Thibodeau: which is not the PROPOSAL... ←
20:20:20 <krp> +1
+1 ←
20:20:21 <davidwood> arnaud: slow down :)
Arnaud Le Hors: slow down :) [ Scribe Assist by David Wood ] ←
20:20:23 <Arnaud> ack eric
Arnaud Le Hors: ack eric ←
20:20:27 <JohnArwe> +1
20:20:32 <cygri> +1
Richard Cyganiak: +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
Eric Prud'hommeaux: 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
... 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+
Steve Battle: q+ ←
20:22:37 <bblfish> GSP http://www.w3.org/TR/sparql11-http-rdf-update/
Henry Story: GSP http://www.w3.org/TR/sparql11-http-rdf-update/ ←
20:22:48 <ericP> +1
Eric Prud'hommeaux: +1 ←
20:22:53 <Arnaud> ack steveb
Arnaud Le Hors: ack steveb ←
20:22:55 <davidwood> +1
David Wood: +1 ←
20:23:06 <krp> stevebattle: if I post to a resource does it become a container?
Steve Battle: if I post to a resource does it become a container? ←
20:23:34 <krp> SteveS: unspecified
Steve Speicher: unspecified ←
20:23:42 <davidwood> I hope not :)
David Wood: 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
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
Trackbot IRC Bot: ISSUE-17 -- changesets as a recommended PATCH format -- open ←
20:23:55 <trackbot> http://www.w3.org/2012/ldp/track/issues/17
Trackbot IRC Bot: http://www.w3.org/2012/ldp/track/issues/17 ←
20:24:19 <Arnaud> "must-haves": 15, 32, 33, 37, 38
Arnaud Le Hors: "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
Trackbot IRC Bot: ISSUE-17 -- changesets as a recommended PATCH format -- open ←
20:25:00 <trackbot> http://www.w3.org/2012/ldp/track/issues/17
Trackbot IRC Bot: 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
Trackbot IRC Bot: ISSUE-17 -- changesets as a recommended PATCH format -- open ←
20:25:19 <trackbot> http://www.w3.org/2012/ldp/track/issues/17
Trackbot IRC Bot: http://www.w3.org/2012/ldp/track/issues/17 ←
20:25:19 <sandro> q+
Sandro Hawke: q+ ←
20:25:36 <Arnaud> "must-haves": 15, 17, 32, 33, 37, 38
Arnaud Le Hors: "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.
Henry Story: Agree if one could do this just with RDF that would be cool. ←
20:26:07 <SteveS> q+
Steve Speicher: q+ ←
20:26:08 <ericP> q?
Eric Prud'hommeaux: 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
Steve Battle: 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
Henry Story: there was this: http://lists.w3.org/Archives/Public/public-ldp-wg/2013Mar/0070.html ←
20:26:22 <Arnaud> ack sandro
Arnaud Le Hors: ack sandro ←
20:26:48 <roger> +q
Roger Menday: +q ←
20:27:28 <krp> sandro: a subset of sparql update. standardise this? (turtle update). I now think TriG with special predicates.
Sandro Hawke: 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
Henry Story: 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
... I like the idea that you can use these things outside of PATCH ←
20:27:56 <SteveBattle> q+
Steve Battle: q+ ←
20:27:57 <Arnaud> ack steves
Arnaud Le Hors: ack steves ←
20:28:16 <bblfish> q+
Henry Story: q+ ←
20:28:44 <davidwood> +1 to TriG. The RDF WG is standardizing TriG as a dataset format.
David Wood: +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
Steve Speicher: defining the patch model for rdf, then the patch document format ←
20:29:15 <Arnaud> ack roger
Arnaud Le Hors: ack roger ←
20:29:24 <roger> q-
Roger Menday: q- ←
20:29:26 <Arnaud> ack steveb
Arnaud Le Hors: ack steveb ←
20:29:46 <krp> stevebattle: the problem with tallis changeset was bnodes in lists?
Steve Battle: 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"
Sandro Hawke: "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
Richard Cyganiak: andy's proposed TriG-based format: http://lists.w3.org/Archives/Public/public-ldp-wg/2013Mar/0058.html ←
20:30:39 <Arnaud> ack bblfish
Arnaud Le Hors: 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
Eric Prud'hommeaux: 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?
Alexandre Bertails: does anybody have an example of a PATCH using TriG? ←
20:31:11 <sandro> q+
Sandro Hawke: q+ ←
20:31:12 <betehess> q+
Alexandre Bertails: q+ ←
20:31:21 <SteveBattle> Isn't that SPARQL update?
Steve Battle: Isn't that SPARQL update? ←
20:31:30 <krp> bblfish: like TriG as simple. advantage of minimal sparql update type thing is pattern matching
Henry Story: like TriG as simple. advantage of minimal sparql update type thing is pattern matching ←
20:31:46 <cygri> q+
Richard Cyganiak: q+ ←
20:31:48 <davidwood> …but that ties LDP to SPARQL
David Wood: …but that ties LDP to SPARQL ←
20:31:52 <Arnaud> ack sandro
Arnaud Le Hors: ack sandro ←
20:32:20 <roger> +q
Roger Menday: +q ←
20:32:48 <JohnArwe> is http://wifo5-03.informatik.uni-mannheim.de/bizer/trig/ the syntax spec we're talking about?
John Arwe: is http://wifo5-03.informatik.uni-mannheim.de/bizer/trig/ the syntax spec we're talking about? ←
20:32:51 <SteveS> q+
Steve Speicher: 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)
Sandro Hawke: 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
Eric Prud'hommeaux: 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
Sandro Hawke: http://lists.w3.org/Archives/Public/public-ldp-wg/2013Mar/0058.html ←
20:33:20 <krp> ... that might scare people off
... 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
Richard Cyganiak: JohnArwe, that's outdated. W3C version: https://dvcs.w3.org/hg/rdf/raw-file/default/trig/index.html ←
20:34:11 <Arnaud> ack bete
Arnaud Le Hors: ack bete ←
20:34:28 <ericP> q+ to answer bblfish's q about how to specify a subset of SPARQL
Eric Prud'hommeaux: 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?
Alexandre Bertails: 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.
Sandro Hawke: yes, could potentially have extensions for lists etc. ←
20:35:37 <krp> ericP: thats a wg worth of work
Eric Prud'hommeaux: thats a wg worth of work ←
20:36:09 <SteveBattle> q+
Steve Battle: q+ ←
20:36:12 <Arnaud> ack cygri
Arnaud Le Hors: ack cygri ←
20:36:24 <Arnaud> ack roger
Arnaud Le Hors: ack roger ←
20:36:44 <betehess> rdf:list are really important for a lot of people
Alexandre Bertails: 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
Roger Menday: 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?
Henry Story: q? ←
20:37:26 <krp> ... of http api operations
... of http api operations ←
20:37:46 <krp> sandro: does this solve the problem of deleting the triple from the middle of a resource
Sandro Hawke: 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
Roger Menday: we should support such operations ←
20:38:07 <Arnaud> ack steves
Arnaud Le Hors: ack steves ←
20:39:00 <Arnaud> ack eric
Arnaud Le Hors: ack eric ←
20:39:00 <Zakim> ericP, you wanted to answer bblfish's q about how to specify a subset of SPARQL
Zakim IRC Bot: 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(??)
Steve Speicher: 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
Steve Speicher: 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
Sandro Hawke: 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.
Eric Prud'hommeaux: 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?
David Wood: wouldn't that look a lot like turtle patch? ←
20:40:03 <betehess> this still does not handle rdf:list or shapeless graphs
Alexandre Bertails: this still does not handle rdf:list or shapeless graphs ←
20:40:24 <sandro> shapeless graphs?
Sandro Hawke: shapeless graphs? ←
20:40:30 <krp> ericP: yes. grammatically define it as subgraph of sparql, and reuse the existing sparql semantics
Eric Prud'hommeaux: 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.
David Wood: 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
Alexandre Bertails: 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
... if there were bnodes in the WHERE ←
20:41:10 <betehess> rdf-list is an example
Alexandre Bertails: rdf-list is an example ←
20:41:14 <sandro> how is that possible? isn't every subgraph a pattern that matches itself?
Sandro Hawke: 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
.. the question is whether we want to match a pattern and do things to it ←
20:41:20 <cygri> q+
Richard Cyganiak: q+ ←
20:41:59 <krp> arnaud: what modification do we need to spec section 4.7?
Arnaud Le Hors: 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
... 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
Richard Cyganiak: if I want to add support for PATCH, I need to know the format I should go for ←
20:43:04 <Arnaud> ack steveb
Arnaud Le Hors: ack steveb ←
20:43:28 <sandro> q?
Sandro Hawke: q? ←
20:43:29 <bblfish> yes, clearly the changeset in rdf/xml is not nice
Henry Story: 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
Steve Battle: 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
Arnaud Le Hors: 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
Sandro Hawke: 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?
Richard Cyganiak: make a recommendation for a particular format and mark at risk? ←
20:45:11 <Arnaud> ack cygri
Arnaud Le Hors: ack cygri ←
20:45:49 <krp> ... whatever option we go for it would mean another rec track document for the wg?
... 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
... 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
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
Richard Cyganiak: 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
David Wood: 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
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
David Wood: 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.
... 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
Richard Cyganiak: 0 +1 -1 0 ←
20:48:17 <roger> does 4). cover BATCH-AS-PATCH ?
Roger Menday: does 4). cover BATCH-AS-PATCH ? ←
20:48:28 <krp> sandro: we would have to define the two predicates for trig.
Sandro Hawke: we would have to define the two predicates for trig. ←
20:48:28 <bblfish> +1 +0.2 -1 -1 -1
Henry Story: +1 +0.2 -1 -1 -1 ←
20:48:29 <davidwood> -0.5, +1, -1, -1, +0
David Wood: -0.5, +1, -1, -1, +0 ←
20:48:47 <cygri> 0 +1 -1 0 0
Richard Cyganiak: 0 +1 -1 0 0 ←
20:49:06 <TallTed> +1, +1, +0, +0, -1
Ted Thibodeau: +1, +1, +1, +0, -1 ←
20:49:10 <betehess> +1 +1 0 -1 -1
Alexandre Bertails: +1 +1 0 -1 -1 ←
20:49:11 <SteveBattle> (0, +1, 0.5, 0, -1)
Steve Battle: (0, +1, 0.5, 0, -1) ←
20:49:18 <sandro> +0 +1 -1 -0 -1
Sandro Hawke: +0 +1 -1 -0 -1 ←
20:49:21 <mesteban> +1 +1 0 1 -1
Miguel Esteban Gutiérrez: +1 +1 0 +1 -1 ←
20:49:29 <krp> 0 +1 -1 -1 -1
0 +1 -1 -1 -1 ←
20:49:30 <rgarcia> 0, +1, 0, -1, 0
Raúl García Castro: 0, +1, 0, -1, 0 ←
20:49:34 <ericP> +1, +0, +0, +0, +0
Eric Prud'hommeaux: +1, +0, +0, +0, +0 ←
20:49:36 <nmihindu> +1 +1 0 0 -1
Nandana Mihindukulasooriya: +1 +1 0 0 -1 ←
20:49:36 <roger> -1, -1, -1, +1, +1
Roger Menday: -1, -1, -1, +1, +1 ←
20:49:39 <SteveS> +0, +1, +0, -1, -1
Steve Speicher: +0, +1, +0, -1, -1 ←
20:50:00 <JohnArwe> +0, +1, -0.5, +0, -1
John Arwe: +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
Sandro Hawke: roger should produce a concrete proposal for batch as patch. someone else produces a more concrete proposal for TriG ←
20:52:10 <Arnaud> q?
Arnaud Le Hors: 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.
Henry Story: 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
Arnaud Le Hors: (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\\//
Eric Prud'hommeaux: s/s\/\+1, \+1, \+0, \+0, -1\/\+1, \+1, \+1, \+0, \-1\//s/\\+1, \\+1, \\+0, \\+0, -1\\\/\\\+1, \\\+1, \\\+1, \\\+0, \\\-1\\// (warning: replacement failed) ←
20:52:50 <krp> roger: objection to (5) is that it's not batch for patch
Roger Menday: 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?
Steve Speicher: isn't that a separate issue? do you want to block trig patch? ←
20:53:34 <TallTed> RRSAgent, pointer?
Ted Thibodeau: RRSAgent, pointer? ←
20:53:34 <RRSAgent> See http://www.w3.org/2013/03/13-ldp-irc#T20-53-34
RRSAgent IRC Bot: 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?
Sandro Hawke: I don't think there's a smaller granularity than trig? ←
20:53:59 <bblfish> Trig is just Turtle with named graphs
Henry Story: 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 }
Henry Story: But it does not have a notion of variables. So it is N3 withouth the { ?a ?r ?b } ←
20:55:11 <betehess> q+
Alexandre Bertails: q+ ←
20:56:25 <betehess> q-
Alexandre Bertails: 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
Sandro Hawke: 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.)
Ted Thibodeau: order of operations needs to be clearly specified (e.g., delete before insert, etc.) [ Scribe Assist by Ted Thibodeau ] ←
20:58:40 <SteveS> q+
Steve Speicher: 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
Roger Menday: 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?
Steve Battle: What would the mime type for the trig be? ←
20:59:58 <SteveBattle> application/x-trig
Steve Battle: 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.
Sandro Hawke: let's define the semantics of trig-based-patch in terms of sparlql-update semantics which are nicely defined. [ Scribe Assist by Sandro Hawke ] ←
21:00:20 <SteveBattle> q+
Steve Battle: q+ ←
21:00:27 <cygri> SteveBattle, application/trig as per https://dvcs.w3.org/hg/rdf/raw-file/default/trig/index.html#sec-mediaReg
Richard Cyganiak: 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
Arnaud Le Hors: 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.
Sandro Hawke: 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
Sandro Hawke: so text/rdf-patch or something ←
21:01:31 <rgarcia> or something with ldp-patch
Raúl García Castro: or something with ldp-patch ←
21:01:36 <cygri> sandro, don't you know that by inspecting the default graph??
Richard Cyganiak: sandro, don't you know that by inspecting the default graph?? ←
21:02:09 <sandro> cygri, maybe.... I haven't thought about this enough.
Sandro Hawke: 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"
John Arwe: cygri, I suspect the counter-example is "my LDPC contains TriG documents" ←
21:02:30 <Arnaud> ack steves
Arnaud Le Hors: ack steves ←
21:02:35 <sandro> JohnArwe, but this is being transmitted via PATCH.
Sandro Hawke: JohnArwe, but this is being transmitted via PATCH. ←
21:02:40 <cygri> JohnArwe, but we only talk about payload to the PATCH method
Richard Cyganiak: JohnArwe, but we only talk about payload to the PATCH method ←
21:03:34 <Arnaud> ack steveb
Arnaud Le Hors: 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
Sandro Hawke: 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)
Steve Speicher: 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.
John Arwe: 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?
Steve Battle: 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
... to allow both atomic ops and patch trig ←
21:05:12 <krp> arnaud: does this bring in transactions, atomicity etc. as discussed earlier?
Arnaud Le Hors: does this bring in transactions, atomicity etc. as discussed earlier? ←
21:05:16 <krp> roger: no
Roger Menday: 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
Richard Cyganiak: 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
Roger Menday: 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
Richard Cyganiak: 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?
... 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
Trackbot IRC Bot: ISSUE-43 -- hint at naming a resource on creation -- closed ←
21:08:08 <trackbot> http://www.w3.org/2012/ldp/track/issues/43
Trackbot IRC Bot: 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
Trackbot IRC Bot: ISSUE-34 -- Adding and removing arcs in weak aggregation -- closed ←
21:08:34 <trackbot> http://www.w3.org/2012/ldp/track/issues/34
Trackbot IRC Bot: 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
Roger Menday: always thought ISSUE-34 addresses this, thought the resolution didn't ←
21:08:52 <krp> ... drifted off into other areas
... 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
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].
Trackbot IRC Bot: Created ACTION-46 - Work with Roger to raise an issue on using standard HTTP verbs for finer-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
Richard Cyganiak: 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)
(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
(No events recorded for 8 minutes)
Arnaud Le Hors: 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?
David Wood: what are the charter requirements for this? ←
21:20:20 <davidwood> It turns out there are some :)
David Wood: It turns out there are some :) ←
21:20:31 <cygri> did I hear davidwood volunteering to edit a Note on Access Control? :-)
Richard Cyganiak: did I hear davidwood volunteering to edit a Note on Access Control? :-) ←
21:20:34 <bblfish> q+
Henry Story: q+ ←
21:21:06 <Arnaud> ack bblfish
Arnaud Le Hors: ack bblfish ←
21:21:15 <SteveBattle> q+
Steve Battle: q+ ←
21:21:28 <Arnaud> ack steveb
Arnaud Le Hors: ack steveb ←
21:21:49 <SteveS> q+
Steve Speicher: q+ ←
<krp> Arnaud: we will start with half an hour to identify breakout sessions people would be interested in
Arnaud Le Hors: 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?
Steve Battle: do we need to address meta issues tomorrow? ←
<krp> davidwood: no
David Wood: no ←
21:22:00 <Arnaud> ack steves
Arnaud Le Hors: ack steves ←
21:22:24 <krp> steves: what time will people need to leave on Friday?
Steve Speicher: what time will people need to leave on Friday? ←
21:22:28 <Zakim> -bblfish
Zakim IRC Bot: -bblfish ←
21:22:45 <krp> ... anyone before 4pm?
... anyone before 4pm? ←
21:22:58 <krp> arnaud: we will meet until 4pm on Friday.
Arnaud Le Hors: we will meet until 4pm on Friday. ←
21:23:11 <krp> ... meeting adjourned for the day.
... meeting adjourned for the day. ←
Formatted by CommonScribe
This revision (#2) generated 2013-03-14 04:07:43 UTC by 'alehors', comments: 'Added missing reference to issue-28 being closed.'