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"

Richard Cyganiak: MacTed, I said "not equal"

13:52:06 <betehess> MacTed: what about hash HTTP URIs then?

Ted Thibodeau: what about hash HTTP URIs then? [ Scribe Assist by Alexandre Bertails ]

13:52:22 <MacTed> a URI is a URI is a URI

Ted Thibodeau: a URI is a URI is a URI

13:52:36 <MacTed> the handling of hash HTTP URIs is a client-side concern

Ted Thibodeau: the handling of hash HTTP URIs is a client-side concern

13:53:17 <ericP> RESOLVED: 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."

RESOLVED: 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."

13:53:31 <ericP> ack oberger

ack oberger

13:53:31 <Zakim> oberger, you wanted to ask if impact on 5.6.2 :

Zakim IRC Bot: oberger, you wanted to ask if impact on 5.6.2 :

13:53:52 <ericP> ArnaudLH: imo, there's no impact on 5.6.2

Arnaud Le Hors: imo, there's no impact on 5.6.2

13:54:00 <cygri> 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.
13:54:04 <ArnaudLH> ack oberger

Arnaud Le Hors: ack oberger

13:54:21 <webr3> suggets issue-6

Nathan Rixham: suggets ISSUE-6

13:54:37 <cygri> ISSUE-6?

Richard Cyganiak: ISSUE-6?

13:54:37 <trackbot> ISSUE-6 -- Should LDBP say that any kind of user-defined simple data type is disallowed? -- open

Trackbot IRC Bot: ISSUE-6 -- Should LDBP say that any kind of user-defined simple data type is disallowed? -- open

13:54:37 <trackbot> http://www.w3.org/2012/ldp/track/issues/6

Trackbot IRC Bot: http://www.w3.org/2012/ldp/track/issues/6

13:56:23 <Ashok_Malhotra> q+

Ashok Malhotra: q+

13:56:53 <cygri> q+

Richard Cyganiak: q+

13:57:01 <ericP> SteveS: the current text says that user-defined simple datatypes are not allowed

Steve Speicher: the current text says that user-defined simple datatypes are not allowed

13:57:11 <betehess> q+ to mention that I'm already using new data types

Alexandre Bertails: q+ to mention that I'm already using new data types

13:57:21 <Ruben> SUBTOPIC: ISSUE-6 (Are user-defined data types disallowed?)

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

Summary: 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.

13:57:26 <ericP> ... this is meant to coallesce on a growing set of (currently XSD) datatypes

... this is meant to coallesce on a growing set of (currently XSD) datatypes

13:57:29 <Ruben> *for tpacbot*

Ruben Verborgh: *for tpacbot*

13:57:37 <ericP> ... feedback is that it is too restrictive

... feedback is that it is too restrictive

13:57:37 <ArnaudLH> ack ashok

Arnaud Le Hors: ack ashok

13:57:45 <ericP> ... proposal is to relax to SHOULD

... proposal is to relax to SHOULD

13:58:04 <webr3> spec says "LDPR representations must use only the following standard datatypes ..." set of only 9 types - this adds constraints to turtle and makes loads of rdf unusable with LDP - i personally have a big issue with that

Nathan Rixham: spec says "LDPR representations must use only the following standard datatypes ..." set of only 9 types - this adds constraints to turtle and makes loads of rdf unusable with LDP - i personally have a big issue with that

13:58:04 <ericP> Ashok_Malhotra: heard from folks saying "i'm using this special datatype"

Ashok Malhotra: heard from folks saying "i'm using this special datatype"

13:58:07 <davidwood> q+ to ask whether the server could simply advertise if it has datatype restrictions.

David Wood: q+ to ask whether the server could simply advertise if it has datatype restrictions.

13:58:22 <ericP> ... how are people going to reference a user-defined datatype with a URI?

... how are people going to reference a user-defined datatype with a URI?

13:58:47 <timbl> q+

Tim Berners-Lee: q+

13:58:49 <ericP> ... there's a doc by jjc telling you how to reference a user-defined datatype using a URI?

... there's a doc by jjc telling you how to reference a user-defined datatype using a URI?

13:59:16 <ArnaudLH> ack cygri

Arnaud Le Hors: ack cygri

13:59:35 <ericP> s/using a URI\?/using a URI/

s/using a URI\?/using a URI/ (warning: replacement failed)

13:59:50 <ericP> cygri: custom datatypes aren't often used in RDF

Richard Cyganiak: custom datatypes aren't often used in RDF

13:59:56 <JohnArwe> must drop for other calls

John Arwe: must drop for other calls

14:00:01 <Zakim> -JohnArwe

Zakim IRC Bot: -JohnArwe

14:00:15 <ericP> ... it's not very clear how to find the definition; what should be at the end of the datatype URI?

... it's not very clear how to find the definition; what should be at the end of the datatype URI?

14:00:34 <ericP> ... jjc's doc talks about how to restrict factets

... jjc's doc talks about how to restrict factets

14:00:51 <timbl> q+ timblPointOfOrder on whether to do 20 because of relative URIs

Tim Berners-Lee: q+ timblPointOfOrder on whether to do 20 because of relative URIs

14:01:21 <ericP> ... if you sort on frequency of datatypes, you see XSD types, misspellings of XSD types, custom types

... if you sort on frequency of datatypes, you see XSD types, misspellings of XSD types, custom types

14:01:51 <webr3> can somebody point out that the spec says: "LDPR representations MUST use **ONLY** the following standard datatypes." (xsd boolean,date,dateTime,decimal,double,float,integer,string + rdf:XMLLiteral) - that misses loads of very common xsd types, and rdf literal +html literal types etc - this is more of an issue than the non custom datatypes

Nathan Rixham: can somebody point out that the spec says: "LDPR representations MUST use **ONLY** the following standard datatypes." (xsd boolean,date,dateTime,decimal,double,float,integer,string + rdf:XMLLiteral) - that misses loads of very common xsd types, and rdf literal +html literal types etc - this is more of an issue than the non custom datatypes

14:01:53 <ahaller2> q+

Armin Haller: q+

14:02:03 <ericP> ... if you use SPARQL doesn't recognize "330"^^xsd:feet as an integer

... if you use SPARQL doesn't recognize "330"^^xsd:feet as an integer

14:02:19 <davidwood> +1 to cygri

David Wood: +1 to cygri

14:02:21 <timbl> Use interpretaion properties not [ value 2; unit kg] form.

Tim Berners-Lee: Use interpretaion properties not [ value 2; unit kg] form.

14:02:30 <ericP> ... i don't think there's a large group who will be impacted by the MUST or SHOULD

... i don't think there's a large group who will be impacted by the MUST or SHOULD

14:02:33 <timbl> Use   [ is kg of 2 ]

Tim Berners-Lee: Use [ is kg of 2 ]

14:02:43 <ericP> q+ to ask how we increase interop

q+ to ask how we increase interop

14:02:44 <bblfish> q+

Henry Story: q+

14:02:51 <ArnaudLH> ack bete

Arnaud Le Hors: ack bete

14:02:51 <Zakim> betehess, you wanted to mention that I'm already using new data types

Zakim IRC Bot: betehess, you wanted to mention that I'm already using new data types

14:02:51 <sandro> RRSAgent, pointer?

Sandro Hawke: RRSAgent, pointer?

14:02:51 <RRSAgent> See http://www.w3.org/2012/11/01-ldp-irc#T14-02-51-2

RRSAgent IRC Bot: See http://www.w3.org/2012/11/01-ldp-irc#T14-02-51-2

14:03:13 <ericP> betehess: i disagree that people don't use custom datatypes [2 negatives]

Alexandre Bertails: i disagree that people don't use custom datatypes [2 negatives]

14:03:18 <ericP> ... i use them a lot

... i use them a lot

14:03:27 <ericP> cygri: you're in a tiny minority

Richard Cyganiak: you're in a tiny minority

14:03:49 <ericP> betehess: people wnat to be able to say what something means in the domain application

Alexandre Bertails: people wnat to be able to say what something means in the domain application

14:04:11 <ericP> ... i have types in e.g. java or scala and i want to restrict the permissible values for a string

... i have types in e.g. java or scala and i want to restrict the permissible values for a string

14:04:12 <SteveBattle> I've also used custom datatypes

Steve Battle: I've also used custom datatypes

14:04:24 <ericP> ... i'm not concearned about SPARQL in my app

... i'm not concearned about SPARQL in my app

14:04:31 <ArnaudLH> ack david

Arnaud Le Hors: ack david

14:04:31 <Zakim> davidwood, you wanted to ask whether the server could simply advertise if it has datatype restrictions.

Zakim IRC Bot: davidwood, you wanted to ask whether the server could simply advertise if it has datatype restrictions.

14:04:38 <antonis> q+

Antonis Loizou: q+

14:04:42 <ericP> ... i didn't know about this issue 'cause it seemed intrinsic to RDF

... i didn't know about this issue 'cause it seemed intrinsic to RDF

14:04:58 <ericP> davidwood: i was surprised when i saw this in the spec

David Wood: i was surprised when i saw this in the spec

14:05:00 <MacTed> present+ MacTed

Ted Thibodeau: present+ MacTed

14:05:14 <ericP> ... thinking through it, i can see why you'd want to do that in your compliant server

... thinking through it, i can see why you'd want to do that in your compliant server

14:05:24 <ericP> ... i don't think i'd want to do it in mine

... i don't think i'd want to do it in mine

14:05:55 <ericP> ... if we can agree on this, we can say "if the server restricts datatypes, it SHOULD advertise those datatypes", e.g. by header, container attrs

... if we can agree on this, we can say "if the server restricts datatypes, it SHOULD advertise those datatypes", e.g. by header, container attrs

14:05:59 <ArnaudLH> a?

Arnaud Le Hors: a?

14:06:05 <ArnaudLH> ack timbl

Arnaud Le Hors: ack timbl

14:06:07 <webr3> the issue is greater.. xsd hexBinary, long, int, short, unsignedlong etc are all made illegal by the spec

Nathan Rixham: the issue is greater.. xsd hexBinary, long, int, short, unsignedlong etc are all made illegal by the spec

14:06:12 <oberger> q+ to ask if this is still needed given that we're no longer discussing Basic Profile (vs Advanced Profiles)

Olivier Berger: q+ to ask if this is still needed given that we're no longer discussing Basic Profile (vs Advanced Profiles)

14:06:13 <bblfish> that's interesting because in any case there will be all kinds of types of restrictions

Henry Story: that's interesting because in any case there will be all kinds of types of restrictions

14:06:30 <ericP> timbl: i think you want to give a name to a system which uses a constrained set of datatypes

Tim Berners-Lee: i think you want to give a name to a system which uses a constrained set of datatypes

14:07:16 <ericP> ... if i'm getting data from some hardware, the value lies in that datatype being transparent

... if i'm getting data from some hardware, the value lies in that datatype being transparent

14:07:37 <ericP> ... if you're going to put datatypes in, it's nice to put it in with another arc

... if you're going to put datatypes in, it's nice to put it in with another arc

14:07:49 <betehess> then please fix the datatype mess in RDF first

Alexandre Bertails: then please fix the datatype mess in RDF first

14:08:02 <betehess> q+

Alexandre Bertails: q+

14:08:11 <sandro> RRSAgent, pointer?

Sandro Hawke: RRSAgent, pointer?

14:08:11 <RRSAgent> See http://www.w3.org/2012/11/01-ldp-irc#T14-08-11

RRSAgent IRC Bot: See http://www.w3.org/2012/11/01-ldp-irc#T14-08-11

14:08:22 <davidwood> +1 to timbl

David Wood: +1 to timbl

14:08:38 <oberger> q-

Olivier Berger: q-

14:08:48 <betehess> my proposal: don't say anything, it's just RDF!

Alexandre Bertails: my proposal: don't say anything, it's just RDF!

14:08:51 <ericP> ack timblPointOfOrder

ack timblPointOfOrder

14:08:51 <Zakim> timblPointOfOrder, you wanted to comment on whether to do 20 because of relative URIs

Zakim IRC Bot: timblPointOfOrder, you wanted to comment on whether to do 20 because of relative URIs

14:08:52 <ArnaudLH> ack timbl

Arnaud Le Hors: ack timbl

14:08:57 <SteveBattle> OWL2 lets you define your own datatypes - so they're not broken.

Steve Battle: OWL2 lets you define your own datatypes - so they're not broken.

14:09:05 <ericP> timbl: i'm excited to talk about relative URLs today

Tim Berners-Lee: i'm excited to talk about relative URLs today

14:09:09 <cygri> ISSUE-20?

Richard Cyganiak: ISSUE-20?

14:09:09 <trackbot> ISSUE-20 -- Identifying and naming POSTed resources -- open

Trackbot IRC Bot: ISSUE-20 -- Identifying and naming POSTed resources -- open

14:09:09 <trackbot> http://www.w3.org/2012/ldp/track/issues/20

Trackbot IRC Bot: http://www.w3.org/2012/ldp/track/issues/20

14:09:12 <MacTed> an existing minority, tiny though it may be, using custom data types makes "MUST only use these data types" absolutely unacceptable to me here.

Ted Thibodeau: an existing minority, tiny though it may be, using custom data types makes "MUST only use these data types" absolutely unacceptable to me here.

14:09:12 <MacTed> "SHOULD" could possibly be argued, in support of greater overall interoperability.

Ted Thibodeau: "SHOULD" could possibly be argued, in support of greater overall interoperability.

14:09:12 <MacTed> I generally like davidwood's suggested direction

Ted Thibodeau: I generally like davidwood's suggested direction

14:09:29 <ArnaudLH> ack ahaller

Arnaud Le Hors: ack ahaller

14:09:46 <ArnaudLH> ack eric

Arnaud Le Hors: ack eric

14:09:46 <Zakim> ericP, you wanted to ask how we increase interop

Zakim IRC Bot: ericP, you wanted to ask how we increase interop

14:10:00 <ericP> ahaller: all ontologies i know solve with units of measure patterns

Armin Haller: all ontologies i know solve with units of measure patterns

14:10:05 <sandro> zakim, who is on the call?

Sandro Hawke: zakim, who is on the call?

14:10:05 <Zakim> On the phone I see St_Clair_3B, [IPcaller], MacTed (muted)

Zakim IRC Bot: On the phone I see St_Clair_3B, [IPcaller], MacTed (muted)

14:10:13 <cygri> q?

Richard Cyganiak: q?

14:10:57 <ArnaudLH> ack bblfish

Arnaud Le Hors: ack bblfish

14:11:19 <SteveBattle> Striking it (4.1.9) out completely gets my vote

Steve Battle: Striking it (4.1.9) out completely gets my vote

14:11:40 <ericP> ericP: in my domain, we use more custom datatypes than most, and for stuff where the SPARQL computability isn't an issue, but i don't think we'd mind a SHOULD which we violated

Eric Prud'hommeaux: in my domain, we use more custom datatypes than most, and for stuff where the SPARQL computability isn't an issue, but i don't think we'd mind a SHOULD which we violated

14:11:48 <cygri> q+

Richard Cyganiak: q+

14:12:39 <ericP> bblfish: there's an assymetric pressure to use standard datatypes

Henry Story: there's an assymetric pressure to use standard datatypes

14:12:42 <ArnaudLH> ack antonis

Arnaud Le Hors: ack antonis

14:12:53 <ericP> ... [hexbinary example]

... [hexbinary example]

14:13:08 <bblfish> plust I need hexBinary, which is not on the list

Henry Story: plust I need hexBinary, which is not on the list

14:13:33 <ArnaudLH> ack bete

Arnaud Le Hors: ack bete

14:13:38 <ericP> antonis: we could say that clients SHOULD NOT use custom datatypes, but if they do, they should be described per davidwood's proposal

Antonis Loizou: we could say that clients SHOULD NOT use custom datatypes, but if they do, they should be described per davidwood's proposal

14:14:02 <bblfish> ?

Henry Story: ?

14:14:06 <bblfish> q?

Henry Story: q?

14:14:07 <ericP> betehess: i feel like this is like in the last conversation where we were restricting HTTP

Alexandre Bertails: i feel like this is like in the last conversation where we were restricting HTTP

14:14:09 <bblfish> q+

Henry Story: q+

14:14:21 <ericP> ... why not restrict vocabularies, ...?

... why not restrict vocabularies, ...?

14:14:44 <ericP> ... i'm not totally motivated by the current deployment

... i'm not totally motivated by the current deployment

14:15:01 <bblfish> my point was the following: there is no need to put restrictions on datatypes, that will come from usage

Henry Story: my point was the following: there is no need to put restrictions on datatypes, that will come from usage

14:15:04 <ericP> ... i don't think that application manufacturers will get it right

... i don't think that application manufacturers will get it right

14:15:21 <ArnaudLH> ack cygri

Arnaud Le Hors: ack cygri

14:15:25 <oberger> q+

Olivier Berger: q+

14:15:30 <webr3> agree w/ bblfish

Nathan Rixham: agree w/ bblfish

14:15:32 <BartvanLeeuwen> q+

Bart van Leeuwen: q+

14:15:42 <betehess> I want to state that I was cut when wanted to discuss the "wrong reasons"

Alexandre Bertails: I want to state that I was cut when wanted to discuss the "wrong reasons"

14:15:55 <ericP> cygri: i think a good reason for restrictions is that there's value in mapping data from an LDP server into application data structures

Richard Cyganiak: i think a good reason for restrictions is that there's value in mapping data from an LDP server into application data structures

14:16:10 <davidwood> antonis' proposal seems to be backward from mine.  I suggest that servers that restrict must advertise the restriction.  Antonis suggests that servers that do *not* restrict must advertise.

David Wood: antonis' proposal seems to be backward from mine. I suggest that servers that restrict must advertise the restriction. Antonis suggests that servers that do *not* restrict must advertise.

14:16:10 <ericP> ... XSD types map naturally to language-native datatypes

... XSD types map naturally to language-native datatypes

14:16:17 <ericP> ... others become complex objects

... others become complex objects

14:16:50 <ericP> ... not that we must always do what JSON does, but one thing makes JSON easy is that you only get native datatypes

... not that we must always do what JSON does, but one thing makes JSON easy is that you only get native datatypes

14:16:53 <Ashok_Malhotra>  PROPOSAL1:  Rewrite the first sentence in 4.1.9 to "It is recommended that LDPR repsenetations use the follwing datatypes"

Ashok Malhotra: PROPOSAL1: Rewrite the first sentence in 4.1.9 to "It is recommended that LDPR repsenetations use the follwing datatypes"

14:16:54 <ArnaudLH> ack bblfish

Arnaud Le Hors: ack bblfish

14:17:08 <ericP> ... is this as a reason to encourage use of standard types

... is this as a reason to encourage use of standard types

14:17:08 <betehess> this statement just forgets the specific needs of domain specific applications

Alexandre Bertails: this statement just forgets the specific needs of domain specific applications

14:17:36 <SteveS> q+

Steve Speicher: q+

14:17:51 <ArnaudLH> ack oberger

Arnaud Le Hors: ack oberger

14:18:02 <ericP> bblfish: there's no hexbinary in the sanctioned list, which rules out webid

Henry Story: there's no hexbinary in the sanctioned list, which rules out webid

14:18:07 <timbl> q+ to suggest that the specification of limited types if you want to keep it, make it an appendix and give it a different name.

Tim Berners-Lee: q+ to suggest that the specification of limited types if you want to keep it, make it an appendix and give it a different name.

14:18:20 <SteveBattle> -1 to the proposal - I prefer the original proposal to delete 4.1.9

Steve Battle: -1 to the proposal - I prefer the original proposal to delete 4.1.9

14:18:22 <betehess> my answer: I believe in standards

Alexandre Bertails: my answer: I believe in standards

14:18:24 <timbl> q+

Tim Berners-Lee: q+

14:18:37 <ericP> oberger: i understand betehess's concearns, but what's it matter if you're not compliant with this aspect?

Olivier Berger: i understand betehess's concearns, but what's it matter if you're not compliant with this aspect?

14:18:38 <antonis> davidwood, agree on the difference between my proposal and yours

Antonis Loizou: davidwood, agree on the difference between my proposal and yours

14:18:58 <ArnaudLH> ack bart

Arnaud Le Hors: ack bart

14:18:59 <ericP> ... i could object to dc:creator, but it's good for the larger goal

... i could object to dc:creator, but it's good for the larger goal

14:19:08 <Ashok_Malhotra> SteveBattle --- that was going to my PROPOSAL 2 ::-)

Ashok Malhotra: SteveBattle --- that was going to my PROPOSAL 2 ::-)

14:19:16 <davidwood> PROPOSAL: Change 4.1.9 to say that servers MAY restrict their datatypes.

PROPOSED: Change 4.1.9 to say that servers MAY restrict their datatypes.

14:19:23 <ericP> BartvanLeeuwen: i jumped on RDF because of it's flexibility

Bart van Leeuwen: i jumped on RDF because of it's flexibility

14:19:23 <davidwood> antonis, thanks

David Wood: antonis, thanks

14:19:35 <ericP> ... we see geo datatypes, which get some use

... we see geo datatypes, which get some use

14:19:35 <ArnaudLH> ack steves

Arnaud Le Hors: ack steves

14:19:46 <SteveBattle> I think 4.1.9 send the wrong message entirely - kill it!

Steve Battle: I think 4.1.9 send the wrong message entirely - kill it!

14:19:53 <ericP> ... i don't think i've heard a good motivation

... i don't think i've heard a good motivation

14:19:59 <betehess> q+

Alexandre Bertails: q+

14:20:12 <ericP> SteveS: true intent is "don't make up a new datatype where one of these suffices"

Steve Speicher: true intent is "don't make up a new datatype where one of these suffices"

14:20:20 <ArnaudLH> ack timbl

Arnaud Le Hors: ack timbl

14:20:20 <Zakim> timbl, you wanted to suggest that the specification of limited types if you want to keep it, make it an appendix and give it a different name. and to

Zakim IRC Bot: timbl, you wanted to suggest that the specification of limited types if you want to keep it, make it an appendix and give it a different name. and to

14:20:22 <webr3> SteveBattle, +1 to what you said, it's a horrible section that makes a huge portion of wild rdf unusable

Nathan Rixham: SteveBattle, +1 to what you said, it's a horrible section that makes a huge portion of wild rdf unusable

14:20:45 <davidwood> Agree that 4.1.9 says "don't fully use RDF".  That's not good.

David Wood: Agree that 4.1.9 says "don't fully use RDF". That's not good.

14:20:46 <ericP> timbl: the only think i care about is the MUST

Tim Berners-Lee: the only think i care about is the MUST

14:21:03 <ericP> ... every time we make a constriant, you cut out users

... every time we make a constriant, you cut out users

14:21:07 <Ruben>  s/think/thing/

Ruben Verborgh: s/think/thing/

14:21:24 <ericP> ... you could say "you can put anything in here with a PUT", which everyone can use

... you could say "you can put anything in here with a PUT", which everyone can use

14:21:58 <ericP> ... you can make a further restriction with interop optimization

... you can make a further restriction with interop optimization

14:22:30 <ArnaudLH> q?

Arnaud Le Hors: q?

14:22:34 <ArnaudLH> ack bete

Arnaud Le Hors: ack bete

14:22:47 <ericP> q+ to repeat points 7, 24 and 282-306

q+ to repeat points 7, 24 and 282-306

14:22:50 <ericP> q-

q-

14:22:51 <bblfish> MUST

Henry Story: MUST

14:22:51 <Ashok_Malhotra> q+

Ashok Malhotra: q+

14:23:06 <ArnaudLH> ack ashok

Arnaud Le Hors: ack ashok

14:23:23 <SteveBattle> +1 to ashok's proposal

Steve Battle: +1 to ashok's proposal

14:23:23 <cygri> PROPOSAL: Delete 4.1.9

PROPOSED: Delete 4.1.9

14:23:37 <oberger> or soften it

Olivier Berger: or soften it

14:23:44 <ericP> davidwood

davidwood

14:23:55 <davidwood> PROPOSAL: Soften 4.1.9 by removing it :)

PROPOSED: Soften 4.1.9 by removing it :)

14:24:00 <timbl> The idea of constraining RDF datatypes to get interop between OO systems is a separate orthogonal protocol, independent of LDP.

Tim Berners-Lee: The idea of constraining RDF datatypes to get interop between OO systems is a separate orthogonal protocol, independent of LDP.

14:24:03 <betehess> I'm happy to put that in a "best practices document for LDP"

Alexandre Bertails: I'm happy to put that in a "best practices document for LDP"

14:24:05 <Ruben> *lol @ davidwood*

Ruben Verborgh: *lol @ davidwood*

14:24:09 <antonis> -1

Antonis Loizou: -1

14:24:11 <oberger> SteveS, you had a proposal ?

Olivier Berger: SteveS, you had a proposal ?

14:24:11 <Ruben> +1 to get rid of it

Ruben Verborgh: +1 to get rid of it

14:24:13 <timbl> +1

Tim Berners-Lee: +1

14:24:16 <rgarcia> +1 to delete

Raúl García Castro: +1 to delete

14:24:17 <SteveBattle> +1 die die die

Steve Battle: +1 die die die

14:24:20 <SteveS> -1

Steve Speicher: -1

14:24:21 <krp> +1

Kevin Page: +1

14:24:22 <BartvanLeeuwen> +1 delete

Bart van Leeuwen: +1 delete

14:24:25 <bblfish> +1

Henry Story: +1

14:24:26 <svillata> +1

Serena Villata: +1

14:24:27 <cygri> ±0

Richard Cyganiak: ±0

14:24:29 <betehess> +1

Alexandre Bertails: +1

14:24:29 <sandro> -0

Sandro Hawke: -0

14:24:31 <webr3> +1 to delete

Nathan Rixham: +1 to delete

14:24:31 <betehess> +1

Alexandre Bertails: +1

14:24:34 <oberger> -0,0

Olivier Berger: -0,0

14:24:35 <MacTed> +1

Ted Thibodeau: +1

14:24:36 <nmihindu> +1 for removing

Nandana Mihindukulasooriya: +1 for removing

14:24:36 <roger> +1

Roger Menday: +1

14:24:40 <davidwood> +1

David Wood: +1

14:24:46 <ahaller2> -0

Armin Haller: -0

14:25:00 <ericP> davidwood: we can strike 4.1.9, soften to a SHOULD, change to language about "encouraging folks to use

David Wood: we can strike 4.1.9, soften to a SHOULD, change to language about "encouraging folks to use the following types when applicable

14:25:03 <ericP> -¹

-¹

14:25:14 <cygri> q+

Richard Cyganiak: q+

14:25:18 <SteveBattle> This kind of advice could go in the primer

Steve Battle: This kind of advice could go in the primer

14:25:42 <ericP> s/encouraging folks to use/encouraging folks to use the following types when applicable/
14:26:23 <HadleyBeeman> *that was my thought too, SteveBattle. It'd be useful for the implementations coming from the GLD WG too

Hadley Beeman: *that was my thought too, SteveBattle. It'd be useful for the implementations coming from the GLD WG too

14:26:31 <ericP> cygri: non-normative best practice on the use of datatypes shouldn't be in this specification

Richard Cyganiak: non-normative best practice on the use of datatypes shouldn't be in this specification

14:26:33 <sandro> sandro:  maybe?   PROPOSED: Replace 4.1.9 with non-normative text, describing which datatypes are widely used -- a best practice.

Sandro Hawke: maybe? PROPOSED: Replace 4.1.9 with non-normative text, describing which datatypes are widely used -- a best practice. [ Scribe Assist by Sandro Hawke ]

14:26:43 <webr3> I'd propose (if it must be kept): swap MUST to SHOULD, remove the word "only" and expand the list to the same set as the union of rif + rdf, then it doesn't preclude anything

Nathan Rixham: I'd propose (if it must be kept): swap MUST to SHOULD, remove the word "only" and expand the list to the same set as the union of rif + rdf, then it doesn't preclude anything

14:26:48 <bblfish> agree with cygri

Henry Story: agree with cygri

14:27:06 <betehess> +1 to avoid informative statements like that whenever possible

Alexandre Bertails: +1 to avoid informative statements like that whenever possible

14:27:12 <ericP> ... since it's a cross-cutting concearn, i'd be more comfortable making no statement at all"

... since it's a cross-cutting concearn, i'd be more comfortable making no statement at all"

14:27:26 <SteveS> PROPOSAL: Soften to SHOUD and explain use instead of inventing custom ones that do the same thing

PROPOSED: Soften to SHOUD and explain use instead of inventing custom ones that do the same thing

14:27:42 <sandro> +1

Sandro Hawke: +1

14:27:46 <MacTed> did we not just RESOLVE to delete it?

Ted Thibodeau: did we not just RESOLVE to delete it?

14:28:20 <davidwood> q+ to ask how clients can know what they can PUT if servers may restrict datatypes

David Wood: q+ to ask how clients can know what they can PUT if servers may restrict datatypes

14:29:25 <sandro> ArnaudLH: -1 means "I cannot live with this proposal" -- expected to lead to a Formal Objection

Arnaud Le Hors: -1 means "I cannot live with this proposal" -- expected to lead to a Formal Objection [ Scribe Assist by Sandro Hawke ]

14:30:25 <betehess> that's an RDF issue to me

Alexandre Bertails: that's an RDF issue to me

14:30:55 <HadleyBeeman> Q+

Hadley Beeman: Q+

14:31:15 <ericP> antonis: i think it should be written somewhere. don't mean to formally object

Antonis Loizou: i think it should be written somewhere. don't mean to formally object

14:31:19 <cygri> q-

Richard Cyganiak: q-

14:31:27 <ArnaudLH> ack david

Arnaud Le Hors: ack david

14:31:27 <Zakim> davidwood, you wanted to ask how clients can know what they can PUT if servers may restrict datatypes

Zakim IRC Bot: davidwood, you wanted to ask how clients can know what they can PUT if servers may restrict datatypes

14:32:02 <ericP> davidwood, if this becomes a SHOULD, some servers will restrict your datatypes, and some won't

davidwood, if this becomes a SHOULD, some servers will restrict your datatypes, and some won't

14:32:10 <bblfish> q+

Henry Story: q+

14:32:28 <ericP> ... how does a client know what to expect?

... how does a client know what to expect?

14:33:01 <ericP> ... we need a way to advertise the types

... we need a way to advertise the types

14:33:01 <ArnaudLH> ack hadley

Arnaud Le Hors: ack hadley

14:33:02 <betehess> q+

Alexandre Bertails: q+

14:33:23 <ericP> HadleyBeeman: we have this prob everywhere (gov LD, RDF Core)

Hadley Beeman: we have this prob everywhere (gov LD, RDF Core)

14:33:35 <ericP> ... doesn't belong in this group

... doesn't belong in this group

14:33:46 <cygri> PROPOSAL: Delete 4.1.9 and annoy RDF-WG about doing something about datatype best practice

PROPOSED: Delete 4.1.9 and annoy RDF-WG about doing something about datatype best practice

14:33:55 <ArnaudLH> ack bblfish

Arnaud Le Hors: ack bblfish

14:34:16 <ericP> bblfish: agreeing that collections can be typed and restricted

Henry Story: agreeing that collections can be typed and restricted

14:34:29 <ericP> ... +1 to davidwood

... +1 to davidwood

14:34:54 <ArnaudLH> q- bete

Arnaud Le Hors: q- bete

14:34:54 <MacTed> "servers MAY restrict datatypes to this (or another) list, MAY exclude user-defined datatypes.  if datatypes are so restricted, such restrictions MUST be advertised."

Ted Thibodeau: "servers MAY restrict datatypes to this (or another) list, MAY exclude user-defined datatypes. if datatypes are so restricted, such restrictions MUST be advertised."

14:34:56 <betehess> q-

Alexandre Bertails: q-

14:35:05 <ericP> SteveS: two reasons to object:

Steve Speicher: two reasons to object:

14:35:29 <ericP> ... .. the issues around saying SHOULD (not reinvent)

... .. the issues around saying SHOULD (not reinvent)

14:35:47 <ericP> ... .. would like to encourage best practices as much as can

... .. would like to encourage best practices as much as can

14:36:15 <webr3> atonis, are you 0 or +1 now?

Nathan Rixham: atonis, are you 0 or +1 now?

14:36:18 <antonis> 0

Antonis Loizou: 0

14:36:20 <ArnaudLH> a?

Arnaud Le Hors: a?

14:36:22 <ArnaudLH> q?

Arnaud Le Hors: q?

14:36:23 <timbl> q+

Tim Berners-Lee: q+

14:36:44 <ericP> ArnaudLH: i think we understand adding constraints for interop

Arnaud Le Hors: i think we understand adding constraints for interop

14:37:16 <ericP> davidwood: sandro pointed out that somewhere it says that "if a client PUTs datatypes other than this, they are stripped"?

David Wood: sandro pointed out that the MUST

14:37:54 <cygri> q+

Richard Cyganiak: q+

14:38:06 <sandro> s/sandro pointed out that somewhere it says that "if a client PUTs datatypes other than this, they are stripped"?/sandro pointed out that the MUST/SHOULD is only about the representation, not about server behavior/
14:38:13 <ericP> ... the server has to construct a representation of these datatypes

... the server has to construct a representation of these datatypes

14:38:17 <ericP> q+

q+

14:38:34 <webr3> yes MUST *ONLY*

Nathan Rixham: yes MUST *ONLY*

14:38:38 <MacTed> server doesn't have to *strip* the datatype, but must figure out how to represent those other datatypes with the given short-list

Ted Thibodeau: server doesn't have to *strip* the datatype, but must figure out how to represent those other datatypes with the given short-list

14:38:42 <MacTed> *that*'s problematc

Ted Thibodeau: *that*'s problematc

14:38:43 <svillata> q?

Serena Villata: q?

14:38:52 <ericP> q+ to point out that we're never going to convince a non-triplestore server to not strip unknown stuff

q+ to point out that we're never going to convince a non-triplestore server to not strip unknown stuff

14:39:20 <SteveS> -0

Steve Speicher: -0

14:39:26 <antonis> 0

Antonis Loizou: 0

14:39:29 <ericP> +∞×ø

+∞×ø

14:39:33 <sandro> +1

Sandro Hawke: +1

14:39:41 <SteveBattle> "+1"^^xsd:short

Steve Battle: "+1"^^xsd:short

14:40:37 <cygri> ^^ This resolves ISSUE-6

Richard Cyganiak: ^^ This resolves ISSUE-6

14:41:10 <Zakim> -[IPcaller]

Zakim IRC Bot: -[IPcaller]

14:41:22 <ericP> RESOLVED: Close ISSUE-6 by DELETing LDP §4.1.9

RESOLVED: Close ISSUE-6 by DELETing LDP §4.1.9

14:41:22 <ArnaudLH> close issue-6 with deleting section 4.1.9 and editing any related sections in the spec accordingly

Arnaud Le Hors: close ISSUE-6 with deleting section 4.1.9 and editing any related sections in the spec accordingly

14:41:30 <cygri> summary: 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.
14:41:56 <Zakim> -MacTed

Zakim IRC Bot: -MacTed

14:42:03 <sandro> MacTed, everypone is gone, no clue

Sandro Hawke:

15:03:23 <cygri> MacTed, we're slowly reconvening

(No events recorded for 21 minutes)

Richard Cyganiak:

15:05:51 <MacTed> tnx

Ted Thibodeau:

15:08:07 <Zakim> +[OpenLink]

Zakim IRC Bot: +[OpenLink]

15:08:16 <sandro> scribe: Ashok_Malhotra

(Scribe set to Ashok Malhotra)

15:08:16 <MacTed> Zakim, [OpenLink] is temporarily me

Ted Thibodeau: Zakim, [OpenLink] is temporarily me

15:08:16 <Zakim> +MacTed; got it

Zakim IRC Bot: +MacTed; got it

15:08:19 <MacTed> Zakim, mute me

Ted Thibodeau: Zakim, mute me

15:08:19 <Zakim> MacTed should now be muted

Zakim IRC Bot: MacTed should now be muted

15:08:21 <Ashok_Malhotra> scribenick:  Ashok_Malhotra
15:08:23 <betehess> s/tnx//
15:08:30 <betehess> s/MacTed, we're slowly reconvening//
15:08:40 <betehess> s/MacTed, everypone is gone, no clue//
15:09:19 <Ashok_Malhotra> TOPIC: Next F2F

4. Next F2F

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

15:08:51 <Ashok_Malhotra> Arnaud:  Let's discuss dinner then pick up issues again

Arnaud Le Hors: Let's discuss dinner then pick up issues again

15:09:01 <Ashok_Malhotra> ... also talk about f2f

... also talk about f2f

15:09:44 <Ashok_Malhotra> Arnaud:  Charter calls for a f2f in March

Arnaud Le Hors: Charter calls for a f2f in March

15:09:58 <Ashok_Malhotra> ... we have to announce 8 weeks ahead of time

... we have to announce 8 weeks ahead of time

15:10:07 <davidwood> W3C event calendar: http://www.w3.org/participate/eventscal.html

David Wood: W3C event calendar: http://www.w3.org/participate/eventscal.html

15:10:23 <Ashok_Malhotra> ... We also need a list of possible hosts

... We also need a list of possible hosts

15:10:29 <davidwood> Sometimes ftf meetings can be in conjunction with another event.

David Wood: Sometimes ftf meetings can be in conjunction with another event.

15:10:29 <bblfish> q+

Henry Story: q+

15:10:34 <bblfish> q-

Henry Story: q-

15:11:27 <Ashok_Malhotra> Ashok:  Maybe Oracle can host in NYC

Ashok Malhotra: Maybe Oracle can host in NYC

15:11:35 <Ashok_Malhotra> Sandro:  We can host at MIT

Sandro Hawke: We can host at MIT

15:11:46 <cygri> ack me

Richard Cyganiak: ack me

15:11:47 <sandro> q- timbl

Sandro Hawke: q- timbl

15:12:04 <sandro> queue=

Sandro Hawke: queue=

15:12:34 <davidwood> Maybe a straw poll on general location? (US East, US West, Europe)

David Wood: Maybe a straw poll on general location? (US East, US West, Europe)

15:13:12 <ahaller2> ahaller2 is offering to host

Armin Haller: ahaller2 is offering to host

15:13:20 <Ashok_Malhotra> Arnaud:  I'm not thinking about Europe

Arnaud Le Hors: I'm not thinking about Europe

15:14:44 <Ashok_Malhotra> David:  Most WGs I have been involved in alternate between Europe and US East Coast

David Wood: Most WGs I have been involved in alternate between Europe and US East Coast

15:16:19 <Ashok_Malhotra> Discussion about expensive lodging in NYC

Discussion about expensive lodging in NYC

15:16:25 <SteveS> -1 to sharing room with ericP

Steve Speicher: -1 to sharing room with ericP

15:16:47 <ericP> wuss

Eric Prud'hommeaux: wuss

15:17:15 <Ashok_Malhotra> Lodging is cheaper in Cambridge

Lodging is cheaper in Cambridge

15:17:52 <Ashok_Malhotra> I can try and find rooms on the West Coast

I can try and find rooms on the West Coast

15:18:36 <Ruben> +1

Ruben Verborgh: +1

15:18:40 <ArnaudLH> west coast?

Arnaud Le Hors: west coast?

15:18:42 <SteveBattle> 0

Steve Battle: 0

15:18:48 <betehess> -1

Alexandre Bertails: -1

15:18:48 <cygri> STRAWPOLL: Who could go to U.S. west coast

STRAWPOLL: Who could go to U.S. west coast

15:18:48 <ArnaudLH> +1

Arnaud Le Hors: +1

15:18:49 <SteveS> +1

Steve Speicher: +1

15:18:52 <cygri> -0.2

Richard Cyganiak: -0.2

15:18:54 <BartvanLeeuwen> 0

Bart van Leeuwen: 0

15:18:56 <ahaller2> 0

Armin Haller: 0

15:18:57 <svillata> 0

Serena Villata: 0

15:19:03 <SteveS> +0.9

Steve Speicher: +0.9

15:19:06 <davidwood> +0.5

David Wood: +0.5

15:19:10 <Ashok_Malhotra> +1

+1

15:19:21 <ArnaudLH> +1

Arnaud Le Hors: +1

15:19:33 <MacTed> 25% chance of west coast attendance.  75% east coast.  90% proximal to Boston.

Ted Thibodeau: 25% chance of west coast attendance. 75% east coast. 90% proximal to Boston.

15:20:53 <SteveBattle> +0.5

Steve Battle: +0.5

15:20:53 <ahaller2> can we co-locate it with some related conference, ac meeting?

Armin Haller: can we co-locate it with some related conference, ac meeting?

15:20:53 <ericP> +1

Eric Prud'hommeaux: +1

15:20:54 <rgarcia> +0.75

Raúl García Castro: +0.75

15:20:57 <cygri> STRAWPOLL: Who could go to U.S. east coast?

STRAWPOLL: Who could go to U.S. east coast?

15:20:58 <roger> +1

Roger Menday: +1

15:20:59 <oberger> +0.5

Olivier Berger: +0.5

15:21:00 <davidwood> +1

David Wood: +1

15:21:00 <BartvanLeeuwen> +0.5

Bart van Leeuwen: +0.5

15:21:00 <svillata> +0.5

Serena Villata: +0.5

15:21:01 <betehess> +1

Alexandre Bertails: +1

15:21:01 <sandro> +1

Sandro Hawke: +1

15:21:01 <Ruben> +1

Ruben Verborgh: +1

15:21:01 <cygri> +0.2

Richard Cyganiak: +0.2

15:21:03 <SteveS> +1

Steve Speicher: +1

15:21:04 <Ashok_Malhotra> +1

+1

15:21:05 <ArnaudLH> +1

Arnaud Le Hors: +1

15:21:05 <krp> +0.5

Kevin Page: +0.5

15:21:05 <ericP> +①

Eric Prud'hommeaux: +①

15:21:26 <Ruben> *for tpacbot*

Ruben Verborgh: *for tpacbot*

15:24:15 <Ashok_Malhotra> SteveS:  I can look into Raleigh, NC

Steve Speicher: I can look into Raleigh, NC

15:24:56 <oberger> SteveS, do you have a cheap flight plan from london ?

Olivier Berger: SteveS, do you have a cheap flight plan from london ?

15:25:01 <Ashok_Malhotra> Arnaud:  can we narrow down timing

Arnaud Le Hors: can we narrow down timing

15:25:37 <Ashok_Malhotra> sandro:  Suggest march 27/28 -- MIT Spring break

Sandro Hawke: Suggest march 27/28 -- MIT Spring break

15:25:49 <rgarcia> that week is Easter

Raúl García Castro: that week is Easter

15:25:53 <rgarcia> at least in Spain

Raúl García Castro: at least in Spain

15:27:34 <SteveS> oberger, american airline flight is usually not bad LHR-RDU $1,200 USD atm

Steve Speicher: oberger, american airline flight is usually not bad LHR-RDU $1,200 USD atm

15:27:52 <oberger> ouch

Olivier Berger: ouch

15:28:27 <Ashok_Malhotra> Arnaud:  Week of March 12?

Arnaud Le Hors: Week of March 12?

15:31:25 <Ashok_Malhotra> oberger: Asks about what we will discuss

Olivier Berger: Asks about what we will discuss

15:32:13 <oberger> for expenses reason

Olivier Berger: for expenses reason

15:32:15 <Ashok_Malhotra> Bart:  March 14/16 may work

Bart van Leeuwen: March 14/16 may work

15:33:05 <Ashok_Malhotra> Discussion about whether a Video Conferencing facility would be available

Discussion about whether a Video Conferencing facility would be available

15:34:03 <oberger> Nice at Eurecom maybe

Olivier Berger: Nice at Eurecom maybe

15:34:09 <Ashok_Malhotra> Eric:  I would book rooms for 14/15 March

Eric Prud'hommeaux: I would book rooms for 14/15 March

15:34:21 <sandro> Eric, Done.

Sandro Hawke: Eric, Done.

15:34:27 <svillata> I'll check for video conferencing facility in Nice

Serena Villata: I'll check for video conferencing facility in Nice

15:34:32 <oberger> I mean, for a videoconference room

Olivier Berger: I mean, for a videoconference room

15:35:34 <ahaller2> @davidwood, if you are after great weather, come to Australia in March

Armin Haller: @davidwood, if you are after great weather, come to Australia in March

15:35:52 <Ashok_Malhotra> Arnaud:  I will sort it out and put some proposals before the WG

Arnaud Le Hors: I will sort it out and put some proposals before the WG

15:36:05 <davidwood> ahaller2, maybe earlier for mango season.  Yum!

David Wood: ahaller2, maybe earlier for mango season. Yum!

15:38:20 <cygri> summary: Next F2F likely to be held on the U.S. east coast in March. Oracle (NYC or Raleigh) and MIT (Cambridge) look into hosting.
15:36:21 <Ashok_Malhotra> Topic:  Dinner

5. Dinner

15:36:40 <Ashok_Malhotra> Arnaud:  Who can join the group fro dinner

Arnaud Le Hors: Who can join the group fro dinner

15:36:53 <Ashok_Malhotra> 16 or 17 people

16 or 17 people

15:37:12 <Ashok_Malhotra> ... close to 20 people

... close to 20 people

15:38:04 <oberger> ArnaudLH, Les Adrets maybe ?

Olivier Berger: ArnaudLH, Les Adrets maybe ?

15:38:14 <oberger> dunno if as cheap (kinda)

Olivier Berger: dunno if as cheap (kinda)

15:38:22 <Ashok_Malhotra> Arnaud:  Perhaps same restaurant as the RDF WG dinner

Arnaud Le Hors: Perhaps same restaurant as the RDF WG dinner

15:38:34 <oberger> http://www.lyonresto.com/restaurant-Lyon/restaurant-Les-adrets-Lyon/restaurant-Les-adrets-Lyon-109.html

Olivier Berger: http://www.lyonresto.com/restaurant-Lyon/restaurant-Les-adrets-Lyon/restaurant-Les-adrets-Lyon-109.html

15:38:56 <cygri> http://www.cityvox.fr/restaurants_lyon/le-comptoir-des-marronniers_22595/Profil-Lieu

Richard Cyganiak: http://www.cityvox.fr/restaurants_lyon/le-comptoir-des-marronniers_22595/Profil-Lieu

15:39:21 <cygri> actually http://lecomptoirdesmarronniers.fr/

Richard Cyganiak: actually http://lecomptoirdesmarronniers.fr/

15:39:43 <Ashok_Malhotra> Arnaud:  I see 17 hands ... add 1 for Henry Story

Arnaud Le Hors: I see 17 hands ... add 1 for Henry Story

15:40:53 <bblfish> +1

Henry Story: +1

15:40:57 <Ashok_Malhotra> ... 7:30 PM

... 7:30 PM

15:42:23 <Ashok_Malhotra> TOPIC: ISSUE-20 (Relative URIs in POSTed representations)

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

Summary: 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.

15:41:36 <cygri> ISSUE-20?

Richard Cyganiak: ISSUE-20?

15:41:36 <trackbot> ISSUE-20 -- Identifying and naming POSTed resources -- open

Trackbot IRC Bot: ISSUE-20 -- Identifying and naming POSTed resources -- open

15:41:36 <trackbot> http://www.w3.org/2012/ldp/track/issues/20

Trackbot IRC Bot: http://www.w3.org/2012/ldp/track/issues/20

15:42:09 <timbl> q+

Tim Berners-Lee: q+

15:42:15 <timbl> q-

Tim Berners-Lee: q-

15:42:51 <Ashok_Malhotra> http://www.w3.org/2012/ldp/track/issues/20

http://www.w3.org/2012/ldp/track/issues/20

15:43:57 <Ashok_Malhotra> SteveBattle Introduces the issue

SteveBattle Introduces the issue

15:44:31 <roger> +q

Roger Menday: +q

15:44:35 <betehess> q+ to comment on the use of RDF

Alexandre Bertails: q+ to comment on the use of RDF

15:44:49 <ericP> q+ to ask if this needs to be part of the client contract

Eric Prud'hommeaux: q+ to ask if this needs to be part of the client contract

15:45:33 <timbl> q+

Tim Berners-Lee: q+

15:45:33 <ArnaudLH> ack roger

Arnaud Le Hors: ack roger

15:45:37 <davidwood> q+

David Wood: q+

15:45:44 <cygri> ISSUE-26?

Richard Cyganiak: ISSUE-26?

15:45:44 <trackbot> ISSUE-26 -- creation model for LDP -- open

Trackbot IRC Bot: ISSUE-26 -- creation model for LDP -- open

15:45:44 <trackbot> http://www.w3.org/2012/ldp/track/issues/26

Trackbot IRC Bot: http://www.w3.org/2012/ldp/track/issues/26

15:46:05 <Ashok_Malhotra> Roger:  Issue-26 (above) is related

Roger Menday: ISSUE-26 (above) is related

15:46:27 <oberger> http://maps.google.fr/maps?q=8+Rue+des+Marronniers+-+69002+Lyon&hl=en&ie=UTF8&sll=45.317723,5.43724&sspn=4.557674,11.195068&hnear=8+Rue+des+Marronniers,+69002+Lyon,+Rh�3�4ne,+Rh�3�4ne-Alpes&t=m&z=16

Olivier Berger: http://maps.google.fr/maps?q=8+Rue+des+Marronniers+-+69002+Lyon&hl=en&ie=UTF8&sll=45.317723,5.43724&sspn=4.557674,11.195068&hnear=8+Rue+des+Marronniers,+69002+Lyon,+Rh�3�4ne,+Rh�3�4ne-Alpes&t=m&z=16

15:46:55 <Ashok_Malhotra> ... JohnArwe said it was not a MUST, only a SHOULD

... JohnArwe said it was not a MUST, only a SHOULD

15:47:13 <SteveS> q+

Steve Speicher: q+

15:48:15 <ArnaudLH> ack bete

Arnaud Le Hors: ack bete

15:48:15 <Zakim> betehess, you wanted to comment on the use of RDF

Zakim IRC Bot: betehess, you wanted to comment on the use of RDF

15:49:36 <MacTed> the model is distinct from its serializations...

Ted Thibodeau: the RDF model is distinct from its serializations (Turtle, TriG, RDF...

15:49:36 <ArnaudLH> zakim, who is there?

Arnaud Le Hors: zakim, who is there?

15:49:36 <Zakim> I don't understand your question, ArnaudLH.

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

15:49:41 <Ashok_Malhotra> Betehess:  Cannot have relative URIs in RDF

Alexandre Bertails: Cannot have relative URIs in RDF Abstract Syntax

15:49:52 <sandro> Zakim, who is on the phone?

Sandro Hawke: Zakim, who is on the phone?

15:49:53 <Zakim> On the phone I see St_Clair_3B, MacTed (muted)

Zakim IRC Bot: On the phone I see St_Clair_3B, MacTed (muted)

15:50:03 <Ashok_Malhotra> ... we may have to change the definition

... we may have to change the definition

15:50:05 <sandro> s/RDF/RDF Abstract Syntax
15:50:09 <ericP> q-

Eric Prud'hommeaux: q-

15:50:32 <MacTed> s/the model is distinct from its serializations/the RDF model is distinct from its serializations (Turtle, TriG, RDF/XML, etc.)/
15:50:39 <sandro> q+

Sandro Hawke: q+

15:50:46 <SteveBattle> q+

Steve Battle: q+

15:50:54 <cygri> q+

Richard Cyganiak: q+

15:51:00 <ArnaudLH> ack timbl

Arnaud Le Hors: ack timbl

15:51:07 <Ashok_Malhotra> Betehess:  Jena, for example, always gives you an absolute URIs

Alexandre Bertails: Jena, for example, always gives you an absolute URIs when serializing or deserialising, but you can do it manually

15:51:45 <betehess> s/ always gives you an absolute URIs/ always gives you an absolute URIs when serializing or deserialising, but you can do it manually/
15:51:56 <sandro> timbl: I come to this, with using like N3 like a programming language.  URIs are like variables, and I use their short names, by using relative URIs

Tim Berners-Lee: I come to this, with using like N3 like a programming language. URIs are like variables, and I use their short names, by using relative URIs [ Scribe Assist by Sandro Hawke ]

15:52:12 <bblfish> back, sorry to be late

Henry Story: back, sorry to be late

15:52:21 <sandro> timbl: when I'm writing Turtle all the time, I define lots of URIs locally in the document, with relative URIs.

Tim Berners-Lee: when I'm writing Turtle all the time, I define lots of URIs locally in the document, with relative URIs. [ Scribe Assist by Sandro Hawke ]

15:52:22 <Ashok_Malhotra> Tim:  Use of relative URis are, in my view, crucial

Tim Berners-Lee: Use of relative URis are, in my view, crucial

15:52:45 <betehess> timbl and I raised an issue a while ago re: jena https://issues.apache.org/jira/browse/JENA-132

Alexandre Bertails: timbl and I raised an issue a while ago re: jena https://issues.apache.org/jira/browse/JENA-132

15:53:09 <sandro> timbl: When you're processing the document you don't worry/care about the absolute URI at all.      cwm has always used relative URIs -- which may resolve at file: URIs when I'm running it in the filesystem

Tim Berners-Lee: When you're processing the document you don't worry/care about the absolute URI at all. cwm has always used relative URIs -- which may resolve at file: URIs when I'm running it in the filesystem [ Scribe Assist by Sandro Hawke ]

15:53:29 <betehess> q+ to offer other use-cases

Alexandre Bertails: q+ to offer other use-cases

15:53:39 <sandro> timbl: Then I can serve that from Apache without blinking, with the relateive URIs resolving to be http ones.

Tim Berners-Lee: Then I can serve that from Apache without blinking, with the relateive URIs resolving to be http ones. [ Scribe Assist by Sandro Hawke ]

15:53:49 <oberger> ArnaudLH, I have made a reservation giving your name and my phone number

Olivier Berger: ArnaudLH, I have made a reservation giving your name and my phone number

15:53:57 <sandro> timbl: sometimes it's proxied to another server, and comes out relative to that proxy address.

Tim Berners-Lee: sometimes it's proxied to another server, and comes out relative to that proxy address. [ Scribe Assist by Sandro Hawke ]

15:54:34 <sandro> timbl: Sometimes there's a bug because there's a an absolute URI like localhost:5876 something

Tim Berners-Lee: Sometimes there's a bug because there's a an absolute URI like localhost:5876 something [ Scribe Assist by Sandro Hawke ]

15:55:05 <sandro> timbl: Someone makes a to-do list, and if it uses relative URIs they can move it around.

Tim Berners-Lee: Someone makes a to-do list, and if it uses relative URIs they can move it around. [ Scribe Assist by Sandro Hawke ]

15:55:18 <ArnaudLH> q?

Arnaud Le Hors: q?

15:55:54 <Ashok_Malhotra> Tim:  Explains that he uses relative URIs as local vraibles in a programming language

Tim Berners-Lee: Explains that he uses relative URIs as local vraibles in a programming language

15:56:00 <ArnaudLH> ack david

Arnaud Le Hors: ack david

15:56:01 <sandro> timbl: It would give me a big pain on this, if LDP servers gave back relative URIs.     Server should be able to store and server everything relative.

Tim Berners-Lee: It would give me a big pain on this, if LDP servers gave back relative URIs. Server should be able to store and server everything relative. [ Scribe Assist by Sandro Hawke ]

15:56:02 <oberger> http://lecomptoirdesmarronniers.fr/

Olivier Berger: http://lecomptoirdesmarronniers.fr/

15:56:21 <Ashok_Malhotra> ... would be a big problem if they were prophibited

... would be a big problem if they were prophibited

15:56:46 <SteveBattle> Wasn't that "didn't serve relative URIs"?

Steve Battle: Wasn't that "didn't serve relative URIs"?

15:56:48 <Ashok_Malhotra> s/prophibited/prophibited
15:57:09 <Ashok_Malhotra> s/prophibited/prohibited
15:57:47 <Ashok_Malhotra> DavidWood:  Expalins how he uses URis in Callamachis

David Wood: Expalins how he uses URis in Callamachis

15:58:22 <Ashok_Malhotra> ... so you post to a container and provided a slug and you are good

... so you post to a container and provided a slug and you are good

15:58:38 <Ashok_Malhotra> ... slug is a header ... it's a hint

... slug is a header ... it's a hint

15:58:54 <ArnaudLH> ack steves

Arnaud Le Hors: ack steves

15:58:59 <Ashok_Malhotra> SteveS:

Steve Speicher:

15:59:17 <oberger> davidwood, is a slug http://en.wikipedia.org/wiki/Slug ?

Olivier Berger: davidwood, is a slug http://en.wikipedia.org/wiki/Slug ?

15:59:21 <Ashok_Malhotra> Question is what do you put in the RDF

Question is what do you put in the RDF

15:59:41 <Ashok_Malhotra> DavidWood:  We don't typically self reference

David Wood: We don't typically self reference

16:01:10 <oberger> http://en.wikipedia.org/wiki/Clean_URL#Slug

Olivier Berger: http://en.wikipedia.org/wiki/Clean_URL#Slug

16:01:19 <roger> shame, but, have to go ...

Roger Menday: shame, but, have to go ...

16:01:24 <ArnaudLH>  slug: http://bitworking.org/projects/atom/draft-ietf-atompub-protocol-13.html#rfc.section.9.6

Arnaud Le Hors: slug: http://bitworking.org/projects/atom/draft-ietf-atompub-protocol-13.html#rfc.section.9.6

16:01:39 <ArnaudLH> ack sandro

Arnaud Le Hors: ack sandro

16:02:10 <davidwood> Callimachus documentation for creating resources: http://code.google.com/p/callimachus/wiki/REST_API#CRUD_Operatons_on_BLOB_Content

David Wood: Callimachus documentation for creating resources: http://code.google.com/p/callimachus/wiki/REST_API#CRUD_Operatons_on_BLOB_Content

16:02:21 <oberger> <#new>

Olivier Berger: <#new>

16:02:33 <Ashok_Malhotra> Sandro:  This is not a problem with the RDF model

Sandro Hawke: This is not a problem with the RDF model

16:02:45 <ArnaudLH> q?

Arnaud Le Hors: q?

16:02:55 <ArnaudLH> ack steveb

Arnaud Le Hors: ack steveb

16:03:19 <betehess> https://issues.apache.org/jira/browse/JENA-132

Alexandre Bertails: https://issues.apache.org/jira/browse/JENA-132

16:03:27 <Ashok_Malhotra> SteveBattle:  With Turtle you can send t but not consume it

Steve Battle: With Turtle you can sendbut not consume it

16:03:36 <Ashok_Malhotra> ... other situations work

... other situations work

16:04:05 <Ashok_Malhotra> s/ t /t /
16:04:48 <betehess> [[ Tim - this is not a bug. A bug would be where it does something wrong and the writer writes something that can't be parsed or isn't the RDF given as input.

Alexandre Bertails: [[ Tim - this is not a bug. A bug would be where it does something wrong and the writer writes something that can't be parsed or isn't the RDF given as input.

16:04:49 <betehess> ]]

Alexandre Bertails: ]]

16:04:55 <MacTed> s/sendt /send/
16:05:05 <cygri> q?

Richard Cyganiak: q?

16:05:08 <bblfish> q+

Henry Story: q+

16:05:59 <ArnaudLH> ack cygri

Arnaud Le Hors: ack cygri

16:06:03 <Ashok_Malhotra> SteveBattle: Even with the slug it is a NULL relative URI

Steve Battle: Even with the slug it is a NULL relative URI

16:07:00 <Ashok_Malhotra> Richard:  You post a something and it has a relative URI ... waht do we say about turning it into an absolute URI

Richard Cyganiak: You post a something and it has a relative URI ... waht do we say about turning it into an absolute URI

16:07:09 <krp> http://tools.ietf.org/html/rfc3986#page-26

Kevin Page: http://tools.ietf.org/html/rfc3986#page-26

16:07:15 <cygri> http://tools.ietf.org/html/rfc3986#section-5.1

Richard Cyganiak: http://tools.ietf.org/html/rfc3986#section-5.1

16:07:18 <SteveBattle> q+

Steve Battle: q+

16:08:47 <timbl> q+

Tim Berners-Lee: q+

16:09:08 <Ashok_Malhotra> ... there are general rules about converting relative URI to absolute URis.  We should not do anything against these rules but they do not

... there are general rules about converting relative URI to absolute URis. We should not do anything against these rules but they do not

16:09:18 <timbl> q+ to say that the only logical way is to make the base the newly created URI.

Tim Berners-Lee: q+ to say that the only logical way is to make the base the newly created URI.

16:09:19 <Ashok_Malhotra> completelty specufy the behaviour

completelty specufy the behaviour

16:09:24 <MacTed> POST targets a service.  *nothing* should be tied to that target URI thenceforth.

Ted Thibodeau: POST targets a service. *nothing* should be tied to that target URI thenceforth.

16:09:51 <ArnaudLH> ack bete

Arnaud Le Hors: ack bete

16:09:51 <Zakim> betehess, you wanted to offer other use-cases

Zakim IRC Bot: betehess, you wanted to offer other use-cases

16:09:56 <cygri> MacTed, reference?

Richard Cyganiak: MacTed, reference?

16:09:57 <Ashok_Malhotra> ... there could be different ways of handling this

... there could be different ways of handling this

16:10:35 <ericP> btw, http://www.w3.org/TR/turtle/#sec-iri ¶2 says a little about relative and basee IRIs. normative text in http://www.w3.org/TR/turtle/#sec-iri-references

Eric Prud'hommeaux: btw, http://www.w3.org/TR/turtle/#sec-iri ¶2 says a little about relative and basee IRIs. normative text in http://www.w3.org/TR/turtle/#sec-iri-references

16:11:18 <ericP> q+ to ask what heppens if we don't speak about it (consider it container configuration)

Eric Prud'hommeaux: q+ to ask what heppens if we don't speak about it (consider it container configuration)

16:12:33 <Ashok_Malhotra> Betehess: This question is the same for GET and PUT ... I use the Web as a database ... I go back and forth with relative URIs

Alexandre Bertails: This question is the same for GET and PUT ... I use the Web as a database ... I go back and forth with relative URIs

16:12:35 <cygri> disagree with betehess that it's teh same for GET and PUT. For those, the base URI *is* the request URI, full stop.

Richard Cyganiak: disagree with betehess that it's teh same for GET and PUT. For those, the base URI *is* the request URI, full stop.

16:13:12 <webr3> cygri, false, it's specified by content-location

Nathan Rixham: cygri, false, it's specified by content-location

16:13:23 <cygri> webr3, reference?

Richard Cyganiak: webr3, reference?

16:13:26 <MacTed> http://tools.ietf.org/html/rfc2616#section-9.5

Ted Thibodeau: http://tools.ietf.org/html/rfc2616#section-9.5

16:13:33 <timbl> q+

Tim Berners-Lee: q+

16:13:37 <ArnaudLH> ack bblfish

Arnaud Le Hors: ack bblfish

16:13:43 <betehess> I don't disagree with cygri the way he put it

Alexandre Bertails: I don't disagree with cygri the way he put it

16:14:24 <betehess> cygri, when I say "it's the same", I realized that it's not exactly, based on your comments re: the URI spec

Alexandre Bertails: cygri, when I say "it's the same", I realized that it's not exactly, based on your comments re: the URI spec

16:14:27 <Ashok_Malhotra> bblfish:  I agree with Alex ... If you post to a collection and then cannot address what you created that's a bug

Henry Story: I agree with Alex ... If you post to a collection and then cannot address what you created that's a bug

16:14:35 <ArnaudLH> ack steveb

Arnaud Le Hors: ack steveb

16:14:44 <MacTed> ``The action performed by the POST method might not result in a resource that can be identified by a URI. In this case, either 200 (OK) or 204 (No Content) is the appropriate response status, depending on whether or not the response includes an entity that describes the result.``

Ted Thibodeau: ``The action performed by the POST method might not result in a resource that can be identified by a URI. In this case, either 200 (OK) or 204 (No Content) is the appropriate response status, depending on whether or not the response includes an entity that describes the result.``

16:14:58 <Ashok_Malhotra> SteveBattle:  RFC 3096 is talking about retrieval context

Steve Battle: RFC 3986 is talking about retrieval context

16:15:13 <sandro> +1 SteveBattle -- with POST there is no retreival context, so we drop through the onion

Sandro Hawke: +1 SteveBattle -- with POST there is no retreival context, so we drop through the onion

16:15:19 <timbl> While cycgri's analysis of the HTTP RFC, that may seem to be a way to read the spec, but in that case th LDP has to claify and be logical here.

Tim Berners-Lee: While cycgri's analysis of the HTTP RFC, that may seem to be a way to read the spec, but in that case th LDP has to claify and be logical here.

16:15:20 <cygri> MacTed, but that's not applicable here. In our case, the POST results in a resource that can be identified by a URI.

Richard Cyganiak: MacTed, but that's not applicable here. In our case, the POST results in a resource that can be identified by a URI.

16:15:42 <sandro> SteveBattle: Base URI in content may still be there, ... then we skip to 5.1.4 to App-Dependent

Steve Battle: Base URI in content may still be there, ... then we skip to 5.1.4 to App-Dependent [ Scribe Assist by Sandro Hawke ]

16:15:56 <oberger> s/3096/3986/
16:16:03 <Ashok_Malhotra> Arnaud:  We understand the issue and understand the different points of view

Arnaud Le Hors: We understand the issue and understand the different points of view

16:16:07 <MacTed> cygri - but there's *nothing* that says that the new resource's URI has any connection to the POST target URI.

Ted Thibodeau: cygri - but there's *nothing* that says that the new resource's URI has any connection to the POST target URI.

16:16:31 <SteveBattle> Exactly - it's application dependent.

Steve Battle: Exactly - it's application dependent.

16:16:37 <MacTed> http://tools.ietf.org/html/rfc2616#section-14.30

Ted Thibodeau: http://tools.ietf.org/html/rfc2616#section-14.30

16:16:48 <cygri> MacTed, the question is about what's the base URI in a POST *request*, not what happens afterward

Richard Cyganiak: MacTed, the question is about what's the base URI in a POST *request*, not what happens afterward

16:16:53 <svillata> q?

Serena Villata: q?

16:16:58 <sandro> PROPOSED: Close ISSUE-20 saying we're okay with the design in the FPWD

PROPOSED: Close ISSUE-20 saying we're okay with the design in the FPWD

16:17:03 <ArnaudLH> ack timbl

Arnaud Le Hors: ack timbl

16:17:03 <Zakim> timbl, you wanted to say that the only logical way is to make the base the newly created URI. and to

Zakim IRC Bot: timbl, you wanted to say that the only logical way is to make the base the newly created URI. and to

16:17:20 <MacTed> +1 timbl "the only logical way is to make the base the newly created URI"

Ted Thibodeau: +1 timbl "the only logical way is to make the base the newly created URI"

16:17:23 <sandro> q+

Sandro Hawke: q+

16:17:26 <Ashok_Malhotra> Tim:  We have to make something that is consistent and logical

Tim Berners-Lee: We have to make something that is consistent and logical

16:17:28 <cygri> q+

Richard Cyganiak: q+

16:17:42 <sandro> q- later

Sandro Hawke: q- later

16:18:00 <Ashok_Malhotra> ... the base URI has to be the URI of the resource

... the base URI has to be the URI of the resource

16:18:35 <sandro> timbl: Another reason for this relative-URI reading is that it saves the server having to parse and re-serialize the content

Tim Berners-Lee: Another reason for this relative-URI reading is that it saves the server having to parse and re-serialize the content [ Scribe Assist by Sandro Hawke ]

16:18:38 <Ashok_Malhotra> ... if the base URI is different when I Post and when I get you have to re-serialize the file

... if the base URI is different when I Post and when I get you have to re-serialize the file

16:18:48 <cygri> q+

Richard Cyganiak: q+

16:18:48 <webr3> For reference: http://lists.w3.org/Archives/Public/ietf-http-wg/2012OctDec/0132.html

Nathan Rixham: For reference: http://lists.w3.org/Archives/Public/ietf-http-wg/2012OctDec/0132.html

16:18:55 <webr3> this came up on IETF a week or so ago

Nathan Rixham: this came up on IETF a week or so ago

16:19:01 <sandro> timbl: also, some versions of URI spec said <> always was self-references, regardless of any base

Tim Berners-Lee: also, some versions of URI spec said <> always was self-references, regardless of any base [ Scribe Assist by Sandro Hawke ]

16:19:04 <cygri> webr3, nice find

Richard Cyganiak: webr3, nice find

16:19:22 <ArnaudLH> q?

Arnaud Le Hors: q?

16:19:34 <ArnaudLH> ack eric

Arnaud Le Hors: ack eric

16:19:34 <Zakim> ericP, you wanted to ask what heppens if we don't speak about it (consider it container configuration)

Zakim IRC Bot: ericP, you wanted to ask what heppens if we don't speak about it (consider it container configuration)

16:19:40 <webr3> "If Content-Location is included in a request message, then it MAY be interpreted by the origin server as an indication of where the user agent originall y obtained the content of the enclosed representation" ... "A Content-Location field received in a request message is transitory information that SHOULD NOT be saved with other representation metadata for use in later responses."

Nathan Rixham: "If Content-Location is included in a request message, then it MAY be interpreted by the origin server as an indication of where the user agent originall y obtained the content of the enclosed representation" ... "A Content-Location field received in a request message is transitory information that SHOULD NOT be saved with other representation metadata for use in later responses."

16:19:49 <bblfish> q+

Henry Story: q+

16:20:12 <Ashok_Malhotra> EricP:  What happens if we do not specify this ... how much depends on this

Eric Prud'hommeaux: What happens if we do not specify this ... how much depends on this

16:20:30 <Ashok_Malhotra> ... leave the spec as is

... leave the spec as is

16:20:32 <sandro> SteveBattle: If we get rid of this, it's harder to do testing, for one thing.

Steve Battle: If we get rid of this, it's harder to do testing, for one thing. [ Scribe Assist by Sandro Hawke ]

16:20:58 <bblfish> yes

Henry Story: yes

16:21:03 <betehess> the current wording is missing the 201 Created

Alexandre Bertails: the current wording is missing the 201 Created

16:21:13 <Ashok_Malhotra> EricP:  If we specify the rewrite rules do we lose interoperability

Eric Prud'hommeaux: If we specify the rewrite rules do we lose interoperability

16:21:40 <Ashok_Malhotra> bblfish:  If folks treat relative URIs differently there is going to me a mess

Henry Story: If folks treat relative URIs differently there is going to me a mess

16:21:48 <Ashok_Malhotra> ... this is an important issue

... this is an important issue

16:22:05 <betehess> q?

Alexandre Bertails: q?

16:22:46 <Ashok_Malhotra> EricP:  If two servers have different rules then is the client libraries as les usable ...

Eric Prud'hommeaux: If two servers have different rules then is the client libraries as les usable ...

16:23:36 <MacTed> Zakim, unmute me

Ted Thibodeau: Zakim, unmute me

16:23:36 <Zakim> MacTed should no longer be muted

Zakim IRC Bot: MacTed should no longer be muted

16:23:37 <Ashok_Malhotra> bblfish, Tim:  You cannot be inconsistent

bblfish, Tim: You cannot be inconsistent

16:24:36 <Ashok_Malhotra> Ted:  When you POST you have no control over what the server does

Ted Thibodeau: When you POST you have no control over what the server does

16:24:37 <sandro> MacTed: When you POST, you have no real control over what the server does.

Ted Thibodeau: When you POST, you have no real control over what the server does. [ Scribe Assist by Sandro Hawke ]

16:25:34 <bblfish> let's take an example where the semantics are clear

Henry Story: let's take an example where the semantics are clear

16:25:34 <Ashok_Malhotra> ... there is nothing that says what comes back has any relation to what you posted

... there is nothing that says what comes back has any relation to what you posted

16:25:45 <sandro> timbl: With the spec, POST is well defined.

Tim Berners-Lee: With the spec, POST is well defined. [ Scribe Assist by Sandro Hawke ]

16:26:17 <sandro> timbl: the only option the server has is to pick the location, with LDP.

Tim Berners-Lee: the only option the server has is to pick the location, with LDP. [ Scribe Assist by Sandro Hawke ]

16:26:27 <MacTed> http://tools.ietf.org/html/rfc2616#section-9.6

Ted Thibodeau: http://tools.ietf.org/html/rfc2616#section-9.6

16:26:36 <Ashok_Malhotra> OBerger:  Are we discussing creation or adding to a container

Olivier Berger: Are we discussing creation or adding to a container

16:27:29 <betehess> q+

Alexandre Bertails: q+

16:27:37 <sandro> sandro: MacTed, we're refining HTTP, being more specific about the behavior of certain (LDP) resources.

Sandro Hawke: MacTed, we're refining HTTP, being more specific about the behavior of certain (LDP) resources. [ Scribe Assist by Sandro Hawke ]

16:28:18 <sandro> q?

Sandro Hawke: q?

16:28:19 <ArnaudLH> ack cygri

Arnaud Le Hors: ack cygri

16:28:34 <Ashok_Malhotra> Ted:  The POST URI has no bearing on the resource ...

Ted Thibodeau: The POST URI has no bearing on the resource ...

16:28:49 <MacTed> Zakim, mute me

Ted Thibodeau: Zakim, mute me

16:28:49 <Zakim> MacTed should now be muted

Zakim IRC Bot: MacTed should now be muted

16:28:52 <sandro> cygri: I found tims argument about <> being always self-reference to be fairly compelling.

Richard Cyganiak: I found tims argument about <> being always self-reference to be fairly compelling. [ Scribe Assist by Sandro Hawke ]

16:29:12 <betehess> does the order of the triples matters as well?

Alexandre Bertails: does the order of the triples matters as well?

16:29:17 <SteveS> q+

Steve Speicher: q+

16:29:24 <sandro> cygri: but the URI spec isn't quite clear about this.

Richard Cyganiak: but the URI spec isn't quite clear about this. [ Scribe Assist by Sandro Hawke ]

16:29:35 <SteveBattle> q+

Steve Battle: q+

16:29:56 <Ashok_Malhotra> Cygri:  We can escalate the issue

Richard Cyganiak: We can escalate the issue

16:30:09 <Ashok_Malhotra> Tim:  This spec uses HTTP in a special way

Tim Berners-Lee: This spec uses HTTP in a special way

16:30:11 <bblfish> +1 for cygri's summary: The logical proof of the interpretation of the base URI is that if you POST to a server that returns byte-for-byte what you sent, and if we take the Location header in the 201 into account, then you need to interpret the base as the location, since GET is

Henry Story: +1 for cygri's summary: The logical proof of the interpretation of the base URI is that if you POST to a server that returns byte-for-byte what you sent, and if we take the Location header in the 201 into account, then you need to interpret the base as the location, since GET is

16:30:14 <bblfish> Q+

Henry Story: Q+

16:30:50 <ArnaudLH> ack sandro

Arnaud Le Hors: ack sandro

16:31:28 <Ashok_Malhotra> Arnaud:  Not sure we are converging

Arnaud Le Hors: Not sure we are converging

16:31:32 <davidwood> q+ to ask whether a use of a Slug: header allows me to be compliant or not.  Section 5.4 seems to be ambiguous on that...

David Wood: q+ to ask whether a use of a Slug: header allows me to be compliant or not. Section 5.4 seems to be ambiguous on that...

16:31:44 <sandro> PROPOSED: Close ISSUE-20 saying we're okay with the design in the FPWD.   <> is self-reference within LDP operations, at least.

PROPOSED: Close ISSUE-20 saying we're okay with the design in the FPWD. <> is self-reference within LDP operations, at least.

16:31:54 <SteveBattle> +1

Steve Battle: +1

16:31:57 <Ashok_Malhotra> Sandro:  I'm hearing consensus in the room just questions about the larger implications

Sandro Hawke: I'm hearing consensus in the room just questions about the larger implications

16:32:10 <sandro> +1

Sandro Hawke: +1

16:32:11 <antonis> +1

Antonis Loizou: +1

16:32:15 <ahaller2> +1

Armin Haller: +1

16:32:18 <rgarcia> +1

Raúl García Castro: +1

16:32:21 <SteveS> +1

Steve Speicher: +1

16:32:21 <timbl> +1

Tim Berners-Lee: +1

16:32:22 <ArnaudLH> +1

Arnaud Le Hors: +1

16:32:24 <bblfish> +1

Henry Story: +1

16:32:28 <Ruben> +1

Ruben Verborgh: +1

16:32:35 <svillata> +1

Serena Villata: +1

16:32:39 <nmihindu> +1

Nandana Mihindukulasooriya: +1

16:32:46 <Ashok_Malhotra> Arnaud:  We have other HTTP experts, they can comment on this and if they disagree we can reopen the issue

Arnaud Le Hors: We have other HTTP experts, they can comment on this and if they disagree we can reopen the issue

16:32:58 <davidwood> +0.5, modulo my question above

David Wood: +0.5, modulo my question above

16:33:11 <davidwood> q-

David Wood: q-

16:33:12 <betehess> +1, but there are still some issues with what's currently in the spec right now

Alexandre Bertails: +1, but there are still some issues with what's currently in the spec right now

16:33:28 <timbl> I would like, ideally, for explicitly it to say that the base URI for the posted data is the URI of the new created resource.

Tim Berners-Lee: I would like, ideally, for explicitly it to say that the base URI for the posted data is the URI of the new created resource.

16:33:28 <SteveS> q-

Steve Speicher: q-

16:33:29 <ArnaudLH> ack bblfish

Arnaud Le Hors: ack bblfish

16:33:40 <MacTed> if the server returns it byte-by-byte, it will still be relative!

Ted Thibodeau: if the server returns it byte-by-byte, it will still be relative!

16:33:45 <cygri> +0.5. would still like to see confirmation that it's okay from the people directly involved with the HTTP/URI

Richard Cyganiak: +0.5. would still like to see confirmation that it's okay from the people directly involved with the HTTP/URI

16:33:51 <sandro> bblfish: This is the ONLY consistently, logical interpretation, if the server sends back a location header.

Henry Story: This is the ONLY consistently, logical interpretation, if the server sends back a location header. [ Scribe Assist by Sandro Hawke ]

16:35:04 <MacTed> <> should remain shorthand for base URI -- which *may* be self-reference, but may not, depending on serialization, etc.  Availability of self-reference and other relative reference is vital

Ted Thibodeau: <> should remain shorthand for base URI -- which *may* be self-reference, but may not, depending on serialization, etc. Availability of self-reference and other relative reference is vital

16:35:06 <Ashok_Malhotra> oberger:  Not sure we know what we mean by POST ... create resoaurce or add to container

Olivier Berger: Not sure we know what we mean by POST ... create resoaurce or add to container

16:35:39 <cygri> ISSUE-25?

Richard Cyganiak: ISSUE-25?

16:35:39 <trackbot> ISSUE-25 -- Weak aggregation and strong composition in containers -- open

Trackbot IRC Bot: ISSUE-25 -- Weak aggregation and strong composition in containers -- open

16:35:39 <trackbot> http://www.w3.org/2012/ldp/track/issues/25

Trackbot IRC Bot: http://www.w3.org/2012/ldp/track/issues/25

16:36:05 <sandro> RESOLVED: Close ISSUE-20 saying we're okay with the design in the FPWD.   <> is self-reference within LDP operations, at least.

RESOLVED: Close ISSUE-20 saying we're okay with the design in the FPWD. <> is self-reference within LDP operations, at least.

16:36:20 <cygri> summary: 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.
16:36:29 <betehess> q-

Alexandre Bertails: q-

16:36:35 <ArnaudLH> ack steveb

Arnaud Le Hors: ack steveb

16:37:03 <Ashok_Malhotra> SteveBattle:  I have raised the same issue on HHTPbis ...

Steve Battle: I have raised the same issue on HHTPbis ...

16:37:16 <MacTed> that resolution breaks on Turtle, which allows <> to change from self-reference when base URI changes.  if Turtle isn't usable in LDP operations, ...  we have big trouble.

Ted Thibodeau: that resolution breaks on Turtle, which allows <> to change from self-reference when base URI changes. if Turtle isn't usable in LDP operations, ... we have big trouble.

16:38:12 <cygri> http://lecomptoirdesmarronniers.fr/

Richard Cyganiak: http://lecomptoirdesmarronniers.fr/

16:38:16 <SteveBattle> This doesn't affect use of @base. This proposal just determines the default document base on POST to a container.

Steve Battle: This doesn't affect use of @base. This proposal just determines the default document base on POST to a container.

16:38:36 <MacTed> "<> is self-reference within LDP operations, at least." ?

Ted Thibodeau: "<> is self-reference within LDP operations, at least." ?

16:39:41 <sandro> MacTed, TimBL claimed <> is self-reference.    We're saying that's definitely true within LDP, even if we're not sure about it elsewhere.

Sandro Hawke: MacTed, TimBL claimed <> is self-reference. We're saying that's definitely true within LDP, even if we're not sure about it elsewhere.

16:40:27 <cygri> sandro, MacTed, we're just saying it about POST to a container, really.

Richard Cyganiak: sandro, MacTed, we're just saying it about POST to a container, really.

16:40:36 <SteveBattle> I think the spec should additionally specify something like, "On POST to a container, the default document base is the URI of the created resource."

Steve Battle: I think the spec should additionally specify something like, "On POST to a container, the default document base is the URI of the created resource."

16:40:50 <MacTed> +1 SteveBattle

Ted Thibodeau: +1 SteveBattle

16:42:04 <SteveBattle> Or even clearer, "On POST to a container, the default document base of the POSTed RDF representation is the URI of the created resource."

Steve Battle: Or even clearer, "On POST to a container, the default document base of the POSTed RDF representation is the URI of the created resource."

16:42:05 <betehess> and there were plenty of email on this subject

Alexandre Bertails: and there were plenty of email on this subject

16:42:10 <bblfish> q+

Henry Story: q+

16:42:14 <betehess> explaining why we close it is important as well

Alexandre Bertails: explaining why we close it is important as well

16:42:28 <MacTed> so...   s/RESOLVED: Close ISSUE-20 saying we're okay with the design in the FPWD.   <> is self-reference within LDP operations, at least./RESOLVED: Close ISSUE-20 saying we're okay with the design in the FPWD.   <> is shorthand for base URI in LDP operations, and "On POST to a container, the default document base of the POSTed RDF representation is the URI of the created resource."/

Ted Thibodeau: so... s/RESOLVED: Close ISSUE-20 saying we're okay with the design in the FPWD. <> is self-reference within LDP operations, at least./RESOLVED: Close ISSUE-20 saying we're okay with the design in the FPWD. <> is shorthand for base URI in LDP operations, and "On POST to a container, the default document base of the POSTed RDF representation is the URI of the created resource."/

16:42:34 <Ashok_Malhotra> Arnaud:  People that raise issue should argue why the issue is important

Arnaud Le Hors: People that raise issue should argue why the issue is important

16:42:42 <MacTed> which may require another proposal round.

Ted Thibodeau: which may require another proposal round.

16:43:33 <cygri> MacTed, I think that's consistent with the resolution we made, and good wording. SteveS, you okay with that change?

Richard Cyganiak: MacTed, I think that's consistent with the resolution we made, and good wording. SteveS, you okay with that change?

16:43:36 <SteveBattle> We're discussing the wording of the closure of issue-20.

Steve Battle: We're discussing the wording of the closure of ISSUE-20.

16:43:44 <SteveBattle> Yes.

Steve Battle: Yes.

16:43:56 <SteveBattle> Yes - I agree with the wording.

Steve Battle: Yes - I agree with the wording.

16:45:35 <Zakim> -MacTed

Zakim IRC Bot: -MacTed

16:37:11 <Ruben> Topic: Wrap-up

7. Wrap-up



Formatted by CommonScribe