edit

Linked Data Platform (LDP) Working Group

Minutes of 01 November 2012

Agenda
http://www.w3.org/2012/ldp/wiki/F2F1#Day_1_-_November_1st
Present
David Wood, Sandro Hawke, Raúl García Castro, Nandana Mihindukulasooriya, Eric Prud'hommeaux, Richard Cyganiak, Bart van Leeuwen, Kevin Page, Ruben Verborgh, Arnaud Le Hors, Ashok Malhotra, Serena Villata, Alexandre Bertails, Steve Speicher, Henry Story, Armin Haller, Antonis Loizou, Olivier Berger, Steve Battle, Roger Menday
Guests
Ivan Herman (W3C), Chong Gu (Huawei), Francois Daoust (Joshfire), Jonathan Dray, Hadley Beeman (LinkedGov), Norman Richter, Fabien Gandon, Tim Berners-Lee, Nathan Rixham, Bernadette Hyland
Remote
Andy Seaborne, Yves Lafon, John Arwe, Ted Thibodeau
Chair
Arnaud Le Hors
Scribe
Alexandre Bertails, Armin Haller, Richard Cyganiak, Eric Prud'hommeaux, Ashok Malhotra
IRC Log
Original
Resolutions
  1. The process for adding new use cases is to raise a tracker issue against the UC&R product. link
  2. Issues raised against the UC&R document before XX/YY will be acknowledged or addressed in the first WD of the published document. link
  3. Servers MUST support Turtle; servers MAY deliver other formats using standard HTTP content negotiation; If the client doesn't indicate a preference, Turtle MUST be returned link
  4. Close ISSUE-24 with the following: Delete the phrase in 4.5.1 that says "Until ... Request URI"; add a sentence, "Clients should note that severs may reuse a Request-URI under some circumstances." link
  5. Close ISSUE-6 by DELETing LDP §4.1.9 link
  6. Close ISSUE-20 saying we're okay with the design in the FPWD. <> is self-reference within LDP operations, at least. link
Topics
  1. Welcome and Introductions

    Welcome, logistics, short introduction round, recap of meeting goals, agenda amendments.

  2. Use Cases and Requirements Document

    Long discussion of the UC&R document. The WG resolves that WG members are encouraged to file issues against it, including new use cases, and that all issues raised before a to-be-determined date will be addressed or at least acknowledged before the document goes to FPWD.

  3. LDP Specification

    1. ISSUE-22 and ISSUE-23 (RDF/XML and JSON-LD)

      The WG resolves that Turtle MUST be supported, and other formats MAY be supported via content negotiation, with Turtle as default.

    2. ISSUE-24 (Is deletion permanent?)

      Some feel strongly that URIs assigned by POSTing to a container and then deleted must never be assigned again. But scenarios like “undo of accidental delete” and creation via PUT cause opposition against stronger language. The discussion concludes with an editorial clarification.

    3. ISSUE-6 (Are user-defined data types disallowed?)

      The draft's prohibition to use all but a few enumerated XSD datatypes is attacked with specific use cases and pleas for keeping interoperability and extensibility. The prohibition is removed.

  4. Next F2F

    Next F2F likely to be held on the U.S. east coast in March. Oracle (NYC or Raleigh) and MIT (Cambridge) look into hosting.

  5. Dinner

  6. ISSUE-20 (Relative URIs in POSTed representations)

    TimBL stresses importance of relative URIs. The URI and HTTP spec are ambiguous about the treatment of base URIs in POST. The group decides to set a precedent by sticking to the design that the base URI for POSTed representations is the newly created resource.

  7. Wrap-up

<sandro> Guest: Ivan Herman, W3C
<sandro> Guest: Chong Gu, Huawei
<sandro> Guest: Francois (tidoust) Daoust, Joshfire
<sandro> Guest: Jonathan Dray
<sandro> Guest: Hadley Beeman, LinkedGov
<cygri> Guest: Norman (develD) Richter
<cygri> guest: Fabien Gandon
<cygri> guest: Tim (timbl) Berners-Lee
<cygri> guest: Nathan (webr3) Rixham
<sandro> guest: Bernadette Hyland
<sandro> Present: David, Sandro, Raúl, Nandana, EricP, Cygri, Bart, Kevin, Ruben, Arnaud, Ashok, Serena, Alexandre, SteveS, Henry, Armin, Antonis, Olivier, SteveB, Roger
<sandro> Around Table, in order: Ivan, David, Sandro, Chong, Raúl, Nandana, EricP, Richard, Bart, Kevin, Ruben, Arnaud, Ashok, Serena, Alexandre, SteveS, Henry, Armin, Antonis, Francois, Olivier, SteveB, Roger

Sandro Hawke: Around Table, in order: Ivan, David, Sandro, Chong, Raúl, Nandana, EricP, Richard, Bart, Kevin, Ruben, Arnaud, Ashok, Serena, Alexandre, SteveS, Henry, Armin, Antonis, Francois, Olivier, SteveB, Roger

<sandro> Around Edge of Room: Hadley, Jonathan, unknown

Sandro Hawke: Around Edge of Room: Hadley, Jonathan, unknown

<sandro> Remote: AndyS, Yves, Arwe, macted
07:57:35 <RRSAgent> logging to http://www.w3.org/2012/11/01-ldp-irc

RRSAgent IRC Bot: logging to http://www.w3.org/2012/11/01-ldp-irc

07:57:44 <betehess> RRSAgent, please generate minutes

Alexandre Bertails: RRSAgent, please generate minutes

07:57:44 <RRSAgent> I have made the request to generate http://www.w3.org/2012/11/01-ldp-minutes.html betehess

RRSAgent IRC Bot: I have made the request to generate http://www.w3.org/2012/11/01-ldp-minutes.html betehess

07:58:05 <betehess> chair: Arnaud
07:58:23 <ArnaudLH> agenda: http://www.w3.org/2012/ldp/wiki/F2F1#Day_1_-_November_1st
07:58:59 <betehess> betehess has changed the topic to: agenda: http://www.w3.org/2012/ldp/wiki/F2F1#Day_1_-_November_1st  --  please do add yourself [ present+ Alexandre_Bertails ]

Alexandre Bertails: betehess has changed the topic to: agenda: http://www.w3.org/2012/ldp/wiki/F2F1#Day_1_-_November_1st -- please do add yourself [ present+ Alexandre_Bertails ]

07:59:08 <betehess> present+ Alexandre_Bertails

Alexandre Bertails: present+ Alexandre_Bertails

07:59:14 <betehess> betehess has changed the topic to: agenda: http://www.w3.org/2012/ldp/wiki/F2F1#Day_1_-_November_1st  --  please do add yourself [ present+ Alexandre_Bertails ] (no space)

Alexandre Bertails: betehess has changed the topic to: agenda: http://www.w3.org/2012/ldp/wiki/F2F1#Day_1_-_November_1st -- please do add yourself [ present+ Alexandre_Bertails ] (no space)

07:59:26 <betehess> betehess has changed the topic to: agenda: http://www.w3.org/2012/ldp/wiki/F2F1#Day_1_-_November_1st  --  please do add yourself, eg. [ present+ Alexandre_Bertails ] (no space)

Alexandre Bertails: betehess has changed the topic to: agenda: http://www.w3.org/2012/ldp/wiki/F2F1#Day_1_-_November_1st -- please do add yourself, eg. [ present+ Alexandre_Bertails ] (no space)

07:59:57 <oberger> who said arrival, coffee in the program ?

Olivier Berger: who said arrival, coffee in the program ?

08:07:12 <Ruben> present+ Ruben_Verborgh

(No events recorded for 7 minutes)

Ruben Verborgh: present+ Ruben_Verborgh

08:07:28 <betehess> s|who said arrival, coffee in the program ?||

Alexandre Bertails: s|who said arrival, coffee in the program ?||

08:07:29 <oberger> present+ Olivier Berger

Olivier Berger: present+ Olivier_Berger

08:07:40 <betehess> s/Olivier Berger/Olivier_Berger/
08:08:11 <betehess> betehess has changed the topic to: agenda: http://www.w3.org/2012/ldp/wiki/F2F1#Day_1_-_November_1st  --  please do add yourself, eg. [ present+ Alexandre_Bertails ] (NO_SPACE)

Alexandre Bertails: betehess has changed the topic to: agenda: http://www.w3.org/2012/ldp/wiki/F2F1#Day_1_-_November_1st -- please do add yourself, eg. [ present+ Alexandre_Bertails ] (NO_SPACE)

08:08:41 <jonathandray> present+ Jonathan Dray

Jonathan Dray: present+ Jonathan_Dray

08:08:52 <betehess> s/Jonathan Dray/Jonathan_Dray/
08:09:00 <roger> present+ Roger Menday

Roger Menday: present+ Roger_Menday

08:09:11 <betehess> s/Roger Menday/Roger_Menday/
08:09:13 <ericP> Zakim, please dial St_Clair_3B

Eric Prud'hommeaux: Zakim, please dial St_Clair_3B

08:09:13 <Zakim> sorry, ericP, I don't know what conference this is

Zakim IRC Bot: sorry, ericP, I don't know what conference this is

08:09:22 <SteveBattle> Do we have a hashtag?

Steve Battle: Do we have a hashtag?

08:09:43 <ericP> Zakim, please this ldp

Eric Prud'hommeaux: Zakim, please this ldp

08:09:43 <Zakim> I don't understand 'please this ldp', ericP

Zakim IRC Bot: I don't understand 'please this ldp', ericP

08:09:50 <ericP> Zakim, please this is ldp

Eric Prud'hommeaux: Zakim, please this is ldp

08:09:50 <Zakim> I don't understand 'please this is ldp', ericP

Zakim IRC Bot: I don't understand 'please this is ldp', ericP

08:09:55 <ericP> Zakim, this is ldp

Eric Prud'hommeaux: Zakim, this is ldp

08:09:55 <Zakim> ericP, I see SW_LDP()2:30AM in the schedule but not yet started.  Perhaps you mean "this will be ldp".

Zakim IRC Bot: ericP, I see SW_LDP()2:30AM in the schedule but not yet started. Perhaps you mean "this will be ldp".

08:09:59 <SteveS> present+ SteveSpeicher

Steve Speicher: present+ SteveSpeicher

08:10:03 <ericP> Zakim, please dial St_Clair_3B

Eric Prud'hommeaux: Zakim, please dial St_Clair_3B

08:10:03 <Zakim> sorry, ericP, I don't know what conference this is

Zakim IRC Bot: sorry, ericP, I don't know what conference this is

08:10:05 <BartvanLeeuwen> present+ BartvanLeeuwen

Bart van Leeuwen: present+ BartvanLeeuwen

08:10:13 <ericP> Zakim, this will be ldp

Eric Prud'hommeaux: Zakim, this will be ldp

08:10:13 <Zakim> ok, ericP; I see SW_LDP()2:30AM scheduled to start 100 minutes ago

Zakim IRC Bot: ok, ericP; I see SW_LDP()2:30AM scheduled to start 100 minutes ago

08:10:14 <ericP> Zakim, please dial St_Clair_3B

Eric Prud'hommeaux: Zakim, please dial St_Clair_3B

08:10:14 <Zakim> ok, ericP; the call is being made

Zakim IRC Bot: ok, ericP; the call is being made

08:10:15 <Zakim> SW_LDP()2:30AM has now started

Zakim IRC Bot: SW_LDP()2:30AM has now started

08:10:16 <Zakim> +St_Clair_3B

Zakim IRC Bot: +St_Clair_3B

08:10:21 <ArnaudLH> present+ Arnaud_Le_Hors

Arnaud Le Hors: present+ Arnaud_Le_Hors

08:10:26 <betehess> RRSAgent, please make minutes

Alexandre Bertails: RRSAgent, please make minutes

08:10:26 <RRSAgent> I have made the request to generate http://www.w3.org/2012/11/01-ldp-minutes.html betehess

RRSAgent IRC Bot: I have made the request to generate http://www.w3.org/2012/11/01-ldp-minutes.html betehess

08:10:38 <oberger> SteveBattle, https://twitter.com/LDPWG i.e. @LDPWG seems an option

Olivier Berger: SteveBattle, https://twitter.com/LDPWG i.e. @LDPWG seems an option

08:10:40 <ericP> Zakim, please dial St_Clair_3B

Eric Prud'hommeaux: Zakim, please dial St_Clair_3B

08:10:40 <Zakim> ok, ericP; the call is being made

Zakim IRC Bot: ok, ericP; the call is being made

08:10:41 <Zakim> +St_Clair_3B.a

Zakim IRC Bot: +St_Clair_3B.a

08:10:50 <Zakim> -St_Clair_3B

Zakim IRC Bot: -St_Clair_3B

08:11:15 <ericP> Zakim, St_Clair_3B.a is St_Clair_3B

Eric Prud'hommeaux: Zakim, St_Clair_3B.a is St_Clair_3B

08:11:15 <Zakim> +St_Clair_3B; got it

Zakim IRC Bot: +St_Clair_3B; got it

08:11:29 <oberger> ArnaudLH, are you the owner of @LDPWG ?

Olivier Berger: ArnaudLH, are you the owner of @LDPWG ?

08:13:39 <ArnaudLH> oberger: Erik is

Olivier Berger: Erik is [ Scribe Assist by Arnaud Le Hors ]

08:14:05 <oberger> but #LDPWG may be an interesting hashtag

Olivier Berger: but #LDPWG may be an interesting hashtag

08:14:35 <ericP> Zakim, who is here?

Eric Prud'hommeaux: Zakim, who is here?

08:14:35 <Zakim> On the phone I see St_Clair_3B

Zakim IRC Bot: On the phone I see St_Clair_3B

08:14:36 <Zakim> On IRC I see davidwood, rgarcia, antonis, Ashok_Malhotra, nmihindu, roger, jonathandray, SteveBattle, AndyS, Ruben, FabGandon, chsiao_, svillata, ivan, tidoust, RRSAgent,

Zakim IRC Bot: On IRC I see davidwood, rgarcia, antonis, Ashok_Malhotra, nmihindu, roger, jonathandray, SteveBattle, AndyS, Ruben, FabGandon, chsiao_, svillata, ivan, tidoust, RRSAgent,

08:14:36 <Zakim> ... BartvanLeeuwen, Zakim, ArnaudLH, betehess, oberger, SteveS, ahaller2

Zakim IRC Bot: ... BartvanLeeuwen, Zakim, ArnaudLH, betehess, oberger, SteveS, ahaller2

08:14:37 <betehess> can you avoid uppercase?

Alexandre Bertails: can you avoid uppercase?

08:14:45 <betehess> eg. ldpwg

Alexandre Bertails: eg. ldpwg

08:15:07 <oberger> betehess, I guess it doesn matter much for twitter web app

Olivier Berger: betehess, I guess it doesn matter much for twitter web app

08:15:19 <oberger> but yes lowercase if you will

Olivier Berger: but yes lowercase if you will

08:16:29 <davidwood> Yes, twitter tags are case insensitive.

David Wood: Yes, twitter tags are case insensitive.

08:17:00 <SteveBattle> Where's the coffee?

Steve Battle: Where's the coffee?

08:17:40 <oberger> SteveBattle, shouldn't we ask Zakim ?

Olivier Berger: SteveBattle, shouldn't we ask Zakim ?

08:17:53 <oberger> crappy bots

Olivier Berger: crappy bots

08:18:03 <SteveBattle> zakim, where's the coffee?

Steve Battle: zakim, where's the coffee?

08:18:03 <Zakim> I don't understand your question, SteveBattle.

Zakim IRC Bot: I don't understand your question, SteveBattle.

08:18:46 <Ruben> *Hyper Text Coffee Pot Control Protocol http://tools.ietf.org/html/rfc2324*

Ruben Verborgh: *Hyper Text Coffee Pot Control Protocol http://tools.ietf.org/html/rfc2324*

08:19:45 <oberger> Ruben, would it make a use case to control a coffee pot through REST and RDF ?

Olivier Berger: Ruben, would it make a use case to control a coffee pot through REST and RDF ?

08:20:04 <Ruben> This could actually convince a lot of developers to turn to RDF.

Ruben Verborgh: This could actually convince a lot of developers to turn to RDF.

08:20:38 <oberger> using coffeescript ?

Olivier Berger: using coffeescript ?

08:21:30 <davidwood> http://coffeescript.org/

David Wood: http://coffeescript.org/

08:30:41 <oberger> let's get it started

(No events recorded for 9 minutes)

Olivier Berger: let's get it started

08:30:53 <oberger> ArnaudLH, addressing us

Olivier Berger: ArnaudLH, addressing us

08:31:03 <betehess> topic: Welcome and Introductions

1. Welcome and Introductions

Summary: Welcome, logistics, short introduction round, recap of meeting goals, agenda amendments.

08:31:05 <cygri> summary: Welcome, logistics, short introduction round, recap of meeting goals, agenda amendments.
08:31:09 <betehess> scribenick: betehess

(Scribe set to Alexandre Bertails)

08:31:33 <betehess> ArnaudLH: let's go around the table, introduce yourself

Arnaud Le Hors: let's go around the table, introduce yourself

08:31:59 <betehess> ivan: Ivan Herman, W3C semweb lead

Ivan Herman: Ivan Herman, W3C semweb lead

08:32:05 <betehess> ... here as an observer

... here as an observer

08:32:46 <betehess> davidwood: David Wood, RDF WG

David Wood: David Wood, RDF WG

08:32:53 <Zakim> +Yves

Zakim IRC Bot: +Yves

08:32:53 <betehess> ... but also member of this group

... but also member of this group

08:33:34 <chong> chong

Chong Gu: chong

08:34:02 <rgarcia> rgarcia: Raúl Garcí­a-Castro, Ontology Engineering Group, Universidad Politécnica de Madrid

Raúl García Castro: Raúl Garcí­a-Castro, Ontology Engineering Group, Universidad Politécnica de Madrid [ Scribe Assist by Raúl García Castro ]

08:34:13 <nmihindu> Nandana Mihindukulasooriya from Ontology Engineering Group, Universidad Politécnica de Madrid

Nandana Mihindukulasooriya: Nandana Mihindukulasooriya from Ontology Engineering Group, Universidad Politécnica de Madrid

08:34:15 <ericP> Eric Prud'hommeaux

Eric Prud'hommeaux: Eric Prud'hommeaux

08:35:14 <cygri> Richard Cyganiak, DERI

Richard Cyganiak: Richard Cyganiak, DERI

08:35:34 <Ruben> Ruben / Ghent University – iMinds / PhD student Semantic Web & Web APIs

Ruben Verborgh: Ruben / Ghent University – iMinds / PhD student Semantic Web & Web APIs

08:35:36 <krp> Kevin Page, University of Oxford

Kevin Page: Kevin Page, University of Oxford

08:35:41 <BartvanLeeuwen> Bart van Leeuwen netage.nl (Startup Member)/ Fire Fighter Amsterdam

Bart van Leeuwen: Bart van Leeuwen netage.nl (Startup Member)/ Fire Fighter Amsterdam

08:35:51 <betehess> Alexandre Bertails aka. betehess, W3C Systeam Team. Already working actively on LDP implementation at https://github.com/w3c/banana-rdf

Alexandre Bertails aka. betehess, W3C Systeam Team. Already working actively on LDP implementation at https://github.com/w3c/banana-rdf

08:36:05 <SteveS> I'm Steve Speicher from IBM

Steve Speicher: I'm Steve Speicher from IBM

08:36:06 <svillata> Serena Villata, INRIA Sophia Antipolis

Serena Villata: Serena Villata, INRIA Sophia Antipolis

08:36:16 <antonis> Antonis Loizou, post-doc Vrije Universiteit Amsterdam

Antonis Loizou: Antonis Loizou, post-doc Vrije Universiteit Amsterdam

08:36:17 <ahaller2> Armin Haller

Armin Haller: Armin Haller

08:36:50 <oberger> Olivier Berger aka oberger/olberger/obergix from Institut Telecom / Télécom SudParis

Olivier Berger: Olivier Berger aka oberger/olberger/obergix from Institut Telecom / Télécom SudParis

08:36:51 <tidoust> Francois Daoust from Joshfire. Working on JSON-LD within RDF WG. Observer.

Francois Daoust: Francois Daoust from Joshfire. Working on JSON-LD within RDF WG. Observer.

08:37:10 <SteveBattle> Steve Battle

Steve Battle: Steve Battle

08:38:25 <betehess> jonathandray: Jonathan Dray

Jonathan Dray: Jonathan Dray

08:39:06 <ericP> Zakim, who is on the phone?

Eric Prud'hommeaux: Zakim, who is on the phone?

08:39:06 <Zakim> On the phone I see St_Clair_3B, Yves

Zakim IRC Bot: On the phone I see St_Clair_3B, Yves

08:39:16 <develD> Hey, i am Norman Richter from the univerity of Halle / Leipzig, Germany. I'm doing resarch on webid, web access control, pubsubhubbub. I'm still a student and planning to start with my final thesis on this subject within the next weeks/months. It's about delivering Linked Data as rdf over a PubHub with WebAccessControl / ACL to subscribers who should authentify with webid. I am here as an observer to check out how ldp is related to this subjects.

Norman Richter: Hey, i am Norman Richter from the univerity of Halle / Leipzig, Germany. I'm doing resarch on webid, web access control, pubsubhubbub. I'm still a student and planning to start with my final thesis on this subject within the next weeks/months. It's about delivering Linked Data as rdf over a PubHub with WebAccessControl / ACL to subscribers who should authentify with webid. I am here as an observer to check out how ldp is related to this subjects.

08:39:43 <jonathandray> Jonathan Dray, I worked for a Company called Social Computing on "Just Map It", a data mapping solution. I also worked on a project called SPAR for the BNF on data preservation with Alexandre Bertails. I an here as an observer.

Jonathan Dray: Jonathan Dray, I worked for a Company called Social Computing on "Just Map It", a data mapping solution. I also worked on a project called SPAR for the BNF on data preservation with Alexandre Bertails. I an here as an observer.

08:40:21 <AndyS> Andy Seaborne, Apache Software Foundation.  Work with linked data building customer solutions.  Also work on Apache Jena.

Andy Seaborne: Andy Seaborne, Apache Software Foundation. Work with linked data building customer solutions. Also work on Apache Jena.

08:40:38 <betehess> ArnaudLH: thanks all

Arnaud Le Hors: thanks all

08:40:49 <betehess> ... the agenda was a bit of a challenge

... the agenda was a bit of a challenge

08:41:03 <betehess> ... still on the early days

... still on the early days

08:41:16 <betehess> ... two main topics

... two main topics

08:41:30 <betehess> ... tried to split everything in chunks

... tried to split everything in chunks

08:41:41 <betehess> ... also tried to take timezones into accounts

... also tried to take timezones into accounts

08:41:54 <betehess> ... I'm flexible about these things

... I'm flexible about these things

08:42:18 <betehess> ... as AndyS was the only one to express specific interests in some topics, I'll try to honor them

... as AndyS was the only one to express specific interests in some topics, I'll try to honor them

08:42:24 <betehess> ... no other constraint

... no other constraint

08:42:41 <betehess> ... so just tell me to "move on"

... so just tell me to "move on"

08:42:58 <betehess> davidwood: how many people new to w3c?

David Wood: how many people new to w3c?

08:43:23 <betehess> [only a few]

[only a few]

08:44:04 <betehess> ArnaudLH: any question about the process, then just ask

Arnaud Le Hors: any question about the process, then just ask

08:44:09 <betehess> ... it's a nice place, don't worry

... it's a nice place, don't worry

08:44:53 <betehess> ArnaudLH is going through http://www.w3.org/2012/ldp/wiki/F2F1#Objectives

ArnaudLH is going through http://www.w3.org/2012/ldp/wiki/F2F1#Objectives

08:45:06 <betehess> ArnaudLH: I went back to the charter

Arnaud Le Hors: I went back to the charter

08:45:08 <oberger> http://www.w3.org/2012/ldp/charter

Olivier Berger: http://www.w3.org/2012/ldp/charter

08:45:25 <betehess> ... we need to start speaking about some stuff

... we need to start speaking about some stuff

08:45:30 <betehess> ... eg. test suite

... eg. test suite

08:45:34 <betehess> ... and validator

... and validator

08:45:50 <betehess> ... lots of discussion during charter writing about ACLs

... lots of discussion during charter writing about ACLs

08:46:03 <betehess> ... some wanted that as a MUST

... some wanted that as a MUST

08:46:21 <betehess> ... could be a disaster for some, but for others, the platform may not make sense without it

... could be a disaster for some, but for others, the platform may not make sense without it

08:46:31 <betehess> ... the compromise was: a NOTE defining the requirements

... the compromise was: a NOTE defining the requirements

08:46:39 <betehess> ... these are the main deliverables

... these are the main deliverables

08:46:48 <betehess> ... also want to discuss next f2f meeting

... also want to discuss next f2f meeting

08:47:24 <betehess> ... the FPWD is basically the SUBMISSION annotated with issues

... the FPWD is basically the SUBMISSION annotated with issues

08:47:26 <oberger> FPWD http://www.w3.org/TR/ldp/

Olivier Berger: FPWD http://www.w3.org/TR/ldp/

08:47:33 <betehess> ... we'lll go through the list of issues

... we'lll go through the list of issues

08:47:44 <betehess> q+

q+

08:48:16 <betehess> ... also I want to discuss the path forward to REC

... also I want to discuss the path forward to REC

08:48:34 <betehess> ... glad to say that the group seems to have started doing good job

... glad to say that the group seems to have started doing good job

08:48:40 <betehess> ... eg. the FPWD

... eg. the FPWD

08:49:09 <betehess> ... again, we do have a charter, we need to try to stick to it as much of possible

... again, we do have a charter, we need to try to stick to it as much of possible

08:49:28 <betehess> ... regarding use case and requirements doc, it's a bit different

... regarding use case and requirements doc, it's a bit different

08:49:34 <betehess> ... not published it yet

... not published it yet

08:49:44 <betehess> ... we need to decide what this doc is really about

... we need to decide what this doc is really about

08:50:06 <betehess> ... steeve did a great job to put it together

... steeve did a great job to put it together

08:50:06 <betehess> ... but some stuff does not belong there

... but some stuff does not belong there

08:50:08 <oberger> http://www.w3.org/2012/ldp/wiki/Use_Cases_And_Requirements

Olivier Berger: http://www.w3.org/2012/ldp/wiki/Use_Cases_And_Requirements

08:50:21 <betehess> ... but the plan was to put everything you wanted there first

... but the plan was to put everything you wanted there first

08:50:37 <betehess> Ashok_Malhotra: if you add a requirement

Ashok Malhotra: if you add a requirement

08:50:47 <ericP> q+ to ask SteveS if we should be looking at the editor's draft while discussing the LDP draft

Eric Prud'hommeaux: q+ to ask SteveS if we should be looking at the editor's draft while discussing the LDP draft

08:50:47 <betehess> ... and the spec does not address it

... and the spec does not address it

08:50:53 <betehess> ... then it can be a problem

... then it can be a problem

08:51:21 <betehess> ack eri

ack eri

08:51:21 <Zakim> ericP, you wanted to ask SteveS if we should be looking at the editor's draft while discussing the LDP draft

Zakim IRC Bot: ericP, you wanted to ask SteveS if we should be looking at the editor's draft while discussing the LDP draft

08:51:39 <betehess> ericP: is there something new in the ED since the FPWD?

Eric Prud'hommeaux: is there something new in the ED since the FPWD?

08:51:43 <betehess> ... where should be look at

... where should be look at

08:51:57 <betehess> steeve: not change much

Steve Speicher: not change much

08:51:59 <betehess> ... only locally

... only locally

08:52:17 <oberger> s/steeve/SteveS/
08:52:37 <betehess> ack me

ack me

08:53:09 <oberger> betehess: prioritize issues for people only present today

Alexandre Bertails: prioritize issues for people only present today [ Scribe Assist by Olivier Berger ]

08:53:36 <betehess> q+

q+

08:54:03 <betehess> oberger: would like to hear about implementations and validation

Olivier Berger: would like to hear about implementations and validation

08:54:27 <betehess> ... even if it's not mandatory in the charter

... even if it's not mandatory in the charter

08:54:34 <nmihindu> +1

Nandana Mihindukulasooriya: +1

08:54:40 <betehess> SteveS: wanted to review the path of the spec

Steve Speicher: wanted to review the path of the spec

08:54:45 <betehess> ... and the schedule

... and the schedule

08:55:06 <betehess> davidwood: maybe a wiki page for listing implementations

David Wood: maybe a wiki page for listing implementations

08:55:13 <betehess> ArnaudLH: good idea

Arnaud Le Hors: good idea

08:55:30 <cygri> TOPIC: Use Cases and Requirements Document

2. Use Cases and Requirements Document

Summary: Long discussion of the UC&R document. The WG resolves that WG members are encouraged to file issues against it, including new use cases, and that all issues raised before a to-be-determined date will be addressed or at least acknowledged before the document goes to FPWD.

08:55:52 <betehess> ArnaudLH: the goal is to discuss the usecase and requirements this morning

Arnaud Le Hors: the goal is to discuss the usecase and requirements this morning

08:55:54 <oberger> q+ on which target audience we're seeking

Olivier Berger: q+ on which target audience we're seeking

08:56:02 <betehess> ... and the spec this afternoon

... and the spec this afternoon

08:56:42 <betehess> ArnaudLH: is this reasonable for now?

Arnaud Le Hors: is this reasonable for now?

08:56:59 <betehess> oberger: maybe would like to remind the target of this WG

Olivier Berger: maybe would like to remind the target of this WG

08:57:13 <betehess> ... eg, yesterday there was discussion about LD for devs

... eg, yesterday there was discussion about LD for devs

08:57:18 <betehess> ... Javascript was important

... Javascript was important

08:57:25 <betehess> q+

q+

08:57:36 <betehess> ... just want to understand the objectives

... just want to understand the objectives

08:57:57 <betehess> ... would like to understand the stakeholders

... would like to understand the stakeholders

08:58:09 <betehess> ArnaudLH: what's your objective?

Arnaud Le Hors: what's your objective?

08:58:18 <betehess> oberger: understand better what is out of scope

Olivier Berger: understand better what is out of scope

08:58:30 <betehess> ... so fat, it's about resources and containers

... so fat, it's about resources and containers

08:58:44 <betehess> ... so people mentioned some other datastructures

... so people mentioned some other datastructures

08:59:15 <ArnaudLH> ack betehess

Arnaud Le Hors: ack betehess

08:59:47 <ArnaudLH> ack oberger

Arnaud Le Hors: ack oberger

08:59:47 <Zakim> oberger, you wanted to comment on which target audience we're seeking

Zakim IRC Bot: oberger, you wanted to comment on which target audience we're seeking

09:00:02 <tidoust> betehess: I believe that it is clearly out of scope if you look at the charter. We may revisit that later on but should focus on what's on the charter. The topic is very important for me, but we need to stay focused.

Alexandre Bertails: I believe that it is clearly out of scope if you look at the charter. We may revisit that later on but should focus on what's on the charter. The topic is very important for me, but we need to stay focused. [ Scribe Assist by Francois Daoust ]

09:00:15 <betehess> ArnaudLH: the first answer in the charter

Arnaud Le Hors: the first answer in the charter

09:00:24 <betehess> ... defines the goals

... defines the goals

09:00:30 <betehess> ... then the usecase and requirement refine that

... then the usecase and requirement refine that

09:00:43 <betehess> ... we may conclude that we need something else

... we may conclude that we need something else

09:01:39 <betehess> oberger: if you look at the usecase, there are plenty of them, some redundant

Olivier Berger: if you look at the usecase, there are plenty of them, some redundant

09:01:48 <betehess> ... only a few requirements

... only a few requirements

09:02:10 <betehess> ... maybe we'll see a whole range of other things?

... maybe we'll see a whole range of other things?

09:02:24 <betehess> ... lack of imagination or just people staying on focus?

... lack of imagination or just people staying on focus?

09:02:43 <betehess> cygri: we may be missing some stuff

Richard Cyganiak: we may be missing some stuff

09:03:03 <betehess> ... if you see something like this, just say it

... if you see something like this, just say it

09:03:13 <betehess> ... let's nto brainstorming here at the f2f

... let's nto brainstorming here at the f2f

09:03:51 <betehess> ArnaudLH: anybody can make a proposal at any point

Arnaud Le Hors: anybody can make a proposal at any point

09:03:52 <davidwood> New wiki page for implementations, as requested: http://www.w3.org/2012/ldp/wiki/Implementations

David Wood: New wiki page for implementations, as requested: http://www.w3.org/2012/ldp/wiki/Implementations

09:04:12 <davidwood> (linked from the main page under Ongoing Work)

David Wood: (linked from the main page under Ongoing Work)

09:04:15 <betehess> SteveS: just make things as close as possible to what we have

Steve Speicher: just make things as close as possible to what we have

09:04:31 <betehess> ArnaudLH: let's speak about usecase and requirements

Arnaud Le Hors: let's speak about usecase and requirements

09:05:06 <betehess> ... we already have something good

... we already have something good

09:05:06 <betehess> ... we may want to remove things that don't belong there

... we may want to remove things that don't belong there

09:05:21 <betehess> ... normally, you start with that, then you start the docs

... normally, you start with that, then you start the docs

09:05:37 <betehess> ... here we started with the spec, we're still editing the UCR doc

... here we started with the spec, we're still editing the UCR doc

09:05:44 <SteveBattle> topic : Use Cases and Requirements

Steve Battle: topic : Use Cases and Requirements

09:05:52 <davidwood> q+

David Wood: q+

09:06:02 <betehess> ... there is a good reason for this situation

... there is a good reason for this situation

09:06:25 <ArnaudLH> ack davidwood

Arnaud Le Hors: ack davidwood

09:06:36 <betehess> davidwood: just wanted to mention I created the implementation page

David Wood: just wanted to mention I created the implementation page

09:06:43 <betehess> ... we can use that to ground the use-case

... we can use that to ground the use-case

09:07:30 <betehess> ArnaudLH: I split the schedule in two

Arnaud Le Hors: I split the schedule in two

09:07:35 <betehess> ... the steps

... the steps

09:07:49 <betehess> ... and what's in the doc today

... and what's in the doc today

09:08:11 <betehess> ... also, what does it mean to have a requirement not addressed in the spec?

... also, what does it mean to have a requirement not addressed in the spec?

09:08:20 <betehess> ... eg. security is out-of-scope IMO

... eg. security is out-of-scope IMO

09:08:46 <betehess> SteveBattle: people started to collect stories together

Steve Battle: people started to collect stories together

09:08:51 <betehess> ... two sections

... two sections

09:08:57 <betehess> ... existing user stories

... existing user stories

09:09:13 <betehess> ... and the use cases

... and the use cases

09:09:30 <BartvanLeeuwen> +q

Bart van Leeuwen: +q

09:09:35 <betehess> ... you find here scienarios

... you find here scienarios

09:09:45 <betehess> ... making the use cases more concrete

... making the use cases more concrete

09:09:53 <betehess> ... there are 10 of them so far

... there are 10 of them so far

09:10:08 <betehess> ... there used to be plenty of examples

... there used to be plenty of examples

09:10:19 <betehess> ... they are now somewhere else

... they are now somewhere else

09:11:06 <betehess> [describing a scenario]

[describing a scenario]

09:11:30 <betehess> ... there are also pointers to the issues that were raised

... there are also pointers to the issues that were raised

09:11:42 <oberger> http://www.w3.org/2012/ldp/wiki/Examples

Olivier Berger: http://www.w3.org/2012/ldp/wiki/Examples

09:11:45 <betehess> ... focused on functional requirements

... focused on functional requirements

09:11:56 <sandro> RRSAgent, make logs public

Sandro Hawke: RRSAgent, make logs public

09:12:19 <betehess> ... functional requirement == what do you expect the system to do

... functional requirement == what do you expect the system to do

09:13:25 <betehess> ... functional is the how

... functional is the how

09:13:38 <ArnaudLH> ack bart

Arnaud Le Hors: ack bart

09:13:38 <betehess> BartvanLeeuwen: is it still open?

Bart van Leeuwen: is it still open?

09:13:41 <SteveS> q+

Steve Speicher: q+

09:13:45 <betehess> SteveBattle: it is still open

Steve Battle: it is still open

09:13:54 <betehess> q+

q+

09:14:18 <betehess> ... for user stories, just go ahead

... for user stories, just go ahead

09:14:19 <ArnaudLH> ack steves

Arnaud Le Hors: ack steves

09:14:23 <betehess> ... for requirements, just talk to me

... for requirements, just talk to me

09:14:24 <betehess> q-

q-

09:15:04 <betehess> SteveS: when I look at user scenarios, looks like we're too restrictive

Steve Speicher: when I look at user scenarios, looks like we're too restrictive

09:15:06 <betehess> ... eg. imposing 303

... eg. imposing 303

09:15:06 <betehess> ... should be in the spec

... should be in the spec

09:15:08 <betehess> q+

q+

09:15:37 <betehess> ... response codes are too much detail for example

... response codes are too much detail for example

09:16:15 <betehess> Ashok_Malhotra: there are other possible solutions

Ashok Malhotra: there are other possible solutions

09:17:06 <betehess> ... just pointing out that this is quite open

... just pointing out that this is quite open

09:17:14 <ericP> q+ to propose that another doc capture the very helpful groundings of the use cases

Eric Prud'hommeaux: q+ to propose that another doc capture the very helpful groundings of the use cases

09:17:21 <betehess> ... so 303 may be too early

... so 303 may be too early

09:17:47 <betehess> SteveBattle: it is quite useful to know some things here

Steve Battle: it is quite useful to know some things here

09:17:56 <betehess> ... so it's useful to document

... so it's useful to document

09:17:57 <ivan> rrsagent, draft minutes

Ivan Herman: rrsagent, draft minutes

09:17:57 <RRSAgent> I have made the request to generate http://www.w3.org/2012/11/01-ldp-minutes.html ivan

RRSAgent IRC Bot: I have made the request to generate http://www.w3.org/2012/11/01-ldp-minutes.html ivan

09:18:10 <betehess> ... it's interesting to understand the sequence

... it's interesting to understand the sequence

09:18:22 <betehess> SteveS: it's supposed to drive the spec

Steve Speicher: it's supposed to drive the spec

09:18:40 <Ashok_Malhotra> q?

Ashok Malhotra: q?

09:18:46 <ericP> betehess: i read the UC&R as painging ourselves in a corner

Alexandre Bertails: i read the UC&R as painging ourselves in a corner [ Scribe Assist by Eric Prud'hommeaux ]

09:18:52 <ArnaudLH> ack bete

Arnaud Le Hors: ack bete

09:19:16 <ericP> ... there may be some recipes in the UC&R which we have yet to discuss

Eric Prud'hommeaux: ... there may be some recipes in the UC&R which we have yet to discuss

09:19:34 <ArnaudLH> ack ericp

Arnaud Le Hors: ack ericp

09:19:34 <Zakim> ericP, you wanted to propose that another doc capture the very helpful groundings of the use cases

Zakim IRC Bot: ericP, you wanted to propose that another doc capture the very helpful groundings of the use cases

09:19:49 <betehess> ericP: when I read UCR, I usely don't know anything

Eric Prud'hommeaux: when I read UCR, I usely don't know anything

09:19:54 <betehess> ... here I find many details

... here I find many details

09:20:14 <betehess> ... maybe you can put that stuff to another page

... maybe you can put that stuff to another page

09:20:14 <SteveS> q+

Steve Speicher: q+

09:20:24 <betehess> ... and you link those

... and you link those

09:20:37 <betehess> ... then the reader can ground things to examples

... then the reader can ground things to examples

09:20:48 <betehess> ... and we can compare different proposals

... and we can compare different proposals

09:21:02 <betehess> q+

q+

09:21:32 <betehess> SteveBattle: use cases are requirements

Steve Battle: use cases are requirements

09:21:44 <betehess> cygri: this level of details can't be defined here

Richard Cyganiak: this level of details can't be defined here

09:21:51 <davidwood> q+ to suggest the implementations page be used to record the "where"

David Wood: q+ to suggest the implementations page be used to record the "where"

09:21:57 <betehess> ... there are specific deployment pattern that are used out there

... there are specific deployment pattern that are used out there

09:21:59 <Yves> +1 use case documents should not be a pre-spec, just general goals for the spec

Yves Lafon: +1 use case documents should not be a pre-spec, just general goals for the spec

09:22:16 <betehess> ... some things are already using 303 for example

... some things are already using 303 for example

09:22:34 <betehess> ... we may have to answer quesitons like to we support X? if not, why?

... we may have to answer quesitons like to we support X? if not, why?

09:22:44 <betehess> ... that's something I expect to see in the document

... that's something I expect to see in the document

09:23:04 <betehess> ... and at the end, we may just say that we recomment something else

... and at the end, we may just say that we recomment something else

09:23:09 <oberger> +1 we need such level of details for existing deployment patterns

Olivier Berger: +1 we need such level of details for existing deployment patterns

09:23:09 <ahaller2> q+

Armin Haller: q+

09:23:30 <betehess> ... people want to say the way they expect this to work

... people want to say the way they expect this to work

09:23:42 <RRSAgent> I have made the request to generate http://www.w3.org/2012/11/01-ldp-minutes.html ericP

RRSAgent IRC Bot: I have made the request to generate http://www.w3.org/2012/11/01-ldp-minutes.html ericP

09:24:08 <betehess> ... taking existing deployment into account is a valid point, should not be ignored

... taking existing deployment into account is a valid point, should not be ignored

09:24:16 <betehess> SteveS: +1 to eric

Steve Speicher: +1 to eric

09:24:20 <ArnaudLH> ack steves

Arnaud Le Hors: ack steves

09:24:27 <betehess> ... we may have another wiki page

... we may have another wiki page

09:24:36 <krp> q+

Kevin Page: q+

09:24:46 <betehess> ... where we can say how things match between the doc and the spec

... where we can say how things match between the doc and the spec

09:25:06 <betehess> ... would be bad to have to go back to UCR to change it

... would be bad to have to go back to UCR to change it

09:25:18 <ArnaudLH> ack bete

Arnaud Le Hors: ack bete

09:25:21 <betehess> ArnaudLH: for me, it's too much about the solution, not defining the solution

Arnaud Le Hors: for me, it's too much about the solution, not defining the solution

09:25:43 <SteveBattle> q+

Steve Battle: q+

09:25:46 <oberger> betehess: I want to describe the problem, not the solution

Alexandre Bertails: I want to describe the problem, not the solution [ Scribe Assist by Olivier Berger ]

09:25:55 <ericP> betehess: i don't want to describe the solution, i want to describe the problem, and then tie that to existing solutions

Alexandre Bertails: i don't want to describe the solution, i want to describe the problem, and then tie that to existing solutions [ Scribe Assist by Eric Prud'hommeaux ]

09:27:01 <ericP> ... when you speak of 303s (for folks who want to make a clear distinction between entity and page), some folks use #URIs

Eric Prud'hommeaux: ... when you speak of 303s (for folks who want to make a clear distinction between entity and page), some folks use #URIs

09:27:19 <ericP> cygri: we don't want to throw it out based on the level of detail

Richard Cyganiak: we don't want to throw it out based on the level of detail [ Scribe Assist by Eric Prud'hommeaux ]

09:27:50 <ericP> betehess: if we don't end up matching the UC&R, do we delete UC&R?

Alexandre Bertails: if we don't end up matching the UC&R, do we delete UC&R? [ Scribe Assist by Eric Prud'hommeaux ]

09:28:05 <ArnaudLH> ack david

Arnaud Le Hors: ack david

09:28:05 <Zakim> davidwood, you wanted to suggest the implementations page be used to record the "where"

Zakim IRC Bot: davidwood, you wanted to suggest the implementations page be used to record the "where"

09:28:10 <ericP> cygri: user stories give requirements; requirements give rise to features in the spec

Richard Cyganiak: user stories give requirements; requirements give rise to features in the spec [ Scribe Assist by Eric Prud'hommeaux ]

09:28:11 <betehess> davidwood: maybe a bit orthogonal

David Wood: maybe a bit orthogonal

09:28:18 <betehess> ... trying to capture the what and the how

... trying to capture the what and the how

09:28:19 <ericP> ... sometimes you have to go back. that's just how it is

Eric Prud'hommeaux: ... sometimes you have to go back. that's just how it is

09:28:25 <betehess> ... the where may be missing

... the where may be missing

09:28:39 <betehess> ... eg. to answer waht use-cases are implemented or not

... eg. to answer what use-cases are implemented or not

09:28:53 <betehess> ... we need a place to track those

... we need a place to track those

09:29:18 <betehess> ... I agree it's too detalied in term of the guidance

... I agree it's too detalied in term of the guidance

09:29:24 <betehess> ... we would like to say things only once

... we would like to say things only once

09:29:30 <betehess> ... don't repeat yourself

... don't repeat yourself

09:29:44 <betehess> ... we could change this page to respect the use stories (the why)

... we could change this page to respect the use stories (the why)

09:30:04 <betehess> ... and point to the spec to see where it's discussed

... and point to the spec to see where it's discussed

09:30:04 <SteveS> we should also map the spec sections to the use cases, that way we have a good mapping implementations to uc to spec sections

Steve Speicher: we should also map the spec sections to the use cases, that way we have a good mapping implementations to uc to spec sections

09:30:06 <ArnaudLH> ack ahaller

Arnaud Le Hors: ack ahaller

09:30:13 <betehess> ahaller2: I find this useful to the end-user

Armin Haller: I find this useful to the end-user

09:30:19 <betehess> ... it says hwo to use the platform

... it says hwo to use the platform

09:30:37 <betehess> ArnaudLH: I think there is great material here

Arnaud Le Hors: I think there is great material here

09:30:46 <betehess> ... nobody is saying to throw it out

... nobody is saying to throw it out

09:30:53 <betehess> ... question is what's belong here

... question is what's belong here

09:31:02 <betehess> ... what is the spec going to address

... what is the spec going to address

09:31:18 <betehess> ... we don't just want to delete any of these

... we don't just want to delete any of these

09:31:36 <davidwood> s/waht/what/
09:31:39 <betehess> ... could be a note, or whatever, we decide that later

... could be a note, or whatever, we decide that later

09:32:04 <betehess> ... could a primer as well

... could be a primer as well

09:32:09 <betehess> s/could/could be/
09:32:15 <ArnaudLH> ack krp

Arnaud Le Hors: ack krp

09:32:24 <betehess> krp: could be confusing

Kevin Page: could be confusing

09:32:35 <betehess> ... what don't people like here?

... what don't people like here?

09:32:40 <betehess> ... to many steps?

... too many steps?

09:32:45 <betehess> s/to/too/
09:32:58 <betehess> ... at least, this is a clear requirement

... at least, this is a clear requirement

09:33:11 <betehess> ... could also be a test case

... could also be a test case

09:33:16 <betehess> q+

q+

09:33:23 <ArnaudLH> ack steveb

Arnaud Le Hors: ack steveb

09:34:07 <betehess> SteveBattle: what do you want to move out?

Steve Battle: what do you want to move out?

09:34:23 <ericP> q+ to propose that it may be most helpful to us to partition later and add an issue to say we plan to do so

Eric Prud'hommeaux: q+ to propose that it may be most helpful to us to partition later and add an issue to say we plan to do so

09:34:26 <betehess> ... it's conventional to speak about the steps

... it's conventional to speak about the steps

09:34:38 <betehess> davidwood: the spec speaks about 303 in two places

David Wood: the spec speaks about 303 in two places

09:34:47 <betehess> ... also http verbs

... also http verbs

09:35:03 <ArnaudLH> ack bete

Arnaud Le Hors: ack bete

09:35:16 <ericP> betehess: what's there is valuable

Alexandre Bertails: what's there is valuable [ Scribe Assist by Eric Prud'hommeaux ]

09:35:28 <ericP> ... it's not about the value itself

Eric Prud'hommeaux: ... it's not about the value itself

09:35:41 <ericP> ... this material is excellent for when i'm implementing the test

Eric Prud'hommeaux: ... this material is excellent for when i'm implementing the test

09:35:55 <svillata> oberger +1

Serena Villata: oberger +1

09:35:55 <ericP> ... i want to test the spec, not the user requirement

Eric Prud'hommeaux: ... i want to test the spec, not the user requirement

09:36:14 <davidwood> q+ to suggest starting a test page

David Wood: q+ to suggest starting a test page

09:36:17 <oberger> q+ asking for a coffee break potentially short

Olivier Berger: q+ asking for a coffee break potentially short

09:36:21 <oberger> q-

Olivier Berger: q-

09:36:21 <ericP> ... some folks say "just re-edit the page", but this is against @@1

Eric Prud'hommeaux: ... some folks say "just re-edit the page", but this is against @@1

09:36:32 <ArnaudLH> ack eric

Arnaud Le Hors: ack eric

09:36:32 <Zakim> ericP, you wanted to propose that it may be most helpful to us to partition later and add an issue to say we plan to do so

Zakim IRC Bot: ericP, you wanted to propose that it may be most helpful to us to partition later and add an issue to say we plan to do so

09:36:47 <betehess> ericP: when I said to split out in different document

Eric Prud'hommeaux: when I said to split out in different document

09:36:57 <betehess> ... for the time being, this is very useful

... for the time being, this is very useful

09:37:13 <SteveBattle> q+

Steve Battle: q+

09:37:22 <betehess> ... we'll need to re-edit something anyway

... we'll need to re-edit something anyway

09:37:31 <betehess> ... we can insert a note at the beginning

... we can insert a note at the beginning

09:37:39 <betehess> ... and use color code

... and use color code

09:37:59 <betehess> ... that states what's to be considered

... that states what's to be considered

09:38:13 <betehess> ... and gives fewer places to visit

... and gives fewer places to visit

09:38:42 <ArnaudLH> ack david

Arnaud Le Hors: ack david

09:38:42 <Zakim> davidwood, you wanted to suggest starting a test page

Zakim IRC Bot: davidwood, you wanted to suggest starting a test page

09:38:58 <ArnaudLH> q- asking

Arnaud Le Hors: q- asking

09:39:17 <betehess> davidwood: we could move some of the stuff to a wiki page for tests

David Wood: we could move some of the stuff to a wiki page for tests

09:39:21 <ArnaudLH> ack steveb

Arnaud Le Hors: ack steveb

09:39:34 <betehess> SteveBattle: we'll propose something

Steve Battle: we'll propose something

09:39:40 <rgarcia> +1 to convert examples into tests

Raúl García Castro: +1 to convert examples into tests

09:39:47 <betehess> ... still people need to review the scenarios

... still people need to review the scenarios

09:40:10 <betehess> ArnaudLH: let me try to summarize

Arnaud Le Hors: let me try to summarize

09:40:16 <betehess> ... probably too much in the doc

... probably too much in the doc

09:40:22 <betehess> ... not sure how to address the p

... not sure how to address the p

09:40:33 <betehess> ... some wants to move stuff

... some wants to move stuff

09:40:45 <betehess> ... just happy to give SteveBattle a chance to do another pass

... just happy to give SteveBattle a chance to do another pass

09:41:03 <betehess> ... but I don't want to end up saying "this is not what we wanted"

... but I don't want to end up saying "this is not what we wanted"

09:41:05 <betehess> q+

q+

09:41:25 <betehess> ... any concrete proposal?

... any concrete proposal?

09:41:31 <SteveS> q+

Steve Speicher: q+

09:42:03 <betehess> ... if there is too much, we'll need to sort it out

... if there is too much, we'll need to sort it out

09:42:20 <sandro> zakim, who is on the call?

Sandro Hawke: zakim, who is on the call?

09:42:20 <Zakim> On the phone I see St_Clair_3B, Yves

Zakim IRC Bot: On the phone I see St_Clair_3B, Yves

09:42:22 <betehess> oberger: maybe let's focus on the first 2 ones?

Olivier Berger: maybe let's focus on the first 2 ones?

09:42:46 <betehess> SteveBattle: don't want to loose the information, eg. the status code

Steve Battle: don't want to loose the information, eg. the status code

09:43:01 <ArnaudLH> ack bete

Arnaud Le Hors: ack bete

09:43:58 <Ashok_Malhotra> q+

Ashok Malhotra: q+

09:44:16 <ericP> betehess: maybe we want to have everything for a given user story in one place

Alexandre Bertails: maybe we want to have everything for a given user story in one place [ Scribe Assist by Eric Prud'hommeaux ]

09:44:37 <ArnaudLH> ack steves

Arnaud Le Hors: ack steves

09:44:50 <betehess> SteveS: wanted to echo something similar

Steve Speicher: wanted to echo something similar

09:44:51 <ericP> ... at the end we need to gather all the info one place and this document points to the appropriate places in all the specs

Eric Prud'hommeaux: ... at the end we need to gather all the info one place and this document points to the appropriate places in all the specs

09:45:06 <betehess> ... phrasing is important

... phrasing is important

09:45:28 <betehess> ... then we can extract the things depending on what we need

... then we can extract the things depending on what we need

09:46:02 <BartvanLeeuwen> q+

Bart van Leeuwen: q+

09:46:04 <ArnaudLH> ack ashok

Arnaud Le Hors: ack ashok

09:46:08 <betehess> ArnaudLH: we have decided if we needed a primer yet

Arnaud Le Hors: we have decided if we needed a primer yet

09:46:22 <betehess> Ashok_Malhotra: would take all the stuff other than the 2 headers

Ashok Malhotra: would take all the stuff other than the 2 headers

09:46:32 <ericP> q?

Eric Prud'hommeaux: q?

09:46:39 <betehess> ... could use other colors, this is possible solution

... could use other colors, this is possible solution

09:46:53 <bblfish> q+

Henry Story: q+

09:46:56 <betehess> ... like davidwood's suggestion to move that to test

... like davidwood's suggestion to move that to test

09:47:05 <betehess> ... the spec could end up with something very different

... the spec could end up with something very different

09:47:19 <betehess> davidwood: just said to put in a wiki page to start thing about it

David Wood: just said to put in a wiki page to start thing about it

09:47:22 <betehess> Ashok_Malhotra: that's fine

Ashok Malhotra: that's fine

09:47:23 <ericP> q+ to say that tests are allowed to be controversial

Eric Prud'hommeaux: q+ to say that tests are allowed to be controversial

09:47:25 <bblfish> q-

Henry Story: q-

09:48:07 <betehess> ArnaudLH: SHORT BREAK

Arnaud Le Hors: SHORT BREAK

09:48:13 <BartvanLeeuwen> q+ primer is needed

Bart van Leeuwen: q+ primer is needed

09:48:17 <oberger> resume at 11:00

Olivier Berger: resume at 11:00

09:48:58 <BartvanLeeuwen> q+ to state that primer is needed as in ld-dev yesterday

Bart van Leeuwen: q+ to state that primer is needed as in ld-dev yesterday

09:49:20 <Yves> +1 for a primer

Yves Lafon: +1 for a primer

10:10:01 <SteveBattle> +1

(No events recorded for 20 minutes)

Steve Battle: +1

10:11:35 <bblfish> hi

Henry Story: hi

10:11:40 <cygri> scribe: ahaller2

(Scribe set to Armin Haller)

10:11:44 <ahaller2> again a short round of introductions

again a short round of introductions

10:11:50 <ahaller2> Henry Story

Henry Story

10:12:05 <oberger> sandro's not here

Olivier Berger:

10:12:28 <ahaller2> Hadley Beeman

Hadley Beeman

10:12:31 <ArnaudLH> q?

Arnaud Le Hors: q?

10:12:41 <BartvanLeeuwen> ack me

Bart van Leeuwen: ack me

10:12:41 <Zakim> BartvanLeeuwen, you wanted to state that primer is needed as in ld-dev yesterday

Zakim IRC Bot: BartvanLeeuwen, you wanted to state that primer is needed as in ld-dev yesterday

10:12:50 <SteveBattle> q+

Steve Battle: q+

10:12:54 <betehess> s/sandro's not here//
10:13:02 <oberger> +1 for primer

Olivier Berger: +1 for primer

10:13:04 <ahaller2> Bart: a primer would be a good idea

Bart van Leeuwen: a primer would be a good idea

10:13:05 <cygri> q+

Richard Cyganiak: q+

10:14:26 <ahaller2> ArnaudLH: Would be a note, so we are fine doing a primer

Arnaud Le Hors: Would be a note, so we are fine doing a primer

10:14:38 <oberger> oberger: and bringing a bit more repeating of HTTP in the primer than in the specs would be greay

Olivier Berger: and bringing a bit more repeating of HTTP in the primer than in the specs would be great [ Scribe Assist by Olivier Berger ]

10:14:43 <oberger> s/greay/great/
10:14:57 <SteveS> +1 for primer, would be willing to help do

Steve Speicher: +1 for primer, would be willing to help do

10:15:01 <ArnaudLH> ack eric

Arnaud Le Hors: ack eric

10:15:01 <Zakim> ericP, you wanted to say that tests are allowed to be controversial

Zakim IRC Bot: ericP, you wanted to say that tests are allowed to be controversial

10:15:50 <ArnaudLH> ack steveb

Arnaud Le Hors: ack steveb

10:17:03 <ahaller2> steveB: move specific error codes to a wiki, still talk about supporting redirections, but less detail

Steve Battle: move specific error codes to a wiki, still talk about supporting redirections, but less detail

10:17:14 <ArnaudLH> ack cygri

Arnaud Le Hors: ack cygri

10:17:59 <ahaller2> richard: caution with primers, not always effective, often rushed out, not covering the scope of the working group

Richard Cyganiak: caution with primers, not always effective, often rushed out, not covering the scope of the working group

10:18:30 <ahaller2> ... could be done outside of the working group

... could be done outside of the working group

10:18:57 <oberger> http://patterns.dataincubator.org/book/ provides a nice example of what a primer could be

Olivier Berger: http://patterns.dataincubator.org/book/ provides a nice example of what a primer could be

10:18:58 <ahaller2> ArnaudLH: add primer issue to the agenda if we have time

Arnaud Le Hors: add primer issue to the agenda if we have time

10:19:09 <ahaller2> ... who is the audience of the primer

... who is the audience of the primer

10:20:07 <ahaller2> ArnaudLH: keep the timeline for the UCR document is more important

Arnaud Le Hors: keep the timeline for the UCR document is more important

10:21:00 <ahaller2> ... agree on the status of the document, what sections are in the document, mock the sections if necessary.

... agree on the status of the document, what sections are in the document, mock the sections if necessary.

10:21:48 <ahaller2> ... figure out nature of the content and the audience, don't have an explosion of documents

... figure out nature of the content and the audience, don't have an explosion of documents

10:22:02 <oberger> should be maintain a Linked Data index of the documents, their contents in a nice RDF graph ? ;)

Olivier Berger: should be maintain a Linked Data index of the documents, their contents in a nice RDF graph ? ;)

10:22:25 <oberger> kinda drinking our own champagne

Olivier Berger: kinda drinking our own champagne

10:22:50 <ericP> nicely stated

Eric Prud'hommeaux: nicely stated

10:22:57 <ahaller2> ... the UCR document would have been different if Steve did not have the spec. The document should stand on its own.

... the UCR document would have been different if Steve did not have the spec. The document should stand on its own.

10:23:09 <davidwood> oberger, VoID file?

David Wood: oberger, VoID file?

10:23:09 <bblfish> q+

Henry Story: q+

10:23:23 <ArnaudLH> ack bblfish

Arnaud Le Hors: ack bblfish

10:23:50 <antonis> @oberger +1

Antonis Loizou: @oberger +1

10:24:13 <oberger> some nice UC to add : specify a standard in a standardization body in a collaborative manner, etc ;)

Olivier Berger: some nice US to add : specify a standard in a standardization body in a collaborative manner, etc ;)

10:24:27 <oberger> s/UC/US/ User Story
10:24:47 <oberger> q+

Olivier Berger: q+

10:25:07 <betehess> RRSAgent, please make minutes

Alexandre Bertails: RRSAgent, please make minutes

10:25:07 <RRSAgent> I have made the request to generate http://www.w3.org/2012/11/01-ldp-minutes.html betehess

RRSAgent IRC Bot: I have made the request to generate http://www.w3.org/2012/11/01-ldp-minutes.html betehess

10:25:25 <ahaller2> ArnaudLH: easier to have everything in one document

Arnaud Le Hors: easier to have everything in one document

10:25:39 <ArnaudLH> ack oberger

Arnaud Le Hors: ack oberger

10:25:47 <ahaller2> oberger: should not be afraid of multiple documents

Olivier Berger: should not be afraid of multiple documents

10:26:02 <SteveBattle> q+

Steve Battle: q+

10:26:21 <ArnaudLH> ack steveb

Arnaud Le Hors: ack steveb

10:26:47 <ahaller2> SteveB: use cases should not be vague

Steve Battle: use cases should not be vague

10:27:12 <sandro> seating chart for the room today, as far as I can tell: http://www.w3.org/2012/ldp/meeting/2012-11-01#line0001

Sandro Hawke: seating chart for the room today, as far as I can tell: http://www.w3.org/2012/ldp/meeting/2012-11-01#line0001

10:27:14 <cygri> q+

Richard Cyganiak: q+

10:27:19 <ahaller2> ArnaudLH: ericP proposed to annotate the document

Arnaud Le Hors: ericP proposed to annotate the document

10:27:23 <ArnaudLH> ack cygri

Arnaud Le Hors: ack cygri

10:27:24 <oberger> can we add anchors inside a mediawiki page, that won't be renamed ?

Olivier Berger: can we add anchors inside a mediawiki page, that won't be renamed ?

10:27:35 <bblfish> what does it mean to publish the document? Is it not on the wiki?

Henry Story: what does it mean to publish the document? Is it not on the wiki?

10:27:38 <oberger> so that we can nnotate ?

Olivier Berger: so that we can nnotate ?

10:27:45 <ahaller2> cygri: how to get certain use cases into the document? I have use cases which are not reflected.

Richard Cyganiak: how to get certain use cases into the document? I have use cases which are not reflected.

10:28:04 <ahaller2> ... what level are they, user stories vs. use cases

... what level are they, user stories vs. use cases

10:28:26 <sandro> oberger, yes, <span id="foo"></span> should survive.

Sandro Hawke: oberger, yes, <span id="foo"></span> should survive.

10:28:44 <oberger> sandro, or maybe a less HTML way ?

Olivier Berger: sandro, or maybe a less HTML way ?

10:28:59 <sandro> oberger, I don't know a non-HTML way

Sandro Hawke: oberger, I don't know a non-HTML way

10:29:41 <ahaller2> ... if i have requirement like I have a graph with mio incoming and outgoing links, how would i document that in the UCR document

... if i have requirement like I have a graph with mio incoming and outgoing links, how would i document that in the UCR document

10:29:53 <oberger> sandro, <div id="NameOfAnchorHere">optional text</div> in http://www.mediawiki.org/wiki/Help:Links

Olivier Berger: sandro, <div id="NameOfAnchorHere">optional text</div> in http://www.mediawiki.org/wiki/Help:Links

10:30:00 <ahaller2> ericP: i feel this is more like an issue, not a use case

Eric Prud'hommeaux: i feel this is more like an issue, not a use case

10:30:01 <oberger> sandro, so that's similar

Olivier Berger: sandro, so that's similar

10:30:25 <sandro> yes, oberger, same thing

Sandro Hawke: yes, oberger, same thing

10:30:48 <SteveBattle> q+

Steve Battle: q+

10:31:34 <ahaller2> cygri: i have this big graph, the question is should i put it in right now

Richard Cyganiak: i have this big graph, the question is should i put it in right now

10:32:33 <ahaller2> steveB: examples has two issues, functional and non-functional, scale

Steve Battle: examples has two issues, functional and non-functional, scale

10:33:25 <ahaller2> ArnaudLH: it does not make sense to close the document, you can add use cases later, even though they are harder to be addressed

Arnaud Le Hors: it does not make sense to close the document, you can add use cases later, even though they are harder to be addressed

10:33:39 <ArnaudLH> ack steveb

Arnaud Le Hors: ack steveb

10:33:57 <ericP> q+ to have a valuable position on the queue

Eric Prud'hommeaux: q+ to have a valuable position on the queue

10:34:01 <ericP> q-

Eric Prud'hommeaux: q-

10:34:07 <ahaller2> steveB: prototype primer for use case details

Steve Battle: prototype primer for use case details

10:35:01 <ahaller2> ArnaudLH: multiple ways to communicate with the public, we can publish notes, or a link

Arnaud Le Hors: multiple ways to communicate with the public, we can publish notes, or a link

10:35:16 <ahaller2> steveB: detailed scenarios is important for implementers

Steve Battle: detailed scenarios is important for implementers

10:35:31 <ahaller2> davidwood: where do we provide the details for implementers?

David Wood: where do we provide the details for implementers?

10:35:46 <ahaller2> steveS: webplatform.org

Steve Speicher: webplatform.org

10:35:59 <cygri> q+ to talk about test cases

Richard Cyganiak: q+ to talk about test cases

10:36:26 <ahaller2> steveS: realise that we need to add more examples to spec

Steve Speicher: realise that we need to add more examples to spec

10:36:30 <ArnaudLH> ack cygri

Arnaud Le Hors: ack cygri

10:36:30 <Zakim> cygri, you wanted to talk about test cases

Zakim IRC Bot: cygri, you wanted to talk about test cases

10:37:04 <ahaller2> cygri: some of the details in the UCR would make good test cases

Richard Cyganiak: some of the details in the UCR would make good test cases

10:37:11 <nmihindu> ack cygri

Nandana Mihindukulasooriya: ack cygri

10:37:11 <davidwood> q+

David Wood: q+

10:37:43 <ahaller2> ArnaudLH: i would like to get a timeline.

Arnaud Le Hors: i would like to get a timeline.

10:38:30 <cygri> q+ to suggest doing straw poll on publishing FPWD as is

Richard Cyganiak: q+ to suggest doing straw poll on publishing FPWD as is

10:38:48 <ahaller2> ... how we are going to decide what will be in the UCR document

... how we are going to decide what will be in the UCR document

10:39:07 <betehess>  /me agrees with ArnaudLH as I disagree strongly with some of the current requirements

Alexandre Bertails: /me agrees with ArnaudLH as I disagree strongly with some of the current requirements

10:40:06 <betehess> q+

Alexandre Bertails: q+

10:40:09 <ahaller2> ... two possible approaches: 1) go through document and make decision 2) review the document, the default is everything stays in there, raise an issue

... two possible approaches: 1) go through document and make decision 2) review the document, the default is everything stays in there, raise an issue

10:40:17 <ArnaudLH> ack david

Arnaud Le Hors: ack david

10:40:39 <SteveBattle> If anyone disagrees with the detail of the requirements please raise on the mailing list.

Steve Battle: If anyone disagrees with the detail of the requirements please raise on the mailing list.

10:41:15 <ahaller2> davidwood: UCR is up already

David Wood: UCR is up already

10:41:25 <ahaller2> ArnaudLH: at the end it will be a note

Arnaud Le Hors: at the end it will be a note

10:41:26 <oberger> q+

Olivier Berger: q+

10:41:31 <ArnaudLH> ack cygri

Arnaud Le Hors: ack cygri

10:41:31 <Zakim> cygri, you wanted to suggest doing straw poll on publishing FPWD as is

Zakim IRC Bot: cygri, you wanted to suggest doing straw poll on publishing FPWD as is

10:42:06 <ahaller2> cygri: straw poll on publishing the content as we have it

Richard Cyganiak: straw poll on publishing the content as we have it

10:42:20 <ahaller2> ... surface concerns with straw poll

... surface concerns with straw poll

10:42:22 <nmihindu> q+

Nandana Mihindukulasooriya: q+

10:43:00 <ericP> q+ to say that we have a choice about whether the FPWD includes all ratified use cases

Eric Prud'hommeaux: q+ to say that we have a choice about whether the FPWD includes all ratified use cases

10:43:02 <ahaller2> ... going through document step by step is ok, but i am not sure what is a story and what is a use case

... going through document step by step is ok, but i am not sure what is a story and what is a use case

10:43:04 <davidwood> +1 to section-by-section review by the group

David Wood: +1 to section-by-section review by the group

10:43:20 <ArnaudLH> ack bete

Arnaud Le Hors: ack bete

10:43:25 <ahaller2> ArnaudLH: it will be useful to identify the things that we agree on

Arnaud Le Hors: it will be useful to identify the things that we need to agree on

10:43:48 <ArnaudLH> s/agree/need to agree/
10:43:54 <ericP> q+ to say that we have a choice about whether the FPWD includes only ratified use cases

Eric Prud'hommeaux: q+ to say that we have a choice about whether the FPWD includes only ratified use cases

10:44:01 <ahaller2> betehess: i have a problem with seeing solutions in the UCR document

Alexandre Bertails: i have a problem with seeing solutions in the UCR document

10:44:43 <cygri> q+

Richard Cyganiak: q+

10:44:52 <ahaller2> ... want to know what we add later on

... want to know what we add later on

10:45:00 <bblfish> there is a difference between the wiki and the published document

Henry Story: there is a difference between the wiki and the published document

10:45:02 <ArnaudLH> ack oberger

Arnaud Le Hors: ack oberger

10:45:06 <betehess> why not going through an issue then?

Alexandre Bertails: why not going through an issue then?

10:45:09 <ahaller2> ArnaudLH: controlled process on what will be added later

Arnaud Le Hors: controlled process on what will be added later

10:45:28 <bblfish> +1 for pingback

Henry Story: +1 for pingback

10:45:31 <ahaller2> oberger: some concerns on the mailing list are not in the document

Olivier Berger: some concerns on the mailing list are not in the document

10:45:39 <SteveS> use case for ping back?

Steve Speicher: use case for ping back?

10:45:45 <ahaller2> ... i have a problem to define a use case and/or user story

... i have a problem to define a use case and/or user story

10:46:02 <bblfish> q+

Henry Story: q+

10:46:15 <ahaller2> ... maybe others are in the same situation not knowing how to get something into the document

... maybe others are in the same situation not knowing how to get something into the document

10:46:15 <betehess> pingback relies on so many other things that are not even on scope

Alexandre Bertails: pingback relies on so many other things that are not even on scope

10:46:40 <bblfish> pingback is a use case

Henry Story: pingback is a use case

10:46:43 <ahaller2> ArnaudLH: if enough in the group care, it should be in, but we need to define a process

Arnaud Le Hors: if enough in the group care, it should be in, but we need to define a process

10:47:04 <ahaller2> davidwood: who else contributed to uses cases?

David Wood: who else contributed to uses cases?

10:47:30 <roger__> i can see a lot of uses for pingback!

Roger Menday: i can see a lot of uses for pingback!

10:47:45 <ahaller2> ArnaudLH: if you think the working group is not caring, raise it as an issue

Arnaud Le Hors: if you think the working group is not caring, raise it as an issue

10:48:09 <ahaller2> oberger: issue raised in the tracker not in the document

Olivier Berger: issue raised in the tracker not in the document

10:48:15 <SteveS> we also had feedback from the WG they many were pleased with current use cases and said it covered their cases

Steve Speicher: we also had feedback from the WG they many were pleased with current use cases and said it covered their cases

10:48:28 <ArnaudLH> q?

Arnaud Le Hors: q?

10:48:29 <ahaller2> davidwood: is there a product in tracker on UCR

David Wood: is there a product in tracker on UCR

10:48:51 <ahaller2> ... group member wants a use case, raise an issue

... group member wants a use case, raise an issue

10:48:55 <SteveBattle> +1

Steve Battle: +1

10:49:35 <ericP> PROPOSAL: the process for adding new use cases is to raise a tracker issue against the UC&R product

PROPOSED: the process for adding new use cases is to raise a tracker issue against the UC&R product

10:49:37 <cygri> +1

Richard Cyganiak: +1

10:49:39 <ArnaudLH> +1

Arnaud Le Hors: +1

10:49:41 <ericP> +1

Eric Prud'hommeaux: +1

10:49:42 <rgarcia> +1

Raúl García Castro: +1

10:49:43 <antonis> +1

Antonis Loizou: +1

10:49:43 <bblfish> +1

Henry Story: +1

10:49:44 <BartvanLeeuwen> +1

Bart van Leeuwen: +1

10:49:45 <betehess> +1

Alexandre Bertails: +1

10:49:46 <oberger> +1

Olivier Berger: +1

10:49:47 <ahaller2> +1

+1

10:49:47 <Ruben> +1

Ruben Verborgh: +1

10:49:48 <krp> +1

Kevin Page: +1

10:49:48 <SteveS> +1

Steve Speicher: +1

10:49:49 <svillata> +1

Serena Villata: +1

10:49:50 <SteveBattle> +1

Steve Battle: +1

10:49:54 <nmihindu> +1

Nandana Mihindukulasooriya: +1

10:49:56 <davidwood> +1

David Wood: +1

10:49:57 <sandro> +1

Sandro Hawke: +1

10:49:59 <ericP> APPROVED

Eric Prud'hommeaux: APPROVED

10:50:16 <ericP> RESOLVED: The process for adding new use cases is to raise a tracker issue against the UC&R product.

RESOLVED: The process for adding new use cases is to raise a tracker issue against the UC&R product.

10:50:17 <cygri> q?

Richard Cyganiak: q?

10:50:38 <ArnaudLH> ack nmihindu

Arnaud Le Hors: ack nmihindu

10:51:20 <betehess> that's why the wording is important! what do people expect to find in the UC&R document

Alexandre Bertails: that's why the wording is important! what do people expect to find in the UC&R document

10:51:28 <ahaller2> nmihindu: i have been implementer of specs, these infos we have in the UCR right now, are useful for implementers, but I am not reading the use cases as a implementer.

Nandana Mihindukulasooriya: i have been implementer of specs, these infos we have in the UCR right now, are useful for implementers, but I am not reading the use cases as a implementer.

10:51:30 <ericP> ack me

Eric Prud'hommeaux: ack me

10:51:30 <betehess> +1 to the dev comment

Alexandre Bertails: +1 to the dev comment

10:51:31 <Zakim> ericP, you wanted to say that we have a choice about whether the FPWD includes all ratified use cases and to say that we have a choice about whether the FPWD includes only ratified

Zakim IRC Bot: ericP, you wanted to say that we have a choice about whether the FPWD includes all ratified use cases and to say that we have a choice about whether the FPWD includes only ratified

10:51:31 <Zakim> ... use cases

Zakim IRC Bot: ... use cases

10:51:34 <ArnaudLH> ack eric

Arnaud Le Hors: ack eric

10:51:58 <oberger> FPWD of the UC&R

Olivier Berger: FPWD of the UC&R

10:52:12 <sandro> q?

Sandro Hawke: q?

10:52:20 <ahaller2> ericP: we have a choice of stating what issues have been approved

Eric Prud'hommeaux: we have a choice of stating what issues have been approved

10:52:36 <betehess> q+

Alexandre Bertails: q+

10:52:47 <ahaller2> ... for the 10 use cases in the UCR we can mark them as approved/not approved

... for the 10 use cases in the UCR we can mark them as approved/not approved

10:52:47 <ArnaudLH> ack cygri

Arnaud Le Hors: ack cygri

10:53:31 <ahaller2> cygri: we have a process of highlighting issues in the UCR document. i would like to see a deadline for these issues to be raised.

Richard Cyganiak: we have a process of highlighting issues in the UCR document. i would like to see a deadline for these issues to be raised.

10:53:38 <ArnaudLH> ack bblfish

Arnaud Le Hors: ack bblfish

10:54:08 <ahaller2> bblfish: test this, raise pingback as an issue

Henry Story: test this, raise pingback as an issue

10:54:15 <ahaller2> ArnaudLH: not right now

Arnaud Le Hors: not right now

10:54:18 <ArnaudLH> ack bete

Arnaud Le Hors: ack bete

10:54:45 <webr3> rrsagent, please draft minutes

Nathan Rixham: rrsagent, please draft minutes

10:54:45 <RRSAgent> I have made the request to generate http://www.w3.org/2012/11/01-ldp-minutes.html webr3

RRSAgent IRC Bot: I have made the request to generate http://www.w3.org/2012/11/01-ldp-minutes.html webr3

10:54:55 <SteveS> q+

Steve Speicher: q+

10:55:16 <ahaller2> betehess: agree, implementer will never look at the UCR

Alexandre Bertails: agree, implementer will never look at the UCR

10:55:43 <ahaller2> ... if we put something in the document it will be hard to remove it. cautious with the first public draft.

... if we put something in the document it will be hard to remove it. cautious with the first public draft.

10:55:45 <cygri> q+

Richard Cyganiak: q+

10:56:18 <ArnaudLH> ack steves

Arnaud Le Hors: ack steves

10:56:23 <ahaller2> ArnaudLH: making sure to agree what is in there. big mistake for example to include access control if we are not

Arnaud Le Hors: making sure to agree what is in there. big mistake for example to include access control if we are not

10:56:40 <ahaller2> SteveS: 18 user stories, are we agree on those as well?

Steve Speicher: 18 user stories, are we agree on those as well?

10:56:48 <betehess> so do we just use tracker for that as well?

Alexandre Bertails: so do we just use tracker for that as well?

10:56:54 <ahaller2> ... same process, with raising issue

... same process, with raising issue

10:57:03 <betehess> we need a deadline then

Alexandre Bertails: we need a deadline then

10:57:12 <ahaller2> cygri: use same process, raise an issue

Richard Cyganiak: use same process, raise an issue

10:57:23 <betehess> q+ to ask about a deadline

Alexandre Bertails: q+ to ask about a deadline

10:57:57 <cygri> q-

Richard Cyganiak: q-

10:57:58 <ahaller2> ArnaudLH: by default everything which is not questioned with an issue will be published

Arnaud Le Hors: by default everything which is not questioned with an issue will be published

10:58:13 <ArnaudLH> ack bete

Arnaud Le Hors: ack bete

10:58:13 <Zakim> betehess, you wanted to ask about a deadline

Zakim IRC Bot: betehess, you wanted to ask about a deadline

10:58:25 <cygri> q+

Richard Cyganiak: q+

10:58:32 <ahaller2> betehess: we need a timeline for when the chair will accept issues

Alexandre Bertails: we need a timeline for when the chair will accept issues

10:58:42 <nmihindu> q

Nandana Mihindukulasooriya: q

10:58:46 <ArnaudLH> ack cygri

Arnaud Le Hors: ack cygri

10:58:51 <ahaller2> ... after this point nobody should be allowed to edit the document

... after this point nobody should be allowed to edit the document

10:59:04 <nmihindu> q+

Nandana Mihindukulasooriya: q+

10:59:10 <betehess> as a way to work, we could move to github and use pull-request

Alexandre Bertails: as a way to work, we could move to github and use pull-request

11:00:00 <ahaller2> cygri: one proposal, we set a date, against the first public draft of this document. Editor takes what is in the wiki, at least flags the issues (marker in the document).

Richard Cyganiak: one proposal, we set a date, against the first public draft of this document. Editor takes what is in the wiki, at least flags the issues (marker in the document).

11:00:41 <ArnaudLH> ack nmihindu

Arnaud Le Hors: ack nmihindu

11:00:53 <SteveBattle> q+

Steve Battle: q+

11:01:01 <ahaller2> nmihindu: some user stories are very detailed, some are vague ideas. in the document we have to make them consistent.

Nandana Mihindukulasooriya: some user stories are very detailed, some are vague ideas. in the document we have to make them consistent.

11:01:09 <betehess> +1 to that

Alexandre Bertails: +1 to that

11:01:25 <ahaller2> SteveB: i don't agree we need to make them consistent

Steve Battle: i don't agree we need to make them consistent

11:01:36 <ArnaudLH> ack steveb

Arnaud Le Hors: ack steveb

11:02:12 <cygri> q+

Richard Cyganiak: q+

11:02:38 <ahaller2> ArnaudLH: do we agree with cygri's proposal, that we make sure that everything is at least mentioned in the document (ie. issues)

Arnaud Le Hors: do we agree with cygri's proposal, that we make sure that everything is at least mentioned in the document (ie. issues)

11:04:03 <SteveS> +1 for some consistency in user stories, think the readers will appreciate it

Steve Speicher: +1 for some consistency in user stories, think the readers will appreciate it

11:04:38 <ahaller2> cygri: regarding the timeline. everything before that date will be at least acknowledged

Richard Cyganiak: regarding the timeline. everything before that date will be at least acknowledged

11:04:52 <cygri> PROPOSAL: Issues raised against the UC&R document before XX/YY will be acknowledged or addressed in the first WD of the published document.

PROPOSED: Issues raised against the UC&R document before XX/YY will be acknowledged or addressed in the first WD of the published document.

11:05:38 <sandro> suggest 1 December ?

Sandro Hawke: suggest 1 December ?

11:05:54 <ahaller2> ArnaudLH: agree with that, happy to make that official if people agree

Arnaud Le Hors: agree with that, happy to make that official if people agree

11:06:02 <betehess> too soon for me

Alexandre Bertails: too soon for me

11:07:09 <ahaller2> oberger: can steveB still add issues?

Olivier Berger: can steveB still add issues?

11:07:26 <ahaller2> ArnaudLH: SteveB should go through the same process

Arnaud Le Hors: SteveB should go through the same process

11:07:58 <ahaller2> ArnaudLH: will come up with a deadline by tomorrow

Arnaud Le Hors: will come up with a deadline by tomorrow

11:08:44 <betehess> q+

Alexandre Bertails: q+

11:08:56 <cygri> ack me

Richard Cyganiak: ack me

11:09:06 <ahaller2> ericP: are we picking something specific, like SemTech

Eric Prud'hommeaux: are we picking something specific, like SemTech

11:09:22 <ArnaudLH> ack cygri

Arnaud Le Hors: ack cygri

11:09:31 <ArnaudLH> ack bete

Arnaud Le Hors: ack bete

11:09:42 <oberger> how many weekly meetings/calls do we need ?

Olivier Berger: how many weekly meetings/calls do we need ?

11:09:50 <cygri> q+

Richard Cyganiak: q+

11:09:57 <ahaller2> betehess: if we have a deadline that is too early we will have no agreement on anything

Alexandre Bertails: if we have a deadline that is too early we will have no agreement on anything

11:10:04 <sandro> betehess misunderstood cygri's proposal

Sandro Hawke: betehess misunderstood cygri's proposal

11:10:24 <ahaller2> ArnaudLH: we will have to be optimistic

Arnaud Le Hors: we will have to be optimistic

11:10:25 <oberger> ack cygri

Olivier Berger: ack cygri

11:10:43 <ahaller2> cygri: deadline for raising issues, not for inclusions in the document

Richard Cyganiak: deadline for raising issues, not for inclusions in the document

11:11:02 <ahaller2> ... two separate deadlines

... two separate deadlines

11:11:35 <ahaller2> cygri: PROPOSAL: Issues raised against the UC&R document before XX/YY will be acknowledged or addressed in the first WD of the published document.

Richard Cyganiak: PROPOSAL: Issues raised against the UC&R document before XX/YY will be acknowledged or addressed in the first WD of the published document.

11:11:53 <SteveS> +1

Steve Speicher: +1

11:12:03 <ArnaudLH> +1

Arnaud Le Hors: +1

11:12:07 <BartvanLeeuwen> +1

Bart van Leeuwen: +1

11:12:07 <Ruben> +1

Ruben Verborgh: +1

11:12:08 <krp> +1

Kevin Page: +1

11:12:09 <rgarcia> +1

Raúl García Castro: +1

11:12:10 <svillata> +1

Serena Villata: +1

11:12:11 <bblfish> +1

Henry Story: +1

11:12:11 <antonis> +1

Antonis Loizou: +1

11:12:11 <oberger> ArnaudLH, to propose a timeline tomorow

Olivier Berger: ArnaudLH, to propose a timeline tomorow

11:12:13 <betehess> +1

Alexandre Bertails: +1

11:12:15 <ahaller2> +1

+1

11:12:19 <roger__> +1

Roger Menday: +1

11:12:19 <nmihindu> +1

Nandana Mihindukulasooriya: +1

11:12:32 <Ashok_Malhotra> +1

Ashok Malhotra: +1

11:12:57 <ericP> +1 to the general idea, noting that it has no date

Eric Prud'hommeaux: +1 to the general idea, noting that it has no date

11:13:09 <betehess> +1 to eric's remark

Alexandre Bertails: +1 to eric's remark

11:13:16 <SteveBattle> +1 (and OK with Dec 1 date)

Steve Battle: +1 (and OK with Dec 1 date)

11:13:24 <ericP> +1 to betehess's validation

Eric Prud'hommeaux: +1 to betehess's validation

11:13:57 <cygri> q?

Richard Cyganiak: q?

11:14:03 <ahaller2> ArnaudLH: let's have lunch, get back in 45 minutes

Arnaud Le Hors: let's have lunch, get back in 45 minutes

11:14:04 <ericP> RESOLVED: Issues raised against the UC&R document before XX/YY will be acknowledged or addressed in the first WD of the published document.

RESOLVED: Issues raised against the UC&R document before XX/YY will be acknowledged or addressed in the first WD of the published document.

11:14:10 <cygri> summary: Long discussion of the UC&R document. The WG resolves that WG members are encouraged to file issues against it, including new use cases, and that all issues raised before a to-be-determined date will be addressed or at least acknowledged before the document goes to FPWD.
11:14:33 <nmihindu> present+ Nandana_Mihindukulasooriya

Nandana Mihindukulasooriya: present+ Nandana_Mihindukulasooriya

11:14:49 <rgarcia> present+ Raul_Garcia-Castro

Raúl García Castro: present+ Raul_Garcia-Castro

11:48:20 <Zakim> +JohnArwe

(No events recorded for 33 minutes)

Zakim IRC Bot: +JohnArwe

12:10:49 <oberger> JohnArwe on the phone

(No events recorded for 22 minutes)

Olivier Berger: JohnArwe on the phone

12:10:59 <oberger> q+ what about the restaurant tonite ?

Olivier Berger: q+ what about the restaurant tonite ?

12:11:04 <bblfish> hi JohnArwe

Henry Story: hi JohnArwe

12:11:29 <cygri> oberger, check the agenda :-)

Richard Cyganiak: oberger, check the agenda :-)

12:11:49 <oberger> cygri, doesn't tell where

Olivier Berger: cygri, doesn't tell where

12:11:55 <JohnArwe> I will have to drop in 2 hours.  GMs are so inconsiderate of my existing schedule.

John Arwe: I will have to drop in 2 hours. GMs are so inconsiderate of my existing schedule.

12:12:04 <cygri> oberger, there's a time slot for discussing that.

Richard Cyganiak: oberger, there's a time slot for discussing that.

12:12:46 <oberger> cygri, yes, but if we have to make a reservation, the sooner, the better... that said, dunno

Olivier Berger: cygri, yes, but if we have to make a reservation, the sooner, the better... that said, dunno

12:13:21 <cygri> scribe: cygri

(Scribe set to Richard Cyganiak)

12:13:42 <cygri> TOPIC: LDP Specification

3. LDP Specification

12:13:58 <oberger> http://www.w3.org/2012/ldp/hg/ldp.html

Olivier Berger: http://www.w3.org/2012/ldp/hg/ldp.html

12:13:59 <cygri> ArnaudLH: We could simply go down the issue list in order.

Arnaud Le Hors: We could simply go down the issue list in order.

12:14:13 <cygri> ... To warm up, we could start with some perhaps less controversial issues.

... To warm up, we could start with some perhaps less controversial issues.

12:14:33 <oberger> http://www.w3.org/2012/ldp/track/issues

Olivier Berger: http://www.w3.org/2012/ldp/track/issues

12:14:38 <rgarcia> http://www.w3.org/2012/ldp/track/issues/open

Raúl García Castro: http://www.w3.org/2012/ldp/track/issues/open

12:14:53 <cygri> ... Anyone wants to suggest a particular issue for discussion?

... Anyone wants to suggest a particular issue for discussion?

12:14:54 <Ruben> could we talk about 24 today sometime? (not here tomorrow)

Ruben Verborgh: could we talk about 24 today sometime? (not here tomorrow)

12:16:39 <cygri> [reconciling order of discussion with presence of various participants]

[reconciling order of discussion with presence of various participants]

12:16:48 <betehess> closest to my interest: http://www.w3.org/2012/ldp/track/issues/20

Alexandre Bertails: closest to my interest: http://www.w3.org/2012/ldp/track/issues/20

12:16:54 <JohnArwe> 23 open according to the server (just above table)

John Arwe: 23 open according to the server (just above table)

12:17:15 <AndyS> zakim, code?

Andy Seaborne: zakim, code?

12:17:15 <Zakim> the conference code is 53794 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), AndyS

Zakim IRC Bot: the conference code is 53794 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), AndyS

12:17:31 <roger> i have interest in issue 26 - and will (unfortunately) not be here tommorrow ....

Roger Menday: i have interest in ISSUE-26 - and will (unfortunately) not be here tommorrow ....

12:17:40 <Zakim> +??P0

Zakim IRC Bot: +??P0

12:17:48 <AndyS> zakim, ??P0 is me

Andy Seaborne: zakim, ??P0 is me

12:17:48 <Zakim> +AndyS; got it

Zakim IRC Bot: +AndyS; got it

12:17:50 <betehess> q+

Alexandre Bertails: q+

12:18:05 <betehess> q-

Alexandre Bertails: q-

12:18:17 <betehess> q+

Alexandre Bertails: q+

12:19:04 <FabGandon> Present+FabGandon

Fabien Gandon: Present+FabGandon

12:19:36 <oberger> q?

Olivier Berger: q?

12:21:08 <ArnaudLH> ack bete

Arnaud Le Hors: ack bete

12:21:26 <davidwood> q+ to propose a resolution for ISSUEs 22 and 23

David Wood: q+ to propose a resolution for ISSUEs 22 and 23

12:22:12 <oberger> let's vote on 22 !

Olivier Berger: let's vote on 22 !

12:22:34 <oberger> on discussing 22

Olivier Berger: on discussing 22

12:22:51 <cygri> subtopic: ISSUE-22 and ISSUE-23 (RDF/XML and JSON-LD)

3.1. ISSUE-22 and ISSUE-23 (RDF/XML and JSON-LD)

Summary: The WG resolves that Turtle MUST be supported, and other formats MAY be supported via content negotiation, with Turtle as default.

12:22:56 <ericP> +1

Eric Prud'hommeaux: +1

12:23:05 <davidwood> PROPOSED: Resolve ISSUEs 22 and 23 by stating that LDP servers MUST support Turtle and MAY/SHOULD support any other RDF serialization format that is a W3C Recommendation.

PROPOSED: Resolve ISSUEs 22 and 23 by stating that LDP servers MUST support Turtle and MAY/SHOULD support any other RDF serialization format that is a W3C Recommendation.

12:23:05 <bblfish> +1

Henry Story: +1

12:23:12 <oberger> http://www.w3.org/2012/ldp/track/issues/22

Olivier Berger: http://www.w3.org/2012/ldp/track/issues/22

12:23:17 <bblfish> +1

Henry Story: +1

12:23:19 <SteveBattle> +1

Steve Battle: +1

12:23:22 <cygri> q+

q+

12:23:36 <cygri> ArnaudLH: Turtle is a MUST, we have resolved that already

Arnaud Le Hors: Turtle is a MUST, we have resolved that already

12:23:47 <cygri> davidwood: It should be separated from the other formats

David Wood: It should be separated from the other formats

12:23:58 <betehess> does these format *have* to support relative URIs in their serializations?

Alexandre Bertails: does these format *have* to support relative URIs in their serializations?

12:24:06 <betehess> q+

Alexandre Bertails: q+

12:24:27 <betehess> q+ to ask if these formats MUST support relative URIs in their serializations

Alexandre Bertails: q+ to ask if these formats MUST support relative URIs in their serializations

12:24:32 <cygri> ... Point is to have a consistent policy

... Point is to have a consistent policy

12:24:40 <cygri> ... MAY or SHOULD would be consistent

... MAY or SHOULD would be consistent

12:24:46 <cygri> ack davidwood

ack davidwood

12:24:46 <Zakim> davidwood, you wanted to propose a resolution for ISSUEs 22 and 23

Zakim IRC Bot: davidwood, you wanted to propose a resolution for ISSUEs 22 and 23

12:24:48 <ahaller2> +1 for SHOULD

Armin Haller: +1 for SHOULD

12:24:57 <ArnaudLH> ack david

Arnaud Le Hors: ack david

12:25:00 <bblfish> 1+

Henry Story: 1+

12:25:02 <bblfish> q+

Henry Story: q+

12:25:15 <bblfish> Ntriples would not work because of ISSUE-20

Henry Story: Ntriples would not work because of ISSUE-20

12:25:24 <bblfish> because it does not have relative URIs

Henry Story: because it does not have relative URIs

12:25:39 <ericP> cygri: re: david's proposal, I preferr to just say that Turtle MUST be supported and say nothing about other formats

Richard Cyganiak: re: david's proposal, I preferr to just say that Turtle MUST be supported and say nothing about other formats [ Scribe Assist by Eric Prud'hommeaux ]

12:25:49 <davidwood> ISSUE 20 isn't resolved yet :)

David Wood: ISSUE-20 isn't resolved yet :)

12:26:03 <ericP> ... otherwise we end up in conneg and different representations of the same resource

Eric Prud'hommeaux: ... otherwise we end up in conneg and different representations of the same resource

12:26:06 <ArnaudLH> ack cygri

Arnaud Le Hors: ack cygri

12:26:11 <davidwood> I have no strong objection to cygri's proposal.

David Wood: I have no strong objection to cygri's proposal.

12:26:21 <AndyS> bblfish - strictly, nor does Turtle.  It encodes a graph and a graph has resolved absolute URIs.

Andy Seaborne: bblfish - strictly, nor does Turtle. It encodes a graph and a graph has resolved absolute URIs.

12:26:22 <Ruben> +1 for no other formats than Turtle

Ruben Verborgh: +1 for no other formats than Turtle

12:26:33 <rgarcia> +1 for only Turtle

Raúl García Castro: +1 for only Turtle

12:26:34 <timbl> q+ to suggest "May top connect o other formats"

Tim Berners-Lee: q+ to suggest "May top connect o other formats"

12:26:40 <ericP> oberger: shouldn't we discuss conneg?

Olivier Berger: shouldn't we discuss conneg? [ Scribe Assist by Eric Prud'hommeaux ]

12:26:46 <timbl> q+ to suggest "May top conneg  o other formats"

Tim Berners-Lee: q+ to suggest "May top conneg o other formats"

12:26:47 <ArnaudLH> ack bete

Arnaud Le Hors: ack bete

12:26:47 <Zakim> betehess, you wanted to ask if these formats MUST support relative URIs in their serializations

Zakim IRC Bot: betehess, you wanted to ask if these formats MUST support relative URIs in their serializations

12:26:54 <ericP> cygri: HTTP already talks about conneg

Richard Cyganiak: HTTP already talks about conneg [ Scribe Assist by Eric Prud'hommeaux ]

12:27:13 <ericP> oberger: in an informative section, we could say "of course you can use conneg"

Olivier Berger: in an informative section, we could say "of course you can use conneg" [ Scribe Assist by Eric Prud'hommeaux ]

12:27:20 <ArnaudLH> ack bblfish

Arnaud Le Hors: ack bblfish

12:27:22 <cygri> betehess: davidwood's proposal doesn't work because of relative URIs

Alexandre Bertails: davidwood's proposal doesn't work because of relative URIs

12:27:48 <SteveBattle> q+

Steve Battle: q+

12:27:51 <cygri> bblfish: N-Triples doesn't work because of ISSUE-20

Henry Story: N-Triples doesn't work because of ISSUE-20

12:28:12 <cygri> davidwood: N-Triples is likely to be a W3C recommendation

David Wood: N-Triples is likely to be a W3C recommendation

12:28:41 <AndyS> q+ to say it would have to be a restricted form of Turtle, not all Turtle.

Andy Seaborne: q+ to say it would have to be a restricted form of Turtle, not all Turtle.

12:28:57 <ArnaudLH> ack timbl

Arnaud Le Hors: ack timbl

12:28:57 <Zakim> timbl, you wanted to suggest "May top connect o other formats" and to suggest "May top conneg  o other formats"

Zakim IRC Bot: timbl, you wanted to suggest "May top connect o other formats" and to suggest "May top conneg o other formats"

12:29:01 <SteveBattle> q-

Steve Battle: q-

12:29:03 <cygri> bblfish: N-Triples only allows absolute URIs. ISSUE-20 proposal is to use relative URIs so that servers can fill in the URI after POST

Henry Story: N-Triples only allows absolute URIs. ISSUE-20 proposal is to use relative URIs so that servers can fill in the URI after POST

12:29:35 <oberger> +1 timbl

Olivier Berger: +1 timbl

12:29:47 <cygri> timbl: "MAY do conneg" may be worth stating to make clear that it's okay to support things beside Turtle

Tim Berners-Lee: "MAY do conneg" may be worth stating to make clear that it's okay to support things beside Turtle

12:30:23 <cygri> ... You may have to specify that Turtle MUST be returned dependent on q value

... You may have to specify that Turtle MUST be returned dependent on q value

12:30:37 <cygri> ... q values are an issue in conneg

... q values are an issue in conneg

12:30:40 <ArnaudLH> ack steveb

Arnaud Le Hors: ack steveb

12:30:47 <ArnaudLH> ack andy

Arnaud Le Hors: ack andy

12:30:47 <Zakim> AndyS, you wanted to say it would have to be a restricted form of Turtle, not all Turtle.

Zakim IRC Bot: AndyS, you wanted to say it would have to be a restricted form of Turtle, not all Turtle.

12:31:07 <cygri> AndyS: Depending on ISSUE-20 resolution, we may have to qualify what we mean by Turtle

Andy Seaborne: Depending on ISSUE-20 resolution, we may have to qualify what we mean by Turtle

12:31:08 <betehess> andy's remark is right

Alexandre Bertails: andy's remark is right

12:31:10 <AndyS> ack me

Andy Seaborne: ack me

12:31:14 <webr3> q+ to suggest "issue-20 may be easier solved by handling the use case a different way, simply have a resource which provides or redirects to a "new" free uri on each request, like an auto inc, then PUT to it"

Nathan Rixham: q+ to suggest "ISSUE-20 may be easier solved by handling the use case a different way, simply have a resource which provides or redirects to a "new" free uri on each request, like an auto inc, then PUT to it"

12:31:17 <webr3> q-

Nathan Rixham: q-

12:31:25 <JohnArwe> what was the common misreading of conneg timbl was talking about?  rapid-file syllables didn't make it so well across the pond.

John Arwe: what was the common misreading of conneg timbl was talking about? rapid-file syllables didn't make it so well across the pond.

12:31:40 <betehess> q+

Alexandre Bertails: q+

12:31:42 <Zakim> -Yves

Zakim IRC Bot: -Yves

12:32:05 <cygri> ... One of the ISSUE-20 proposals is that POSTing creates a new resource; the container decides on URI of the new resource and fills in <> with the address of the new resource

... One of the ISSUE-20 proposals is that POSTing creates a new resource; the container decides on URI of the new resource and fills in <> with the address of the new resource

12:32:28 <betehess> q-

Alexandre Bertails: q-

12:32:32 <cygri> ArnaudLH: Let's not talk about opening the resolution that turtle MUST be supported.

Arnaud Le Hors: Let's not talk about opening the resolution that turtle MUST be supported.

12:32:50 <timbl> All my serializers do relative URIs by default and in systems I build that is a fundamentally important thing.

Tim Berners-Lee: All my serializers do relative URIs by default and in systems I build that is a fundamentally important thing.

12:33:12 <AndyS> there are other ways to address issue-20 that do not have the relative URI issue and hence any RDF serialization works.

Andy Seaborne: there are other ways to address ISSUE-20 that do not have the relative URI issue and hence any RDF serialization works.

12:33:28 <ericP> cygri: yes

Richard Cyganiak: yes [ Scribe Assist by Eric Prud'hommeaux ]

12:33:49 <davidwood> +1 to AndyS

David Wood: +1 to AndyS

12:33:59 <cygri> PROPOSAL: MUST use Turtle; MAY do content negotiation with other formats

PROPOSED: MUST use Turtle; MAY do content negotiation with other formats

12:34:06 <Ruben> +1

Ruben Verborgh: +1

12:34:13 <bblfish> +1

Henry Story: +1

12:34:22 <oberger> +1

Olivier Berger: +1

12:34:23 <antonis> +1

Antonis Loizou: +1

12:34:27 <betehess> +1

Alexandre Bertails: +1

12:34:27 <ahaller2> +1

Armin Haller: +1

12:34:28 <SteveS> +1

Steve Speicher: +1

12:34:28 <ericP> +1

Eric Prud'hommeaux: +1

12:34:28 <BartvanLeeuwen> +1

Bart van Leeuwen: +1

12:34:30 <ArnaudLH> +1

Arnaud Le Hors: +1

12:34:34 <rgarcia> +1

Raúl García Castro: +1

12:34:34 <krp> +1

Kevin Page: +1

12:34:35 <AndyS> +1 to mentioning conneg somewhere in docs

Andy Seaborne: +1 to mentioning conneg somewhere in docs

12:34:35 <nmihindu> +1

Nandana Mihindukulasooriya: +1

12:34:38 <davidwood> +1

David Wood: +1

12:34:39 <sandro> +1

Sandro Hawke: +1

12:34:40 <webr3> +1 s/suse/support

Nathan Rixham: +1 s/suse/support

12:34:41 <SteveBattle> q+

Steve Battle: q+

12:34:46 <svillata> +1

Serena Villata: +1

12:35:29 <ArnaudLH> ack steveb

Arnaud Le Hors: ack steveb

12:35:43 <sandro> SteveBattle: If you don't send an accept header on a GET, will you get Turtle?

Steve Battle: If you don't send an accept header on a GET, will you get Turtle? [ Scribe Assist by Sandro Hawke ]

12:35:44 <ericP> q?

Eric Prud'hommeaux: q?

12:36:28 <timbl> (JohnArwe, the failure is that  tabulator for example a s ffox extension can handle turtle and html both fine. And so send the same q value for each.   When people serve both HTML and Turtle, then they have to ideally -- send HTML off the HTML is the master and the turtle is a degraded, information lost congestion from the HTML -- if the other way around, like here, that the turtle -- the data -- is the master and the HTML is generated from it, you should return the

Tim Berners-Lee: (JohnArwe, the failure is that tabulator for example a s ffox extension can handle turtle and html both fine. And so send the same q value for each. When people serve both HTML and Turtle, then they have to ideally -- send HTML off the HTML is the master and the turtle is a degraded, information lost congestion from the HTML -- if the other way around, like here, that the turtle -- the data -- is the master and the HTML is generated from it, you should return the

12:36:29 <timbl> turtle, otherwise you lose the semantics.)

Tim Berners-Lee: turtle, otherwise you lose the semantics.)

12:36:58 <bblfish> q+

Henry Story: q+

12:37:29 <cygri> PROPOSAL: Servers MUST support Turtle; servers MAY deliver other formats using standard HTTP content negotiation; If the client doesn't indicate a preference, Turtle MUST be returned

PROPOSED: Servers MUST support Turtle; servers MAY deliver other formats using standard HTTP content negotiation; If the client doesn't indicate a preference, Turtle MUST be returned

12:37:44 <betehess> q+

Alexandre Bertails: q+

12:37:58 <SteveBattle> +1

Steve Battle: +1

12:37:59 <webr3> +1

Nathan Rixham: +1

12:38:02 <davidwood> +1

David Wood: +1

12:38:05 <sandro> +1

Sandro Hawke: +1

12:38:09 <ArnaudLH> +1

Arnaud Le Hors: +1

12:38:09 <AndyS> +1

Andy Seaborne: +1

12:38:10 <svillata> +1

Serena Villata: +1

12:38:17 <Ruben> +1

Ruben Verborgh: +1

12:38:32 <krp> +1

Kevin Page: +1

12:38:39 <rgarcia> +1

Raúl García Castro: +1

12:38:41 <BartvanLeeuwen> +1

Bart van Leeuwen: +1

12:38:43 <bblfish> +1

Henry Story: +1

12:38:47 <ericP> +1

Eric Prud'hommeaux: +1

12:38:48 <nmihindu> +1

Nandana Mihindukulasooriya: +1

12:38:49 <antonis> +1

Antonis Loizou: +1

12:38:57 <SteveS> +1

Steve Speicher: +1

12:39:03 <roger> +1

Roger Menday: +1

12:39:22 <betehess> +1 but I believe that we must take into account the case the weights are equal (MUST return Turlte)

Alexandre Bertails: +1 but I believe that we must take into account the case the weights are equal (MUST return Turlte)

12:39:34 <cygri> ericP: HTTP only says how to specify a header and how a server indicates its format choice; doesn't specify how the server makes the choice. Why should we change this?

Eric Prud'hommeaux: HTTP only says how to specify a header and how a server indicates its format choice; doesn't specify how the server makes the choice. Why should we change this?

12:39:38 <sandro> betehess, I think the resolution is clear about that, as "no preference"

Sandro Hawke: betehess, I think the resolution is clear about that, as "no preference"

12:40:12 <cygri> [scribe can't follow]

[scribe can't follow]

12:40:13 <davidwood> betehess, the proposal does handle that case because the client has not expressed a preference in that case.

David Wood: betehess, the proposal does handle that case because the client has not expressed a preference in that case.

12:40:14 <betehess> sandro, I think it's cheap to speak about a "default"

Alexandre Bertails: sandro, I think it's cheap to speak about a "default"

12:40:35 <sandro> ArnaudLH, is that RESOLVED, in your chair judgement?

Sandro Hawke: ArnaudLH, is that RESOLVED, in your chair judgement?

12:40:44 <betehess> davidwood, maybe a English issue on my side, but I disagree

Alexandre Bertails: davidwood, maybe a English issue on my side, but I disagree

12:41:02 <cygri> RESOLVED: Servers MUST support Turtle; servers MAY deliver other formats using standard HTTP content negotiation; If the client doesn't indicate a preference, Turtle MUST be returned

RESOLVED: Servers MUST support Turtle; servers MAY deliver other formats using standard HTTP content negotiation; If the client doesn't indicate a preference, Turtle MUST be returned

12:41:15 <sandro> close issue-22

Sandro Hawke: close ISSUE-22

12:41:15 <trackbot> Sorry... closing ISSUE-22 failed, please let sysreq know about it

Trackbot IRC Bot: Sorry... closing ISSUE-22 failed, please let sysreq know about it

12:41:22 <cygri> ArnaudLH: Accordingly, we can close ISSUE-22 and ISSUE-23

Arnaud Le Hors: Accordingly, we can close ISSUE-22 and ISSUE-23

12:42:00 <cygri> summary: The WG resolves that Turtle MUST be supported, and other formats MAY be supported via content negotiation, with Turtle as default.
12:42:41 <Ruben> q+

Ruben Verborgh: q+

12:42:45 <betehess> q-

Alexandre Bertails: q-

12:42:45 <bblfish> q-

Henry Story: q-

12:42:52 <timbl> q?

Tim Berners-Lee: q?

12:43:28 <cygri> subtopic: ISSUE-24 (Is deletion permanent?)

3.2. ISSUE-24 (Is deletion permanent?)

Summary: Some feel strongly that URIs assigned by POSTing to a container and then deleted must never be assigned again. But scenarios like “undo of accidental delete” and creation via PUT cause opposition against stronger language. The discussion concludes with an editorial clarification.

12:42:59 <oberger> http://www.w3.org/2012/ldp/track/issues/24

Olivier Berger: http://www.w3.org/2012/ldp/track/issues/24

12:43:12 <davidwood> q+ to remind the WG on PURL's DELETE behavior

David Wood: q+ to remind the WG on PURL's DELETE behavior

12:43:38 <ArnaudLH> ack ruben

Arnaud Le Hors: ack ruben

12:43:43 <SteveS> q+

Steve Speicher: q+

12:43:45 <ArnaudLH> ack david

Arnaud Le Hors: ack david

12:43:45 <Zakim> davidwood, you wanted to remind the WG on PURL's DELETE behavior

Zakim IRC Bot: davidwood, you wanted to remind the WG on PURL's DELETE behavior

12:43:45 <ericP> +1 to not saying anything about re-use

Eric Prud'hommeaux: +1 to not saying anything about re-use

12:44:06 <cygri> davidwood: There are legitimate reasons why a server may not re-use a URL.

David Wood: There are legitimate reasons why a server may not re-use a URL.

12:44:14 <cygri> ... Example, pURLs.

... Example, pURLs.

12:44:31 <cygri> ... I strongly recommend we close this issue by stating that servers decide.

... I strongly recommend we close this issue by stating that servers decide.

12:44:38 <Ashok_Malhotra> q+

Ashok Malhotra: q+

12:44:58 <betehess> q+ to offer dev perspective

Alexandre Bertails: q+ to offer dev perspective

12:45:08 <ahaller2> q+

Armin Haller: q+

12:45:09 <cygri> ... I have a minor preference for including a sentence that states it's up to the server whether deleted URIs can be recycled.

... I have a minor preference for including a sentence that states it's up to the server whether deleted URIs can be recycled.

12:45:15 <ArnaudLH> ack steves

Arnaud Le Hors: ack steves

12:45:16 <SteveBattle> q+

Steve Battle: q+

12:45:38 <ArnaudLH> ack steves

Arnaud Le Hors: ack steves

12:45:40 <cygri> SteveS: Agree, it's application-specific. I also agree it's not a best practice.

Steve Speicher: Agree, it's application-specific. I also agree it's not a best practice.

12:45:43 <ArnaudLH> ack ashok

Arnaud Le Hors: ack ashok

12:46:05 <Ruben> my main issue was the phrasing, which currently is "until another resource is created", as "another" seems to suggest that it can't be the same

Ruben Verborgh: my main issue was the phrasing, which currently is "until another resource is created", as "another" seems to suggest that it can't be the same

12:46:10 <cygri> Ashok_Malhotra: Reading 4.5.1 in the spec, it reads like you cannot re-use a URI

Ashok Malhotra: Reading 4.5.1 in the spec, it reads like you cannot re-use a URI

12:46:17 <timbl> q+ to say that is a URI has been automatically allocated by the server then it should NEVER EVER be re-used after having been deleted, to avoid people following an old link to new bad data.

Tim Berners-Lee: q+ to say that is a URI has been automatically allocated by the server then it should NEVER EVER be re-used after having been deleted, to avoid people following an old link to new bad data.

12:46:27 <cygri> davidwood: [quotes offending spec text]

David Wood: [quotes offending spec text]

12:46:35 <AndyS> q+ to wonder about implications on containers and adding entries

Andy Seaborne: q+ to wonder about implications on containers and adding entries

12:46:52 <cygri> ... When you create a resource in a container, the server assigns a URI. Server may decide to re-use an existing URI.

... When you create a resource in a container, the server assigns a URI. Server may decide to re-use an existing URI.

12:46:57 <Ruben> I agree with timbl that non-reuse should be that way to go… or we should at least suggest it

Ruben Verborgh: I agree with timbl that non-reuse should be that way to go… or we should at least suggest it

12:47:14 <ahaller2> q-

Armin Haller: q-

12:47:17 <cygri> q?

q?

12:47:41 <cygri> timbl: If a resource was deleted, it's URI should never ever be re-used.

Tim Berners-Lee: If a resource was deleted, it's URI should never ever be re-used.

12:47:54 <davidwood> q+ to disagree with Tim.

David Wood: q+ to disagree with Tim.

12:48:05 <ArnaudLH> ack bete

Arnaud Le Hors: ack bete

12:48:05 <Zakim> betehess, you wanted to offer dev perspective

Zakim IRC Bot: betehess, you wanted to offer dev perspective

12:48:06 <AndyS> test -- what about re-PUTing the same content as before?

Andy Seaborne: test -- what about re-PUTing the same content as before?

12:48:25 <ericP> vulnerable to the lost-DELETE variant of the lost-UPDATE problem

Eric Prud'hommeaux: vulnerable to the lost-DELETE variant of the lost-UPDATE problem

12:48:25 <oberger> q+ to discuss whether this is linked to issue 25

Olivier Berger: q+ to discuss whether this is linked to ISSUE-25

12:48:57 <ArnaudLH> ack steveb

Arnaud Le Hors: ack steveb

12:49:02 <Ruben>  side-remark: can be reused for the same resource? (e.g., not 410)

Ruben Verborgh: side-remark: can be reused for the same resource? (e.g., not 410)

12:49:07 <ericP> party A GETs R1; party B DELETEs R1; party A PUTs R1.

Eric Prud'hommeaux: party A GETs R1; party B DELETEs R1; party A PUTs R1.

12:49:17 <cygri> SteveBattle: I agree we should delete 4.5.1 phrasing “until another resource is created”

Steve Battle: I agree we should delete 4.5.1 phrasing “until another resource is created”

12:49:21 <ericP> (not a real issue if you are tracking ETags well)

Eric Prud'hommeaux: (not a real issue if you are tracking ETags well)

12:49:30 <betehess> when people say "application", is it server-side or client-side?

Alexandre Bertails: when people say "application", is it server-side or client-side?

12:49:32 <ArnaudLH> ack timbl

Arnaud Le Hors: ack timbl

12:49:32 <cygri> ... There may be valid reasons for restoring a deleted resource

... There may be valid reasons for restoring a deleted resource

12:49:32 <Zakim> timbl, you wanted to say that is a URI has been automatically allocated by the server then it should NEVER EVER be re-used after having been deleted, to avoid people following an

Zakim IRC Bot: timbl, you wanted to say that is a URI has been automatically allocated by the server then it should NEVER EVER be re-used after having been deleted, to avoid people following an

12:49:33 <Ruben> ericP: indeed, that should be possible for the *same* resource

Eric Prud'hommeaux: indeed, that should be possible for the *same* resource [ Scribe Assist by Ruben Verborgh ]

12:49:35 <Zakim> ... old link to new bad data.

Zakim IRC Bot: ... old link to new bad data.

12:49:47 <ArnaudLH> ack andy

Arnaud Le Hors: ack andy

12:49:47 <Zakim> AndyS, you wanted to wonder about implications on containers and adding entries

Zakim IRC Bot: AndyS, you wanted to wonder about implications on containers and adding entries

12:50:08 <cygri> q+

q+

12:50:40 <ArnaudLH> ack david

Arnaud Le Hors: ack david

12:50:40 <Zakim> davidwood, you wanted to disagree with Tim.

Zakim IRC Bot: davidwood, you wanted to disagree with Tim.

12:50:44 <oberger> q-

Olivier Berger: q-

12:51:25 <cygri> timbl: [clarifies that *server*-assigned URIs should never be re-used after deleting]

Tim Berners-Lee: [clarifies that *server*-assigned URIs should never be re-used after deleting]

12:51:33 <AndyS> Some resources e.g. "todays weather" can be reasonably deleted and then PUT.

Andy Seaborne: Some resources e.g. "todays weather" can be reasonably deleted and then PUT.

12:51:36 <webr3> q+ to say 4.5 HTTP DELETE should say something about If-Match ETags, and to +1 @ericP's suggestion to replace "until another resource is created or associated with the same Request-URI." with "The service SHOULD NOT permit the creation of a different resource with the same Request-URI."

Nathan Rixham: q+ to say 4.5 HTTP DELETE should say something about If-Match ETags, and to +1 @ericP's suggestion to replace "until another resource is created or associated with the same Request-URI." with "The service SHOULD NOT permit the creation of a different resource with the same Request-URI."

12:51:37 <betehess> I believe that timbl is restricting his definition to the case we POST to a Container, right?

Alexandre Bertails: I believe that timbl is restricting his definition to the case we POST to a Container, right?

12:51:59 <bblfish> agree with AndyS that corner cases ( such as undelete ) should be explained as a best practice

Henry Story: agree with AndyS that corner cases ( such as undelete ) should be explained as a best practice

12:52:05 <cygri> davidwood: I suggested earlier that clients should be able to request a certain URI

David Wood: I suggested earlier that clients should be able to request a certain URI

12:52:12 <Ruben> is there a way to stop clients from not reusing for different resoruces, in case POST is not used?

Ruben Verborgh: is there a way to stop clients from not reusing for different resources, in case POST is not used?

12:52:20 <Ruben> s/resoruces/resources/
12:52:33 <cygri> ... If the server needs to track what resources were allocated and deleted, this makes it harder to create a minimal compliant server

... If the server needs to track what resources were allocated and deleted, this makes it harder to create a minimal compliant server

12:52:40 <Ruben> q+

Ruben Verborgh: q+

12:52:43 <AndyS> agree about server assigned URIs ... but rePUT the original content (it's called "restore" :-) or a correction.

Andy Seaborne: agree about server assigned URIs ... but rePUT the original content (it's called "restore" :-) or a correction.

12:52:59 <Ruben> q+ to say that recreating the *same* resource is not a problem

Ruben Verborgh: q+ to say that recreating the *same* resource is not a problem

12:53:11 <cygri> ... Seen in the wild: create a resource, delete it, create it again; because deleting causes housekeeping in the server

... Seen in the wild: create a resource, delete it, create it again; because deleting causes housekeeping in the server

12:53:30 <ArnaudLH> ack cygri

Arnaud Le Hors: ack cygri

12:53:35 <sandro> +1 davidwood allow clients to DELETE and PUT again

Sandro Hawke: +1 davidwood allow clients to DELETE and PUT again

12:53:45 <ericP> cygri: we're defining a protocol between a client and a server

Richard Cyganiak: we're defining a protocol between a client and a server [ Scribe Assist by Eric Prud'hommeaux ]

12:54:23 <ericP> ... it's important to specify client expectations but not [other] server behavior

Eric Prud'hommeaux: ... it's important to specify client expectations but not [other] server behavior

12:54:29 <bblfish> q+

Henry Story: q+

12:54:45 <ericP> ... i see this as a best practice about server behavior

Eric Prud'hommeaux: ... i see this as a best practice about server behavior

12:54:48 <sandro> cygri: I agree with Tim that servers should not generate the same URI twice, but I don't think that's part of the protocol

Richard Cyganiak: I agree with Tim that servers should not generate the same URI twice, but I don't think that's part of the protocol [ Scribe Assist by Sandro Hawke ]

12:54:49 <AndyS> +1 to ruben : *same* resource / *different* resource is the key point.  Can't mandate in the protocol about such "sameness". Having advice in docs is *very* helpful.

Andy Seaborne: +1 to ruben : *same* resource / *different* resource is the key point. Can't mandate in the protocol about such "sameness". Having advice in docs is *very* helpful.

12:54:59 <betehess> as an implementor, I'd like to know the expected behaviour

Alexandre Bertails: as an implementor, I'd like to know the expected behaviour

12:55:09 <cygri> timbl: I request a new URI, I want it to be never used before. That's part of the protocol

Tim Berners-Lee: I request a new URI, I want it to be never used before. That's part of the protocol

12:55:11 <bblfish> nathan? on the phone?

Henry Story: nathan? on the phone?

12:55:15 <webr3> q-

Nathan Rixham: q-

12:55:17 <AndyS> webr3?

Andy Seaborne: webr3?

12:55:17 <webr3> no phone

Nathan Rixham: no phone

12:55:27 <ArnaudLH> q?

Arnaud Le Hors: q?

12:55:33 <betehess> s|webr3?||

Alexandre Bertails: s|webr3?||

12:55:36 <ArnaudLH> ack ruben

Arnaud Le Hors: ack ruben

12:55:36 <Zakim> Ruben, you wanted to say that recreating the *same* resource is not a problem

Zakim IRC Bot: Ruben, you wanted to say that recreating the *same* resource is not a problem

12:55:41 <betehess> s|no phone||

Alexandre Bertails: s|no phone||

12:55:42 <sandro> timbl: I want part of the protocol to be that servers will generate new unique URIs each time

Tim Berners-Lee: I want part of the protocol to be that servers will generate new unique URIs each time [ Scribe Assist by Sandro Hawke ]

12:55:49 <betehess> s|nathan? on the phone?||

Alexandre Bertails: s|nathan? on the phone?||

12:55:51 <ericP> timbl: i disagree that this isn't in the protocol [i.e. client expecation]

Tim Berners-Lee: i disagree that this isn't in the protocol [i.e. client expecation] [ Scribe Assist by Eric Prud'hommeaux ]

12:55:58 <ArnaudLH> q?

Arnaud Le Hors: q?

12:55:59 <cygri> Ruben: There's a difference between using re-using a URI for the same resource, and using same URI for a different one

Ruben Verborgh: There's a difference between using re-using a URI for the same resource, and using same URI for a different one

12:56:11 <ArnaudLH> ack bblfish

Arnaud Le Hors: ack bblfish

12:56:20 <JohnArwe> @webr3, same #s we use for weekly calls

John Arwe: @webr3, same #s we use for weekly calls

12:56:24 <timbl> q+ to say this IS a portico issue:  when the client adds a new resource and server end an id, it is a valuable property of the protocol that the client knows that URI will never be issued to her or anyone else, even if she gives it back.

Tim Berners-Lee: q+ to say this IS a protocol issue: when the client adds a new resource and server end an id, it is a valuable property of the protocol that the client knows that URI will never be issued to her or anyone else, even if she gives it back.

12:56:28 <timbl> q-

Tim Berners-Lee: q-

12:56:32 <betehess> s|@webr3, same #s we use for weekly calls||

Alexandre Bertails: s|@webr3, same #s we use for weekly calls||

12:56:43 <cygri> bblfish: The container part of the spec should say that POST gives you a new URI. If it's not fresh, it's not a new one.

Henry Story: The container part of the spec should say that POST gives you a new URI. If it's not fresh, it's not a new one.

12:56:59 <davidwood> s/portico/protocol/
12:57:12 <ericP> q+ to say that webr appears had proposed text

Eric Prud'hommeaux: q+ to say that webr appears had proposed text

12:57:17 <Ruben> +q to say I'm against just removing

Ruben Verborgh: +q to say I'm against just removing

12:57:19 <antonis> q+

Antonis Loizou: q+

12:57:45 <cygri> ericP: [reads earlier webr3 comment]

Eric Prud'hommeaux: [reads earlier webr3 comment]

12:57:46 <davidwood> +1 to Ruben. Removing the text is not sufficient.

David Wood: +1 to Ruben. Removing the text is not sufficient.

12:58:03 <ArnaudLH> PROPOSAL: delete "until another resource is created or associated with the same Request-URI."

PROPOSED: delete "until another resource is created or associated with the same Request-URI."

12:58:26 <Ruben> -1 for just deleting, need to clarify what is possible

Ruben Verborgh: -1 for just deleting, need to clarify what is possible

12:58:43 <sandro> -1 agreed; I want a change proposal, not just to remove it

Sandro Hawke: -1 agreed; I want a change proposal, not just to remove it

12:58:48 <davidwood> -1 to just removing

David Wood: -1 to just removing

12:58:54 <HadleyBeeman> *wonders if this issue goes back to the old discussion about whether a URI refers to one and only one thing.

Hadley Beeman: *wonders if this issue goes back to the old discussion about whether a URI refers to one and only one thing.

12:59:11 <davidwood> HadleyBeeman, yes.

David Wood: HadleyBeeman, yes.

12:59:16 <ArnaudLH> q?

Arnaud Le Hors: q?

12:59:17 <timbl> The server MUST never reallocate the same server-allocated URI twice.  The client should nor use the same client-generated URI to refer to different things.

Tim Berners-Lee: The server MUST never reallocate the same server-allocated URI twice. The client should not use the same client-generated URI to refer to different things.

12:59:28 <sandro> s/nor/not
12:59:37 <ericP> ack me

Eric Prud'hommeaux: ack me

12:59:38 <oberger> do we need a "compare" primitive in the servers to be able to determine resource "sameness" ?

Olivier Berger: do we need a "compare" primitive in the servers to be able to determine resource "sameness" ?

12:59:38 <Zakim> ericP, you wanted to say that webr appears had proposed text

Zakim IRC Bot: ericP, you wanted to say that webr appears had proposed text

12:59:40 <HadleyBeeman> Thanks, davidwood. Pieces falling together :)

Hadley Beeman: Thanks, davidwood. Pieces falling together :)

12:59:48 <roger> in my experience, there is a very limited number of cases for using DELETE. once something exists, i think it is good to know later on that it did once exist

Roger Menday: in my experience, there is a very limited number of cases for using DELETE. once something exists, i think it is good to know later on that it did once exist

12:59:54 <cygri> [scribe fail]

[scribe fail]

13:00:02 <roger> not that it changes the issue ...

Roger Menday: not that it changes the issue ...

13:00:26 <ArnaudLH> ack eric

Arnaud Le Hors: ack eric

13:00:29 <SteveS> q+

Steve Speicher: q+

13:00:33 <ArnaudLH> ack ruben

Arnaud Le Hors: ack ruben

13:00:33 <Zakim> Ruben, you wanted to say I'm against just removing

Zakim IRC Bot: Ruben, you wanted to say I'm against just removing

13:00:49 <sandro> q+

Sandro Hawke: q+

13:00:52 <cygri> q+ to say you can't PUT a resource

q+ to say you can't PUT a resource

13:01:20 <sandro> +1 cygri, you can't delete a resource

Sandro Hawke: +1 cygri, you can't delete a resource

13:01:22 <Ruben> q-

Ruben Verborgh: q-

13:01:22 <ArnaudLH> ack antonis

Arnaud Le Hors: ack antonis

13:01:27 <nmihindu> q+

Nandana Mihindukulasooriya: q+

13:01:32 <betehess> q+

Alexandre Bertails: q+

13:01:55 <cygri> antonis: Two separate cases. 1. Remove a resoruce from a container, forever. 2. We want to change a resource, e.g., weather

Antonis Loizou: Two separate cases. 1. Remove a resoruce from a container, forever. 2. We want to change a resource, e.g., weather

13:02:21 <sandro> how could you know you'll never want to put a resource back into a container?

Sandro Hawke: how could you know you'll never want to put a resource back into a container?

13:02:26 <bblfish> q+

Henry Story: q+

13:02:31 <svillata> q?

Serena Villata: q?

13:02:37 <ArnaudLH> ack steves

Arnaud Le Hors: ack steves

13:02:41 <Ruben> " a resource R is a temporally varying membership function MR(t), which for time t maps to a set of entities, or values, which are equivalent."

Ruben Verborgh: " a resource R is a temporally varying membership function MR(t), which for time t maps to a set of entities, or values, which are equivalent."

13:02:41 <bblfish> I'd be for voting on deleting. It's easier

Henry Story: I'd be for voting on deleting. It's easier

13:03:01 <Ruben> "Some resources are static in the sense that, when examined at any time after their creation, they always correspond to the same value set. Others have a high degree of variance in their value over time. The only thing that is required to be static for a resource is the semantics of the mapping, since the semantics is what distinguishes one resource from another."

Ruben Verborgh: "Some resources are static in the sense that, when examined at any time after their creation, they always correspond to the same value set. Others have a high degree of variance in their value over time. The only thing that is required to be static for a resource is the semantics of the mapping, since the semantics is what distinguishes one resource from another."

13:03:21 <ericP> q?

Eric Prud'hommeaux: q?

13:03:30 <JohnArwe> +1 ruben

John Arwe: +1 ruben

13:03:32 <bblfish> but how can you delete a methematical object?

Henry Story: but how can you delete a methematical object?

13:03:39 <ArnaudLH> ack sandro

Arnaud Le Hors: ack sandro

13:03:51 <davidwood> timbl made a proposal that may have become lost. "The server MUST never reallocate the same server-allocated URI twice.  The client SHOULD NOT use the same client-generated URI to refer to different things."

David Wood: timbl made a proposal that may have become lost. "The server MUST never reallocate the same server-allocated URI twice. The client SHOULD NOT use the same client-generated URI to refer to different things."

13:03:59 <Ruben> bblfish: you can delete it from a server

Henry Story: you can delete it from a server [ Scribe Assist by Ruben Verborgh ]

13:04:40 <cygri> sandro: You delete a file in the file system, you can create a new one with the same name. Anything else would be absurd

Sandro Hawke: You delete a file in the file system, you can create a new one with the same name. Anything else would be absurd

13:04:48 <bblfish> yes, but the resource is the thing pointed by the URI.

Henry Story: yes, but the resource is the thing pointed by the URI.

13:05:01 <cygri> oberger: A directory is a container. It's happening in the container.

Olivier Berger: A directory is a container. It's happening in the container.

13:05:08 <antonis> q+

Antonis Loizou: q+

13:05:12 <ArnaudLH> ack cygri

Arnaud Le Hors: ack cygri

13:05:13 <Zakim> cygri, you wanted to say you can't PUT a resource

Zakim IRC Bot: cygri, you wanted to say you can't PUT a resource

13:05:14 <cygri> sandro: Deleting in file system is same as HTTP delete

Sandro Hawke: Deleting in file system is same as HTTP delete

13:05:26 <betehess> cygri: maybe we shouldn't be talking about identity of resource

Richard Cyganiak: maybe we shouldn't be talking about identity of resource [ Scribe Assist by Alexandre Bertails ]

13:05:31 <betehess> ... rather what happens to the container

Alexandre Bertails: ... rather what happens to the container

13:05:45 <betehess> ... was URI assigned to the server?

Alexandre Bertails: ... was URI assigned to the server?

13:05:50 <ericP> cygri: we SHOULDn't be talking about DELETing a resource but instead POSTing to a container

Richard Cyganiak: we SHOULDn't be talking about DELETing a resource but instead POSTing to a container [ Scribe Assist by Eric Prud'hommeaux ]

13:05:50 <sandro> oberger, I'm not thinking about containers here.

Sandro Hawke: oberger, I'm not thinking about containers here.

13:05:51 <bblfish> cygri: one should not talk about what one should do when one deletes a resource, but what should be done when one POSTs to a container

Richard Cyganiak: one should not talk about what one should do when one deletes a resource, but what should be done when one POSTs to a container [ Scribe Assist by Henry Story ]

13:05:54 <bblfish> +1

Henry Story: +1

13:05:57 <SteveBattle> +1

Steve Battle: +1

13:06:08 <svillata> +1

Serena Villata: +1

13:06:08 <betehess> ... what's the constraint on the server?

Alexandre Bertails: ... what's the constraint on the server?

13:06:12 <sandro> +1

Sandro Hawke: +1

13:06:12 <oberger> verbs CREATE and ADD TO CONTAINER should really be distinguished

Olivier Berger: verbs CREATE and ADD TO CONTAINER should really be distinguished

13:06:13 <ericP> ... timbl asked about the constraint on the server and the server assigns the URI

Eric Prud'hommeaux: ... timbl asked about the constraint on the server and the server assigns the URI

13:06:20 <ArnaudLH> q?

Arnaud Le Hors: q?

13:06:24 <svillata> q?

Serena Villata: q?

13:06:31 <SteveBattle> The constraint is to not generate the same URI twice

Steve Battle: The constraint is to not generate the same URI twice

13:06:31 <ericP> ... that's the place were we can state more clearly what happens with these URIs

Eric Prud'hommeaux: ... that's the place were we can state more clearly what happens with these URIs

13:06:33 <ArnaudLH> ack nmihindu

Arnaud Le Hors: ack nmihindu

13:06:49 <cygri> nmihindu: Putting in the spec that it must be the same entity/resource is practically infeasible.

Nandana Mihindukulasooriya: Putting in the spec that it must be the same entity/resource is practically infeasible.

13:06:50 <ahaller2> q+

Armin Haller: q+

13:06:55 <SteveS> Trying to establish a basic model if resource URI used to get, update, then if deleted, you would not expect to update a resource that does not exist.  Semantics may be that put can be used to create resources of a known name, which is not update in my mind

Steve Speicher: Trying to establish a basic model if resource URI used to get, update, then if deleted, you would not expect to update a resource that does not exist. Semantics may be that put can be used to create resources of a known name, which is not update in my mind

13:06:55 <ArnaudLH> ack bete

Arnaud Le Hors: ack bete

13:06:57 <timbl> q?

Tim Berners-Lee: q?

13:07:25 <Ruben> …unless it's a 410, then you know it existed at some time

Ruben Verborgh: …unless it's a 410, then you know it existed at some time

13:07:33 <cygri> betehess: I would expect the invariant from the server that after I GET and get a 404, I can do a PUT and create the resource.

Alexandre Bertails: I would expect the invariant from the server that after I GET and get a 404, I can do a PUT and create the resource.

13:07:44 <cygri> ... We don't know if the resource existed before or not.

... We don't know if the resource existed before or not.

13:07:56 <ArnaudLH> ack bblfish

Arnaud Le Hors: ack bblfish

13:08:30 <cygri> bblfish: If you do a DELETE and the client gets a 404, shouldn't clients put this in an index of things they never should request again?

Henry Story: If you do a DELETE and the client gets a 404, shouldn't clients put this in an index of things they never should request again?

13:08:33 <Ruben> 404 doesn't imply permanency… can be 404 before a resource was created

Ruben Verborgh: 404 doesn't imply permanency… can be 404 before a resource was created

13:08:43 <JohnArwe> q+ security and debug considerations

John Arwe: q+ security and debug considerations

13:08:48 <ericP> bblfish is getting into the contentious space of negative directory caching

Eric Prud'hommeaux: bblfish is getting into the contentious space of negative directory caching

13:08:55 <JohnArwe> q+

John Arwe: q+

13:09:01 <cygri> BartvanLeeuwen: Isn't there another code for that?

Bart van Leeuwen: Isn't there another code for that?

13:09:04 <cygri> ericP: 410

Eric Prud'hommeaux: 410

13:09:05 <ArnaudLH> ack antonis

Arnaud Le Hors: ack antonis

13:09:09 <ericP> (which was a bane of AFS)

Eric Prud'hommeaux: (which was a bane of AFS)

13:09:24 <sandro> http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.htmlhttp://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

Sandro Hawke: http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.htmlhttp://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

13:09:39 <sandro> "10.4.11 410 Gone

Sandro Hawke: "10.4.11 410 Gone

13:09:39 <sandro> The requested resource is no longer available at the server and no forwarding address is known. This condition is expected to be considered permanent."

Sandro Hawke: The requested resource is no longer available at the server and no forwarding address is known. This condition is expected to be considered permanent."

13:09:40 <Ruben> the 404 can include a reason

Ruben Verborgh: the 404 can include a reason

13:09:44 <cygri> antonis: There are two different modes for deletion. Sometimes there's scientific data that is invalid, we want to really delete it. 404 is not strong enough.

Antonis Loizou: There are two different modes for deletion. Sometimes there's scientific data that is invalid, we want to really delete it. 404 is not strong enough.

13:09:49 <cygri> q+

q+

13:09:50 <ArnaudLH> ack ahaller

Arnaud Le Hors: ack ahaller

13:09:53 <bblfish> yes, thanks. for the 410

Henry Story: yes, thanks. for the 410

13:10:13 <sandro> zakim, who is on the call?

Sandro Hawke: zakim, who is on the call?

13:10:13 <Zakim> On the phone I see St_Clair_3B, JohnArwe, AndyS

Zakim IRC Bot: On the phone I see St_Clair_3B, JohnArwe, AndyS

13:10:13 <betehess> 410 looks like a difficult constraint to impose in the general case

Alexandre Bertails: 410 looks like a difficult constraint to impose in the general case

13:10:33 <betehess> probably good practice

Alexandre Bertails: probably good practice

13:11:42 <oberger> q+ suggesting we should we discuss creation and ownership by containers

Olivier Berger: q+ suggesting we should we discuss creation and ownership by containers

13:11:45 <bblfish> bad practice has a cost

Henry Story: bad practice has a cost

13:12:04 <bblfish> q?

Henry Story: q?

13:12:18 <oberger> q+, suggesting we should we discuss creation and ownership by containers

Olivier Berger: q+, suggesting we should we discuss creation and ownership by containers

13:12:24 <oberger> wth

Olivier Berger: wth

13:12:25 <oberger> q+

Olivier Berger: q+

13:12:30 <Ruben> *oberger, say q+ to blabla*

Ruben Verborgh: *oberger, say q+ to blabla*

13:12:41 <Ruben> *the "to" is important*

Ruben Verborgh: *the "to" is important*

13:12:53 <betehess> s|wth||

Alexandre Bertails: s|wth||

13:13:02 <betehess> s|q+, suggesting we should we discuss creation and ownership by containers||

Alexandre Bertails: s|q+, suggesting we should we discuss creation and ownership by containers||

13:13:05 <cygri> ahaller2: Example: server uses hash function to generate URI. Can't guarantee that you get a clash

Armin Haller: Example: server uses hash function to generate URI. Can't guarantee that you get a clash

13:13:06 <betehess> s|q+ suggesting we should we discuss creation and ownership by containers||

Alexandre Bertails: s|q+ suggesting we should we discuss creation and ownership by containers||

13:13:15 <cygri> timbl: That server will be statistically conforming

Tim Berners-Lee: That server will be statistically conforming

13:13:16 <ArnaudLH> ack john

Arnaud Le Hors: ack john

13:13:59 <cygri> JohnArwe: Whether today's weather can be deleted depends on the concept on the server.

John Arwe: Whether today's weather can be deleted depends on the concept on the server.

13:14:04 <sandro> q+ to suggest PROPOSED: Close issue-24, saying "No", after a resource is deleted it might come back, in some circumstances.   If the URI was created by a client PUT, then it's reasonable for a client to DELETE it, then PUT again to re-create it.

Sandro Hawke: q+ to suggest PROPOSED: Close ISSUE-24, saying "No", after a resource is deleted it might come back, in some circumstances. If the URI was created by a client PUT, then it's reasonable for a client to DELETE it, then PUT again to re-create it.

13:14:32 <cygri> ... In loosely coupled environment, 410 is useful

... In loosely coupled environment, 410 is useful

13:15:01 <timbl> (cygri, yes the server operator of one which generates large random numbers can afford to buy everyone a round of drinks if they collide.    But it is very easy to keep a little .nextid file in the directory and use it to track the next id to allocate.)

Tim Berners-Lee: (cygri, yes the server operator of one which generates large random numbers can afford to buy everyone a round of drinks if they collide. But it is very easy to keep a little .nextid file in the directory and use it to track the next id to allocate.)

13:15:33 <Ruben> sandro: remember the title was a bit of a misnomer, the actual question is whether, after deletion, we should suggest to reuse the same URI for a different resource

Sandro Hawke: remember the title was a bit of a misnomer, the actual question is whether, after deletion, we should suggest to reuse the same URI for a different resource [ Scribe Assist by Ruben Verborgh ]

13:15:48 <bblfish> thanks

Henry Story: thanks

13:15:52 <ArnaudLH> ack cygri

Arnaud Le Hors: ack cygri

13:16:14 <ericP> q+ to say that sandro's discovery has pushed me to amend web3r's text

Eric Prud'hommeaux: q+ to say that sandro's discovery has pushed me to amend web3r's text

13:17:10 <ericP> cygri: we seem to mostly agree that if a client doesn't know the server's DELETE policy, and the server returns a 404 or 410, the file MIGHT come back

Richard Cyganiak: we seem to mostly agree that if a client doesn't know the server's DELETE policy, and the server returns a 404 or 410, the file MIGHT come back [ Scribe Assist by Eric Prud'hommeaux ]

13:17:22 <ericP> ... the filesystem analogy is compelling to me

Eric Prud'hommeaux: ... the filesystem analogy is compelling to me

13:17:39 <ericP> ... i agree that server-assigned IDs should only be assigned once

Eric Prud'hommeaux: ... i agree that server-assigned IDs should only be assigned once

13:17:45 <Ashok_Malhotra> q?

Ashok Malhotra: q?

13:17:59 <sandro> cygri: I see that server-assigned IDs should not be re-assigned.    that's likely to cause problems.    let's address that in POST-to-Container text

Richard Cyganiak: I see that server-assigned IDs should not be re-assigned. that's likely to cause problems. let's address that in POST-to-Container text [ Scribe Assist by Sandro Hawke ]

13:18:03 <ericP> ... POST->ID/1 ; POST->ID/1  will of course create problems

Eric Prud'hommeaux: ... POST->ID/1 ; POST->ID/1 will of course create problems

13:18:12 <ericP> ... that's two issues to resolve

Eric Prud'hommeaux: ... that's two issues to resolve

13:18:16 <Ruben> betehess: this is not REST, but Cool URIs

Alexandre Bertails: this is not REST, but Cool URIs [ Scribe Assist by Ruben Verborgh ]

13:18:27 <sandro> q?

Sandro Hawke: q?

13:18:39 <ericP> ... third issue: different expecations if the server returns a 404 or a 410

Eric Prud'hommeaux: ... third issue: different expecations if the server returns a 404 or a 410

13:18:48 <bblfish> q?

Henry Story: q?

13:19:12 <ericP> ... the HTTP spec says that 410 is permanent, but doesn't say if the client is not supposed to do a PUT

Eric Prud'hommeaux: ... the HTTP spec says that 410 is permanent, but doesn't say if the client is not supposed to do a PUT

13:19:22 <betehess> ack ober

Alexandre Bertails: ack ober

13:19:23 <Zakim> +[IPcaller]

Zakim IRC Bot: +[IPcaller]

13:19:54 <cygri> oberger: If we haven't properly discussed creation, then we can't properly discuss deletion. We should discuss ISSUE-25 first.

Olivier Berger: If we haven't properly discussed creation, then we can't properly discuss deletion. We should discuss ISSUE-25 first.

13:20:01 <sandro> q?

Sandro Hawke: q?

13:20:09 <Ashok_Malhotra> ack next

Ashok Malhotra: ack next

13:20:10 <Zakim> sandro, you wanted to suggest PROPOSED: Close issue-24, saying "No", after a resource is deleted it might come back, in some circumstances.   If the URI was created by a client

Zakim IRC Bot: sandro, you wanted to suggest PROPOSED: Close ISSUE-24, saying "No", after a resource is deleted it might come back, in some circumstances. If the URI was created by a client

13:20:10 <Zakim> ... PUT, then it's reasonable for a client to DELETE it, then PUT again to re-create it.

Zakim IRC Bot: ... PUT, then it's reasonable for a client to DELETE it, then PUT again to re-create it.

13:20:18 <ArnaudLH> q?

Arnaud Le Hors: q?

13:20:46 <betehess> -1 to say that much

Alexandre Bertails: -1 to say that much

13:21:02 <betehess> we would overstep on the http spec

Alexandre Bertails: we would overstep on the http spec

13:21:14 <svillata> q?

Serena Villata: q?

13:21:23 <ericP> - until another resource is created or associated with the same Request-URI.

Eric Prud'hommeaux: - until another resource is created or associated with the same Request-URI.

13:21:23 <ericP> + . The service SHOULD NOT permit the creation of a different resource with the same Request-URI.

Eric Prud'hommeaux: + . The service SHOULD NOT permit the creation of a different resource with the same Request-URI.

13:21:26 <ericP> + Note that HTTP considers any DELETEd resource for which the server returns a 410 Gone to be permanently removed.

Eric Prud'hommeaux: + Note that HTTP considers any DELETEd resource for which the server returns a 410 Gone to be permanently removed.

13:21:29 <ericP> + A server SHOULD (@@MUST?) NOT permit either a later PUT to a POST to re-create such a resource.

Eric Prud'hommeaux: + A server SHOULD (@@MUST?) NOT permit either a later PUT to a POST to re-create such a resource.

13:21:33 <betehess> q+

Alexandre Bertails: q+

13:22:02 <Zakim> -AndyS

Zakim IRC Bot: -AndyS

13:22:37 <bblfish> q?

Henry Story: q?

13:22:42 <bblfish> q+

Henry Story: q+

13:22:44 <ericP> + . The service SHOULD NOT create (as a response to a POST) of a different resource with the same Request-URI.

Eric Prud'hommeaux: + . The service SHOULD NOT create (as a response to a POST) of a different resource with the same Request-URI.

13:22:44 <betehess> ack eric

Alexandre Bertails: ack eric

13:22:44 <Zakim> ericP, you wanted to say that sandro's discovery has pushed me to amend web3r's text

Zakim IRC Bot: ericP, you wanted to say that sandro's discovery has pushed me to amend web3r's text

13:22:49 <ericP> + . The service SHOULD NOT create (as a response to a POST) a different resource with the same Request-URI.

Eric Prud'hommeaux: + . The service SHOULD NOT create (as a response to a POST) a different resource with the same Request-URI.

13:23:13 <timbl> You can't say "a different resource"

Tim Berners-Lee: You can't say "a different resource"

13:23:21 <sandro>  thinking: PROPOSED: Close issue-24, saying "No", after a resource is deleted it might come back, in some circumstances.   For example, If the URI was allocated by a client PUT, then it's reasonable for a client to do a DELETE on that URI, then PUT again with the same URI to re-allocated it.

Sandro Hawke: thinking: PROPOSED: Close ISSUE-24, saying "No", after a resource is deleted it might come back, in some circumstances. For example, If the URI was allocated by a client PUT, then it's reasonable for a client to do a DELETE on that URI, then PUT again with the same URI to re-allocated it.

13:23:27 <sandro> q+

Sandro Hawke: q+

13:23:39 <bblfish> q-

Henry Story: q-

13:23:39 <ericP> + . The service SHOULD NOT create (as a response to a POST to the Request-URI's container) a different resource with the same Request-URI.

Eric Prud'hommeaux: + . The service SHOULD NOT create (as a response to a POST to the Request-URI's container) a different resource with the same Request-URI.

13:23:55 <cygri> q+

q+

13:24:08 <cygri> q-

q-

13:24:14 <timbl> The server should never allocate the same URI twice in response to a POST to a container.

Tim Berners-Lee: The server should never allocate the same URI twice in response to a POST to a container.

13:24:25 <sandro>  thinking: PROPOSED: Close issue-24 (Should DELETED resources remain deleted?)  saying "Not Necessaril", after a resource is deleted it might come back, in some circumstances.   For example, If the URI was allocated by a client PUT, then it's reasonable for a client to do a DELETE on that URI, then PUT again with the same URI to re-allocated it.

Sandro Hawke: thinking: PROPOSED: Close ISSUE-24 (Should DELETED resources remain deleted?) saying "Not Necessaril", after a resource is deleted it might come back, in some circumstances. For example, If the URI was allocated by a client PUT, then it's reasonable for a client to do a DELETE on that URI, then PUT again with the same URI to re-allocated it.

13:25:02 <ericP> scribenick: ericP

(Scribe set to Eric Prud'hommeaux)

13:25:09 <cygri> q+

Richard Cyganiak: q+

13:25:14 <timbl> seconded

Tim Berners-Lee: seconded

13:25:43 <svillata> q?

Serena Villata: q?

13:25:46 <ericP> oberger: do we have a use case to refer to?

Olivier Berger: do we have a use case to refer to?

13:26:03 <ericP> cygri: i think we all know the filesystem use case

Richard Cyganiak: i think we all know the filesystem use case

13:26:09 <bblfish> q?

Henry Story: q?

13:26:33 <ericP> betehess: we have no authority over HTTP

Alexandre Bertails: we have no authority over HTTP

13:26:56 <ericP> sandro: and you know that 404 isn't permanent in HTTP world, right?

Sandro Hawke: and you know that 404 isn't permanent in HTTP world, right?

13:26:56 <ArnaudLH> ack bete

Arnaud Le Hors: ack bete

13:27:22 <sandro> Yves, are you an HTTP expert?

Sandro Hawke: Yves, are you an HTTP expert?

13:27:31 <ericP> betehess: we don't have people can tell us how HTTP is used out there

Alexandre Bertails: we don't have people can tell us how HTTP is used out there

13:28:01 <ericP> timbl: i perfer to treat 404 and 410 just the same

Tim Berners-Lee: i perfer to treat 404 and 410 just the same

13:28:03 <ArnaudLH> ack bete

Arnaud Le Hors: ack bete

13:28:22 <sandro> PROPOSED: Close issue-24 (Should DELETED resources remain deleted?)  saying "Not Necessaril", after a resource is deleted it might come back, in some circumstances.   For example, If the URI was allocated by a client PUT, then it's reasonable for a client to do a DELETE on that URI, then PUT again with the same URI to re-allocated it.

PROPOSED: Close ISSUE-24 (Should DELETED resources remain deleted?) saying "Not necessarily", after a resource is deleted it might come back, in some circumstances. For example, If the URI was allocated by a client PUT, then it's reasonable for a client to do a DELETE on that URI, then PUT again with the same URI to re-allocated it.

13:28:24 <ArnaudLH> ack sandro

Arnaud Le Hors: ack sandro

13:28:36 <ericP> sandro: i'd like to be done with issue 24 and record the fact that we all seem to agree

Sandro Hawke: i'd like to be done with ISSUE-24 and record the fact that we all seem to agree

13:28:43 <SteveBattle> +1

Steve Battle: +1

13:28:58 <davidwood> +1

David Wood: +1

13:29:01 <Ruben> +1

Ruben Verborgh: +1

13:29:02 <SteveS> +1

Steve Speicher: +1

13:29:03 <ericP> +1

+1

13:29:05 <ahaller2> +1

Armin Haller: +1

13:29:06 <BartvanLeeuwen> +1

Bart van Leeuwen: +1

13:29:07 <sandro> +1

Sandro Hawke: +1

13:29:07 <nmihindu> +1

Nandana Mihindukulasooriya: +1

13:29:08 <betehess> +1

Alexandre Bertails: +1

13:29:09 <roger> +1

Roger Menday: +1

13:29:09 <rgarcia> +1

Raúl García Castro: +1

13:29:10 <bblfish> q?

Henry Story: q?

13:29:11 <ArnaudLH> +1

Arnaud Le Hors: +1

13:29:13 <bblfish> q+

Henry Story: q+

13:29:14 <svillata> +1

Serena Villata: +1

13:29:14 <ivan> s/Necessaril/necessarily/
13:29:23 <JohnArwe> +1

John Arwe: +1

13:29:24 <timbl> +1

Tim Berners-Lee: +1

13:29:25 <krp> +1

Kevin Page: +1

13:29:40 <ericP> cygri: i agree, but don't think our spec contains examples of what's already constrained by the HTTP spec

Richard Cyganiak: i agree, but don't think our spec contains examples of what's already constrained by the HTTP spec

13:30:09 <ArnaudLH> ack cygri

Arnaud Le Hors: ack cygri

13:30:13 <ericP> ... if it doesn't further constrain the HTTP spec, we shouldn't include it

... if it doesn't further constrain the HTTP spec, we shouldn't include it

13:30:23 <betehess> would this is normative or informative?

Alexandre Bertails: would this be normative or informative?

13:30:30 <betehess> s/this is/this be/
13:31:06 <ericP> cygri: per this resolution, the spec can remain the same

Richard Cyganiak: per this resolution, the spec can remain the same

13:31:36 <sandro> (temporarily) RESOLVED: Close issue-24 (Should DELETED resources remain deleted?)  saying "Not Necessarily", after a resource is deleted it might come back, in some circumstances.   For example, If the URI was allocated by a client PUT, then it's reasonable for a client to do a DELETE on that URI, then PUT again with the same URI to re-allocated it.

Sandro Hawke: (temporarily) RESOLVED: Close ISSUE-24 (Should DELETED resources remain deleted?) saying "Not Necessarily", after a resource is deleted it might come back, in some circumstances. For example, If the URI was allocated by a client PUT, then it's reasonable for a client to do a DELETE on that URI, then PUT again with the same URI to re-allocated it.

13:31:39 <webr3> remove "until another resource is created or associated with the same Request-URI." replace with something else

Nathan Rixham: remove "until the state of the resource is changed again." replace with something else

13:31:40 <krp> The words "another" and "created" in combination imply something that isn't intende

Kevin Page: The words "another" and "created" in combination imply something that isn't intende

13:31:59 <cygri> s/until another resource is created or associated with the same Request-URI/until the state of the resource is changed again/
13:32:09 <cygri> q+

Richard Cyganiak: q+

13:32:15 <bblfish> q-

Henry Story: q-

13:32:23 <ArnaudLH> ack cygri

Arnaud Le Hors: ack cygri

13:32:34 <rgarcia> +q

Raúl García Castro: +q

13:32:43 <bblfish> q+

Henry Story: q+

13:32:55 <ericP> cygri: PROPOSED: s/until another resource is created or associated with the same Request-URI/until the state of the resource is changed again/

Richard Cyganiak: PROPOSED: s/until another resource is created or associated with the same Request-URI/until the state of the resource is changed again/

13:33:05 <Ruben> +1 on cygri's proposal

Ruben Verborgh: +1 on cygri's proposal

13:33:08 <webr3> -1

Nathan Rixham: -1

13:33:16 <ericP> bblfish: we can include text which describes some of the problems

Henry Story: we can include text which describes some of the problems

13:33:34 <ericP> ... there are all kinds of consequences about changing a 410

... there are all kinds of consequences about changing a 410

13:33:47 <webr3> proposed: s/until another resource is created or associated with the same Request-URI// then have informative text about 404+410 and not cha

PROPOSED: s/until another resource is created or associated with the same Request-URI// then have informative text about 404+410 and not cha

13:33:57 <webr3> .. changing the uri's usage

Nathan Rixham: .. changing the uri's usage

13:34:04 <bblfish> q-

Henry Story: q-

13:34:15 <ArnaudLH> ack rgarcia

Arnaud Le Hors: ack rgarcia

13:34:16 <ericP> ... e.g. if you check the logs and no one's gotten a 410, then no one knows it's gone

... e.g. if you check the logs and no one's gotten a 410, then no one knows it's gone

13:34:48 <oberger> q+ to propose better use cases

Olivier Berger: q+ to propose better use cases

13:34:54 <davidwood> SteveS, I propose removing the phrase and adding a sentence, "Clients should note that severs may reuse a Request-URI under some circumstances."

David Wood: SteveS, I propose removing the phrase and adding a sentence, "Clients should note that severs may reuse a Request-URI under some circumstances."

13:34:56 <ericP> rgarcia: this should be part of the HTTP guide where we say the behavior of this HTTP verb is X

Raúl García Castro: this should be part of the HTTP guide where we say the behavior of this HTTP verb is X

13:34:56 <ArnaudLH> ack oberger

Arnaud Le Hors: ack oberger

13:34:56 <Zakim> oberger, you wanted to propose better use cases

Zakim IRC Bot: oberger, you wanted to propose better use cases

13:35:02 <ericP> oberger: we need use cases

Olivier Berger: we need use cases

13:35:16 <ericP> ... we have different interpretations of HTTP DELETE

... we have different interpretations of HTTP DELETE

13:35:29 <cygri> q+

Richard Cyganiak: q+

13:35:49 <Zakim> +OpenLink_Software

Zakim IRC Bot: +OpenLink_Software

13:35:56 <MacTed> Zakim, OpenLink_Software is temporarily me

Ted Thibodeau: Zakim, OpenLink_Software is temporarily me

13:35:56 <Zakim> +MacTed; got it

Zakim IRC Bot: +MacTed; got it

13:35:58 <MacTed> Zakim, mute me

Ted Thibodeau: Zakim, mute me

13:35:58 <Zakim> MacTed should now be muted

Zakim IRC Bot: MacTed should now be muted

13:35:59 <sandro> q+ to talk about use cases being a sometimes-necessary expense

Sandro Hawke: q+ to talk about use cases being a sometimes-necessary expense

13:36:00 <ArnaudLH> ack cygri

Arnaud Le Hors: ack cygri

13:36:28 <sandro> +1 cygri -- what HTTP spec says about DELETE is enough

Sandro Hawke: +1 cygri -- what HTTP spec says about DELETE is enough

13:36:28 <ericP> cygri: i'm not convinced we need to go beyond the HTTP spec for DELETE

Richard Cyganiak: i'm not convinced we need to go beyond the HTTP spec for DELETE

13:36:31 <betehess> why am I hoping that this issue is already fully solved in HTTP spec? maybe in Fielding's thesis?

Alexandre Bertails: why am I hoping that this issue is already fully solved in HTTP spec? maybe in Fielding's thesis?

13:36:39 <bblfish> q+

Henry Story: q+

13:36:58 <Ruben> betehess: not in F's thesis

Alexandre Bertails: not in F's thesis [ Scribe Assist by Ruben Verborgh ]

13:36:58 <ericP> ... we are bound by HTTP, and we can add specific behavior that distinguishes an LDP server

... we are bound by HTTP, and we can add specific behavior that distinguishes an LDP server

13:37:04 <timbl> Agree, you should only add constraints to the HTTP spec where you really need to for a special LDP-specific reason.

Tim Berners-Lee: Agree, you should only add constraints to the HTTP spec where you really need to for a special LDP-specific reason.

13:37:06 <FabGandon> +1 cygri (from observer)

Fabien Gandon: +1 cygri (from observer)

13:37:11 <webr3> can somebody say for me (no mic): '''can the resolution just be to remove the text "until another resource is created or associated with the same Request-URI" and close the issue, then later if more text is needed write it'''

Nathan Rixham: can somebody say for me (no mic): '''can the resolution just be to remove the text "until another resource is created or associated with the same Request-URI" and close the issue, then later if more text is needed write it'''

13:37:26 <SteveBattle> Can we put this issue to bed - pleeeeaaase?

Steve Battle: Can we put this issue to bed - pleeeeaaase?

13:37:31 <svillata> +1 cygri

Serena Villata: +1 cygri

13:37:36 <sandro> no webr3 some of us -1'd that

Sandro Hawke: no webr3 some of us -1'd that

13:37:39 <ericP> ... i haven't heard us proposing a stronger behavior than HTTP's DELETE

... i haven't heard us proposing a stronger behavior than HTTP's DELETE

13:37:54 <ericP> davidwood: doesn't 4.5.2 extend HTTP's DELETE?

David Wood: doesn't 4.5.2 extend HTTP's DELETE?

13:38:08 <Ruben> *betehess, the text is online, too. I've read it, and it's not there*

Ruben Verborgh: *betehess, the text is online, too. I've read it, and it's not there*

13:38:21 <Ashok_Malhotra> q+

Ashok Malhotra: q+

13:38:22 <ericP> cygri: it's a MAY and only talks about how it applies to our resources

Richard Cyganiak: it's a MAY and only talks about how it applies to our resources

13:38:59 <timbl> q?

Tim Berners-Lee: q?

13:39:25 <ericP> ... the resource to which we send the DELETE is a web resource which might have an associated RDF resource

... the resource to which we send the DELETE is a web resource which might have an associated RDF resource

13:39:53 <bblfish> q-

Henry Story: q-

13:39:58 <ericP> ArnaudLH: there's no reason for the text apart from stating what HTTP mandates

Arnaud Le Hors: there's no reason for the text apart from stating what HTTP mandates

13:40:06 <svillata> q?

Serena Villata: q?

13:40:10 <bblfish> q+

Henry Story: q+

13:40:15 <ericP> ... we can remove the offending text or just defer to HTTP

... we can remove the offending text or just defer to HTTP

13:40:29 <Ruben> +q

Ruben Verborgh: +q

13:40:46 <ArnaudLH> ack sandro

Arnaud Le Hors: ack sandro

13:40:46 <Zakim> sandro, you wanted to talk about use cases being a sometimes-necessary expense

Zakim IRC Bot: sandro, you wanted to talk about use cases being a sometimes-necessary expense

13:40:47 <oberger> we just say that the server SHOULD "support" DELETE ?

Olivier Berger: we just say that the server SHOULD "support" DELETE ?

13:40:48 <krp> is there a perceived problem with 4.5.2, or in how we relate it to http? atompub modifies other resources after a DELETE (e.g. deleting Media Link deletes Media Resource)

Kevin Page: is there a perceived problem with 4.5.2, or in how we relate it to http? atompub modifies other resources after a DELETE (e.g. deleting Media Link deletes Media Resource)

13:40:48 <Ruben> q+ to answer Arnaud's question

Ruben Verborgh: q+ to answer Arnaud's question

13:40:50 <davidwood> There is no "Web resource" or "RDF resource". There is only a "resource" associated with a URI.

David Wood: There is no "Web resource" or "RDF resource". There is only a "resource" associated with a URI.

13:41:03 <ericP> ... we agree to do what HTTP says, but don't know how to state it

... we agree to do what HTTP says, but don't know how to state it

13:41:11 <ArnaudLH> ack ashok

Arnaud Le Hors: ack ashok

13:41:58 <ericP> sandro: if someone expects a different behavior than HTTP, than we need to motivate that with a use case (which is an expensive process)

Sandro Hawke: if someone expects a different behavior than HTTP, than we need to motivate that with a use case (which is an expensive process)

13:42:14 <JohnArwe> q+ to say as an editor, why not use the experience from other specs, and simply make it clear through some convention in the document when we are (informatively) summarizing implications from other specs like HTTP vs when we are imposing additional normative requirements of our own?

John Arwe: q+ to say as an editor, why not use the experience from other specs, and simply make it clear through some convention in the document when we are (informatively) summarizing implications from other specs like HTTP vs when we are imposing additional normative requirements of our own?

13:42:17 <ArnaudLH> ack bblfish

Arnaud Le Hors: ack bblfish

13:42:29 <timbl> q+

Tim Berners-Lee: q+

13:42:38 <ericP> Ashok_Malhotra: we could split removing "until another resource is created or associated with the same Request-URI" and the other text

Ashok Malhotra: we could split removing "until another resource is created or associated with the same Request-URI" and the other text

13:42:44 <Ruben> *betehess: true, he deserved that*

Ruben Verborgh: *betehess: true, he deserved that*

13:42:53 <MacTed> +1 davidwood `There is no "Web resource" or "RDF resource". There is only a "resource" associated with a URI.`

Ted Thibodeau: +1 davidwood `There is no "Web resource" or "RDF resource". There is only a "resource" associated with a URI.`

13:42:56 <ericP> sandro: some of us -1'd simply removing the text

Sandro Hawke: some of us -1'd simply removing the text

13:43:06 <ArnaudLH> ack ruben

Arnaud Le Hors: ack ruben

13:43:06 <Zakim> Ruben, you wanted to answer Arnaud's question

Zakim IRC Bot: Ruben, you wanted to answer Arnaud's question

13:43:11 <cygri> MacTed, literals are RDF resources but not web resources

Richard Cyganiak: MacTed, literals are RDF resources but not web resources

13:43:19 <MacTed> nonsense.

Ted Thibodeau: nonsense.

13:43:22 <ericP> Ruben: removing is fine for me

Ruben Verborgh: removing is fine for me

13:43:28 <ericP> ... the phrasing is fine

... it was just the phrasing that could be confusing

13:43:31 <ArnaudLH> ack john

Arnaud Le Hors: ack john

13:43:31 <Zakim> JohnArwe, you wanted to say as an editor, why not use the experience from other specs, and simply make it clear through some convention in the document when we are (informatively)

Zakim IRC Bot: JohnArwe, you wanted to say as an editor, why not use the experience from other specs, and simply make it clear through some convention in the document when we are (informatively)

13:43:35 <Zakim> ... summarizing implications from other specs like HTTP vs when we are imposing additional normative requirements of our own?

Zakim IRC Bot: ... summarizing implications from other specs like HTTP vs when we are imposing additional normative requirements of our own?

13:43:52 <oberger> sandro, out of scope of the current discussion at least

Olivier Berger: sandro, out of scope of the current discussion at least

13:44:10 <Ruben> s/the phrasing is fine/it was just the phrasing that could be confusing/
13:44:16 <MacTed> anything nameable and transmissible over the wire may be considered a web resource.  literals are nameable and transmissible over the wire.

Ted Thibodeau: anything nameable and transmissible over the wire may be considered a web resource. literals are nameable and transmissible over the wire.

13:44:26 <ArnaudLH> q?

Arnaud Le Hors: q?

13:44:26 <ericP> JohnArwe: i worked on other specs and the convention for imposing normative requirements in addition to the base specs

John Arwe: i worked on other specs and the convention for imposing normative requirements in addition to the base specs

13:44:37 <ArnaudLH> ack timbl

Arnaud Le Hors: ack timbl

13:45:00 <ericP> timbl: i thought that "until another resource is created or associated with the same Request-URI" was gone by mow

Tim Berners-Lee: i thought that "until another resource is created or associated with the same Request-URI" was gone by now

13:45:36 <ericP> ... if you put something in a collection, the collection gives you the list that includes that new element

... if you put something in a collection, the collection gives you the list that includes that new element

13:45:50 <oberger> s/mow/now/
13:46:03 <krp> even if just a hyperlink to the container section

Kevin Page: even if just a hyperlink to the container section

13:46:15 <cygri> MacTed, refinement: REST resource != RDF resource

Richard Cyganiak: MacTed, refinement: REST resource != RDF resource

13:46:28 <ericP> ... is it worth saying that DELETing a resource removes it from the container?

... is it worth saying that DELETing a resource removes it from the container?

13:46:46 <ericP> ... or is that clear to any spec reader?

... or is that clear to any spec reader?

13:47:02 <SteveS> As editor I might remove the last words and add something like: "Whether a resource is exposed again at the same URI, is implementation specific, this can happen based on HTTP PUTs that don't have server-assigned URIs"

Steve Speicher: As editor I might remove the last words and add something like: "Whether a resource is exposed again at the same URI, is implementation specific, this can happen based on HTTP PUTs that don't have server-assigned URIs"

13:47:06 <ericP> [general agreement that it's the latter]

[general agreement that it's the latter]

13:47:53 <davidwood>  SteveS, I propose removing the phrase and adding a sentence, "Clients should note that severs may reuse a Request-URI under some circumstances."

David Wood: SteveS, I propose removing the phrase and adding a sentence, "Clients should note that severs may reuse a Request-URI under some circumstances."

13:48:21 <ahaller2> +1 davidwood

Armin Haller: +1 davidwood

13:48:28 <oberger> request-Uri -> resource URI ?

Olivier Berger: request-Uri -> resource URI ?

13:48:40 <SteveBattle> +1 david's wording to replace the grey sentence

Steve Battle: +1 david's wording to replace the grey sentence

13:48:53 <Ruben> +1

Ruben Verborgh: +1

13:48:59 <MacTed> cygri - I would like to see your definitions of each of those. I don't think I agree, but I'm not clear enough on what you mean to express my disagreement.

Ted Thibodeau: cygri - I would like to see your definitions of each of those. I don't think I agree, but I'm not clear enough on what you mean to express my disagreement.

13:49:08 <oberger> davidwood,  request-Uri -> resource URI ?

Olivier Berger: davidwood, request-Uri -> resource URI ?

13:49:28 <cygri> MacTed, RDF resource as defined in RDF 1.1 concepts. REST resource as defined in Fielding's thesis.

Richard Cyganiak: MacTed, RDF resource as defined in RDF 1.1 concepts. REST resource as defined in Fielding's thesis.

13:49:48 <antonis> can we not mention PUT or POST either at this point ?

Antonis Loizou: can we not mention PUT or POST either at this point ?

13:50:10 <Ashok_Malhotra> PROPOSAL:  Close Issue-24 with the following"  Delete the phrase in 4.5.1 that nsays "until ...Request URI" and adding a sentence, "Clients should note that severs may reuse a Request-URI under some circumstances."

PROPOSED: Close ISSUE-24 with the following" Delete the phrase in 4.5.1 that nsays "until ...Request URI" and adding a sentence, "Clients should note that severs may reuse a Request-URI under some circumstances."

13:50:22 <antonis> +1

Antonis Loizou: +1

13:50:22 <Ruben> +1

Ruben Verborgh: +1

13:50:24 <ericP> +1

+1

13:50:26 <cygri> +1

Richard Cyganiak: +1

13:50:28 <rgarcia> +1

Raúl García Castro: +1

13:50:29 <ahaller2> +1

Armin Haller: +1

13:50:29 <svillata> +1

Serena Villata: +1

13:50:30 <BartvanLeeuwen> +1

Bart van Leeuwen: +1

13:50:31 <davidwood> +1

David Wood: +1

13:50:31 <ArnaudLH> +1

Arnaud Le Hors: +1

13:50:33 <betehess> +1

Alexandre Bertails: +1

13:50:34 <sandro> +1

Sandro Hawke: +1

13:50:35 <krp> +1

Kevin Page: +1

13:50:36 <nmihindu> +1

Nandana Mihindukulasooriya: +1

13:50:39 <oberger> +1

Olivier Berger: +1

13:50:42 <webr3> -0 (the use of may kind of enourages bad form - sorry)

Nathan Rixham: -0 (the use of may kind of enourages bad form - sorry)

13:50:43 <MacTed> +1

Ted Thibodeau: +1

13:50:43 <SteveBattle> there was a suggestion to change that to 'resource URI'

Steve Battle: there was a suggestion to change that to 'resource URI'

13:50:45 <roger> +1

Roger Menday: +1

13:50:50 <cygri> Note that it shouldn't be "request URI" as per oberger

Richard Cyganiak: Note that it shouldn't be "request URI" as per oberger

13:51:02 <bblfish> -0 I think it's ok. But it is too vague

Henry Story: -0 I think it's ok. But it is too vague

13:51:06 <SteveS> +1

Steve Speicher: +1

13:51:07 <MacTed> cygri - I'd like specific links and/or quotation. those kinds of handwaves don't serve anyone well.

Ted Thibodeau: cygri - I'd like specific links and/or quotation. those kinds of handwaves don't serve anyone well.

13:51:24 <oberger> q+ to ask if impact on 5.6.2 :

Olivier Berger: q+ to ask if impact on 5.6.2 :

13:51:30 <bblfish> so I think the second sentence should go in non normative text

Henry Story: so I think the second sentence should go in non normative text

13:51:36 <MacTed> cygri - you seem to be suggesting that RDF resources and REST resources are disjoint, and I firmly disagree with that.

Ted Thibodeau: cygri - you seem to be suggesting that RDF resources and REST resources are disjoint, and I firmly disagree with that.

13:51:53 <cygri> MacTed, I said "not equal"