<SteveBattle> Do we have a hashtag?

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

<oberger> ArnaudLH, are you the owner of @LDPWG ?

<ArnaudLH> oberger: Erik is

<oberger> but #LDPWG may be an interesting hashtag

<betehess> can you avoid uppercase?

<betehess> eg. ldpwg

<oberger> betehess, I guess it doesn matter much for twitter web app

<oberger> but yes lowercase if you will

<davidwood> Yes, twitter tags are case insensitive.

<SteveBattle> Where's the coffee?

<oberger> SteveBattle, shouldn't we ask Zakim ?

<oberger> crappy bots

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

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

<Ruben> This could actually convince a lot of developers to turn to RDF.

<oberger> using coffeescript ?

<davidwood> http://coffeescript.org/

<oberger> let's get it started

<oberger> ArnaudLH, addressing us

Welcome, logistics, short intro round, recap of meeting goals, agenda amendments

<betehess> scribenick: betehess

ArnaudLH: let's go around the table, introduce yourself

ivan: Ivan Herman, W3C semweb lead
... here as an observer

davidwood: David Wood, RDF WG
... but also member of this group

<chong> chong

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

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

<ericP> Eric Prud'hommeaux

<cygri> Richard Cyganiak, DERI

<Ruben> Ruben / Ghent University – iMinds / PhD student Semantic Web & Web APIs

<krp> Kevin Page, University of Oxford

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

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

<SteveS> I'm Steve Speicher from IBM

<svillata> Serena Villata, INRIA Sophia Antipolis

<antonis> Antonis Loizou, post-doc Vrije Universiteit Amsterdam

<ahaller2> Armin Haller

<oberger> Olivier Berger aka oberger/olberger/obergix from Institut Telecom / T�l�com SudParis

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

<SteveBattle> Steve Battle

jonathandray: Jonathan Dray

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

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

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

ArnaudLH: thanks all
... the agenda was a bit of a challenge
... still on the early days
... two main topics
... tried to split everything in chunks
... also tried to take timezones into accounts
... I'm flexible about these things
... as AndyS was the only one to express specific interests in some topics, I'll try to honor them
... no other constraint
... so just tell me to "move on"

davidwood: how many people new to w3c?

[only a few]

ArnaudLH: any question about the process, then just ask
... it's a nice place, don't worry

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

ArnaudLH: I went back to the charter

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

ArnaudLH: we need to start speaking about some stuff
... eg. test suite
... and validator
... lots of discussion during charter writing about ACLs
... some wanted that as a MUST
... could be a disaster for some, but for others, the platform may not make sense without it
... the compromise was: a NOTE defining the requirements
... these are the main deliverables
... also want to discuss next f2f meeting
... the FPWD is basically the SUBMISSION annotated with issues

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

ArnaudLH: we'lll go through the list of issues
... also I want to discuss the path forward to REC
... glad to say that the group seems to have started doing good job
... eg. the FPWD
... again, we do have a charter, we need to try to stick to it as much of possible
... regarding use case and requirements doc, it's a bit different
... not published it yet
... we need to decide what this doc is really about
... steeve did a great job to put it together
... but some stuff does not belong there

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

ArnaudLH: but the plan was to put everything you wanted there first

Ashok_Malhotra: if you add a requirement
... and the spec does not address it
... then it can be a problem

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

ericP: is there something new in the ED since the FPWD?
... where should be look at

SteveS: not change much
... only locally

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

oberger: would like to hear about implementations and validation
... even if it's not mandatory in the charter

<nmihindu> +1

SteveS: wanted to review the path of the spec
... and the schedule

davidwood: maybe a wiki page for listing implementations

ArnaudLH: good idea
... the goal is to discuss the usecase and requirements this morning
... and the spec this afternoon
... is this reasonable for now?

oberger: maybe would like to remind the target of this WG
... eg, yesterday there was discussion about LD for devs
... Javascript was important
... just want to understand the objectives
... would like to understand the stakeholders

ArnaudLH: what's your objective?

oberger: understand better what is out of scope
... so fat, it's about resources and containers
... so people mentioned some other datastructures

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

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

ArnaudLH: the first answer in the charter
... defines the goals
... then the usecase and requirement refine that
... we may conclude that we need something else

oberger: if you look at the usecase, there are plenty of them, some redundant
... only a few requirements
... maybe we'll see a whole range of other things?
... lack of imagination or just people staying on focus?

cigry: we may be missing some stuff
... if you see something like this, just say it
... let's nto brainstorming here at the f2f

ArnaudLH: anybody can make a proposal at any point

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

<davidwood> (linked from the main page under Ongoing Work)

SteveS: just make things as close as possible to what we have

ArnaudLH: let's speak about usecase and requirements
... we already have something good
... we may want to remove things that don't belong there
... normally, you start with that, then you start the docs
... here we started with the spec, we're still editing the UCR doc

<SteveBattle> topic : Use Cases and Requirements

ArnaudLH: there is a good reason for this situation

davidwood: just wanted to mention I created the implementation page
... we can use that to ground the use-case

ArnaudLH: I split the schedule in two
... the steps
... and what's in the doc today
... also, what does it mean to have a requirement not addressed in the spec?
... eg. security is out-of-scope IMO

SteveBattle: people started to collect stories together
... two sections
... existing user stories
... and the use cases

<BartvanLeeuwen> +q

SteveBattle: you find here scienarios
... making the use cases more concrete
... there are 10 of them so far
... there used to be plenty of examples
... they are now somewhere else

[describing a scenario]

scribe: there are also pointers to the issues that were raised

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

scribe: focused on functional requirements
... functional requirement == what do you expect the system to do
... functional is the how

BartvanLeeuwen: is it still open?

SteveBattle: it is still open
... for user stories, just go ahead
... for requirements, just talk to me

SteveS: when I look at user scenarios, looks like we're too restrictive
... eg. imposing 303
... should be in the spec
... response codes are too much detail for example

Ashok_Malhotra: there are other possible solutions
... just pointing out that this is quite open
... so 303 may be too early

SteveBattle: it is quite useful to know some things here
... so it's useful to document
... it's interesting to understand the sequence

SteveS: it's supposed to drive the spec

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

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

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

ericP: when I read UCR, I usely don't know anything
... here I find many details
... maybe you can put that stuff to another page
... and you link those
... then the reader can ground things to examples
... and we can compare different proposals

SteveBattle: use cases are requirements

cygri: this level of details can't be defined here
... there are specific deployment pattern that are used out there

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

cygri: some things are already using 303 for example
... we may have to answer quesitons like to we support X? if not, why?
... that's something I expect to see in the document
... and at the end, we may just say that we recomment something else

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

cygri: people want to say the way they expect this to work
... taking existing deployment into account is a valid point, should not be ignored

SteveS: +1 to eric
... we may have another wiki page
... where we can say how things match between the doc and the spec
... would be bad to have to go back to UCR to change it

ArnaudLH: for me, it's too much about the solution, not defining the solution

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

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

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

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

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

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

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

davidwood: maybe a bit orthogonal
... trying to capture the what and the how

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

davidwood: the where may be missing
... eg. to answer what use-cases are implemented or not
... we need a place to track those
... I agree it's too detalied in term of the guidance
... we would like to say things only once
... don't repeat yourself
... we could change this page to respect the use stories (the why)
... and point to the spec to see where it's discussed

<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

ahaller2: I find this useful to the end-user
... it says hwo to use the platform

ArnaudLH: I think there is great material here
... nobody is saying to throw it out
... question is what's belong here
... what is the spec going to address
... we don't just want to delete any of these
... could be a note, or whatever, we decide that later
... could be a primer as well

krp: could be confusing
... what don't people like here?
... too many steps?
... at least, this is a clear requirement
... could also be a test case

SteveBattle: what do you want to move out?
... it's conventional to speak about the steps

davidwood: the spec speaks about 303 in two places
... also http verbs

<ericP> betehess: what's there is valuable

<ericP> ... it's not about the value itself

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

<svillata> oberger +1

<ericP> ... i want to test the spec, not the user requirement

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

<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

ericP: when I said to split out in different document
... for the time being, this is very useful
... we'll need to re-edit something anyway
... we can insert a note at the beginning
... and use color code
... that states what's to be considered
... and gives fewer places to visit

<Zakim> davidwood, you wanted to suggest starting a test page

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

SteveBattle: we'll propose something

<rgarcia> +1 to convert examples into tests

SteveBattle: still people need to review the scenarios

ArnaudLH: let me try to summarize
... probably too much in the doc
... not sure how to address the p
... some wants to move stuff
... just happy to give SteveBattle a chance to do another pass
... but I don't want to end up saying "this is not what we wanted"
... any concrete proposal?
... if there is too much, we'll need to sort it out

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

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

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

SteveS: wanted to echo something similar

<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

SteveS: phrasing is important
... then we can extract the things depending on what we need

ArnaudLH: we have decided if we needed a primer yet

Ashok_Malhotra: would take all the stuff other than the 2 headers
... could use other colors, this is possible solution
... like davidwood's suggestion to move that to test
... the spec could end up with something very different

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

Ashok_Malhotra: that's fine

ArnaudLH: SHORT BREAK

<oberger> resume at 11:00

<Yves> +1 for a primer

<SteveBattle> +1

<bblfish> hi

<oberger> again a short round of introductions

<ahaller2> Henry Story

<ahaller2> Hadley Beeman

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

<oberger> +1 for primer

<ahaller2> Bart: a primer would be a good idea

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

<oberger> oberger: and bringing a bit more repeating of HTTP in the primer than in the specs would be great

<SteveS> +1 for primer, would be willing to help do

<Zakim> ericP, you wanted to say that tests are allowed to be controversial

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

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

<ahaller2> ... could be done outside of the working group

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

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

<ahaller2> ... who is the audience of the primer

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

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

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

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

<oberger> kinda drinking our own champagne

<ericP> nicely stated

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

<davidwood> oberger, VoID file?

<antonis> @oberger +1

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

<oberger> s/UC/US/ User Story

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

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

<ahaller2> SteveB: use cases should not be vague

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

<ahaller2> ArnaudLH: ericP proposed to annotate the document

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

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

<oberger> so that we can nnotate ?

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

<ahaller2> ... what level are they, user stories vs. use cases

<sandro> oberger, yes, <span id="foo"></span> should survive.

<oberger> sandro, or maybe a less HTML way ?

<sandro> oberger, I don't know a non-HTML way

<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

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

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

<oberger> sandro, so that's similar

<sandro> yes, oberger, same thing

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

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

<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

<ahaller2> steveB: prototype primer for use case details

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

<ahaller2> steveB: detailed scenarios is important for implementers

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

<ahaller2> steveS: webplatform.org

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

<Zakim> cygri, you wanted to talk about test cases

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

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

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

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

<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

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

<ahaller2> davidwood: UCR is up already

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

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

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

<ahaller2> ... surface concerns with straw poll

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

<davidwood> +1 to section-by-section review by the group

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

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

<ahaller2> ... want to know what we add later on

<bblfish> there is a difference between the wiki and the published document

why not going through an issue then?

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

<bblfish> +1 for pingback

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

<SteveS> use case for ping back?

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

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

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

<bblfish> pingback is a use case

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

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

<roger__> i can see a lot of uses for pingback!

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

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

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

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

<ahaller2> ... group member wants a use case, raise an issue

<SteveBattle> +1

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

<cygri> +1

<ArnaudLH> +1

<ericP> +1

<rgarcia> +1

<antonis> +1

<bblfish> +1

<BartvanLeeuwen> +1

+1

<oberger> +1

<ahaller2> +1

<Ruben> +1

<krp> +1

<SteveS> +1

<svillata> +1

<SteveBattle> +1

<nmihindu> +1

<davidwood> +1

<sandro> +1

<ericP> APPROVED

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

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

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

+1 to the dev comment

<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

<oberger> FPWD of the UC&R

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

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

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

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

<ahaller2> ArnaudLH: not right now

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

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

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

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

so do we just use tracker for that as well?

<ahaller2> ... same process, with raising issue

we need a deadline then

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

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

<Zakim> betehess, you wanted to ask about a deadline

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

<nmihindu> q

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

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

<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).

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

+1 to that

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

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

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

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

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

<sandro> suggest 1 December ?

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

too soon for me

<ahaller2> oberger: can steveB still add issues?

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

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

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

<oberger> how many weekly meetings/calls do we need ?

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

<sandro> betehess misunderstood cygri's proposal

<ahaller2> ArnaudLH: we will have to be optimistic

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

<ahaller2> ... two separate deadlines

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

<SteveS> +1

<ArnaudLH> +1

<BartvanLeeuwen> +1

<Ruben> +1

<krp> +1

<rgarcia> +1

<svillata> +1

<bblfish> +1

<antonis> +1

<oberger> ArnaudLH, to propose a timeline tomorow

+1

<ahaller2> +1

<roger__> +1

<nmihindu> +1

<Ashok_Malhotra> +1

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

+1 to eric's remark

<SteveBattle> +1 (and OK with Dec 1 date)

<ericP> +1 to betehess's validation

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

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

<oberger> JohnArwe on the phone

<bblfish> hi JohnArwe

<cygri> oberger, check the agenda :-)

<oberger> cygri, doesn't tell where

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

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

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

<cygri> scribe: cygri

LDP Specification

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

ArnaudLH: We could simply go down the issue list in order.
... To warm up, we could start with some perhaps less controversial issues.

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

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

ArnaudLH: Anyone wants to suggest a particular issue for discussion?

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

[reconciling order of discussion with presence of various participants]

<betehess> closest to my interest: http://www.w3.org/2012/ldp/track/issues/20

<JohnArwe> 23 open according to the server (just above table)

<roger> i have interest in issue 26 - and will (unfortunately) not be here tommorrow ....

<oberger> let's vote on 22 !

<oberger> on discussing 22

subtopic: ISSUE-22 and ISSUE-23 (RDF/XML and JSON-LD)

<ericP> +1

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

<bblfish> +1

<oberger> http://www.w3.org/2012/ldp/track/issues/22

<bblfish> +1

<SteveBattle> +1

ArnaudLH: Turtle is a MUST, we have resolved that already

davidwood: It should be separated from the other formats

<betehess> does these format *have* to support relative URIs in their serializations?

davidwood: Point is to have a consistent policy
... MAY or SHOULD would be consistent

<Zakim> davidwood, you wanted to propose a resolution for ISSUEs 22 and 23

<ahaller2> +1 for SHOULD

<bblfish> 1+

<bblfish> Ntriples would not work because of ISSUE-20

<bblfish> because it does not have relative URIs

<ericP> cygri: re: david's proposal, I preferr to just say that Turtle MUST be supported and say nothing about other formats

<davidwood> ISSUE 20 isn't resolved yet :)

<ericP> ... otherwise we end up in conneg and different representations of the same resource

<davidwood> I have no strong objection to cygri's proposal.

<AndyS> bblfish - strictly, nor does Turtle. It encodes a graph and a graph has resolved absolute URIs.

<Ruben> +1 for no other formats than Turtle

<rgarcia> +1 for only Turtle

<ericP> oberger: shouldn't we discuss conneg?

<Zakim> betehess, you wanted to ask if these formats MUST support relative URIs in their serializations

<ericP> cygri: HTTP already talks about conneg

<ericP> oberger: in an informative section, we could say "of course you can use conneg"

betehess: davidwood's proposal doesn't work because of relative URIs

bblfish: N-Triples doesn't work because of ISSUE-20

davidwood: N-Triples is likely to be a W3C recommendation

<Zakim> timbl, you wanted to suggest "May top connect o other formats" and to suggest "May top conneg o other formats"

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

<oberger> +1 timbl

timbl: "MAY do conneg" may be worth stating to make clear that it's okay to support things beside Turtle
... You may have to specify that Turtle MUST be returned dependent on q value
... q values are an issue in conneg

<Zakim> AndyS, you wanted to say it would have to be a restricted form of Turtle, not all Turtle.

AndyS: Depending on ISSUE-20 resolution, we may have to qualify what we mean by Turtle

<betehess> andy's remark is right

<JohnArwe> what was the common misreading of conneg timbl was talking about? rapid-file syllables didn't make it so well across the pond.

AndyS: 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

ArnaudLH: Let's not talk about opening the resolution that turtle MUST be supported.

<timbl> All my serializers do relative URIs by default and in systems I build that is a fundamentally important thing.

<AndyS> there are other ways to address issue-20 that do not have the relative URI issue and hence any RDF serialization works.

<ericP> cygri: yes

<davidwood> +1 to AndyS

PROPOSAL: MUST use Turtle; MAY do content negotiation with other formats

<Ruben> +1

<bblfish> +1

<oberger> +1

<antonis> +1

<betehess> +1

<ahaller2> +1

<SteveS> +1

<ericP> +1

<BartvanLeeuwen> +1

<ArnaudLH> +1

<rgarcia> +1

<krp> +1

<AndyS> +1 to mentioning conneg somewhere in docs

<nmihindu> +1

<davidwood> +1

<sandro> +1

<webr3> +1 s/suse/support

<svillata> +1

<sandro> SteveBattle: If you don't send an accept header on a GET, will you get Turtle?

<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

<timbl> turtle, otherwise you lose the semantics.)

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

<SteveBattle> +1

<webr3> +1

<davidwood> +1

<sandro> +1

<ArnaudLH> +1

<AndyS> +1

<svillata> +1

<Ruben> +1

<krp> +1

<rgarcia> +1

<BartvanLeeuwen> +1

<bblfish> +1

<ericP> +1

<nmihindu> +1

<antonis> +1

<SteveS> +1

<roger> +1

<betehess> +1 but I believe that we must take into account the case the weights are equal (MUST return Turlte)

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?

<sandro> betehess, I think the resolution is clear about that, as "no preference"

[scribe can't follow]

<davidwood> betehess, the proposal does handle that case because the client has not expressed a preference in that case.

<betehess> sandro, I think it's cheap to speak about a "default"

<sandro> ArnaudLH, is that RESOLVED, in your chair judgement?

<betehess> davidwood, maybe a English issue on my side, but I disagree

RESOLUTION: 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

<sandro> close issue-22

<trackbot> Sorry... closing ISSUE-22 failed, please let sysreq know about it

ArnaudLH: Accordingly, we can close ISSUE-22 and ISSUE-23

guest: JohnArwe
... webr3

<oberger> http://www.w3.org/2012/ldp/track/issues/24

guest: FabGandon
... timbl

subtopic: ISSUE-24

<Zakim> davidwood, you wanted to remind the WG on PURL's DELETE behavior

<ericP> +1 to not saying anything about re-use

davidwood: There are legitimate reasons why a server may not re-use a URL.
... Example, pURLs.
... I strongly recommend we close this issue by stating that servers decide.
... I have a minor preference for including a sentence that states it's up to the server whether deleted URIs can be recycled.

SteveS: Agree, it's application-specific. I also agree it's not a best practice.

<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

Ashok_Malhotra: Reading 4.5.1 in the spec, it reads like you cannot re-use a URI

davidwood: [quotes offending spec text]
... When you create a resource in a container, the server assigns a URI. Server may decide to re-use an existing URI.

<Ruben> I agree with timbl that non-reuse should be that way to go… or we should at least suggest it

timbl: If a resource was deleted, it's URI should never ever be re-used.

<Zakim> betehess, you wanted to offer dev perspective

<AndyS> test -- what about re-PUTing the same content as before?

<ericP> vulnerable to the lost-DELETE variant of the lost-UPDATE problem

<Ruben> side-remark: can be reused for the same resource? (e.g., not 410)

<ericP> party A GETs R1; party B DELETEs R1; party A PUTs R1.

SteveBattle: I agree we should delete 4.5.1 phrasing “until another resource is created”

<ericP> (not a real issue if you are tracking ETags well)

<betehess> when people say "application", is it server-side or client-side?

SteveBattle: There may be valid reasons for restoring a deleted resource

<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

<Ruben> ericP: indeed, that should be possible for the *same* resource

<Zakim> AndyS, you wanted to wonder about implications on containers and adding entries

<Zakim> davidwood, you wanted to disagree with Tim.

timbl: [clarifies that *server*-assigned URIs should never be re-used after deleting]

<AndyS> Some resources e.g. "todays weather" can be reasonably deleted and then PUT.

<betehess> I believe that timbl is restricting his definition to the case we POST to a Container, right?

<bblfish> agree with AndyS that corner cases ( such as undelete ) should be explained as a best practice

davidwood: I suggested earlier that clients should be able to request a certain URI

<Ruben> is there a way to stop clients from not reusing for different resoruces, in case POST is not used?

<Ruben> s/resoruces/resources/

davidwood: If the server needs to track what resources were allocated and deleted, this makes it harder to create a minimal compliant server

<AndyS> agree about server assigned URIs ... but rePUT the original content (it's called "restore" :-) or a correction.

davidwood: Seen in the wild: create a resource, delete it, create it again; because deleting causes housekeeping in the server

<sandro> +1 davidwood allow clients to DELETE and PUT again

<ericP> cygri: we're defining a protocol between a client and a server

<ericP> ... it's important to specify client expectations but not [other] server behavior

<ericP> ... i see this as a best practice about server behavior

<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

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

<betehess> as an implementor, I'd like to know the expected behaviour

timbl: I request a new URI, I want it to be never used before. That's part of the protocol

<bblfish> nathan? on the phone?

<AndyS> webr3?

<webr3> no phone

<betehess> s|webr3?||

<Zakim> Ruben, you wanted to say that recreating the *same* resource is not a problem

<betehess> s|no phone||

<sandro> timbl: I want part of the protocol to be that servers will generate new unique URIs each time

<betehess> s|nathan? on the phone?||

<ericP> timbl: i disagree that this isn't in the protocol [i.e. client expecation]

Ruben: There's a difference between using re-using a URI for the same resource, and using same URI for a different one

<JohnArwe> @webr3, same #s we use for weekly calls

<betehess> s|@webr3, same #s we use for weekly calls||

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.

<davidwood> s/portico/protocol/

<Ruben> +q to say I'm against just removing

ericP: [reads earlier webr3 comment]

<davidwood> +1 to Ruben. Removing the text is not sufficient.

<ArnaudLH> PROPOSAL: delete "until another resource is created or associated with the same Request-URI."

<Ruben> -1 for just deleting, need to clarify what is possible

<sandro> -1 agreed; I want a change proposal, not just to remove it

<davidwood> -1 to just removing

<HadleyBeeman> *wonders if this issue goes back to the old discussion about whether a URI refers to one and only one thing.

<davidwood> HadleyBeeman, yes.

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

<sandro> s/nor/not

<oberger> do we need a "compare" primitive in the servers to be able to determine resource "sameness" ?

<Zakim> ericP, you wanted to say that webr appears had proposed text

<HadleyBeeman> Thanks, davidwood. Pieces falling together :)

<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

[scribe fail]

<roger> not that it changes the issue ...

<Zakim> Ruben, you wanted to say I'm against just removing

<sandro> +1 cygri, you can't delete a resource

antonis: Two separate cases. 1. Remove a resoruce from a container, forever. 2. We want to change a resource, e.g., weather

<sandro> how could you know you'll never want to put a resource back into a container?

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

<bblfish> I'd be for voting on deleting. It's easier

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

<JohnArwe> +1 ruben

<bblfish> but how can you delete a methematical object?

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

<Ruben> bblfish: you can delete it from a server

sandro: You delete a file in the file system, you can create a new one with the same name. Anything else would be absurd

<bblfish> yes, but the resource is the thing pointed by the URI.

oberger: A directory is a container. It's happening in the container.

<Zakim> cygri, you wanted to say you can't PUT a resource

sandro: Deleting in file system is same as HTTP delete

<betehess> cygri: maybe we shouldn't be talking about identity of resource

<betehess> ... rather what happens to the container

<betehess> ... was URI assigned to the server?

<ericP> cygri: we SHOULDn't be talking about DELETing a resource but instead POSTing to a container

<sandro> oberger, I'm not thinking about containers here.

<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

<bblfish> +1

<SteveBattle> +1

<svillata> +1

<betehess> ... what's the constraint on the server?

<sandro> +1

<oberger> verbs CREATE and ADD TO CONTAINER should really be distinguished

<ericP> ... timbl asked about the constraint on the server and the server assigns the URI

<SteveBattle> The constraint is to not generate the same URI twice

<ericP> ... that's the place were we can state more clearly what happens with these URIs

nmihindu: Putting in the spec that it must be the same entity/resource is practically infeasible.

<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

<Ruben> …unless it's a 410, then you know it existed at some time

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.
... We don't know if the resource existed before or not.

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?

<Ruben> 404 doesn't imply permanency… can be 404 before a resource was created

<ericP> bblfish is getting into the contentious space of negative directory caching

BartvanLeeuwen: Isn't there another code for that?

ericP: 410

<ericP> (which was a bane of AFS)

<sandro> http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.htmlhttp://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

<sandro> "10.4.11 410 Gone

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

<Ruben> the 404 can include a reason

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.

<bblfish> yes, thanks. for the 410

<betehess> 410 looks like a difficult constraint to impose in the general case

<betehess> probably good practice

<bblfish> bad practice has a cost

<oberger> wth

<Ruben> *oberger, say q+ to blabla*

<Ruben> *the "to" is important*

<betehess> s|wth||

<betehess> s|q+, suggesting we should we discuss creation and ownership by containers||

ahaller2: Example: server uses hash function to generate URI. Can't guarantee that you get a clash

<betehess> s|q+ suggesting we should we discuss creation and ownership by containers||

timbl: That server will be statistically conforming

JohnArwe: Whether today's weather can be deleted depends on the concept on the server.
... In loosely coupled environment, 410 is useful

<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.)

<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

<bblfish> thanks

<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

<ericP> ... the filesystem analogy is compelling to me

<ericP> ... i agree that server-assigned IDs should only be assigned once

<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

<ericP> ... POST->ID/1 ; POST->ID/1 will of course create problems

<ericP> ... that's two issues to resolve

<Ruben> betehess: this is not REST, but Cool URIs

<ericP> ... third issue: different expecations if the server returns a 404 or a 410

<ericP> ... the HTTP spec says that 410 is permanent, but doesn't say if the client is not supposed to do a PUT

oberger: If we haven't properly discussed creation, then we can't properly discuss deletion. We should discuss ISSUE-25 first.

<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

<betehess> -1 to say that much

<betehess> we would overstep on the http spec

<ericP> - until another resource is created or associated with the same Request-URI.

<ericP> + . The service SHOULD NOT permit the creation of a different resource with the same Request-URI.

<ericP> + Note that HTTP considers any DELETEd resource for which the server returns a 410 Gone to be permanently removed.

<ericP> + A server SHOULD (@@MUST?) NOT permit either a later PUT to a POST to re-create such a resource.

<ericP> + . The service SHOULD NOT create (as a response to a POST) of a different resource with the same Request-URI.

<Zakim> ericP, you wanted to say that sandro's discovery has pushed me to amend web3r's text

<ericP> + . The service SHOULD NOT create (as a response to a POST) a different resource with the same Request-URI.

<timbl> You can't say "a different resource"

<sandro> thinkiing: 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.

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

<timbl> The server should never allocate the same URI twice in response to a POST to a container.

<sandro> thinkiing: 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.

<ericP> scribenick: ericP

<timbl> seconded

oberger: do we have a use case to refer to?

cygri: i think we all know the filesystem use case

betehess: we have no authority over HTTP

sandro: and you know that 404 isn't permanent in HTTP world, right?

<sandro> Yves, are you an HTTP expert?

betehess: we don't have people can tell us how HTTP is used out there

timbl: i perfer to treat 404 and 410 just the same

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

sandro: i'd like to be done with issue 24 and record the fact that we all seem to agree

<SteveBattle> +1

<davidwood> +1

<Ruben> +1

<SteveS> +1

+1

<ahaller2> +1

<BartvanLeeuwen> +1

<sandro> +1

<nmihindu> +1

<betehess> +1

<roger> +1

<rgarcia> +1

<ArnaudLH> +1

<svillata> +1

<ivan> s/Necessaril/necessarily/

<JohnArwe> +1

<timbl> +1

<krp> +1

cygri: i agree, but don't think our spec contains examples of what's already constrained by the HTTP spec
... if it doesn't further constrain the HTTP spec, we shouldn't include it

<betehess> would this is normative or informative?

<betehess> s/this is/this be/

cygri: per this resolution, the spec can remain the same

<sandro> 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.

<webr3> remove "until another resource is created or associated with the same Request-URI." replace with something else

<krp> The words "another" and "created" in combination imply something that isn't intende

<cygri> s/until another resource is created or associated with the same Request-URI/until the state of the resource is changed again/

<rgarcia> +q

cygri: PROPOSED: s/until another resource is created or associated with the same Request-URI/until the state of the resource is changed again/

<Ruben> +1 on cygri's proposal

<webr3> -1

bblfish: we can include text which describes some of the problems
... there are all kinds of consequences about changing a 410

<webr3> propose: s/until another resource is created or associated with the same Request-URI// then have informative text about 404+410 and not cha

<webr3> .. changing the uri's usage

bblfish: e.g. if you check the logs and no one's gotten a 410, then no one knows it's gone

<davidwood> SteveS, I propose removing the phrase and adding a sentence, "Clients should note that severs may reuse a Request-URI under some circumstances."

rgarcia: this should be part of the HTTP guide where we say the behavior of this HTTP verb is X

<Zakim> oberger, you wanted to propose better use cases

oberger: we need use cases
... we have different interpretations of HTTP DELETE

<sandro> +1 cygri -- what HTTP spec says about DELETE is enough

cygri: i'm not convinced we need to go beyond the HTTP spec for DELETE

<betehess> why am I hoping that this issue is already fully solved in HTTP spec? maybe in Fielding's thesis?

<Ruben> betehess: not in F's thesis

cygri: we are bound by HTTP, and we can add specific behavior that distinguishes an LDP server

<timbl> Agree, you should only add constraints to the HTTP spec where you really need to for a special LDP-specific reason.

<FabGandon> +1 cygri (from observer)

<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'''

<SteveBattle> Can we put this issue to bed - pleeeeaaase?

<svillata> +1 cygri

<sandro> no webr3 some of us -1'd that

cygri: i haven't heard us proposing a stronger behavior than HTTP's DELETE

davidwood: doesn't 4.5.2 extend HTTP's DELETE?

<Ruben> *betehess, the text is online, too. I've read it, and it's not there*

cygri: it's a MAY and only talks about how it applies to our resources
... the resource to which we send the DELETE is a web resource which might have an associated RDF resource

ArnaudLH: there's no reason for the text apart from stating what HTTP mandates
... we can remove the offending text or just defer to HTTP

<Ruben> +q

<Zakim> sandro, you wanted to talk about use cases being a sometimes-necessary expense

<oberger> we just say that the server SHOULD "support" DELETE ?

<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)

<davidwood> There is no "Web resource" or "RDF resource". There is only a "resource" associated with a URI.

ArnaudLH: we agree to do what HTTP says, but don't know how to state it

sandro: if someone expects a different behavior than HTTP, than we need to motivate that with a use case (which is an expensive process)

Ashok_Malhotra: we could split removing "until another resource is created or associated with the same Request-URI" and the other text

<Ruben> *betehess: true, he deserved that*

<MacTed> +1 davidwood `There is no "Web resource" or "RDF resource". There is only a "resource" associated with a URI.`

sandro: some of us -1'd simply removing the text

<Zakim> Ruben, you wanted to answer Arnaud's question

<cygri> MacTed, literals are RDF resources but not web resources

<MacTed> nonsense.

Ruben: removing is fine for me
... the phrasing is fine

<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)

<oberger> sandro, out of scope of the current discussion at least

<Ruben> s/the phrasing is fine/it was just the phrasing that could be confusing/

<MacTed> anything nameable and transmissible over the wire may be considered a web resource. literals are nameable and transmissible over the wire.

JohnArwe: i worked on other specs and the convention for imposing normative requirements in addition to the base specs

timbl: i thought that "until another resource is created or associated with the same Request-URI" was gone by mow
... if you put something in a collection, the collection gives you the list that includes that new element

<oberger> s/mow/now/

<krp> even if just a hyperlink to the container section

<cygri> MacTed, refinement: REST resource != RDF resource

timbl: is it worth saying that DELETing a resource removes it from the container?
... or is that clear to any spec reader?

<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"

[general agreement that it's the latter]

<davidwood> SteveS, I propose removing the phrase and adding a sentence, "Clients should note that severs may reuse a Request-URI under some circumstances."

<ahaller2> +1 davidwood

<oberger> request-Uri -> resource URI ?

<SteveBattle> +1 david's wording to replace the grey sentence

<Ruben> +1

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

<oberger> davidwood, request-Uri -> resource URI ?

<cygri> MacTed, RDF resource as defined in RDF 1.1 concepts. REST resource as defined in Fielding's thesis.

<antonis> can we not mention PUT or POST either at this point ?

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

<antonis> +1

<Ruben> +1

+1

<cygri> +1

<rgarcia> +1

<ahaller2> +1

<svillata> +1

<BartvanLeeuwen> +1

<davidwood> +1

<ArnaudLH> +1

<betehess> +1

<sandro> +1

<krp> +1

<nmihindu> +1

<oberger> +1

<webr3> -0 (the use of may kind of enourages bad form - sorry)

<MacTed> +1

<SteveBattle> there was a suggestion to change that to 'resource URI'

<roger> +1

<cygri> Note that it shouldn't be "request URI" as per oberger

<bblfish> -0 I think it's ok. But it is too vague

<SteveS> +1

<MacTed> cygri - I'd like specific links and/or quotation. those kinds of handwaves don't serve anyone well.

<bblfish> so I think the second sentence should go in non normative text

<MacTed> cygri - you seem to be suggesting that RDF resources and REST resources are disjoint, and I firmly disagree with that.

<cygri> MacTed, I said "not equal"

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

<MacTed> a URI is a URI is a URI

<MacTed> the handling of hash HTTP URIs is a client-side concern

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

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

ArnaudLH: imo, there's no impact on 5.6.2

<webr3> suggets issue-6

<cygri> ISSUE-6?

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

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

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

ISSUE-6 -- Should LDBP say that any kind of user-defined simple data type is disallowed?

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

<Ruben> *for tpacbot*

SteveS: feedback is that it is too restrictive
... proposal is to relax to SHOULD

<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

Ashok_Malhotra: heard from folks saying "i'm using this special datatype"
... how are people going to reference a user-defined datatype with a URI?
... there's a doc by jjc telling you how to reference a user-defined datatype using a URI?

s/using a URI\?/using a URI/

cygri: custom datatypes aren't often used in RDF

<JohnArwe> must drop for other calls

cygri: it's not very clear how to find the definition; what should be at the end of the datatype URI?
... jjc's doc talks about how to restrict factets
... if you sort on frequency of datatypes, you see XSD types, misspellings of XSD types, custom types

<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

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

<davidwood> +1 to cygri

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

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

<timbl> Use [ is kg of 2 ]

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

betehess: i disagree that people don't use custom datatypes [2 negatives]
... i use them a lot

cygri: you're in a tiny minority

betehess: people wnat to be able to say what something means in the domain application
... i have types in e.g. java or scala and i want to restrict the permissible values for a string

<SteveBattle> I've also used custom datatypes

betehess: i'm not concearned about SPARQL in my app

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

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

davidwood: i was surprised when i saw this in the spec
... thinking through it, i can see why you'd want to do that in your compliant server
... i don't think i'd want to do it in mine
... 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

<ArnaudLH> a?

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

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

timbl: i think you want to give a name to a system which uses a constrained set of datatypes
... if i'm getting data from some hardware, the value lies in that datatype being transparent
... if you're going to put datatypes in, it's nice to put it in with another arc

<betehess> then please fix the datatype mess in RDF first

<davidwood> +1 to timbl

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

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

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

timbl: i'm excited to talk about relative URLs today

<cygri> ISSUE-20?

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

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

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

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

<MacTed> I generally like davidwood's suggested direction

<Zakim> ericP, you wanted to ask how we increase interop

ahaller: all ontologies i know solve with units of measure patterns

<SteveBattle> Striking it (4.1.9) out completely gets my vote

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

bblfish: there's an assymetric pressure to use standard datatypes
... [hexbinary example]

<bblfish> plust I need hexBinary, which is not on the list

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

<bblfish> ?

betehess: i feel like this is like in the last conversation where we were restricting HTTP
... why not restrict vocabularies, ...?
... i'm not totally motivated by the current deployment

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

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

<webr3> agree w/ bblfish

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

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

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

cygri: XSD types map naturally to language-native datatypes
... others become complex objects
... not that we must always do what JSON does, but one thing makes JSON easy is that you only get native datatypes

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

cygri: is this as a reason to encourage use of standard types

<betehess> this statement just forgets the specific needs of domain specific applications

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

<SteveBattle> -1 to the proposal - I prefer the original proposal to delete 4.1.9

<betehess> my answer: I believe in standards

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

<antonis> davidwood, agree on the difference between my proposal and yours

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

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

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

BartvanLeeuwen: i jumped on RDF because of it's flexibility

<davidwood> antonis, thanks

BartvanLeeuwen: we see geo datatypes, which get some use

<SteveBattle> I think 4.1.9 send the wrong message entirely - kill it!

BartvanLeeuwen: i don't think i've heard a good motivation

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

<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

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

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

timbl: the only think i care about is the MUST
... every time we make a constriant, you cut out users

<Ruben> s/think/thing/

timbl: you could say "you can put anything in here with a PUT", which everyone can use
... you can make a further restriction with interop optimization

<bblfish> MUST

<SteveBattle> +1 to ashok's proposal

<cygri> PROPOSAL: Delete 4.1.9

<oberger> or soften it

davidwood

<davidwood> PROPOSAL: Soften 4.1.9 by removing it :)

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

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

<Ruben> *lol @ davidwood*

<antonis> -1

<oberger> SteveS, you had a proposal ?

<Ruben> +1 to get rid of it

<timbl> +1

<rgarcia> +1 to delete

<SteveBattle> +1 die die die

<SteveS> -1

<krp> +1

<BartvanLeeuwen> +1 delete

<bblfish> +1

<svillata> +1

<cygri> ±0

<betehess> +1

<sandro> -0

<webr3> +1 to delete

<betehess> +1

<oberger> -0,0

<MacTed> +1

<nmihindu> +1 for removing

<roger> +1

<davidwood> +1

<ahaller2> -0

davidwood: we can strike 4.1.9, soften to a SHOULD, change to language about "encouraging folks to use

-¹

<SteveBattle> This kind of advice could go in the primer

s/encouraging folks to use/encouraging folks to use the following types when applicable/

<HadleyBeeman> *that was my thought too, SteveBattle. It'd be useful for the implementations coming from the GLD WG too

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

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

<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

<bblfish> agree with cygri

<betehess> +1 to avoid informative statements like that whenever possible

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

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

<sandro> +1

<MacTed> did we not just RESOLVE to delete it?

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

<betehess> that's an RDF issue to me

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

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

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

scribe: how does a client know what to expect?
... we need a way to advertise the types

HadleyBeeman: we have this prob everywhere (gov LD, RDF Core)
... doesn't belong in this group

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

bblfish: agreeing that collections can be typed and restricted
... +1 to davidwood

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

SteveS: two reasons to object:
... .. the issues around saying SHOULD (not reinvent)
... .. would like to encourage best practices as much as can

<webr3> atonis, are you 0 or +1 now?

<antonis> 0

<ArnaudLH> a?

ArnaudLH: i think we understand adding constraints for interop

davidwood: sandro pointed out that somewhere it says that "if a client PUTs datatypes other than this, they are stripped"?

<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/

davidwood: the server has to construct a representation of these datatypes

<webr3> yes MUST *ONLY*

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

<MacTed> *that*'s problematc

<SteveS> -0

<antonis> 0

+∞×ø

<sandro> +1

<SteveBattle> "+1"^^xsd:short

APPROVED: Delete 4.1.9

<cygri> ^^ This resolves ISSUE-6

RESOLUTION: Delete 4.1.9

RESOLUTION: close issue-6 by DELETing LDP §4.1.9

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

<sandro> MacTed, everypone is gone, no clue

<cygri> MacTed, we're slowly reconvening

<MacTed> tnx

<sandro> scribe: Ashok_Malhotra

<scribe> scribenick: Ashok_Malhotra

<betehess> s/tnx//

<betehess> s/MacTed, we're slowly reconvening//

<betehess> s/MacTed, everypone is gone, no clue//

Arnaud: Let's discuss dinner then pick up issues again
... also talk about f2f

f2f

Arnaud: Charter calls for a f2f in March
... we have to announce 8 weeks ahead of time

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

Arnaud: We also need a list of possible hosts

<davidwood> Sometimes ftf meetings can be in conjunction with another event.

Ashok: Maybe Oracle can host in NYC

Sandro: We can host at MIT

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

<ahaller2> ahaller2 is offering to host

Arnaud: I'm not thinking about Europe

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

Discussion about expensive lodging in NYC

<SteveS> -1 to sharing room with ericP

<ericP> wuss

Lodging is cheaper in Cambridge

I can try and find rooms on the West Coast

<Ruben> +1

<ArnaudLH> west coast?

<SteveBattle> 0

<betehess> -1

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

<ArnaudLH> +1

<SteveS> +1

<cygri> -0.2

<BartvanLeeuwen> 0

<ahaller2> 0

<svillata> 0

<SteveS> +0.9

<davidwood> +0.5

+1

<ArnaudLH> +1

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

<SteveBattle> +0.5

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

<ericP> +1

<rgarcia> +0.75

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

<roger> +1

<oberger> +0.5

<davidwood> +1

<BartvanLeeuwen> +0.5

<svillata> +0.5

<betehess> +1

<sandro> +1

<Ruben> +1

<cygri> +0.2

<SteveS> +1

+1

<ArnaudLH> +1

<krp> +0.5

<ericP> +①

Next LDPWG meeting

<Ruben> *for tpacbot*

SteveS: I can look into Raleigh, NC

<oberger> SteveS, do you have a cheap flight plan from london ?

Arnaud: can we narrow down timing

sandro: Suggest march 27/28 -- MIT Spring break

<rgarcia> that week is Easter

<rgarcia> at least in Spain

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

<oberger> ouch

Arnaud: Week of March 12?

oberger: Asks about what we will discuss

<oberger> for expenses reason

Bart: March 14/16 may work

Discussion about whether a Video Conferencing facility would be available

<oberger> Nice at Eurecom maybe

Eric: I would book rooms for 14/15 March

<sandro> Eric, Done.

<svillata> I'll check for video conferencing facility in Nice

<oberger> I mean, for a videoconference room

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

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

<davidwood> ahaller2, maybe earlier for mango season. Yum!

Dinner

Arnaud: Who can join the group fro dinner

16 or 17 people

scribe: close to 20 people

<oberger> ArnaudLH, Les Adrets maybe ?

<oberger> dunno if as cheap (kinda)

Arnaud: Perhaps same restaurant as the RDF WG dinner

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

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

<cygri> actually http://lecomptoirdesmarronniers.fr/

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

<bblfish> +1

Arnaud: 7:30 PM

<cygri> ISSUE-20?

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

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

Issue-20

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

SteveBattle Introduces the issue

<roger> +q

<cygri> ISSUE-26?

<trackbot> ISSUE-26 -- creation model for LDP -- open

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

Roger: Issue-26 (above) is related

<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,+Rh34ne,+Rh34ne-Alpes&t=m&z=16

Roger: JohnArwe said it was not a MUST, only a SHOULD

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

<MacTed> the model is distinct from its serializations...

Betehess: Cannot have relative URIs in RDF
... we may have to change the definition

<sandro> s/RDF/RDF Abstract Syntax

<MacTed> s/the model is distinct from its serializations/the RDF model is distinct from its serializations (Turtle, TriG, RDF/XML, etc.)/

Betehess: Jena, for example, always gives you an absolute URIs

<betehess> s/ always gives you an absolute URIs/ always gives you an absolute URIs when serializing or deserialising, but you can do it manually/

<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

<bblfish> back, sorry to be late

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

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

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

<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

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

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

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

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

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

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

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

<oberger> http://lecomptoirdesmarronniers.fr/

Tim: would be a big problem if they were prophibited

<SteveBattle> Wasn't that "didn't serve relative URIs"?

s/prophibited/prophibited

s/prophibited/prohibited

DavidWood: Expalins how he uses URis in Callamachis
... so you post to a container and provided a slug and you are good
... slug is a header ... it's a hint

SteveS:

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

Question is what do you put in the RDF

DavidWood: We don't typically self reference

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

<roger> shame, but, have to go ...

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

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

<oberger> <#new>

Sandro: This is not a problem with the RDF model

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

SteveBattle: With Turtle you can send t but not consume it
... other situations work

s/ t /t /

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

<betehess> ]]

<MacTed> s/sendt /send/

SteveBattle: Even with the slug it is a NULL relative URI

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

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

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

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

completelty specufy the behaviour

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

<Zakim> betehess, you wanted to offer other use-cases

<cygri> MacTed, reference?

scribe: there could be different ways of handling this

<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

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

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

<webr3> cygri, false, it's specified by content-location

<cygri> webr3, reference?

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

<betehess> I don't disagree with cygri the way he put it

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

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

<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.``

SteveBattle: RFC 3096 is talking about retrieval context

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

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

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

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

<oberger> s/3096/3986/

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

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

<SteveBattle> Exactly - it's application dependent.

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

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

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

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

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

Tim: We have to make something that is consistent and logical
... the base URI has to be the URI of the resource

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

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

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

<webr3> this came up on IETF a week or so ago

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

<cygri> webr3, nice find

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

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

EricP: What happens if we do not specify this ... how much depends on this
... leave the spec as is

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

<bblfish> yes

<betehess> the current wording is missing the 201 Created

EricP: If we specify the rewrite rules do we lose interoperability

bblfish: If folks treat relative URIs differently there is going to me a mess
... this is an important issue

EricP: If two servers have different rules then is the client libraries as les usable ...

bblfish, Tim: You cannot be inconsistent

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

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

<bblfish> let's take an example where the semantics are clear

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

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

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

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

OBerger: Are we discussing creation or adding to a container

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

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

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

<betehess> does the order of the triples matters as well?

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

Cygri: We can escalate the issue

Tim: This spec uses HTTP in a special way

<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

Arnaud: Not sure we are converging

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

<SteveBattle> +1

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

<sandro> +1

<antonis> +1

<ahaller2> +1

<rgarcia> +1

<SteveS> +1

<timbl> +1

<ArnaudLH> +1

<bblfish> +1

<Ruben> +1

<svillata> +1

<nmihindu> +1

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

<davidwood> +0.5, modulo my question above

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

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

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

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

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

<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

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

<cygri> ISSUE-25?

<trackbot> ISSUE-25 -- Weak aggregation and strong composition in containers -- open

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

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

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

SteveBattle: I have raised the same issue on HHTPbis ...

Wrap-up for the day

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

<cygri> http://lecomptoirdesmarronniers.fr/

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

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

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

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

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

<MacTed> +1 SteveBattle

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

<betehess> and there were plenty of email on this subject

<betehess> explaining why we close it is important as well

<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."/

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

<MacTed> which may require another proposal round.

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

<SteveBattle> We're discussing the wording of the closure of issue-20.

<SteveBattle> Yes.

<SteveBattle> Yes - I agree with the wording.

This is scribe.perl Revision: 1.137  of Date: 2012/09/20 20:19:01  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s|who said arrival, coffee in the program ?||
Succeeded: s/Olivier Berger/Olivier_Berger/
Succeeded: s/Jonathan Dray/Jonathan_Dray/
Succeeded: s/Roger Menday/Roger_Menday/
Succeeded: s/steeve/SteveS/
Succeeded: s/waht/what/
Succeeded: s/could/could be/
Succeeded: s/to/too/
Succeeded: s/sandro's not here//
Succeeded: s/greay/great/
WARNING: Bad s/// command: s/UC/US/ User Story
Succeeded: s/agree/need to agree/
FAILED: s/resoruces/resources/
FAILED: s|webr3?||
FAILED: s|no phone||
FAILED: s|nathan? on the phone?||
FAILED: s|@webr3, same #s we use for weekly calls||
FAILED: s/portico/protocol/
FAILED: s/nor/not/
FAILED: s|wth||
FAILED: s|q+, suggesting we should we discuss creation and ownership by containers||
FAILED: s|q+ suggesting we should we discuss creation and ownership by containers||
FAILED: s/Necessaril/necessarily/
FAILED: s/this is/this be/
FAILED: s/until another resource is created or associated with the same Request-URI/until the state of the resource is changed again/
FAILED: s/the phrasing is fine/it was just the phrasing that could be confusing/
FAILED: s/mow/now/
FAILED: s/using a URI\?/using a URI/
FAILED: s/think/thing/
FAILED: s/encouraging folks to use/encouraging folks to use the following types when applicable/
WARNING: Bad s/// command: 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/
FAILED: s/tnx//
FAILED: s/MacTed, we're slowly reconvening//
FAILED: s/MacTed, everypone is gone, no clue//
FAILED: s/RDF/RDF Abstract Syntax/
WARNING: Bad s/// command: s/the model is distinct from its serializations/the RDF model is distinct from its serializations (Turtle, TriG, RDF/XML, etc.)/
FAILED: s/ always gives you an absolute URIs/ always gives you an absolute URIs when serializing or deserialising, but you can do it manually/
FAILED: s/prophibited/prophibited/
FAILED: s/prophibited/prohibited/
FAILED: s/ t /t /
FAILED: s/sendt /send/
FAILED: s/3096/3986/
Found ScribeNick: betehess
Found Scribe: cygri
Inferring ScribeNick: cygri
Found ScribeNick: ericP
Found Scribe: Ashok_Malhotra
Inferring ScribeNick: Ashok_Malhotra
Found ScribeNick: Ashok_Malhotra
Scribes: cygri, Ashok_Malhotra
ScribeNicks: betehess, cygri, ericP, Ashok_Malhotra
Present: Alexandre_Bertails Ruben_Verborgh Olivier_Berger Jonathan_Dray Roger_Menday SteveSpeicher BartvanLeeuwen Arnaud_Le_Hors Nandana_Mihindukulasooriya Raul_Garcia-Castro FabGandon MacTed

WARNING: No meeting title found!
You should specify the meeting title like this:
<dbooth> Meeting: Weekly Baking Club Meeting

Agenda: http://www.w3.org/2012/ldp/wiki/F2F1#Day_1_-_November_1st
Got date from IRC log name: 01 Nov 2012
Guessing minutes URL: http://www.w3.org/2012/11/01-ldp-minutes.html
People with action items: