IRC log of ldp on 2012-11-01

Timestamps are in UTC.

07:57:35 [RRSAgent]
RRSAgent has joined #ldp
07:57:35 [RRSAgent]
logging to http://www.w3.org/2012/11/01-ldp-irc
07:57:44 [betehess]
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
07:57:53 [tidoust]
tidoust has joined #ldp
07:58:05 [betehess]
chair: Arnaud
07:58:13 [ivan]
ivan has joined #ldp
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 ]
07:59:08 [betehess]
present+ Alexandre_Bertails
07:59:13 [svillata]
svillata has joined #ldp
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)
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)
07:59:57 [oberger]
who said arrival, coffee in the program ?
08:00:48 [chsiao_]
chsiao_ has joined #ldp
08:01:16 [FabGandon]
FabGandon has joined #ldp
08:06:59 [Ruben]
Ruben has joined #ldp
08:07:11 [AndyS]
AndyS has joined #ldp
08:07:12 [Ruben]
present+ Ruben_Verborgh
08:07:14 [SteveBattle]
SteveBattle has joined #ldp
08:07:28 [betehess]
s|who said arrival, coffee in the program ?||
08:07:29 [oberger]
present+ Olivier Berger
08:07:40 [betehess]
s/Olivier Berger/Olivier_Berger/
08:07:46 [jonathandray]
jonathandray has joined #ldp
08:08:05 [roger]
roger has joined #ldp
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)
08:08:26 [nmihindu]
nmihindu has joined #ldp
08:08:41 [jonathandray]
present+ Jonathan Dray
08:08:52 [betehess]
s/Jonathan Dray/Jonathan_Dray/
08:09:00 [roger]
present+ Roger Menday
08:09:11 [betehess]
s/Roger Menday/Roger_Menday/
08:09:13 [ericP]
Zakim, please dial St_Clair_3B
08:09:13 [Zakim]
sorry, ericP, I don't know what conference this is
08:09:22 [SteveBattle]
Do we have a hashtag?
08:09:43 [ericP]
Zakim, please this ldp
08:09:43 [Zakim]
I don't understand 'please this ldp', ericP
08:09:44 [Ashok_Malhotra]
Ashok_Malhotra has joined #ldp
08:09:50 [ericP]
Zakim, please this is ldp
08:09:50 [Zakim]
I don't understand 'please this is ldp', ericP
08:09:55 [ericP]
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".
08:09:59 [SteveS]
present+ SteveSpeicher
08:10:03 [ericP]
Zakim, please dial St_Clair_3B
08:10:03 [Zakim]
sorry, ericP, I don't know what conference this is
08:10:05 [BartvanLeeuwen]
present+ BartvanLeeuwen
08:10:13 [ericP]
Zakim, this will be ldp
08:10:13 [Zakim]
ok, ericP; I see SW_LDP()2:30AM scheduled to start 100 minutes ago
08:10:14 [ericP]
Zakim, please dial St_Clair_3B
08:10:14 [Zakim]
ok, ericP; the call is being made
08:10:15 [Zakim]
SW_LDP()2:30AM has now started
08:10:16 [Zakim]
+St_Clair_3B
08:10:21 [ArnaudLH]
present+ Arnaud_Le_Hors
08:10:26 [betehess]
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
08:10:30 [antonis]
antonis has joined #ldp
08:10:38 [oberger]
SteveBattle, https://twitter.com/LDPWG i.e. @LDPWG seems an option
08:10:40 [ericP]
Zakim, please dial St_Clair_3B
08:10:40 [Zakim]
ok, ericP; the call is being made
08:10:41 [Zakim]
+St_Clair_3B.a
08:10:50 [Zakim]
-St_Clair_3B
08:11:15 [ericP]
Zakim, St_Clair_3B.a is St_Clair_3B
08:11:15 [Zakim]
+St_Clair_3B; got it
08:11:29 [oberger]
ArnaudLH, are you the owner of @LDPWG ?
08:12:03 [rgarcia]
rgarcia has joined #ldp
08:13:00 [davidwood]
davidwood has joined #ldp
08:13:39 [ArnaudLH]
oberger: Erik is
08:14:05 [oberger]
but #LDPWG may be an interesting hashtag
08:14:35 [ericP]
Zakim, who is here?
08:14:35 [Zakim]
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,
08:14:36 [Zakim]
... BartvanLeeuwen, Zakim, ArnaudLH, betehess, oberger, SteveS, ahaller2
08:14:37 [betehess]
can you avoid uppercase?
08:14:45 [betehess]
eg. ldpwg
08:15:07 [oberger]
betehess, I guess it doesn matter much for twitter web app
08:15:19 [oberger]
but yes lowercase if you will
08:16:29 [davidwood]
Yes, twitter tags are case insensitive.
08:17:00 [SteveBattle]
Where's the coffee?
08:17:40 [oberger]
SteveBattle, shouldn't we ask Zakim ?
08:17:53 [oberger]
crappy bots
08:18:03 [SteveBattle]
zakim, where's the coffee?
08:18:03 [Zakim]
I don't understand your question, SteveBattle.
08:18:46 [Ruben]
*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 ?
08:20:04 [Ruben]
This could actually convince a lot of developers to turn to RDF.
08:20:38 [oberger]
using coffeescript ?
08:21:30 [davidwood]
http://coffeescript.org/
08:24:21 [chong]
chong has joined #ldp
08:30:41 [oberger]
let's get it started
08:30:53 [oberger]
ArnaudLH, addressing us
08:31:03 [betehess]
topic: Welcome, logistics, short intro round, recap of meeting goals, agenda amendments
08:31:07 [cygri]
cygri has joined #ldp
08:31:09 [betehess]
scribenick: betehess
08:31:33 [betehess]
ArnaudLH: let's go around the table, introduce yourself
08:31:59 [betehess]
ivan: Ivan Herman, W3C semweb lead
08:32:05 [betehess]
... here as an observer
08:32:46 [betehess]
davidwood: David Wood, RDF WG
08:32:53 [Zakim]
+Yves
08:32:53 [betehess]
... but also member of this group
08:33:34 [chong]
chong
08:33:49 [develD]
develD has joined #ldp
08:34:02 [rgarcia]
rgarcia: Raúl García-Castro, Ontology Engineering Group, Universidad Politécnica de Madrid
08:34:13 [nmihindu]
Nandana Mihindukulasooriya from Ontology Engineering Group, Universidad Politécnica de Madrid
08:34:15 [ericP]
Eric Prud'hommeaux
08:34:27 [krp]
krp has joined #ldp
08:35:14 [cygri]
Richard Cyganiak, DERI
08:35:34 [Ruben]
Ruben / Ghent University – iMinds / PhD student Semantic Web & Web APIs
08:35:36 [krp]
Kevin Page, University of Oxford
08:35:41 [BartvanLeeuwen]
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
08:36:05 [SteveS]
I'm Steve Speicher from IBM
08:36:06 [svillata]
Serena Villata, INRIA Sophia Antipolis
08:36:16 [antonis]
Antonis Loizou, post-doc Vrije Universiteit Amsterdam
08:36:17 [ahaller2]
Armin Haller
08:36:50 [oberger]
Olivier Berger aka oberger/olberger/obergix from Institut Telecom / Tlcom SudParis
08:36:51 [tidoust]
Francois Daoust from Joshfire. Working on JSON-LD within RDF WG. Observer.
08:37:10 [SteveBattle]
Steve Battle
08:38:18 [cgueret]
cgueret has joined #ldp
08:38:25 [betehess]
jonathandray: Jonathan Dray
08:39:06 [ericP]
Zakim, who is on the phone?
08:39:06 [Zakim]
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.
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.
08:40:21 [AndyS]
Andy Seaborne, Apache Software Foundation. Work with linked data building customer solutions. Also work on Apache Jena.
08:40:38 [betehess]
ArnaudLH: thanks all
08:40:49 [betehess]
... the agenda was a bit of a challenge
08:41:03 [betehess]
... still on the early days
08:41:16 [betehess]
... two main topics
08:41:30 [betehess]
... tried to split everything in chunks
08:41:41 [betehess]
... also tried to take timezones into accounts
08:41:54 [betehess]
... 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
08:42:24 [betehess]
... no other constraint
08:42:41 [betehess]
... so just tell me to "move on"
08:42:58 [betehess]
davidwood: how many people new to w3c?
08:43:23 [betehess]
[only a few]
08:44:04 [betehess]
ArnaudLH: any question about the process, then just ask
08:44:09 [betehess]
... 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
08:45:06 [betehess]
ArnaudLH: I went back to the charter
08:45:08 [oberger]
http://www.w3.org/2012/ldp/charter
08:45:25 [betehess]
... we need to start speaking about some stuff
08:45:30 [betehess]
... eg. test suite
08:45:34 [betehess]
... and validator
08:45:50 [betehess]
... lots of discussion during charter writing about ACLs
08:46:03 [betehess]
... 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
08:46:31 [betehess]
... the compromise was: a NOTE defining the requirements
08:46:34 [cygri]
cygri has joined #ldp
08:46:39 [betehess]
... these are the main deliverables
08:46:48 [betehess]
... also want to discuss next f2f meeting
08:47:24 [betehess]
... the FPWD is basically the SUBMISSION annotated with issues
08:47:26 [oberger]
FPWD http://www.w3.org/TR/ldp/
08:47:33 [betehess]
... we'lll go through the list of issues
08:47:44 [betehess]
q+
08:48:16 [betehess]
... 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
08:48:40 [betehess]
... 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
08:49:28 [betehess]
... regarding use case and requirements doc, it's a bit different
08:49:34 [betehess]
... not published it yet
08:49:44 [betehess]
... we need to decide what this doc is really about
08:49:51 [cygri]
cygri has joined #ldp
08:50:06 [betehess]
... steeve did a great job to put it together
08:50:06 [betehess]
... but some stuff does not belong there
08:50:08 [oberger]
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
08:50:37 [betehess]
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
08:50:47 [betehess]
... and the spec does not address it
08:50:53 [betehess]
... then it can be a problem
08:51:21 [betehess]
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
08:51:39 [betehess]
ericP: is there something new in the ED since the FPWD?
08:51:43 [betehess]
... where should be look at
08:51:57 [betehess]
steeve: not change much
08:51:59 [betehess]
... only locally
08:52:17 [oberger]
s/steeve/SteveS/
08:52:37 [betehess]
ack me
08:53:09 [oberger]
betehess: prioritize issues for people only present today
08:53:23 [roger]
roger has joined #ldp
08:53:36 [betehess]
q+
08:53:42 [davidwood]
davidwood has joined #ldp
08:53:44 [cygri]
cygri has joined #ldp
08:54:03 [betehess]
oberger: would like to hear about implementations and validation
08:54:27 [betehess]
... even if it's not mandatory in the charter
08:54:34 [nmihindu]
+1
08:54:40 [betehess]
SteveS: wanted to review the path of the spec
08:54:45 [betehess]
... and the schedule
08:55:05 [cygri]
cygri has joined #ldp
08:55:06 [betehess]
davidwood: maybe a wiki page for listing implementations
08:55:13 [betehess]
ArnaudLH: good idea
08:55:52 [betehess]
... the goal is to discuss the usecase and requirements this morning
08:55:54 [oberger]
q+ on which target audience we're seeking
08:56:02 [betehess]
... and the spec this afternoon
08:56:23 [cygri]
cygri has joined #ldp
08:56:42 [betehess]
ArnaudLH: is this reasonable for now?
08:56:59 [betehess]
oberger: maybe would like to remind the target of this WG
08:57:13 [betehess]
... eg, yesterday there was discussion about LD for devs
08:57:18 [betehess]
... Javascript was important
08:57:25 [betehess]
q+
08:57:36 [betehess]
... just want to understand the objectives
08:57:57 [betehess]
... would like to understand the stakeholders
08:58:09 [betehess]
ArnaudLH: what's your objective?
08:58:18 [betehess]
oberger: understand better what is out of scope
08:58:30 [betehess]
... so fat, it's about resources and containers
08:58:44 [betehess]
... so people mentioned some other datastructures
08:59:03 [cygri]
cygri has joined #ldp
08:59:15 [ArnaudLH]
ack betehess
08:59:47 [ArnaudLH]
ack oberger
08:59:47 [Zakim]
oberger, you wanted to comment on which target audience we're seeking
09:00:01 [cygri]
cygri has joined #ldp
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.
09:00:15 [betehess]
ArnaudLH: the first answer in the charter
09:00:24 [betehess]
... defines the goals
09:00:30 [betehess]
... then the usecase and requirement refine that
09:00:43 [betehess]
... we may conclude that we need something else
09:00:57 [cygri]
cygri has joined #ldp
09:01:39 [betehess]
oberger: if you look at the usecase, there are plenty of them, some redundant
09:01:48 [betehess]
... only a few requirements
09:02:10 [betehess]
... maybe we'll see a whole range of other things?
09:02:24 [betehess]
... lack of imagination or just people staying on focus?
09:02:43 [betehess]
cigry: we may be missing some stuff
09:03:03 [betehess]
... if you see something like this, just say it
09:03:13 [betehess]
... let's nto brainstorming here at the f2f
09:03:51 [betehess]
ArnaudLH: 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
09:04:12 [davidwood]
(linked from the main page under Ongoing Work)
09:04:15 [betehess]
SteveS: just make things as close as possible to what we have
09:04:31 [betehess]
ArnaudLH: let's speak about usecase and requirements
09:05:06 [betehess]
... we already have something good
09:05:06 [betehess]
... 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
09:05:37 [betehess]
... here we started with the spec, we're still editing the UCR doc
09:05:44 [SteveBattle]
topic : Use Cases and Requirements
09:05:52 [davidwood]
q+
09:06:02 [betehess]
... there is a good reason for this situation
09:06:25 [ArnaudLH]
ack davidwood
09:06:36 [betehess]
davidwood: just wanted to mention I created the implementation page
09:06:43 [betehess]
... we can use that to ground the use-case
09:07:30 [betehess]
ArnaudLH: I split the schedule in two
09:07:35 [betehess]
... the steps
09:07:49 [betehess]
... 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?
09:08:20 [betehess]
... eg. security is out-of-scope IMO
09:08:46 [betehess]
SteveBattle: people started to collect stories together
09:08:51 [betehess]
... two sections
09:08:57 [betehess]
... existing user stories
09:09:03 [cygri]
cygri has joined #ldp
09:09:13 [betehess]
... and the use cases
09:09:30 [BartvanLeeuwen]
+q
09:09:35 [betehess]
... you find here scienarios
09:09:45 [betehess]
... making the use cases more concrete
09:09:53 [betehess]
... there are 10 of them so far
09:10:08 [betehess]
... there used to be plenty of examples
09:10:19 [betehess]
... they are now somewhere else
09:11:06 [betehess]
[describing a scenario]
09:11:30 [betehess]
... there are also pointers to the issues that were raised
09:11:42 [oberger]
http://www.w3.org/2012/ldp/wiki/Examples
09:11:45 [betehess]
... focused on functional requirements
09:11:56 [sandro]
RRSAgent, make logs public
09:12:19 [betehess]
... functional requirement == what do you expect the system to do
09:13:25 [betehess]
... functional is the how
09:13:38 [ArnaudLH]
ack bart
09:13:38 [betehess]
BartvanLeeuwen: is it still open?
09:13:41 [SteveS]
q+
09:13:45 [betehess]
SteveBattle: it is still open
09:13:50 [bblfish]
bblfish has joined #ldp
09:13:54 [betehess]
q+
09:14:18 [betehess]
... for user stories, just go ahead
09:14:19 [ArnaudLH]
ack steves
09:14:23 [betehess]
... for requirements, just talk to me
09:14:24 [betehess]
q-
09:15:04 [betehess]
SteveS: when I look at user scenarios, looks like we're too restrictive
09:15:06 [betehess]
... eg. imposing 303
09:15:06 [betehess]
... should be in the spec
09:15:08 [betehess]
q+
09:15:37 [betehess]
... response codes are too much detail for example
09:16:15 [betehess]
Ashok_Malhotra: there are other possible solutions
09:17:06 [betehess]
... 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
09:17:21 [betehess]
... so 303 may be too early
09:17:47 [betehess]
SteveBattle: it is quite useful to know some things here
09:17:56 [betehess]
... so it's useful to document
09:17:57 [ivan]
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
09:18:10 [betehess]
... it's interesting to understand the sequence
09:18:22 [betehess]
SteveS: it's supposed to drive the spec
09:18:40 [Ashok_Malhotra]
q?
09:18:46 [ericP]
betehess: i read the UC&R as painging ourselves in a corner
09:18:52 [ArnaudLH]
ack bete
09:19:16 [ericP]
... there may be some recipes in the UC&R which we have yet to discuss
09:19:34 [ArnaudLH]
ack ericp
09:19:34 [Zakim]
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
09:19:54 [betehess]
... here I find many details
09:20:14 [betehess]
... maybe you can put that stuff to another page
09:20:14 [SteveS]
q+
09:20:24 [betehess]
... and you link those
09:20:37 [betehess]
... then the reader can ground things to examples
09:20:48 [betehess]
... and we can compare different proposals
09:21:02 [betehess]
q+
09:21:32 [betehess]
SteveBattle: use cases are requirements
09:21:44 [betehess]
cygri: 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"
09:21:57 [betehess]
... 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
09:22:16 [betehess]
... 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?
09:22:44 [betehess]
... 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
09:23:09 [oberger]
+1 we need such level of details for existing deployment patterns
09:23:09 [ahaller2]
q+
09:23:30 [betehess]
... 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
09:24:08 [betehess]
... taking existing deployment into account is a valid point, should not be ignored
09:24:12 [cygri]
cygri has joined #ldp
09:24:16 [betehess]
SteveS: +1 to eric
09:24:20 [ArnaudLH]
ack steves
09:24:27 [betehess]
... we may have another wiki page
09:24:36 [krp]
q+
09:24:46 [betehess]
... 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
09:25:06 [cygri_]
cygri_ has joined #ldp
09:25:18 [ArnaudLH]
ack bete
09:25:21 [betehess]
ArnaudLH: for me, it's too much about the solution, not defining the solution
09:25:43 [SteveBattle]
q+
09:25:46 [oberger]
betehess: I want to describe the problem, not the solution
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
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
09:27:19 [ericP]
cygri: we don't want to throw it out based on the level of detail
09:27:50 [ericP]
betehess: if we don't end up matching the UC&R, do we delete UC&R?
09:28:05 [ArnaudLH]
ack david
09:28:05 [Zakim]
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
09:28:11 [betehess]
davidwood: maybe a bit orthogonal
09:28:16 [cygri]
cygri has joined #ldp
09:28:18 [betehess]
... trying to capture the what and the how
09:28:19 [ericP]
... sometimes you have to go back. that's just how it is
09:28:25 [betehess]
... the where may be missing
09:28:39 [betehess]
... eg. to answer waht use-cases are implemented or not
09:28:53 [betehess]
... we need a place to track those
09:29:18 [betehess]
... I agree it's too detalied in term of the guidance
09:29:23 [cygri]
cygri has joined #ldp
09:29:24 [betehess]
... we would like to say things only once
09:29:30 [betehess]
... don't repeat yourself
09:29:44 [betehess]
... we could change this page to respect the use stories (the why)
09:29:51 [cygri]
cygri has joined #ldp
09:30:04 [betehess]
... 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
09:30:06 [ArnaudLH]
ack ahaller
09:30:13 [betehess]
ahaller2: I find this useful to the end-user
09:30:19 [betehess]
... it says hwo to use the platform
09:30:25 [cygri]
cygri has joined #ldp
09:30:37 [betehess]
ArnaudLH: I think there is great material here
09:30:46 [betehess]
... nobody is saying to throw it out
09:30:53 [betehess]
... question is what's belong here
09:31:02 [betehess]
... what is the spec going to address
09:31:18 [betehess]
... 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
09:32:04 [betehess]
... could a primer as well
09:32:09 [betehess]
s/could/could be/
09:32:15 [ArnaudLH]
ack krp
09:32:24 [betehess]
krp: could be confusing
09:32:35 [betehess]
... what don't people like here?
09:32:40 [betehess]
... to many steps?
09:32:45 [betehess]
s/to/too/
09:32:58 [betehess]
... at least, this is a clear requirement
09:33:11 [betehess]
... could also be a test case
09:33:16 [betehess]
q+
09:33:23 [ArnaudLH]
ack steveb
09:34:07 [betehess]
SteveBattle: 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
09:34:26 [betehess]
... it's conventional to speak about the steps
09:34:38 [betehess]
davidwood: the spec speaks about 303 in two places
09:34:47 [betehess]
... also http verbs
09:35:03 [ArnaudLH]
ack bete
09:35:16 [ericP]
betehess: what's there is valuable
09:35:23 [cygri]
cygri has joined #ldp
09:35:28 [ericP]
... it's not about the value itself
09:35:41 [ericP]
... this material is excellent for when i'm implementing the test
09:35:55 [svillata]
oberger +1
09:35:55 [ericP]
... i want to test the spec, not the user requirement
09:36:14 [davidwood]
q+ to suggest starting a test page
09:36:17 [oberger]
q+ asking for a coffee break potentially short
09:36:21 [oberger]
q-
09:36:21 [ericP]
... some folks say "just re-edit the page", but this is against @@1
09:36:32 [ArnaudLH]
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
09:36:47 [betehess]
ericP: when I said to split out in different document
09:36:57 [betehess]
... for the time being, this is very useful
09:37:13 [SteveBattle]
q+
09:37:22 [betehess]
... we'll need to re-edit something anyway
09:37:31 [betehess]
... we can insert a note at the beginning
09:37:39 [betehess]
... and use color code
09:37:59 [betehess]
... that states what's to be considered
09:38:13 [betehess]
... and gives fewer places to visit
09:38:23 [cygri]
cygri has joined #ldp
09:38:42 [ArnaudLH]
ack david
09:38:42 [Zakim]
davidwood, you wanted to suggest starting a test page
09:38:58 [ArnaudLH]
q- asking
09:39:17 [betehess]
davidwood: we could move some of the stuff to a wiki page for tests
09:39:21 [ArnaudLH]
ack steveb
09:39:25 [cygri]
cygri has joined #ldp
09:39:34 [betehess]
SteveBattle: we'll propose something
09:39:40 [rgarcia]
+1 to convert examples into tests
09:39:47 [betehess]
... still people need to review the scenarios
09:40:10 [betehess]
ArnaudLH: let me try to summarize
09:40:16 [betehess]
... probably too much in the doc
09:40:22 [betehess]
... not sure how to address the p
09:40:33 [betehess]
... some wants to move stuff
09:40:45 [betehess]
... just happy to give SteveBattle a chance to do another pass
09:41:01 [cygri]
cygri has joined #ldp
09:41:03 [betehess]
... but I don't want to end up saying "this is not what we wanted"
09:41:05 [betehess]
q+
09:41:25 [betehess]
... any concrete proposal?
09:41:31 [SteveS]
q+
09:42:03 [betehess]
... if there is too much, we'll need to sort it out
09:42:14 [cygri]
cygri has joined #ldp
09:42:20 [sandro]
zakim, who is on the call?
09:42:20 [Zakim]
On the phone I see St_Clair_3B, Yves
09:42:22 [betehess]
oberger: 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
09:42:49 [cygri]
cygri has joined #ldp
09:43:01 [ArnaudLH]
ack bete
09:43:28 [cygri_]
cygri_ has joined #ldp
09:43:58 [Ashok_Malhotra]
q+
09:44:16 [ericP]
betehess: maybe we want to have everything for a given user story in one place
09:44:37 [ArnaudLH]
ack steves
09:44:46 [HadleyBeeman]
HadleyBeeman has joined #ldp
09:44:50 [betehess]
SteveS: 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
09:45:06 [betehess]
... phrasing is important
09:45:28 [betehess]
... then we can extract the things depending on what we need
09:46:02 [BartvanLeeuwen]
q+
09:46:02 [cygri]
cygri has joined #ldp
09:46:04 [ArnaudLH]
ack ashok
09:46:08 [betehess]
ArnaudLH: 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
09:46:32 [ericP]
q?
09:46:39 [betehess]
... could use other colors, this is possible solution
09:46:45 [cygri]
cygri has joined #ldp
09:46:53 [bblfish]
q+
09:46:56 [betehess]
... like davidwood's suggestion to move that to test
09:47:05 [betehess]
... 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
09:47:22 [betehess]
Ashok_Malhotra: that's fine
09:47:23 [ericP]
q+ to say that tests are allowed to be controversial
09:47:25 [bblfish]
q-
09:48:07 [betehess]
ArnaudLH: SHORT BREAK
09:48:13 [BartvanLeeuwen]
q+ primer is needed
09:48:17 [oberger]
resume at 11:00
09:48:58 [BartvanLeeuwen]
q+ to state that primer is needed as in ld-dev yesterday
09:49:20 [Yves]
+1 for a primer
09:55:35 [Ruben]
Ruben has joined #ldp
09:55:53 [chsiao]
chsiao has joined #ldp
09:56:44 [BartvanLeeuwen]
BartvanLeeuwen has joined #ldp
09:58:37 [cygri]
cygri has joined #ldp
09:59:19 [cygri]
cygri has joined #ldp
10:00:11 [cygri_]
cygri_ has joined #ldp
10:04:41 [rgarcia]
rgarcia has joined #ldp
10:07:40 [nmihindu]
nmihindu has joined #ldp
10:10:01 [SteveBattle]
+1
10:10:48 [cygri]
cygri has joined #ldp
10:11:35 [bblfish]
hi
10:11:44 [oberger]
again a short round of introductions
10:11:50 [ahaller2]
Henry Story
10:12:05 [oberger]
sandro's not here
10:12:28 [ahaller2]
Hadley Beeman
10:12:31 [ArnaudLH]
q?
10:12:41 [BartvanLeeuwen]
ack me
10:12:41 [Zakim]
BartvanLeeuwen, you wanted to state that primer is needed as in ld-dev yesterday
10:12:50 [SteveBattle]
q+
10:12:54 [betehess]
s/sandro's not here//
10:13:02 [oberger]
+1 for primer
10:13:04 [ahaller2]
Bart: a primer would be a good idea
10:13:05 [cygri]
q+
10:14:26 [ahaller2]
ArnaudLH: 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
10:14:43 [oberger]
s/greay/great/
10:14:57 [SteveS]
+1 for primer, would be willing to help do
10:15:01 [ArnaudLH]
ack eric
10:15:01 [Zakim]
ericP, you wanted to say that tests are allowed to be controversial
10:15:50 [ArnaudLH]
ack steveb
10:17:03 [ahaller2]
steveB: move specific error codes to a wiki, still talk about supporting redirections, but less detail
10:17:14 [ArnaudLH]
ack cygri
10:17:59 [ahaller2]
richard: 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
10:18:57 [oberger]
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
10:19:03 [jonathandray]
jonathandray has joined #ldp
10:19:09 [ahaller2]
... who is the audience of the primer
10:20:07 [ahaller2]
ArnaudLH: 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.
10:21:48 [ahaller2]
... 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 ? ;)
10:22:25 [oberger]
kinda drinking our own champagne
10:22:50 [ericP]
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.
10:23:09 [davidwood]
oberger, VoID file?
10:23:09 [bblfish]
q+
10:23:23 [ArnaudLH]
ack bblfish
10:23:50 [antonis]
@oberger +1
10:24:13 [oberger]
some nice UC 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+
10:25:07 [betehess]
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
10:25:25 [ahaller2]
ArnaudLH: easier to have everything in one document
10:25:39 [ArnaudLH]
ack oberger
10:25:47 [ahaller2]
oberger: should not be afraid of multiple documents
10:25:47 [roger__]
roger__ has joined #ldp
10:26:02 [SteveBattle]
q+
10:26:21 [ArnaudLH]
ack steveb
10:26:47 [ahaller2]
SteveB: 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
10:27:14 [cygri]
q+
10:27:19 [ahaller2]
ArnaudLH: ericP proposed to annotate the document
10:27:23 [ArnaudLH]
ack cygri
10:27:24 [oberger]
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?
10:27:38 [oberger]
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.
10:28:04 [ahaller2]
... what level are they, user stories vs. use cases
10:28:26 [sandro]
oberger, yes, <span id="foo"></span> should survive.
10:28:44 [oberger]
sandro, or maybe a less HTML way ?
10:28:59 [sandro]
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
10:29:53 [oberger]
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
10:30:01 [oberger]
sandro, so that's similar
10:30:25 [sandro]
yes, oberger, same thing
10:30:48 [SteveBattle]
q+
10:31:34 [ahaller2]
cygri: 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
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
10:33:39 [ArnaudLH]
ack steveb
10:33:57 [ericP]
q+ to have a valuable position on the queue
10:34:01 [ericP]
q-
10:34:07 [ahaller2]
steveB: 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
10:35:16 [ahaller2]
steveB: detailed scenarios is important for implementers
10:35:31 [ahaller2]
davidwood: where do we provide the details for implementers?
10:35:46 [ahaller2]
steveS: webplatform.org
10:35:59 [cygri]
q+ to talk about test cases
10:36:26 [ahaller2]
steveS: realise that we need to add more examples to spec
10:36:30 [ArnaudLH]
ack cygri
10:36:30 [Zakim]
cygri, you wanted to talk about test cases
10:36:55 [develD]
develD has joined #ldp
10:37:04 [ahaller2]
cygri: some of the details in the UCR would make good test cases
10:37:11 [nmihindu]
ack cygri
10:37:11 [davidwood]
q+
10:37:43 [ahaller2]
ArnaudLH: i would like to get a timeline.
10:38:30 [cygri]
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
10:39:07 [betehess]
/me agrees with ArnaudLH as I disagree strongly with some of the current requirements
10:40:06 [betehess]
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
10:40:17 [ArnaudLH]
ack david
10:40:39 [SteveBattle]
If anyone disagrees with the detail of the requirements please raise on the mailing list.
10:41:15 [ahaller2]
davidwood: UCR is up already
10:41:25 [ahaller2]
ArnaudLH: at the end it will be a note
10:41:26 [oberger]
q+
10:41:31 [ArnaudLH]
ack cygri
10:41:31 [Zakim]
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
10:42:20 [ahaller2]
... surface concerns with straw poll
10:42:22 [nmihindu]
q+
10:43:00 [ericP]
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
10:43:04 [davidwood]
+1 to section-by-section review by the group
10:43:20 [ArnaudLH]
ack bete
10:43:25 [ahaller2]
ArnaudLH: it will be useful to identify the things that we 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
10:44:01 [ahaller2]
betehess: i have a problem with seeing solutions in the UCR document
10:44:43 [cygri]
q+
10:44:52 [ahaller2]
... want to know what we add later on
10:45:00 [bblfish]
there is a difference between the wiki and the published document
10:45:02 [ArnaudLH]
ack oberger
10:45:06 [betehess]
why not going through an issue then?
10:45:09 [ahaller2]
ArnaudLH: controlled process on what will be added later
10:45:28 [bblfish]
+1 for pingback
10:45:31 [ahaller2]
oberger: some concerns on the mailing list are not in the document
10:45:39 [SteveS]
use case for ping back?
10:45:45 [ahaller2]
... i have a problem to define a use case and/or user story
10:46:02 [bblfish]
q+
10:46:15 [ahaller2]
... 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
10:46:40 [bblfish]
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
10:47:04 [ahaller2]
davidwood: who else contributed to uses cases?
10:47:30 [roger__]
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
10:48:09 [ahaller2]
oberger: 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
10:48:28 [ArnaudLH]
q?
10:48:29 [ahaller2]
davidwood: is there a product in tracker on UCR
10:48:51 [ahaller2]
... group member wants a use case, raise an issue
10:48:55 [SteveBattle]
+1
10:49:32 [webr3]
webr3 has joined #ldp
10:49:35 [ericP]
PROPOSAL: the process for adding new use cases is to raise a tracker issue against the UC&R product
10:49:37 [cygri]
+1
10:49:39 [ArnaudLH]
+1
10:49:41 [ericP]
+1
10:49:42 [rgarcia]
+1
10:49:43 [antonis]
+1
10:49:43 [bblfish]
+1
10:49:44 [BartvanLeeuwen]
+1
10:49:45 [betehess]
+1
10:49:46 [oberger]
+1
10:49:47 [ahaller2]
+1
10:49:47 [davidwood]
davidwood has joined #ldp
10:49:47 [Ruben]
+1
10:49:48 [krp]
+1
10:49:48 [SteveS]
+1
10:49:49 [svillata]
+1
10:49:50 [SteveBattle]
+1
10:49:54 [nmihindu]
+1
10:49:56 [davidwood]
+1
10:49:57 [sandro]
+1
10:49:59 [ericP]
APPROVED
10:50:16 [ericP]
APPROVED: the process for adding new use cases is to raise a tracker issue against the UC&R product
10:50:17 [cygri]
q?
10:50:38 [ArnaudLH]
ack nmihindu
10:51:20 [betehess]
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.
10:51:30 [ericP]
ack me
10:51:30 [betehess]
+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
10:51:31 [Zakim]
... use cases
10:51:34 [ArnaudLH]
ack eric
10:51:58 [oberger]
FPWD of the UC&R
10:52:12 [sandro]
q?
10:52:20 [ahaller2]
ericP: we have a choice of stating what issues have been approved
10:52:36 [betehess]
q+
10:52:47 [ahaller2]
... for the 10 use cases in the UCR we can mark them as approved/not approved
10:52:47 [ArnaudLH]
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.
10:53:38 [ArnaudLH]
ack bblfish
10:54:08 [ahaller2]
bblfish: test this, raise pingback as an issue
10:54:15 [ahaller2]
ArnaudLH: not right now
10:54:18 [ArnaudLH]
ack bete
10:54:45 [webr3]
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
10:54:55 [SteveS]
q+
10:55:16 [ahaller2]
betehess: 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.
10:55:45 [cygri]
q+
10:56:18 [ArnaudLH]
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
10:56:40 [ahaller2]
SteveS: 18 user stories, are we agree on those as well?
10:56:48 [betehess]
so do we just use tracker for that as well?
10:56:54 [ahaller2]
... same process, with raising issue
10:57:03 [betehess]
we need a deadline then
10:57:05 [develD]
develD has joined #ldp
10:57:12 [ahaller2]
cygri: use same process, raise an issue
10:57:23 [betehess]
q+ to ask about a deadline
10:57:57 [cygri]
q-
10:57:58 [ahaller2]
ArnaudLH: by default everything which is not questioned with an issue will be published
10:58:13 [ArnaudLH]
ack bete
10:58:13 [Zakim]
betehess, you wanted to ask about a deadline
10:58:25 [cygri]
q+
10:58:32 [ahaller2]
betehess: we need a timeline for when the chair will accept issues
10:58:42 [nmihindu]
q
10:58:46 [ArnaudLH]
ack cygri
10:58:51 [ahaller2]
... after this point nobody should be allowed to edit the document
10:59:04 [nmihindu]
q+
10:59:10 [betehess]
as a way to work, we could move to github and use pull-request
10:59:26 [yaso]
yaso has joined #ldp
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).
11:00:41 [ArnaudLH]
ack nmihindu
11:00:53 [SteveBattle]
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.
11:01:09 [betehess]
+1 to that
11:01:25 [ahaller2]
SteveB: i don't agree we need to make them consistent
11:01:36 [ArnaudLH]
ack steveb
11:02:12 [cygri]
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)
11:04:03 [SteveS]
+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
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.
11:05:38 [sandro]
suggest 1 December ?
11:05:54 [ahaller2]
ArnaudLH: agree with that, happy to make that official if people agree
11:06:02 [betehess]
too soon for me
11:07:09 [ahaller2]
oberger: can steveB still add issues?
11:07:26 [ahaller2]
ArnaudLH: SteveB should go through the same process
11:07:58 [ahaller2]
ArnaudLH: will come up with a deadline by tomorrow
11:08:44 [betehess]
q+
11:08:56 [cygri]
ack me
11:09:06 [ahaller2]
ericP: are we picking something specific, like SemTech
11:09:22 [ArnaudLH]
ack cygri
11:09:31 [ArnaudLH]
ack bete
11:09:42 [oberger]
how many weekly meetings/calls do we need ?
11:09:50 [cygri]
q+
11:09:57 [ahaller2]
betehess: 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
11:10:24 [ahaller2]
ArnaudLH: we will have to be optimistic
11:10:25 [oberger]
ack cygri
11:10:43 [ahaller2]
cygri: deadline for raising issues, not for inclusions in the document
11:11:02 [ahaller2]
... 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.
11:11:53 [SteveS]
+1
11:12:03 [ArnaudLH]
+1
11:12:07 [BartvanLeeuwen]
+1
11:12:07 [Ruben]
+1
11:12:08 [krp]
+1
11:12:09 [rgarcia]
+1
11:12:10 [svillata]
+1
11:12:11 [bblfish]
+1
11:12:11 [antonis]
+1
11:12:11 [oberger]
ArnaudLH, to propose a timeline tomorow
11:12:13 [betehess]
+1
11:12:15 [ahaller2]
+1
11:12:19 [roger__]
+1
11:12:19 [nmihindu]
+1
11:12:32 [Ashok_Malhotra]
+1
11:12:57 [ericP]
+1 to the general idea, noting that it has no date
11:13:09 [betehess]
+1 to eric's remark
11:13:16 [SteveBattle]
+1 (and OK with Dec 1 date)
11:13:24 [ericP]
+1 to betehess's validation
11:13:57 [cygri]
q?
11:14:03 [ahaller2]
ArnaudLH: let's have lunch, get back in 45 minutes
11:14:04 [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.
11:14:33 [nmihindu]
present+ Nandana_Mihindukulasooriya
11:14:49 [rgarcia]
present+ Raul_Garcia-Castro
11:19:02 [yaso]
yaso has joined #ldp
11:33:18 [tidoust]
tidoust has joined #ldp
11:34:23 [tidoust]
tidoust has left #ldp
11:36:08 [chsiao]
chsiao has left #ldp
11:48:03 [JohnArwe]
JohnArwe has joined #ldp
11:48:20 [Zakim]
+JohnArwe
12:07:26 [rgarcia]
rgarcia has joined #ldp
12:08:00 [cygri]
cygri has joined #ldp
12:08:01 [bblfish]
bblfish has joined #ldp
12:08:08 [nmihindu]
nmihindu has joined #ldp
12:08:37 [ahaller2]
ahaller2 has joined #ldp
12:09:01 [SteveBattle]
SteveBattle has joined #ldp
12:09:23 [SteveS]
SteveS has joined #ldp
12:09:40 [Ruben]
Ruben has joined #ldp
12:09:59 [oberger]
oberger has joined #ldp
12:10:49 [oberger]
JohnArwe on the phone
12:10:59 [oberger]
q+ what about the restaurant tonite ?
12:11:04 [bblfish]
hi JohnArwe
12:11:29 [cygri]
oberger, check the agenda :-)
12:11:49 [oberger]
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.
12:12:04 [cygri]
oberger, there's a time slot for discussing that.
12:12:21 [davidwood]
davidwood has joined #ldp
12:12:46 [oberger]
cygri, yes, but if we have to make a reservation, the sooner, the better... that said, dunno
12:13:21 [cygri]
scribe: cygri
12:13:42 [cygri]
topic: LDP Specification
12:13:58 [oberger]
http://www.w3.org/2012/ldp/hg/ldp.html
12:13:59 [cygri]
ArnaudLH: We could simply go down the issue list in order.
12:14:07 [roger]
roger has joined #ldp
12:14:13 [cygri]
... To warm up, we could start with some perhaps less controversial issues.
12:14:22 [svillata]
svillata has joined #ldp
12:14:33 [oberger]
http://www.w3.org/2012/ldp/track/issues
12:14:38 [rgarcia]
http://www.w3.org/2012/ldp/track/issues/open
12:14:53 [cygri]
... Anyone wants to suggest a particular issue for discussion?
12:14:54 [Ruben]
could we talk about 24 today sometime? (not here tomorrow)
12:15:09 [HadleyBeeman]
HadleyBeeman has joined #ldp
12:16:39 [cygri]
[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
12:16:54 [JohnArwe]
23 open according to the server (just above table)
12:17:15 [AndyS]
zakim, code?
12:17:15 [Zakim]
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 ....
12:17:40 [Zakim]
+??P0
12:17:42 [jonathandray]
jonathandray has joined #ldp
12:17:48 [AndyS]
zakim, ??P0 is me
12:17:48 [Zakim]
+AndyS; got it
12:17:50 [betehess]
q+
12:18:05 [betehess]
q-
12:18:17 [betehess]
q+
12:18:44 [FabGandon]
FabGandon has joined #ldp
12:19:04 [FabGandon]
Present+FabGandon
12:19:36 [oberger]
q?
12:21:08 [ArnaudLH]
ack bete
12:21:26 [davidwood]
q+ to propose a resolution for ISSUEs 22 and 23
12:21:48 [timbl]
timbl has joined #ldp
12:22:12 [oberger]
let's vote on 22 !
12:22:34 [oberger]
on discussing 22
12:22:51 [cygri]
subtopic: ISSUE-22 and ISSUE-23 (RDF/XML and JSON-LD)
12:22:56 [ericP]
+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.
12:23:05 [bblfish]
+1
12:23:12 [oberger]
http://www.w3.org/2012/ldp/track/issues/22
12:23:17 [bblfish]
+1
12:23:19 [SteveBattle]
+1
12:23:22 [cygri]
q+
12:23:36 [cygri]
ArnaudLH: Turtle is a MUST, we have resolved that already
12:23:47 [cygri]
davidwood: It should be separated from the other formats
12:23:58 [betehess]
does these format *have* to support relative URIs in their serializations?
12:24:06 [betehess]
q+
12:24:27 [betehess]
q+ to ask if these formats MUST support relative URIs in their serializations
12:24:32 [cygri]
... Point is to have a consistent policy
12:24:40 [cygri]
... MAY or SHOULD would be consistent
12:24:46 [cygri]
ack davidwood
12:24:46 [Zakim]
davidwood, you wanted to propose a resolution for ISSUEs 22 and 23
12:24:48 [ahaller2]
+1 for SHOULD
12:24:57 [ArnaudLH]
ack david
12:25:00 [bblfish]
1+
12:25:02 [bblfish]
q+
12:25:15 [bblfish]
Ntriples would not work because of ISSUE-20
12:25:24 [bblfish]
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
12:25:49 [davidwood]
ISSUE 20 isn't resolved yet :)
12:26:03 [ericP]
... otherwise we end up in conneg and different representations of the same resource
12:26:06 [ArnaudLH]
ack cygri
12:26:11 [davidwood]
I have no strong objection to cygri's proposal.
12:26:13 [jonathandray]
jonathandray has joined #ldp
12:26:21 [AndyS]
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
12:26:33 [rgarcia]
+1 for only Turtle
12:26:34 [timbl]
q+ to suggest "May top connect o other formats"
12:26:40 [ericP]
oberger: shouldn't we discuss conneg?
12:26:46 [timbl]
q+ to suggest "May top conneg o other formats"
12:26:47 [ArnaudLH]
ack bete
12:26:47 [Zakim]
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
12:27:13 [ericP]
oberger: in an informative section, we could say "of course you can use conneg"
12:27:15 [krp]
krp has joined #ldp
12:27:20 [ArnaudLH]
ack bblfish
12:27:22 [cygri]
betehess: davidwood's proposal doesn't work because of relative URIs
12:27:48 [SteveBattle]
q+
12:27:51 [cygri]
bblfish: N-Triples doesn't work because of ISSUE-20
12:28:12 [cygri]
davidwood: 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.
12:28:57 [ArnaudLH]
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"
12:29:01 [SteveBattle]
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
12:29:35 [oberger]
+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
12:30:23 [cygri]
... 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
12:30:40 [ArnaudLH]
ack steveb
12:30:47 [ArnaudLH]
ack andy
12:30:47 [Zakim]
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
12:31:08 [betehess]
andy's remark is right
12:31:10 [AndyS]
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"
12:31:17 [webr3]
q-
12:31:18 [Ashok_Malhotra]
Ashok_Malhotra has joined #ldp
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.
12:31:40 [betehess]
q+
12:31:42 [Zakim]
-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
12:32:28 [betehess]
q-
12:32:32 [cygri]
ArnaudLH: 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.
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.
12:33:28 [ericP]
cygri: yes
12:33:49 [davidwood]
+1 to AndyS
12:33:59 [cygri]
PROPOSAL: MUST use Turtle; MAY do content negotiation with other formats
12:34:06 [Ruben]
+1
12:34:13 [bblfish]
+1
12:34:22 [oberger]
+1
12:34:23 [antonis]
+1
12:34:27 [betehess]
+1
12:34:27 [ahaller2]
+1
12:34:28 [SteveS]
+1
12:34:28 [ericP]
+1
12:34:28 [BartvanLeeuwen]
+1
12:34:30 [ArnaudLH]
+1
12:34:34 [rgarcia]
+1
12:34:34 [krp]
+1
12:34:35 [AndyS]
+1 to mentioning conneg somewhere in docs
12:34:35 [nmihindu]
+1
12:34:38 [davidwood]
+1
12:34:39 [sandro]
+1
12:34:40 [webr3]
+1 s/suse/support
12:34:41 [SteveBattle]
q+
12:34:46 [svillata]
+1
12:35:29 [ArnaudLH]
ack steveb
12:35:43 [sandro]
SteveBattle: If you don't send an accept header on a GET, will you get Turtle?
12:35:44 [ericP]
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
12:36:29 [timbl]
turtle, otherwise you lose the semantics.)
12:36:58 [bblfish]
q+
12:37:01 [yaso]
yaso has joined #ldp
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
12:37:44 [betehess]
q+
12:37:58 [SteveBattle]
+1
12:37:59 [webr3]
+1
12:38:02 [davidwood]
+1
12:38:05 [sandro]
+1
12:38:09 [ArnaudLH]
+1
12:38:09 [AndyS]
+1
12:38:10 [svillata]
+1
12:38:17 [Ruben]
+1
12:38:32 [krp]
+1
12:38:39 [rgarcia]
+1
12:38:41 [BartvanLeeuwen]
+1
12:38:43 [bblfish]
+1
12:38:47 [ericP]
+1
12:38:48 [nmihindu]
+1
12:38:49 [antonis]
+1
12:38:57 [SteveS]
+1
12:39:03 [roger]
+1
12:39:22 [betehess]
+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?
12:39:38 [sandro]
betehess, I think the resolution is clear about that, as "no preference"
12:40:12 [cygri]
[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.
12:40:14 [betehess]
sandro, I think it's cheap to speak about a "default"
12:40:35 [sandro]
ArnaudLH, is that RESOLVED, in your chair judgement?
12:40:44 [betehess]
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
12:41:15 [sandro]
close issue-22
12:41:15 [trackbot]
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
12:42:35 [cygri]
guest: JohnArwe
12:42:41 [Ruben]
q+
12:42:45 [betehess]
q-
12:42:45 [bblfish]
q-
12:42:47 [cygri]
guest: webr3
12:42:52 [timbl]
q?
12:42:59 [oberger]
http://www.w3.org/2012/ldp/track/issues/24
12:42:59 [cygri]
guest: FabGandon
12:43:05 [cygri]
guest: timbl
12:43:12 [davidwood]
q+ to remind the WG on PURL's DELETE behavior
12:43:28 [cygri]
subtopic: ISSUE-24
12:43:38 [ArnaudLH]
ack ruben
12:43:43 [SteveS]
q+
12:43:45 [ArnaudLH]
ack david
12:43:45 [Zakim]
davidwood, you wanted to remind the WG on PURL's DELETE behavior
12:43:45 [ericP]
+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.
12:44:14 [cygri]
... Example, pURLs.
12:44:31 [cygri]
... I strongly recommend we close this issue by stating that servers decide.
12:44:38 [Ashok_Malhotra]
q+
12:44:58 [betehess]
q+ to offer dev perspective
12:45:08 [ahaller2]
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.
12:45:15 [ArnaudLH]
ack steves
12:45:16 [SteveBattle]
q+
12:45:38 [ArnaudLH]
ack steves
12:45:40 [cygri]
SteveS: Agree, it's application-specific. I also agree it's not a best practice.
12:45:43 [ArnaudLH]
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
12:46:10 [cygri]
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.
12:46:27 [cygri]
davidwood: [quotes offending spec text]
12:46:35 [AndyS]
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.
12:46:57 [Ruben]
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-
12:47:17 [cygri]
q?
12:47:41 [cygri]
timbl: If a resource was deleted, it's URI should never ever be re-used.
12:47:54 [davidwood]
q+ to disagree with Tim.
12:48:05 [ArnaudLH]
ack bete
12:48:05 [Zakim]
betehess, you wanted to offer dev perspective
12:48:06 [AndyS]
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
12:48:25 [oberger]
q+ to discuss whether this is linked to issue 25
12:48:57 [ArnaudLH]
ack steveb
12:49:02 [Ruben]
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.
12:49:17 [cygri]
SteveBattle: 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)
12:49:30 [betehess]
when people say "application", is it server-side or client-side?
12:49:32 [ArnaudLH]
ack timbl
12:49:32 [cygri]
... 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
12:49:33 [Ruben]
ericP: indeed, that should be possible for the *same* resource
12:49:35 [Zakim]
... old link to new bad data.
12:49:47 [ArnaudLH]
ack andy
12:49:47 [Zakim]
AndyS, you wanted to wonder about implications on containers and adding entries
12:50:08 [cygri]
q+
12:50:40 [ArnaudLH]
ack david
12:50:40 [Zakim]
davidwood, you wanted to disagree with Tim.
12:50:44 [oberger]
q-
12:51:23 [tpacbot]
tpacbot has joined #ldp
12:51:25 [cygri]
timbl: [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.
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."
12:51:37 [betehess]
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
12:52:05 [cygri]
davidwood: 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?
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
12:52:40 [Ruben]
q+
12:52:43 [AndyS]
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
12:53:00 [ivan]
ivan has joined #ldp
12:53:11 [cygri]
... 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
12:53:35 [sandro]
+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
12:54:23 [ericP]
... it's important to specify client expectations but not [other] server behavior
12:54:29 [bblfish]
q+
12:54:45 [ericP]
... 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
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.
12:54:59 [betehess]
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
12:55:11 [bblfish]
nathan? on the phone?
12:55:15 [webr3]
q-
12:55:17 [AndyS]
webr3?
12:55:17 [webr3]
no phone
12:55:27 [ArnaudLH]
q?
12:55:33 [betehess]
s|webr3?||
12:55:36 [ArnaudLH]
ack ruben
12:55:36 [Zakim]
Ruben, you wanted to say that recreating the *same* resource is not a problem
12:55:41 [betehess]
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
12:55:49 [betehess]
s|nathan? on the phone?||
12:55:51 [ericP]
timbl: i disagree that this isn't in the protocol [i.e. client expecation]
12:55:58 [ArnaudLH]
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
12:56:11 [ArnaudLH]
ack bblfish
12:56:20 [JohnArwe]
@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.
12:56:28 [timbl]
q-
12:56:32 [betehess]
s|@webr3, same #s we use for weekly calls||
12:56:40 [develD]
develD has joined #ldp
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.
12:56:59 [davidwood]
s/portico/protocol/
12:57:12 [ericP]
q+ to say that webr appears had proposed text
12:57:17 [Ruben]
+q to say I'm against just removing
12:57:19 [antonis]
q+
12:57:45 [cygri]
ericP: [reads earlier webr3 comment]
12:57:46 [davidwood]
+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."
12:58:26 [Ruben]
-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
12:58:48 [davidwood]
-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.
12:59:11 [davidwood]
HadleyBeeman, yes.
12:59:16 [ArnaudLH]
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.
12:59:28 [sandro]
s/nor/not
12:59:37 [ericP]
ack me
12:59:38 [oberger]
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
12:59:40 [HadleyBeeman]
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
12:59:54 [cygri]
[scribe fail]
13:00:02 [roger]
not that it changes the issue ...
13:00:26 [ArnaudLH]
ack eric
13:00:29 [SteveS]
q+
13:00:33 [ArnaudLH]
ack ruben
13:00:33 [Zakim]
Ruben, you wanted to say I'm against just removing
13:00:49 [sandro]
q+
13:00:52 [cygri]
q+ to say you can't PUT a resource
13:01:20 [sandro]
+1 cygri, you can't delete a resource
13:01:22 [Ruben]
q-
13:01:22 [ArnaudLH]
ack antonis
13:01:27 [nmihindu]
q+
13:01:32 [betehess]
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
13:02:21 [sandro]
how could you know you'll never want to put a resource back into a container?
13:02:26 [bblfish]
q+
13:02:31 [svillata]
q?
13:02:37 [ArnaudLH]
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."
13:02:41 [bblfish]
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."
13:03:21 [ericP]
q?
13:03:30 [JohnArwe]
+1 ruben
13:03:32 [bblfish]
but how can you delete a methematical object?
13:03:39 [ArnaudLH]
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."
13:03:59 [Ruben]
bblfish: you can delete it from a server
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
13:04:48 [bblfish]
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.
13:05:08 [antonis]
q+
13:05:12 [ArnaudLH]
ack cygri
13:05:13 [Zakim]
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
13:05:26 [betehess]
cygri: maybe we shouldn't be talking about identity of resource
13:05:31 [betehess]
... rather what happens to the container
13:05:45 [betehess]
... 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
13:05:50 [sandro]
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
13:05:54 [bblfish]
+1
13:05:57 [SteveBattle]
+1
13:06:08 [svillata]
+1
13:06:08 [betehess]
... what's the constraint on the server?
13:06:12 [sandro]
+1
13:06:12 [oberger]
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
13:06:20 [ArnaudLH]
q?
13:06:24 [svillata]
q?
13:06:31 [SteveBattle]
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
13:06:33 [ArnaudLH]
ack nmihindu
13:06:49 [cygri]
nmihindu: Putting in the spec that it must be the same entity/resource is practically infeasible.
13:06:50 [ahaller2]
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
13:06:55 [ArnaudLH]
ack bete
13:06:57 [timbl]
q?
13:07:25 [Ruben]
…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.
13:07:44 [cygri]
... We don't know if the resource existed before or not.
13:07:56 [ArnaudLH]
ack bblfish
13:08:00 [yaso]
yaso has joined #ldp
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?
13:08:33 [Ruben]
404 doesn't imply permanency… can be 404 before a resource was created
13:08:43 [JohnArwe]
q+ security and debug considerations
13:08:48 [ericP]
bblfish is getting into the contentious space of negative directory caching
13:08:53 [develD]
develD has joined #ldp
13:08:55 [JohnArwe]
q+
13:09:01 [cygri]
BartvanLeeuwen: Isn't there another code for that?
13:09:04 [cygri]
ericP: 410
13:09:05 [ArnaudLH]
ack antonis
13:09:09 [ericP]
(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
13:09:39 [sandro]
"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."
13:09:40 [Ruben]
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.
13:09:49 [cygri]
q+
13:09:50 [ArnaudLH]
ack ahaller
13:09:53 [bblfish]
yes, thanks. for the 410
13:10:13 [sandro]
zakim, who is on the call?
13:10:13 [Zakim]
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
13:10:33 [betehess]
probably good practice
13:11:42 [oberger]
q+ suggesting we should we discuss creation and ownership by containers
13:11:45 [bblfish]
bad practice has a cost
13:12:04 [bblfish]
q?
13:12:18 [oberger]
q+, suggesting we should we discuss creation and ownership by containers
13:12:24 [oberger]
wth
13:12:25 [oberger]
q+
13:12:30 [Ruben]
*oberger, say q+ to blabla*
13:12:41 [Ruben]
*the "to" is important*
13:12:53 [betehess]
s|wth||
13:13:02 [betehess]
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
13:13:06 [betehess]
s|q+ suggesting we should we discuss creation and ownership by containers||
13:13:15 [cygri]
timbl: That server will be statistically conforming
13:13:16 [ArnaudLH]
ack john
13:13:59 [cygri]
JohnArwe: 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.
13:14:32 [cygri]
... 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.)
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
13:15:48 [bblfish]
thanks
13:15:52 [ArnaudLH]
ack cygri
13:16:14 [ericP]
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
13:17:13 [LeeF]
LeeF has joined #ldp
13:17:22 [ericP]
... the filesystem analogy is compelling to me
13:17:39 [ericP]
... i agree that server-assigned IDs should only be assigned once
13:17:45 [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
13:18:03 [ericP]
... POST->ID/1 ; POST->ID/1 will of course create problems
13:18:12 [ericP]
... that's two issues to resolve
13:18:16 [Ruben]
betehess: this is not REST, but Cool URIs
13:18:17 [yaso]
yaso has joined #ldp
13:18:27 [sandro]
q?
13:18:39 [ericP]
... third issue: different expecations if the server returns a 404 or a 410
13:18:48 [bblfish]
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
13:19:22 [betehess]
ack ober
13:19:23 [Zakim]
+[IPcaller]
13:19:25 [roger]
roger has joined #ldp
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.
13:20:01 [sandro]
q?
13:20:09 [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
13:20:10 [Zakim]
... PUT, then it's reasonable for a client to DELETE it, then PUT again to re-create it.
13:20:18 [ArnaudLH]
q?
13:20:46 [betehess]
-1 to say that much
13:21:02 [betehess]
we would overstep on the http spec
13:21:14 [svillata]
q?
13:21:23 [ericP]
- 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.
13:21:26 [ericP]
+ 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.
13:21:33 [betehess]
q+
13:22:02 [Zakim]
-AndyS
13:22:37 [bblfish]
q?
13:22:42 [bblfish]
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.
13:22:44 [betehess]
ack eric
13:22:44 [Zakim]
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.
13:23:13 [timbl]
You can't say "a different resource"
13:23:21 [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.
13:23:27 [sandro]
q+
13:23:39 [bblfish]
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.
13:23:55 [cygri]
q+
13:24:08 [cygri]
q-
13:24:14 [timbl]
The server should never allocate the same URI twice in response to a POST to a container.
13:24:25 [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.
13:24:29 [jonathandray]
jonathandray has joined #ldp
13:25:02 [ericP]
scribenick: ericP
13:25:09 [cygri]
q+
13:25:14 [timbl]
seconded
13:25:43 [svillata]
q?
13:25:46 [ericP]
oberger: do we have a use case to refer to?
13:26:03 [ericP]
cygri: i think we all know the filesystem use case
13:26:09 [bblfish]
q?
13:26:33 [ericP]
betehess: we have no authority over HTTP
13:26:42 [oberger]
oberger has joined #ldp
13:26:56 [ericP]
sandro: and you know that 404 isn't permanent in HTTP world, right?
13:26:56 [ArnaudLH]
ack bete
13:27:08 [MacTed]
MacTed has joined #ldp
13:27:22 [sandro]
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
13:28:01 [ericP]
timbl: i perfer to treat 404 and 410 just the same
13:28:03 [ArnaudLH]
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.
13:28:24 [ArnaudLH]
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
13:28:43 [SteveBattle]
+1
13:28:58 [davidwood]
+1
13:29:01 [Ruben]
+1
13:29:02 [SteveS]
+1
13:29:03 [ericP]
+1
13:29:05 [ahaller2]
+1
13:29:06 [BartvanLeeuwen]
+1
13:29:07 [sandro]
+1
13:29:07 [nmihindu]
+1
13:29:08 [betehess]
+1
13:29:09 [roger]
+1
13:29:09 [rgarcia]
+1
13:29:10 [bblfish]
q?
13:29:11 [ArnaudLH]
+1
13:29:13 [bblfish]
q+
13:29:14 [svillata]
+1
13:29:14 [ivan]
s/Necessaril/necessarily/
13:29:23 [JohnArwe]
+1
13:29:24 [timbl]
+1
13:29:25 [krp]
+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
13:30:09 [ArnaudLH]
ack cygri
13:30:13 [ericP]
... if it doesn't further constrain the HTTP spec, we shouldn't include it
13:30:23 [betehess]
would this is 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
13:31:36 [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.
13:31:39 [webr3]
remove "until another resource is created or associated with the same Request-URI." replace with something else
13:31:40 [krp]
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+
13:32:15 [bblfish]
q-
13:32:23 [ArnaudLH]
ack cygri
13:32:34 [rgarcia]
+q
13:32:43 [bblfish]
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/
13:33:05 [Ruben]
+1 on cygri's proposal
13:33:08 [webr3]
-1
13:33:16 [ericP]
bblfish: we can include text which describes some of the problems
13:33:34 [ericP]
... there are all kinds of consequences about changing a 410
13:33:47 [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
13:33:57 [webr3]
.. changing the uri's usage
13:34:04 [bblfish]
q-
13:34:15 [ArnaudLH]
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
13:34:48 [oberger]
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."
13:34:56 [ericP]
rgarcia: 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
13:34:56 [Zakim]
oberger, you wanted to propose better use cases
13:35:02 [ericP]
oberger: we need use cases
13:35:16 [ericP]
... we have different interpretations of HTTP DELETE
13:35:29 [cygri]
q+
13:35:49 [Zakim]
+OpenLink_Software
13:35:56 [MacTed]
Zakim, OpenLink_Software is temporarily me
13:35:56 [Zakim]
+MacTed; got it
13:35:58 [MacTed]
Zakim, mute me
13:35:58 [Zakim]
MacTed should now be muted
13:35:59 [sandro]
q+ to talk about use cases being a sometimes-necessary expense
13:36:00 [ArnaudLH]
ack cygri
13:36:28 [sandro]
+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
13:36:31 [betehess]
why am I hoping that this issue is already fully solved in HTTP spec? maybe in Fielding's thesis?
13:36:39 [bblfish]
q+
13:36:58 [Ruben]
betehess: not in F's thesis
13:36:58 [ericP]
... 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.
13:37:06 [FabGandon]
+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'''
13:37:26 [SteveBattle]
Can we put this issue to bed - pleeeeaaase?
13:37:31 [svillata]
+1 cygri
13:37:36 [sandro]
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
13:37:54 [ericP]
davidwood: 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*
13:38:21 [Ashok_Malhotra]
q+
13:38:22 [ericP]
cygri: it's a MAY and only talks about how it applies to our resources
13:38:59 [timbl]
q?
13:39:25 [ericP]
... the resource to which we send the DELETE is a web resource which might have an associated RDF resource
13:39:53 [bblfish]
q-
13:39:58 [ericP]
ArnaudLH: there's no reason for the text apart from stating what HTTP mandates
13:40:06 [svillata]
q?
13:40:10 [bblfish]
q+
13:40:15 [ericP]
... we can remove the offending text or just defer to HTTP
13:40:29 [Ruben]
+q
13:40:46 [ArnaudLH]
ack sandro
13:40:46 [Zakim]
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 ?
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)
13:40:48 [Ruben]
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.
13:41:03 [ericP]
... we agree to do what HTTP says, but don't know how to state it
13:41:11 [ArnaudLH]
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)
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?
13:42:17 [ArnaudLH]
ack bblfish
13:42:29 [timbl]
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
13:42:44 [Ruben]
*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.`
13:42:56 [ericP]
sandro: some of us -1'd simply removing the text
13:43:06 [ArnaudLH]
ack ruben
13:43:06 [Zakim]
Ruben, you wanted to answer Arnaud's question
13:43:11 [cygri]
MacTed, literals are RDF resources but not web resources
13:43:19 [MacTed]
nonsense.
13:43:22 [ericP]
Ruben: removing is fine for me
13:43:28 [ericP]
... the phrasing is fine
13:43:31 [ArnaudLH]
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)
13:43:35 [Zakim]
... 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
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.
13:44:26 [ArnaudLH]
q?
13:44:26 [ericP]
JohnArwe: i worked on other specs and the convention for imposing normative requirements in addition to the base specs
13:44:37 [ArnaudLH]
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
13:45:36 [ericP]
... 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
13:46:15 [cygri]
MacTed, refinement: REST resource != RDF resource
13:46:28 [ericP]
... 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?
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"
13:47:06 [ericP]
[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."
13:48:21 [ahaller2]
+1 davidwood
13:48:28 [oberger]
request-Uri -> resource URI ?
13:48:40 [SteveBattle]
+1 david's wording to replace the grey sentence
13:48:53 [Ruben]
+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.
13:49:08 [oberger]
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.
13:49:48 [antonis]
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."
13:50:22 [antonis]
+1
13:50:22 [Ruben]
+1
13:50:24 [ericP]
+1
13:50:26 [cygri]
+1
13:50:28 [rgarcia]
+1
13:50:29 [ahaller2]
+1
13:50:29 [svillata]
+1
13:50:30 [BartvanLeeuwen]
+1
13:50:31 [davidwood]
+1
13:50:31 [ArnaudLH]
+1
13:50:33 [betehess]
+1
13:50:34 [sandro]
+1
13:50:35 [krp]
+1
13:50:36 [nmihindu]
+1
13:50:39 [oberger]
+1
13:50:42 [webr3]
-0 (the use of may kind of enourages bad form - sorry)
13:50:43 [MacTed]
+1
13:50:43 [SteveBattle]
there was a suggestion to change that to 'resource URI'
13:50:45 [roger]
+1
13:50:50 [cygri]
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
13:51:06 [SteveS]
+1
13:51:07 [MacTed]
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 :
13:51:30 [bblfish]
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.
13:51:53 [cygri]
MacTed, I said "not equal"
13:52:06 [betehess]
MacTed: what about hash HTTP URIs then?
13:52:22 [MacTed]
a URI is a URI is a URI
13:52:36 [MacTed]
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 nsays "until ...Request URI" and adding a sentence, "Clients should note that severs may reuse a Request-URI under some circumstances."
13:53:31 [ericP]
ack oberger
13:53:31 [Zakim]
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
13:54:04 [ArnaudLH]
ack oberger
13:54:21 [webr3]
suggets issue-6
13:54:37 [cygri]
ISSUE-6?
13:54:37 [trackbot]
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
13:56:23 [Ashok_Malhotra]
q+
13:56:53 [cygri]
q+
13:57:01 [ericP]
SteveS: 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
13:57:21 [Ruben]
Topic: ISSUE-6 -- Should LDBP say that any kind of user-defined simple data type is disallowed?
13:57:26 [ericP]
... this is meant to coallesce on a growing set of (currently XSD) datatypes
13:57:29 [Ruben]
*for tpacbot*
13:57:37 [ericP]
... feedback is that it is too restrictive
13:57:37 [ArnaudLH]
ack ashok
13:57:45 [ericP]
... 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
13:58:04 [ericP]
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.
13:58:22 [ericP]
... how are people going to reference a user-defined datatype with a URI?
13:58:47 [timbl]
q+
13:58:49 [ericP]
... there's a doc by jjc telling you how to reference a user-defined datatype using a URI?
13:59:16 [ArnaudLH]
ack cygri
13:59:35 [ericP]
s/using a URI\?/using a URI/
13:59:50 [ericP]
cygri: custom datatypes aren't often used in RDF
13:59:56 [JohnArwe]
must drop for other calls
14:00:01 [Zakim]
-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?
14:00:34 [ericP]
... jjc's doc talks about how to restrict factets
14:00:51 [timbl]
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
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
14:01:53 [ahaller2]
q+
14:02:03 [ericP]
... if you use SPARQL doesn't recognize "330"^^xsd:feet as an integer
14:02:19 [davidwood]
+1 to cygri
14:02:21 [timbl]
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
14:02:33 [timbl]
Use [ is kg of 2 ]
14:02:43 [ericP]
q+ to ask how we increase interop
14:02:44 [bblfish]
q+
14:02:51 [ArnaudLH]
ack bete
14:02:51 [Zakim]
betehess, you wanted to mention that I'm already using new data types
14:02:51 [sandro]
RRSAgent, pointer?
14:02:51 [RRSAgent]
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]
14:03:18 [ericP]
... i use them a lot
14:03:24 [MacTed]
MacTed has joined #ldp
14:03:27 [ericP]
cygri: 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
14:04:11 [ericP]
... 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
14:04:24 [ericP]
... i'm not concearned about SPARQL in my app
14:04:31 [ArnaudLH]
ack david
14:04:31 [Zakim]
davidwood, you wanted to ask whether the server could simply advertise if it has datatype restrictions.
14:04:38 [antonis]
q+
14:04:42 [ericP]
... 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
14:05:00 [MacTed]
present+ MacTed
14:05:14 [ericP]
... 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
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
14:05:59 [ArnaudLH]
a?
14:06:05 [ArnaudLH]
ack timbl
14:06:07 [webr3]
the issue is greater.. xsd hexBinary, long, int, short, unsignedlong etc are all made illegal by the spec
14:06:09 [bhyland1]
bhyland1 has joined #ldp
14:06:12 [oberger]
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
14:06:30 [ericP]
timbl: 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
14:07:37 [ericP]
... 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
14:08:02 [betehess]
q+
14:08:11 [sandro]
RRSAgent, pointer?
14:08:11 [RRSAgent]
See http://www.w3.org/2012/11/01-ldp-irc#T14-08-11
14:08:22 [davidwood]
+1 to timbl
14:08:38 [oberger]
q-
14:08:48 [betehess]
my proposal: don't say anything, it's just RDF!
14:08:51 [ericP]
ack timblPointOfOrder
14:08:51 [Zakim]
timblPointOfOrder, you wanted to comment on whether to do 20 because of relative URIs
14:08:52 [ArnaudLH]
ack timbl
14:08:57 [SteveBattle]
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
14:09:09 [cygri]
ISSUE-20?
14:09:09 [trackbot]
ISSUE-20 -- Identifying and naming POSTed resources -- open
14:09:09 [trackbot]
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.
14:09:12 [MacTed]
"SHOULD" could possibly be argued, in support of greater overall interoperability.
14:09:12 [MacTed]
I generally like davidwood's suggested direction
14:09:29 [ArnaudLH]
ack ahaller
14:09:46 [ArnaudLH]
ack eric
14:09:46 [Zakim]
ericP, you wanted to ask how we increase interop
14:10:00 [ericP]
ahaller: all ontologies i know solve with units of measure patterns
14:10:05 [sandro]
zakim, who is on the call?
14:10:05 [Zakim]
On the phone I see St_Clair_3B, [IPcaller], MacTed (muted)
14:10:13 [cygri]
q?
14:10:57 [ArnaudLH]
ack bblfish
14:11:19 [SteveBattle]
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
14:11:48 [cygri]
q+
14:12:39 [ericP]
bblfish: there's an assymetric pressure to use standard datatypes
14:12:42 [ArnaudLH]
ack antonis
14:12:53 [ericP]
... [hexbinary example]
14:13:08 [bblfish]
plust I need hexBinary, which is not on the list
14:13:33 [ArnaudLH]
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
14:13:42 [JohnArwe]
JohnArwe has joined #ldp
14:14:02 [bblfish]
?
14:14:06 [bblfish]
q?
14:14:07 [ericP]
betehess: i feel like this is like in the last conversation where we were restricting HTTP
14:14:09 [bblfish]
q+
14:14:21 [ericP]
... why not restrict vocabularies, ...?
14:14:44 [ericP]
... 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
14:15:04 [ericP]
... i don't think that application manufacturers will get it right
14:15:21 [ArnaudLH]
ack cygri
14:15:25 [oberger]
q+
14:15:30 [webr3]
agree w/ bblfish
14:15:32 [BartvanLeeuwen]
q+
14:15:42 [betehess]
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
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.
14:16:10 [ericP]
... XSD types map naturally to language-native datatypes
14:16:17 [ericP]
... 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
14:16:53 [Ashok_Malhotra]
PRPOSAL1: 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
14:17:08 [ericP]
... 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
14:17:36 [SteveS]
q+
14:17:51 [ArnaudLH]
ack oberger
14:18:02 [ericP]
bblfish: 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.
14:18:20 [SteveBattle]
-1 to the proposal - I prefer the original proposal to delete 4.1.9
14:18:22 [betehess]
my answer: I believe in standards
14:18:24 [timbl]
q+
14:18:37 [ericP]
oberger: 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
14:18:58 [ArnaudLH]
ack bart
14:18:59 [ericP]
... 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 ::-)
14:19:16 [davidwood]
PROPOSAL: 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
14:19:23 [davidwood]
antonis, thanks
14:19:35 [ericP]
... we see geo datatypes, which get some use
14:19:35 [ArnaudLH]
ack steves
14:19:46 [SteveBattle]
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
14:19:59 [betehess]
q+
14:20:12 [ericP]
SteveS: true intent is "don't make up a new datatype where one of these suffices"
14:20:20 [ArnaudLH]
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
14:20:22 [webr3]
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.
14:20:46 [ericP]
timbl: the only think i care about is the MUST
14:21:03 [ericP]
... every time we make a constriant, you cut out users
14:21:07 [Ruben]
s/think/thing/
14:21:24 [ericP]
... you could say "you can put anything in here with a PUT", which everyone can use
14:21:48 [develD]
develD has joined #ldp
14:21:58 [ericP]
... you can make a further restriction with interop optimization
14:22:30 [ArnaudLH]
q?
14:22:34 [ArnaudLH]
ack bete
14:22:47 [ericP]
q+ to repeat points 7, 24 and 282-306
14:22:50 [ericP]
q-
14:22:51 [bblfish]
MUST
14:22:51 [Ashok_Malhotra]
q+
14:23:06 [ArnaudLH]
ack ashok
14:23:23 [SteveBattle]
+1 to ashok's proposal
14:23:23 [cygri]
PROPOSAL: Delete 4.1.9
14:23:37 [oberger]
or soften it
14:23:44 [ericP]
davidwood
14:23:55 [davidwood]
PROPOSAL: 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.
14:24:03 [betehess]
I'm happy to put that in a "best practices document for LDP"
14:24:05 [Ruben]
*lol @ davidwood*
14:24:09 [antonis]
-1
14:24:11 [oberger]
SteveS, you had a proposal ?
14:24:11 [Ruben]
+1 to get rid of it
14:24:13 [timbl]
+1
14:24:16 [rgarcia]
+1 to delete
14:24:17 [SteveBattle]
+1 die die die
14:24:20 [SteveS]
-1
14:24:21 [krp]
+1
14:24:22 [BartvanLeeuwen]
+1 delete
14:24:25 [bblfish]
+1
14:24:26 [svillata]
+1
14:24:27 [cygri]
±0
14:24:29 [betehess]
+1
14:24:29 [sandro]
-0
14:24:31 [webr3]
+1 to delete
14:24:31 [betehess]
+1
14:24:34 [oberger]
-0,0
14:24:35 [MacTed]
+1
14:24:36 [nmihindu]
+1 for removing
14:24:36 [roger]
+1
14:24:40 [davidwood]
+1
14:24:46 [ahaller2]
-0
14:25:00 [ericP]
davidwood: we can strike 4.1.9, soften to a SHOULD, change to language about "encouraging folks to use
14:25:03 [ericP]
-¹
14:25:14 [cygri]
q+
14:25:18 [SteveBattle]
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:14 [MacTed]
MacTed has joined #ldp
14:26:23 [HadleyBeeman]
*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
14:26:33 [sandro]
sandro: maybe? PROPOSED: Replace 4.1.9 with non-normative text, describing which datatypes are widely used -- a best practice.
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
14:26:48 [bblfish]
agree with cygri
14:27:06 [betehess]
+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"
14:27:26 [SteveS]
PROPOSAL: Soften to SHOUD and explain use instead of inventing custom ones that do the same thing
14:27:42 [sandro]
+1
14:27:46 [MacTed]
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
14:29:25 [sandro]
ArnaudLH: -1 means "I cannot live with this proposal" -- expected to lead to a Formal Objection
14:30:25 [betehess]
that's an RDF issue to me
14:30:55 [HadleyBeeman]
Q+
14:31:15 [ericP]
antonis: i think it should be written somewhere. don't mean to formally object
14:31:19 [cygri]
q-
14:31:27 [ArnaudLH]
ack david
14:31:27 [Zakim]
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
14:32:10 [bblfish]
q+
14:32:28 [ericP]
... how does a client know what to expect?
14:33:01 [ericP]
... we need a way to advertise the types
14:33:01 [ArnaudLH]
ack hadley
14:33:02 [betehess]
q+
14:33:23 [ericP]
HadleyBeeman: we have this prob everywhere (gov LD, RDF Core)
14:33:35 [ericP]
... 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
14:33:55 [ArnaudLH]
ack bblfish
14:34:16 [ericP]
bblfish: agreeing that collections can be typed and restricted
14:34:29 [ericP]
... +1 to davidwood
14:34:54 [ArnaudLH]
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."
14:34:56 [betehess]
q-
14:35:05 [ericP]
SteveS: two reasons to object:
14:35:29 [ericP]
... .. the issues around saying SHOULD (not reinvent)
14:35:47 [ericP]
... .. would like to encourage best practices as much as can
14:36:15 [webr3]
atonis, are you 0 or +1 now?
14:36:18 [antonis]
0
14:36:20 [ArnaudLH]
a?
14:36:21 [jonathandray]
jonathandray has joined #ldp
14:36:22 [ArnaudLH]
q?
14:36:23 [timbl]
q+
14:36:44 [ericP]
ArnaudLH: 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"?
14:37:54 [cygri]
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
14:38:17 [ericP]
q+
14:38:34 [webr3]
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
14:38:42 [MacTed]
*that*'s problematc
14:38:43 [svillata]
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
14:39:20 [SteveS]
-0
14:39:26 [antonis]
0
14:39:29 [ericP]
+∞×ø
14:39:33 [sandro]
+1
14:39:41 [SteveBattle]
"+1"^^xsd:short
14:40:23 [ericP]
APPROVED: Delete 4.1.9
14:40:37 [cygri]
^^ This resolves ISSUE-6
14:40:45 [ericP]
RESOLVED: Delete 4.1.9
14:41:10 [Zakim]
-[IPcaller]
14:41:22 [ericP]
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
14:41:56 [Zakim]
-MacTed
14:42:03 [sandro]
MacTed, everypone is gone, no clue
14:46:59 [Ruben]
Ruben has joined #ldp
15:03:18 [rgarcia]
rgarcia has joined #ldp
15:03:23 [cygri]
MacTed, we're slowly reconvening
15:03:59 [svillata]
svillata has joined #ldp
15:03:59 [nmihindu]
nmihindu has joined #ldp
15:05:35 [develD]
develD has joined #ldp
15:05:51 [MacTed]
tnx
15:08:07 [Zakim]
+[OpenLink]
15:08:16 [sandro]
scribe: Ashok_Malhotra
15:08:16 [MacTed]
Zakim, [OpenLink] is temporarily me
15:08:16 [Zakim]
+MacTed; got it
15:08:19 [MacTed]
Zakim, mute me
15:08:19 [Zakim]
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:08:51 [Ashok_Malhotra]
Arnaud: Let's discuss dinner then pick up issues again
15:09:01 [Ashok_Malhotra]
... also talk about f2f
15:09:19 [jmvanel]
jmvanel has joined #ldp
15:09:19 [Ashok_Malhotra]
Topic: f2f
15:09:38 [jonathandray]
jonathandray has joined #ldp
15:09:44 [Ashok_Malhotra]
Arnaud: Charter calls for a f2f in March
15:09:58 [Ashok_Malhotra]
... we have to announce 8 weeks ahead of time
15:10:07 [davidwood]
W3C event calendar: http://www.w3.org/participate/eventscal.html
15:10:23 [Ashok_Malhotra]
... We also need a list of possible hosts
15:10:29 [davidwood]
Sometimes ftf meetings can be in conjunction with another event.
15:10:29 [bblfish]
q+
15:10:34 [bblfish]
q-
15:11:27 [Ashok_Malhotra]
Ashok: Maybe Oracle can host in NYC
15:11:35 [Ashok_Malhotra]
Sandro: We can host at MIT
15:11:46 [cygri]
ack me
15:11:47 [sandro]
q- timbl
15:12:04 [sandro]
queue=
15:12:20 [bblfish]
bblfish has joined #ldp
15:12:34 [davidwood]
Maybe a straw poll on general location? (US East, US West, Europe)
15:13:12 [ahaller2]
ahaller2 is offering to host
15:13:20 [Ashok_Malhotra]
Arnaud: I'm not thinking about Europe
15:13:52 [krp]
krp has joined #ldp
15:14:44 [Ashok_Malhotra]
David: 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
15:16:25 [SteveS]
-1 to sharing room with ericP
15:16:47 [ericP]
wuss
15:17:15 [Ashok_Malhotra]
Lodging is cheaper in Cambridge
15:17:52 [Ashok_Malhotra]
I can try and find rooms on the West Coast
15:18:36 [Ruben]
+1
15:18:40 [ArnaudLH]
west coast?
15:18:42 [SteveBattle]
0
15:18:48 [betehess]
-1
15:18:48 [cygri]
STRAWPOLL: Who could go to U.S. west coast
15:18:48 [ArnaudLH]
+1
15:18:49 [SteveS]
+1
15:18:52 [cygri]
-0.2
15:18:54 [BartvanLeeuwen]
0
15:18:56 [ahaller2]
0
15:18:57 [svillata]
0
15:19:03 [SteveS]
+0.9
15:19:06 [davidwood]
+0.5
15:19:10 [Ashok_Malhotra]
+1
15:19:21 [ArnaudLH]
+1
15:19:33 [MacTed]
25% chance of west coast attendance. 75% east coast. 90% proximal to Boston.
15:20:53 [SteveBattle]
+0.5
15:20:53 [ahaller2]
can we co-locate it with some related conference, ac meeting?
15:20:53 [ericP]
+1
15:20:54 [rgarcia]
+0.75
15:20:57 [cygri]
STRAWPOLL: Who could go to U.S. east coast?
15:20:58 [roger]
+1
15:20:59 [oberger]
+0.5
15:21:00 [davidwood]
+1
15:21:00 [BartvanLeeuwen]
+0.5
15:21:00 [svillata]
+0.5
15:21:01 [betehess]
+1
15:21:01 [sandro]
+1
15:21:01 [Ruben]
+1
15:21:01 [cygri]
+0.2
15:21:03 [SteveS]
+1
15:21:04 [Ashok_Malhotra]
+1
15:21:05 [ArnaudLH]
+1
15:21:05 [krp]
+0.5
15:21:05 [ericP]
+①
15:21:22 [Ruben]
Topic: Next LDPWG meeting
15:21:26 [Ruben]
*for tpacbot*
15:24:15 [Ashok_Malhotra]
SteveS: I can look into Raleigh, NC
15:24:56 [oberger]
SteveS, do you have a cheap flight plan from london ?
15:25:01 [Ashok_Malhotra]
Arnaud: can we narrow down timing
15:25:37 [Ashok_Malhotra]
sandro: Suggest march 27/28 -- MIT Spring break
15:25:49 [rgarcia]
that week is Easter
15:25:53 [rgarcia]
at least in Spain
15:27:34 [SteveS]
oberger, american airline flight is usually not bad LHR-RDU $1,200 USD atm
15:27:52 [oberger]
ouch
15:28:27 [Ashok_Malhotra]
Arnaud: Week of March 12?
15:31:25 [Ashok_Malhotra]
oberger: Asks about what we will discuss
15:32:13 [oberger]
for expenses reason
15:32:15 [Ashok_Malhotra]
Bart: March 14/16 may work
15:33:05 [Ashok_Malhotra]
Discussion about whether a Video Conferencing facility would be available
15:34:03 [oberger]
Nice at Eurecom maybe
15:34:09 [Ashok_Malhotra]
Eric: I would book rooms for 14/15 March
15:34:21 [sandro]
Eric, Done.
15:34:27 [svillata]
I'll check for video conferencing facility in Nice
15:34:32 [oberger]
I mean, for a videoconference room
15:35:34 [ahaller2]
@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
15:36:05 [davidwood]
ahaller2, maybe earlier for mango season. Yum!
15:36:21 [Ashok_Malhotra]
Topic: Dinner
15:36:40 [Ashok_Malhotra]
Arnaud: Who can join the group fro dinner
15:36:53 [Ashok_Malhotra]
16 or 17 people
15:37:12 [Ashok_Malhotra]
... close to 20 people
15:38:04 [oberger]
ArnaudLH, Les Adrets maybe ?
15:38:14 [oberger]
dunno if as cheap (kinda)
15:38:22 [Ashok_Malhotra]
Arnaud: 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
15:38:56 [cygri]
http://www.cityvox.fr/restaurants_lyon/le-comptoir-des-marronniers_22595/Profil-Lieu
15:39:21 [cygri]
actually http://lecomptoirdesmarronniers.fr/
15:39:35 [bhyland]
bhyland has joined #ldp
15:39:43 [Ashok_Malhotra]
Arnaud: I see 17 hands ... add 1 for Henry Story
15:40:53 [bblfish]
+1
15:40:57 [Ashok_Malhotra]
... 7:30 PM
15:41:36 [cygri]
ISSUE-20?
15:41:36 [trackbot]
ISSUE-20 -- Identifying and naming POSTed resources -- open
15:41:36 [trackbot]
http://www.w3.org/2012/ldp/track/issues/20
15:42:09 [timbl]
q+
15:42:15 [timbl]
q-
15:42:23 [Ashok_Malhotra]
Topic: Issue-20
15:42:51 [Ashok_Malhotra]
http://www.w3.org/2012/ldp/track/issues/20
15:43:12 [bhyland]
bhyland has joined #ldp
15:43:57 [Ashok_Malhotra]
SteveBattle Introduces the issue
15:44:31 [roger]
+q
15:44:35 [betehess]
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
15:45:33 [timbl]
q+
15:45:33 [ArnaudLH]
ack roger
15:45:37 [davidwood]
q+
15:45:44 [cygri]
ISSUE-26?
15:45:44 [trackbot]
ISSUE-26 -- creation model for LDP -- open
15:45:44 [trackbot]
http://www.w3.org/2012/ldp/track/issues/26
15:46:05 [Ashok_Malhotra]
Roger: 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,+Rh34ne,+Rh34ne-Alpes&t=m&z=16
15:46:55 [Ashok_Malhotra]
... JohnArwe said it was not a MUST, only a SHOULD
15:47:13 [SteveS]
q+
15:48:15 [ArnaudLH]
ack bete
15:48:15 [Zakim]
betehess, you wanted to comment on the use of RDF
15:49:36 [MacTed]
the model is distinct from its serializations...
15:49:36 [ArnaudLH]
zakim, who is there?
15:49:36 [Zakim]
I don't understand your question, ArnaudLH.
15:49:41 [Ashok_Malhotra]
Betehess: Cannot have relative URIs in RDF
15:49:52 [sandro]
Zakim, who is on the phone?
15:49:53 [Zakim]
On the phone I see St_Clair_3B, MacTed (muted)
15:50:03 [Ashok_Malhotra]
... we may have to change the definition
15:50:05 [sandro]
s/RDF/RDF Abstract Syntax
15:50:09 [ericP]
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:32 [trackbot]
trackbot has joined #ldp
15:50:39 [sandro]
q+
15:50:46 [SteveBattle]
q+
15:50:54 [cygri]
q+
15:51:00 [ArnaudLH]
ack timbl
15:51:07 [Ashok_Malhotra]
Betehess: Jena, for example, always gives you an absolute URIs
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
15:52:01 [bblfish]
bblfish has joined #ldp
15:52:12 [bblfish]
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.
15:52:22 [Ashok_Malhotra]
Tim: 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
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
15:53:29 [betehess]
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.
15:53:49 [oberger]
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.
15:54:34 [sandro]
timbl: Sometimes there's a bug because there's a an absolute URI like localhost:5876 something
15:55:05 [sandro]
timbl: Someone makes a to-do list, and if it uses relative URIs they can move it around.
15:55:18 [ArnaudLH]
q?
15:55:54 [Ashok_Malhotra]
Tim: Explains that he uses relative URIs as local vraibles in a programming language
15:56:00 [ArnaudLH]
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.
15:56:02 [oberger]
http://lecomptoirdesmarronniers.fr/
15:56:21 [Ashok_Malhotra]
... would be a big problem if they were prophibited
15:56:46 [SteveBattle]
Wasn't that "didn't serve relative URIs"?
15:56:48 [Ashok_Malhotra]
s/prophibited/prophibited
15:56:52 [lcpvrr]
lcpvrr has joined #ldp
15:57:09 [Ashok_Malhotra]
s/prophibited/prohibited
15:57:47 [Ashok_Malhotra]
DavidWood: 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
15:58:38 [Ashok_Malhotra]
... slug is a header ... it's a hint
15:58:54 [ArnaudLH]
ack steves
15:58:59 [Ashok_Malhotra]
SteveS:
15:59:17 [oberger]
davidwood, is a slug http://en.wikipedia.org/wiki/Slug ?
15:59:21 [Ashok_Malhotra]
Question is what do you put in the RDF
15:59:41 [Ashok_Malhotra]
DavidWood: We don't typically self reference
15:59:52 [lcpvrr]
lcpvrr has left #ldp
16:01:10 [oberger]
http://en.wikipedia.org/wiki/Clean_URL#Slug
16:01:19 [roger]
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
16:01:39 [ArnaudLH]
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
16:02:21 [oberger]
<#new>
16:02:33 [Ashok_Malhotra]
Sandro: This is not a problem with the RDF model
16:02:45 [ArnaudLH]
q?
16:02:55 [ArnaudLH]
ack steveb
16:03:19 [betehess]
https://issues.apache.org/jira/browse/JENA-132
16:03:27 [Ashok_Malhotra]
SteveBattle: With Turtle you can send t but not consume it
16:03:36 [Ashok_Malhotra]
... 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.
16:04:49 [betehess]
]]
16:04:55 [MacTed]
s/sendt /send/
16:05:05 [cygri]
q?
16:05:08 [bblfish]
q+
16:05:59 [ArnaudLH]
ack cygri
16:06:03 [Ashok_Malhotra]
SteveBattle: 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
16:07:09 [krp]
http://tools.ietf.org/html/rfc3986#page-26
16:07:15 [cygri]
http://tools.ietf.org/html/rfc3986#section-5.1
16:07:18 [SteveBattle]
q+
16:08:47 [timbl]
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
16:09:18 [timbl]
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
16:09:24 [MacTed]
POST targets a service. *nothing* should be tied to that target URI thenceforth.
16:09:51 [ArnaudLH]
ack bete
16:09:51 [Zakim]
betehess, you wanted to offer other use-cases
16:09:56 [cygri]
MacTed, reference?
16:09:57 [Ashok_Malhotra]
... 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
16:11:18 [ericP]
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
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.
16:13:12 [webr3]
cygri, false, it's specified by content-location
16:13:23 [cygri]
webr3, reference?
16:13:26 [MacTed]
http://tools.ietf.org/html/rfc2616#section-9.5
16:13:33 [timbl]
q+
16:13:37 [ArnaudLH]
ack bblfish
16:13:43 [betehess]
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
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
16:14:35 [ArnaudLH]
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.``
16:14:58 [Ashok_Malhotra]
SteveBattle: RFC 3096 is talking about retrieval context
16:15:13 [sandro]
+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.
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.
16:15:42 [sandro]
SteveBattle: Base URI in content may still be there, ... then we skip to 5.1.4 to App-Dependent
16:15:50 [BartvanLeeuwen]
BartvanLeeuwen has joined #ldp
16:15:56 [oberger]
s/3096/3986/
16:16:03 [Ashok_Malhotra]
Arnaud: 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.
16:16:31 [SteveBattle]
Exactly - it's application dependent.
16:16:37 [MacTed]
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
16:16:53 [svillata]
q?
16:16:58 [sandro]
PROPOSED: Close ISSUE-20 saying we're okay with the design in the FPWD
16:17:03 [ArnaudLH]
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
16:17:20 [MacTed]
+1 timbl "the only logical way is to make the base the newly created URI"
16:17:23 [sandro]
q+
16:17:26 [Ashok_Malhotra]
Tim: We have to make something that is consistent and logical
16:17:28 [cygri]
q+
16:17:42 [sandro]
q- later
16:18:00 [Ashok_Malhotra]
... 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
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
16:18:48 [cygri]
q+
16:18:48 [webr3]
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
16:19:01 [sandro]
timbl: also, some versions of URI spec said <> always was self-references, regardless of any base
16:19:04 [cygri]
webr3, nice find
16:19:22 [ArnaudLH]
q?
16:19:34 [ArnaudLH]
ack eric
16:19:34 [Zakim]
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."
16:19:49 [bblfish]
q+
16:20:12 [Ashok_Malhotra]
EricP: What happens if we do not specify this ... how much depends on this
16:20:30 [Ashok_Malhotra]
... 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.
16:20:58 [bblfish]
yes
16:21:03 [betehess]
the current wording is missing the 201 Created
16:21:13 [Ashok_Malhotra]
EricP: 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
16:21:48 [Ashok_Malhotra]
... this is an important issue
16:22:05 [betehess]
q?
16:22:46 [Ashok_Malhotra]
EricP: If two servers have different rules then is the client libraries as les usable ...
16:23:36 [MacTed]
Zakim, unmute me
16:23:36 [Zakim]
MacTed should no longer be muted
16:23:37 [Ashok_Malhotra]
bblfish, Tim: You cannot be inconsistent
16:24:36 [Ashok_Malhotra]
Ted: 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.
16:25:34 [bblfish]
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
16:25:45 [sandro]
timbl: With the spec, POST is well defined.
16:26:17 [sandro]
timbl: the only option the server has is to pick the location, with LDP.
16:26:27 [MacTed]
http://tools.ietf.org/html/rfc2616#section-9.6
16:26:36 [Ashok_Malhotra]
OBerger: Are we discussing creation or adding to a container
16:27:29 [betehess]
q+
16:27:37 [sandro]
sandro: MacTed, we're refining HTTP, being more specific about the behavior of certain (LDP) resources.
16:27:44 [jonathandray]
jonathandray has joined #ldp
16:28:18 [sandro]
q?
16:28:19 [ArnaudLH]
ack cygri
16:28:34 [Ashok_Malhotra]
Ted: The POST URI has no bearing on the resource ...
16:28:49 [MacTed]
Zakim, mute me
16:28:49 [Zakim]
MacTed should now be muted
16:28:52 [sandro]
cygri: I found tims argument about <> being always self-reference to be fairly compelling.
16:29:12 [betehess]
does the order of the triples matters as well?
16:29:17 [SteveS]
q+
16:29:24 [sandro]
cygri: but the URI spec isn't quite clear about this.
16:29:35 [SteveBattle]
q+
16:29:56 [Ashok_Malhotra]
Cygri: We can escalate the issue
16:30:09 [Ashok_Malhotra]
Tim: 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
16:30:14 [bblfish]
Q+
16:30:33 [BartvanLeeuwen]
BartvanLeeuwen has joined #ldp
16:30:50 [ArnaudLH]
ack sandro
16:31:28 [Ashok_Malhotra]
Arnaud: 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...
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.
16:31:54 [SteveBattle]
+1
16:31:57 [Ashok_Malhotra]
Sandro: I'm hearing consensus in the room just questions about the larger implications
16:32:10 [sandro]
+1
16:32:11 [antonis]
+1
16:32:15 [ahaller2]
+1
16:32:18 [rgarcia]
+1
16:32:21 [SteveS]
+1
16:32:21 [timbl]
+1
16:32:22 [ArnaudLH]
+1
16:32:24 [bblfish]
+1
16:32:28 [Ruben]
+1
16:32:35 [svillata]
+1
16:32:39 [nmihindu]
+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
16:32:58 [davidwood]
+0.5, modulo my question above
16:33:11 [davidwood]
q-
16:33:12 [betehess]
+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.
16:33:28 [SteveS]
q-
16:33:29 [ArnaudLH]
ack bblfish
16:33:40 [MacTed]
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
16:33:51 [sandro]
bblfish: This is the ONLY consistently, logical interpretation, if the server sends back a location header.
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
16:35:06 [Ashok_Malhotra]
oberger: Not sure we know what we mean by POST ... create resoaurce or add to container
16:35:39 [cygri]
ISSUE-25?
16:35:39 [trackbot]
ISSUE-25 -- Weak aggregation and strong composition in containers -- open
16:35:39 [trackbot]
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.
16:36:19 [Ashok_Malhotra]
RESOLVED: Close ISSUE-20 saying we're okay with the design in the FPWD. <> is self-reference within LDP operations, at least.
16:36:29 [betehess]
q-
16:36:35 [ArnaudLH]
ack steveb
16:37:03 [Ashok_Malhotra]
SteveBattle: I have raised the same issue on HHTPbis ...
16:37:11 [Ruben]
Topic: Wrap-up for the day
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.
16:38:12 [cygri]
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.
16:38:36 [MacTed]
"<> 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.
16:40:27 [cygri]
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."
16:40:50 [MacTed]
+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."
16:42:05 [betehess]
and there were plenty of email on this subject
16:42:10 [bblfish]
q+
16:42:14 [betehess]
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."/
16:42:34 [Ashok_Malhotra]
Arnaud: People that raise issue should argue why the issue is important
16:42:42 [MacTed]
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?
16:43:36 [SteveBattle]
We're discussing the wording of the closure of issue-20.
16:43:44 [SteveBattle]
Yes.
16:43:56 [SteveBattle]
Yes - I agree with the wording.
16:44:10 [jonathandray]
jonathandray has joined #ldp
16:45:35 [Zakim]
-MacTed
16:46:56 [Ruben]
Ruben has left #ldp
16:47:38 [ericP]
RRSAgent, please draft minutes
16:47:38 [RRSAgent]
I have made the request to generate http://www.w3.org/2012/11/01-ldp-minutes.html ericP
16:48:18 [Zakim]
-St_Clair_3B
16:48:19 [Zakim]
SW_LDP()2:30AM has ended
16:48:19 [Zakim]
Attendees were St_Clair_3B, Yves, JohnArwe, AndyS, [IPcaller], MacTed
16:56:16 [SteveBattle]
SteveBattle has joined #ldp
16:57:32 [jonathandray]
jonathandray has joined #ldp
16:59:02 [roger__]
roger__ has joined #ldp
17:06:05 [jonathandray]
jonathandray has joined #ldp
17:06:29 [jonathandray]
jonathandray has joined #ldp
17:06:36 [jonathandray]
jonathandray has joined #ldp
17:06:56 [spiroid]
spiroid has joined #ldp
17:18:25 [cgueret]
cgueret has joined #ldp
17:21:43 [BartvanLeeuwen]
BartvanLeeuwen has joined #ldp
17:23:25 [timbl_]
timbl_ has joined #ldp
17:26:32 [Arnaud]
Arnaud has joined #ldp
17:34:27 [antonis]
antonis has joined #ldp
17:41:50 [SteveS]
SteveS has joined #ldp
17:44:17 [krp]
krp has joined #ldp
17:49:38 [Arnaud1]
Arnaud1 has joined #ldp
17:57:59 [trackbot]
trackbot has joined #ldp
17:58:59 [trackbot]
trackbot has joined #ldp
17:59:18 [trackbot]
trackbot has joined #ldp
18:25:45 [ahaller2]
ahaller2 has joined #ldp