Warning:
This wiki has been archived and is now read-only.
Chatlog 2013-03-15
From Linked Data Platform
See original RRSAgent log or preview nicely formatted version.
Please justify/explain all edits to this page, in your "edit summary" text.
01:55:04 <SteveS> SteveS has joined #ldp 02:43:14 <krp> krp has joined #ldp 02:51:04 <Arnaud> Arnaud has joined #ldp 03:01:22 <Zakim> Zakim has joined #ldp 03:01:37 <Arnaud> zakim: make minutes public 03:12:10 <Arnaud> rrsagent, publish minutes 03:12:10 <RRSAgent> I have made the request to generate http://www.w3.org/2013/03/15-ldp-minutes.html Arnaud 03:37:42 <bhyland> bhyland has joined #ldp 09:51:05 <Zakim> Zakim has left #ldp 09:54:51 <Arnaud> Arnaud has joined #ldp 10:51:50 <bhyland> bhyland has joined #ldp 12:05:22 <Arnaud> Arnaud has joined #ldp 12:44:08 <davidwood> davidwood has joined #ldp 12:45:40 <davidwood1> davidwood1 has joined #ldp 12:47:47 <bblfish> bblfish has joined #ldp 12:49:18 <rgarcia> rgarcia has joined #ldp 13:01:12 <SteveS> SteveS has joined #ldp 13:02:14 <Arnaud> Arnaud has joined #ldp 13:02:22 <Arnaud> trackbot, start meeting 13:02:24 <trackbot> RRSAgent, make logs public 13:02:24 <Zakim> Zakim has joined #ldp 13:02:26 <trackbot> Zakim, this will be LDP 13:02:26 <Zakim> ok, trackbot, I see SW_LDP(F2F)8:30AM already started 13:02:27 <trackbot> Meeting: Linked Data Platform (LDP) Working Group Teleconference 13:02:27 <trackbot> Date: 15 March 2013 13:05:44 <krp> krp has joined #ldp 13:06:32 <nmihindu> nmihindu has joined #ldp 13:08:47 <cygri> cygri has joined #ldp 13:10:44 <cody> cody has joined #ldp 13:11:01 <Ashok> Ashok has joined #ldp 13:11:53 <mesteban> mesteban has joined #ldp 13:12:12 <Arnaud> scribe: cody 13:12:15 <Arnaud> chair: Arnaud 13:13:36 <cody> topic: Next face to face 13:14:33 <Zakim> +WG-meeting <cody> arnaud: how long is the last call period? 13:15:01 <cody> davidwood: last call period is minimum 3 weeks 13:15:11 <davidwood1> http://www.w3.org/2005/10/Process-20051014/tr.html#last-call 13:16:02 <cody> arnaud: Steve and I were looking at the calendar the other day. Doesn't seem that easy to find a week that's going to work that well. 13:16:26 <cody> … first week of June is Semtech in San Fran 13:16:38 <cody> … week of 3rd of June is out 13:17:02 <cody> … one possibility: aim for second week of June 13:17:32 <bblfish> I don't really hear anything. Arnaud is very distant, and there is background noise. 13:17:49 <cody> … discussing the WHERE 13:18:03 <cody> sandro: you're all welcome to come back here (M.I.T.) 13:19:16 <cody> arnaud: ashok agreed to host in New York, but others complained that it's expensive 13:20:12 <cody> mesteban: We have to check for permission, but I think Madrid may be possible. We have to check for permission and get back to the group about that. 13:22:28 <bblfish> ah the noise is better now 13:22:35 <cody> kevin: another thing to avoid is SWC which is like May 26 13:22:48 <bblfish> I can hear Arnaud and others discussing W3C AC meeting... 13:23:51 <TallTed> TallTed has joined #ldp 13:23:55 <cody> arnaud: if we want to give buffer with our last call, should we aim for a bit later in June? 13:24:03 <cody> sandro: the week of July 8th 13:24:40 <bblfish> The last call is already coming up? 13:24:47 <davidwood> yes 13:24:58 <bblfish> I thought this project was a 3 year project 13:25:07 <bblfish> and we were only in the first year 13:25:33 <mesteban> q+ 13:27:13 <cody> sandro: last week of June is European Sem Web conference 13:27:35 <cody> arnaud: I'm just wondering about May 20th 13:27:54 <mesteban> No, the ESWC is the last week of May. 13:28:54 <cody> arnaud: Except WWW conference is the week before 13:29:20 <cody> ashok: isn't that a bit early? 13:29:38 <cody> steves: I think it makes sense in this case, just to try to get to last call 13:30:13 <cody> arnaud: Either the week of 10th of June or week of 17th of June 13:30:53 <cody> arnaud: for now, let's go for the week of June 17th. We would do like 18, 19, 20 (if we want to do another 3 day) 13:31:12 <roger> roger has joined #ldp 13:31:50 <cody> F2F3 candidate locations, Madrid, London, or Boston (team favors that order), but arguing travel budgets 13:32:05 <cody> davidwood: let's do a straw poll 13:32:14 <bblfish> the noise has come back. 13:32:19 <JohnArwe> JohnArwe has joined #ldp 13:32:24 <Arnaud> strawpoll: 1) madrid, 2) london, 3) boston 13:32:31 <SteveBattle> SteveBattle has joined #ldp 13:32:42 <ericP> 1 0 -1 13:32:42 <bblfish> +1 +1 -0.33333 13:32:45 <TallTed> -1, -1, +1 13:32:45 <Ashok> 0,0,1 13:32:49 <SteveS> +1, +1, +1 13:32:50 <sandro> -1 -1 +1 13:32:51 <cygri> +0.5 +1 0 13:32:52 <davidwood> -1 −1 +1 13:32:55 <JohnArwe> +1 +1 +1 13:32:58 <roger> +1, +1, +1 13:32:59 <cody> cody: +0,+0,+1 13:33:14 <bblfish> ok 13:33:15 <SteveBattle> +1, +1, 0 13:33:27 <nmihindu> +1 0 -1 13:33:33 <mesteban> +1, +1, 0 13:33:33 <bblfish> I hear now. 13:33:46 <bblfish> q+ 13:33:52 <mesteban> q- 13:33:54 <bblfish> that works 13:34:13 <sandro> RRSAgent, pointer? 13:34:13 <RRSAgent> See http://www.w3.org/2013/03/15-ldp-irc#T13-34-13 13:34:18 <Arnaud> ack bblfish 13:34:47 <bblfish> I'll check the charter 13:34:48 <cody> arnaud: it is not a 3 year project; we're chartered for 2 years 13:35:34 <davidwood> Charter: http://www.w3.org/2012/ldp/charter 13:35:38 <Arnaud> 0 +1 +1 13:35:48 <davidwood> 2012-06 13:35:48 <davidwood> F2F3 13:35:48 <davidwood> Face-to-face meeting, if needed 13:37:20 <cody> arnaud: OK, we'll leave it at that for now. We have proposed dates, locations, and a general straw poll 13:37:40 <cody> topic: LDP Specification - Pending Issues (continues) 13:38:30 <cody> arnaud: technically we don't HAVE to take public comments into account at this point, but I think it is wise to deal with them sooner, rather than later. 13:39:08 <cody> … need to figure out how we want to address the comments. davaidwood, one of your colleagues, for example, submitted several 13:39:44 <cygri> q+ 13:40:08 <cygri> q- 13:40:47 <cody> davidwood: somebody needs to get back to James formally, in the working group, and say that we acknowledge the comments 13:41:02 <cody> … I can do that. I'm sure Jame's perspective is similar to mine. 13:41:29 <cody> sandro: do we want to start tracking comments now? lc tracker? 13:41:45 <cody> … it's a comment tracker 13:41:46 <bblfish> q+ 13:43:22 <bblfish> q- 13:43:27 <JohnArwe> s/davaidwood/davidwood/ 13:43:46 <cygri> q+ 13:45:11 <Arnaud> ack cygri 13:45:58 <bblfish> Is someone scribing cygri's question because I did not hear what he said 13:45:59 <cody> cygri: would be good to report on how we tried to make sense of some of the terminology issues at dinner last night 13:46:38 <bblfish> q+ 13:46:39 <cody> cygri: I don't know that we made consensus amongst ourselves, though 13:47:03 <cody> … What we talked about can be lumped under ISSUE 37 (the model) 13:48:00 <cody> … I objected to this notion that you could post to a container and then have a member of a container that is not an LDPR; I thought through and withdrawal that objection 13:48:10 <Arnaud> ack bblfish 13:48:18 <bblfish> Issue-52 13:48:18 <trackbot> ISSUE-52 -- base -- raised 13:48:18 <trackbot> http://www.w3.org/2012/ldp/track/issues/52 13:49:17 <cody> arnaud: lets talk about the issues we'd like to talk about today first, then we can sort out priority 13:49:32 <cody> … there is the one on batch versus patch 13:49:36 <cody> … we had binary 13:49:39 <cody> … and model 13:49:43 <cody> … missing any? 13:50:08 <cody> stevebattle: issue 50 (one of henry's) 13:50:56 <SteveBattle> issue-50 13:50:56 <trackbot> ISSUE-50 -- Intuitive Containers: better support for relative URIs -- open 13:50:56 <trackbot> http://www.w3.org/2012/ldp/track/issues/50 13:51:05 <cody> arnaud: So, we have to try to manage time here. Can we first try to see if the dinner helped us get anywhere related to pagination. <cody> subtopic: ISSUE-33: Pagination for non-container resources 13:51:16 <cody> … Roger feels we rushed that 13:51:23 <cody> … ISSUE 33 13:51:30 <SteveS> ISSUE-33 ? 13:51:30 <trackbot> ISSUE-33 -- Pagination for non-container resources -- closed 13:51:30 <trackbot> http://www.w3.org/2012/ldp/track/issues/33 13:52:03 <cody> … Roger, is there anything you want to tell us about this issue to help us reconsider. 13:52:25 <SteveS> http://www.w3.org/2012/ldp/meeting/2013-03-14#resolution_1 13:52:27 <cody> … Have you slept on it? 13:53:26 <cody> roger: it seems that a lot of our issues, not just the pagination (update or patch, or for creation issues) ... 13:54:00 <SteveBattle> q+ 13:54:25 <cody> scribe is not yet understanding roger's point (hold on) 13:54:48 <Arnaud> ack steveb 13:56:14 <cody> steves: post to add. We closed an issue a few days ago to say that we wouldn't do that 13:56:27 <SteveBattle> The example is about POSTing the literal string "Mary" to Peter; how would this generalize to other datatypes? 13:56:56 <SteveBattle> q+ 13:59:06 <cody> roger: I tried to identify useful concepts for pagination and updates. You essentially get something that looks like PATCH. A useful construct for both issues: patch and pagination 13:59:40 <cody> arnaud: how is that telling me that the decision we made yesterday is not a good one? 13:59:49 <davidwood> davidwood has joined #ldp 13:59:51 <cody> roger: yeah - on face value it looks kind of the same 13:59:54 <Ashok> q+ 13:59:58 <Arnaud> ack steveb 14:00:45 <cody> tallted: updates could different if you've paginated or haven't paginated 14:01:11 <cody> arnaud: are we talking about robust pagination, which we have another issue for? 14:01:34 <roger> roger has joined #ldp 14:01:41 <cody> … still trying to figure out how they are linked together 14:02:15 <cody> ted: it will benefit us if richard could summarize the discussion last night 14:02:21 <Arnaud> ack ashok 14:03:09 <JohnArwe> q+ 14:03:22 <JohnArwe> q- 14:03:33 <cody> arnaud: agree - we need a debrief of last night 14:04:06 <cody> … lets switch gears, forget ISSUE 33 for now, and discuss the informal break-out session from last night 14:04:23 <cody> subtopic: ISSUE-37: What is the LDP data model and the LDP interaction model? 14:03:54 <cygri> http://www.w3.org/2012/ldp/wiki/User:Rcygania2/Richard%27s_LDP_101 14:04:41 <cody> cygr: my way of explaining how LDP works 14:04:47 <cody> … LDP has 2 parts to it: 14:06:04 <cody> documented in wiki "The two things that LDP does" 14:06:51 <cody> … Value sets : a set of triples with the same subject, same predicate, different object 14:07:21 <cody> … let's not get hung up on the term though 14:07:30 <cody> … you could call it a set of membership triples 14:07:44 <cody> … there is also the inverse 14:07:55 <cody> … same predicate, same object, but different subject 14:08:27 <cody> … LDP names value sets with an IRI 14:08:50 <cody> … and can be interacted with in various ways using HTTP. 14:09:45 <bblfish> What is the point of making this restriction? 14:10:25 <bblfish> I am assuming that the notion of triple set is being introduced in order to restrict what should go in an LDPR... 14:10:48 <bblfish> s/assuming/worried/ 14:10:51 <cody> … /foo/p1 s the IRI for a Value Set. If you do a GET on that URL, you'll get back those 3 triples 14:11:14 <roger> in my opinion it is being introduced to *partition* a LDPR 14:11:30 <cody> … but the URI of the Value Set is NOT the subject in the triples (unless maybe in some rare special cases) 14:11:33 <bblfish> to partition it into what? 14:11:53 <roger> into groupings according to predicate names 14:11:56 <bblfish> is this for Container membership? 14:11:59 <cody> tallted: imagine that each one of those 3 positions is filled with a full URI 14:12:08 <bblfish> s/Container/Pagination partition/ 14:12:38 <cody> cygri: the subject you have in the value sets is not the same as the URI of the value set 14:12:57 <rgarcia> rgarcia has joined #ldp 14:13:08 <cody> … the subject uri could be anything. It doesn't matter at all what the subject URI is (for this value et thing) 14:13:49 <bblfish> Yes, I still don't know why this concept is being introduced. Did I miss something? 14:14:26 <cody> … so in our example where the subject is foo, there could be other value sets that have foo as the subject 14:15:55 <cody> … container: value sets are really handy for building these REST style containers. The term container may lead to a narrow view of what you can do with them 14:16:18 <Ashok> Ashok has joined #ldp 14:16:24 <cody> … Value Set is my current conceptual replacement for what we've been calling Container 14:16:51 <Ashok> q+ 14:17:01 <cody> … the spec says you can PUT and PATCH to put any triples into this container; I don't see how that's helpful. 14:18:02 <Arnaud> ack ashok 14:18:16 <cody> ashok: My worry is that if I want to create a container that has apples and oranges... 14:18:43 <cody> cygri: VS has single subject, single predicate. If you want a diff predicate, that's a diff value set 14:18:55 <cody> tallted: apples and oranges are objects, not predicates 14:20:17 <cody> johnarwe: membership triples in a container have same subject and predicate (been in the spec since beginning) 14:20:45 <cody> ashok: I'm hung up on the thing that the subject and predicate have to be the same in the collection 14:21:11 <cody> sandro: thats a normal RDF graph, this is a special kind of RDF graph that is more constrained 14:21:28 <cody> cygri: DELETE > two forms 14:22:13 <bblfish> cygri wants to turn RDF into a plain OO system. 14:22:39 <bblfish> You can see that he is thinking of URLs as objects with the methods and varialbes as the relations 14:23:33 <SteveBattle> q+ 14:23:47 <bblfish> But this removes a lot of flexibility from the system. 14:24:03 <cody> cygri: and the third thing is pagination 14:24:20 <cody> … you can follow a next pointer to get more triples in the value set 14:25:03 <cody> … Roger wants to add a single member to a value set by posting to a URI 14:25:08 <krp> krp has joined #ldp 14:26:04 <Arnaud> ack steveb 14:26:18 <roger> … also wants to do dynamic introspection of what is possible with a value set 14:26:47 <nmihindu> +q 14:27:10 <SteveS> SteveS has joined #ldp 14:28:24 <Arnaud> ack nmihindu 14:29:39 <SteveBattle> If I have value-set <foo/p3> I'm still unsure about what I can do on <foo> 14:30:00 <cody> cygri: in order to remove single member from a container in current spec, the only way is using PUT or PATCH 14:31:22 <SteveBattle> q+ 14:31:46 <cody> nandana: where does it differ from current spec, except for the naming changes? 14:32:05 <cody> cygri: I'm folding in some changes I'd like to see in paging, but that's a separate issue. 14:32:14 <cody> … what I'm trying to make clear is that 14:32:28 <cody> … there is a distinction between this subject resource and the Value Set 14:32:50 <cody> … by using the term Container, it doesn't make it mentally easy to keep those two things apart 14:33:23 <bblfish> ? 14:33:56 <Arnaud> ack steveb 14:34:09 <JohnArwe> what is your ? henry 14:34:24 <bblfish> I don't understand where this is going. 14:34:34 <cody> … this is just describing the current spec in different words 14:34:42 <cody> arnaud: there are differences, that's not true 14:34:55 <cody> cygri: with the exception of paging, I don't think so 14:35:09 <SteveBattle> Do I get RDF if I do a GET on a value-set? (Yes) 14:36:00 <SteveBattle> If I want to delete a single triple from a value set, I still have to do a PUT or PATCH? (still unanswered) 14:36:21 <JohnArwe> henry: people had a sense that many of the disagreements were people talking past each other. at dinner several of those with widely different-sounding viewpoints came up with something we could all agree to. 14:37:04 <JohnArwe> ... to first order, the intent is that this is simply another way to speak about the same spec as we have today in terms more people can relate to. 14:37:19 <cody> … GET on a value set also gives some metadata. (see Metadata triples in value sets) 14:37:52 <cody> … GET on foo, you get some RDF and the met data triples about any value sets that use foo 14:37:55 <bblfish> there seems to be a suggestion that a LDPR should only contian one value set. 14:37:58 <nmihindu_> nmihindu_ has joined #ldp 14:38:08 <JohnArwe> ... what complicated things slightly is (1) not everyone has all the ins/outs of the spec in their forebrains, so when cyrgi made certain existing aspects more explicit people are surprised (Kevin's pt) (2) cygri did introduced a change or two around pagination. 14:38:13 <TallTed> q+ 14:38:30 <Arnaud> ack tallted 14:38:59 <JohnArwe> no, his intent is that one LDP*C* contains exactly one value set ... hence the stmts that "value set" can be thought of as just another name for today's "membership triples" 14:39:03 <Ashok> q+ 14:39:57 <bblfish> <> a foaf:PersonalProfileDocument; 14:39:57 <bblfish> foaf:primaryTopic <#me> . 14:39:57 <bblfish> <#me> a foaf:Person… 14:39:58 <bblfish> foaf:knows [ = <../jack#me>; foaf:name "Joe" ]… 14:40:00 <bblfish> How many value sets in there. How does this help? 14:40:02 <SteveBattle> q+ 14:40:25 <cody> … we have ability distinguish delete and recessive delete in the metadata 14:40:34 <JohnArwe> how many containers are in your sample henry? 14:40:39 <cody> sandro: essentially a domain-specific LDPR 14:40:59 <bblfish> is this restricted to containers? 14:41:43 <cody> cygri: one of these containers exists purely for managing the values of a certain property. 14:42:07 <SteveBattle> q- 14:42:20 <roger> i.e. an LDPC is not a domain resource 14:42:40 <bblfish> <> a ldp:Container; 14:42:40 <bblfish> :member [ = <card>; :title "Foaf Profile"; author [ = <jack>; foaf:name "Jack"; ] ] . 14:43:08 <cody> … container: managing the resource - not really a domain object. It exist in order to provide ability to add, remove, manipulate, page through members 14:43:11 <JohnArwe> as cygri is using the term, "value set" is essentially equivalent to "container" (his wiki page explicitly asserts that) ... he agreed informally as well as here that "v s" also equiv to "membership triples" b/c for him that set of triples are a major feature of containers, but also a feature that would be useful in other contexts 14:43:21 <Arnaud> ack ashok 14:43:36 <SteveBattle> Can someone answer my PUT/PATCH question, "To change a value-set I still have to use PUT/PATCH?" 14:44:10 <cody> ashok: we agreed containers can have containers within them 14:44:38 <cody> … we've got to be able to put a value set in a value set 14:44:42 <JohnArwe> SB, I think it's on "have to" that differences might emerge. can you? yes. 14:44:45 <bblfish> Since Value set is a purely RDF graph centric thing, I don't see how it is related to containers. Containers is about resource creation. It happens to often be described by a pattern called a value set. 14:44:53 <cody> cygri: there's nothing that stops you from using the URI of another Value Set 14:45:13 <cody> stevebattle: to modify a value set do I still use PUT and PATCH? 14:46:07 <JohnArwe> Henry, that sounds like violent agreement with cygri. As he pointed out last night, some people come at this from a REST/interaction viewpoint (so they care about create etc more), others from a more purely RDF standpoint (and for them the membership triples are more important) 14:46:44 <bblfish> Yes, but I don't see that you need restrictions to value sets. 14:46:51 <bblfish> graphs are good enough 14:47:04 <cody> tallted: this is the result of all of our conversation last night; doesn't lay the groundwork we began with. We discussed... 14:47:27 <JohnArwe> q+ 14:47:30 <cody> … current container: a factory, an enumerator, a modifier (including delete) 14:48:29 <bblfish> you want a new HTTP DELETE method? 14:48:38 <bblfish> RECURSIVE-DELETE ? 14:48:43 <Arnaud> ack john 14:51:11 <bblfish> If you don't want a new HTTP delete method, then you want something like factory methods. 14:51:20 <JohnArwe> Ted was suggesting that, assuming we keep recursive delete which he was not especially a fan of, it should be an option on the delete request (however we do that) rather than a choice baked into a container's implementation all the time. if a container impln chose to only offer one kind of delete, I suspect he'd be fine with that as well. 14:52:27 <bblfish> ok. 14:53:05 <JohnArwe> ...while not part of cygri's page, informally ted mentioned that (as an example) http delete might always be NON recursive, and containers that offer recursive delete would advertise that by exposing a predicate we define whose object is a url that does the recursive delete 14:54:51 <SteveBattle> DELETE <URI>?recursively ? 14:55:39 <SteveBattle> (hoping zakim doesn't try to execute that!) 15:04:29 <TallTed> TallTed has joined #ldp 15:05:51 <davidwood> davidwood has joined #ldp 15:06:09 <Arnaud> http://www.w3.org/2012/ldp/wiki/User:Rcygania2/Richard%27s_LDP_101 15:07:19 <rgarcia> rgarcia has joined #ldp 15:07:30 <roger> roger has joined #ldp 15:08:05 <roger> arnaud: thanks cygri for the report 15:08:12 <JohnArwe> Scribe: Roger 15:09:08 <SteveS> SteveS has joined #ldp 15:09:18 <roger> arnaud: wants to know what we can do with value-sets going forward 15:12:06 <davidwood> q+ to ask Richard what a "REST-style container" is 15:12:15 <roger> arnaud: should the naming difference (container vs. value set) be carried forward ? 15:13:10 <davidwood> +1 to cygri for figuring out that we are overloading a core concept ("One issue with LDP as currently designed is that it doesn't really give you flexibility to use these three abilities independently.") 15:15:19 <Arnaud> ack david 15:15:19 <Zakim> davidwood, you wanted to ask Richard what a "REST-style container" is 15:15:34 <roger> arnaud: not everyone liked the filesystem analogy 15:17:03 <roger> cygri: a REST-style container is something you post to create something new 15:17:58 <JohnArwe> Note: not all "REST-style containers" support create, some are read/only 15:18:44 <roger> yes, but, there are not part of the 'model' as such, they are there to support interaction. 15:20:14 <roger> SteveS: is there a link from Steve to his friends value-set? 15:20:27 <roger> +q 15:21:40 <SteveBattle> q+ 15:22:37 <Zakim> -bblfish 15:22:58 <Arnaud> ack roger 15:23:40 <JohnArwe> roger: issue-51 was exactly that issue - how to find container from member 15:23:41 <Zakim> +bblfish 15:23:53 <bblfish> Issue-51? 15:23:53 <trackbot> ISSUE-51 -- Linking from a Resource to its Containers (aka 'backlinks') -- raised 15:23:53 <trackbot> http://www.w3.org/2012/ldp/track/issues/51 15:24:34 <Arnaud> ack steveb 15:25:10 <JohnArwe> steve B? 15:25:35 <Ashok> q+ 15:25:42 <roger> roger: the addition to issue 51 is how to discover an empty value-set - to bootstrap it's manipulation 15:26:06 <Arnaud> ack ashok 15:26:28 <SteveBattle> q+ 15:26:43 <roger> ashok: if you access Steve you should get URI to each of its value-sets, right ? 15:28:19 <roger> +q 15:29:29 <roger> arnald: where is the factory ? 15:29:50 <Arnaud> ack steveb 15:30:57 <TallTed> hopefuly plausible example: 15:30:57 <TallTed> valueSet: http://example.com/TedKnows 15:30:57 <TallTed> membershipSubject: http://id.myopenlink.net/dataspace/person/tthibodeau 15:30:57 <TallTed> membershipPredicate: foaf:knows 15:30:57 <TallTed> to add/change/delete 15:30:58 <TallTed> - MAY PUT/PATCH/POST to http://example.com/TedKnows 15:31:00 <TallTed> - MAY PATCH/POST to http://id.myopenlink.net/dataspace/person/tthibodeau 15:31:02 <TallTed> - MAY but SHOULD NOT PUT to http://id.myopenlink.net/dataspace/person/tthibodeau 15:31:47 <TallTed> s/arnald:/arnaud:/ 15:31:51 <Arnaud> ack roger 15:33:25 <SteveBattle> So, we can only use a value set where that has previously set up using a membership-predicate. We can't use value sets on any arbitrary property. 15:33:29 <SteveS> q+ 15:33:44 <Arnaud> ack steves 15:33:57 <JohnArwe> q+ 15:34:15 <Arnaud> ack john 15:34:43 <davidwood> I have added the following issues as requested by the chair: 15:34:43 <davidwood> https://www.w3.org/2012/ldp/track/issues/53 15:34:43 <davidwood> https://www.w3.org/2012/ldp/track/issues/54 15:34:43 <davidwood> https://www.w3.org/2012/ldp/track/issues/55 15:34:43 <davidwood> https://www.w3.org/2012/ldp/track/issues/56 15:34:43 <davidwood> 15:34:43 <davidwood> They were all based on comments made by James Leigh on the public comments mailing list. 15:35:01 <roger> @SteveBattle - unless you use some kind of lazy creation process and some kind of template 15:35:35 <bblfish> perhaps this microphone is not working as well as what we had yesterday. 15:35:41 <SteveBattle> I still don't get how Roger's back-links are supported by this. 15:36:09 <roger> Where there are changes to the text according to the discussions of this morning, this should be clearly visible. 15:36:22 <roger> they are not bloody back-links :) 15:37:23 <SteveBattle> How do I discover the 'container'/value-set from a member? 15:38:07 <JohnArwe> preference from several for editors to create high level list of places where the wiki text is adapted as it is incorporated as a resolution to issue-37 15:39:04 <roger> @SteveB: either as 1. explicit links for each VS, or 2. via some kind of templated link. 15:39:17 <roger> Arwe: is this a potential resolution to issue 37 ? <roger> Arnaud: yes but I'd rather leave it open for now until people have a chance to review the text in the spec 15:39:21 <bblfish> can someone put the original microphone back. I heard the room better yesterday. 15:39:47 <SteveBattle> @roger: Insufficient data... 15:40:58 <cygri> ISSUE-15? 15:40:58 <trackbot> ISSUE-15 -- sharing binary resources and metadata -- open 15:40:58 <trackbot> http://www.w3.org/2012/ldp/track/issues/15 15:41:14 <bblfish> Issue-37? 15:41:15 <trackbot> ISSUE-37 -- What is the LDP data model and the LDP interaction model? -- open 15:41:15 <trackbot> http://www.w3.org/2012/ldp/track/issues/37 <roger> subTopic: ISSUE-33: Pagination for non-container resources (again) 15:41:35 <bblfish> Issue-33? 15:41:35 <trackbot> ISSUE-33 -- Pagination for non-container resources -- closed 15:41:35 <trackbot> http://www.w3.org/2012/ldp/track/issues/33 15:41:48 <bblfish> ok <roger> Arnaud: roger, based on what we just discussed are you now satisfied with the resolution we made on Issue-33? <roger> roger: yes 15:42:41 <JohnArwe> q+ 15:44:02 <sandro> (testing) 15:44:21 <Arnaud> ack john 15:45:56 <JohnArwe> q+ 15:46:05 <JohnArwe> q- 15:46:10 <SteveBattle> This is going way beyond pagination! 15:47:11 <JohnArwe> steve B, not grokking your ! 15:48:31 <roger> subTopic: ISSUE-17: changesets as a recommended PATCH format 15:48:35 <bblfish> Issue-17 15:48:35 <trackbot> ISSUE-17 -- changesets as a recommended PATCH format -- open 15:48:35 <trackbot> http://www.w3.org/2012/ldp/track/issues/17 15:48:36 <SteveBattle> @JohnArwe: The '!' represents my unease about discussing undocumented proposals. 15:48:46 <SteveS> http://www.w3.org/2012/ldp/meeting/2013-03-13#Issue__2d_17__3a__changesets_as_a_recommended_PATCH_format 15:49:44 <Zakim> -bblfish 15:53:01 <sandro> q+ 15:53:11 <JohnArwe> q+ 15:53:22 <Arnaud> ack sandro 15:54:30 <cygri> q+ 15:55:21 <JohnArwe> q- 15:55:37 <Arnaud> ack john 15:55:41 <TallTed> we've run into a need to interrogate the server for its features/support at a number of points ... or at least, that ability would make (or have made) several things easier 15:55:46 <Arnaud> ack cygri 15:55:52 <sandro> sandro: the server would need to advertise any patch-extensions it understands; the client MUST NOT assume the extensions are present unless its seen the server advertising it. 15:56:38 <SteveS> See Accept-Patch header http://tools.ietf.org/html/rfc5789#section-3.1 15:57:54 <sandro> (yes, that's one way to advertise it.) 15:58:04 <sandro> (if we clone trig to other media types.) 15:59:51 <sandro> issue-17? 15:59:51 <trackbot> ISSUE-17 -- changesets as a recommended PATCH format -- open 15:59:51 <trackbot> http://www.w3.org/2012/ldp/track/issues/17 16:00:53 <roger> arnaud: perhaps issue 17 is close-able with an action to develop something more concrete based on AndyS email. 16:01:00 <Arnaud> Proposed: Use Andy's proposal http://lists.w3.org/Archives/Public/public-ldp-wg/2013Mar/0058.html as the basis for solving issue-17 16:01:14 <sandro> +1 16:01:19 <roger> +1 16:01:22 <SteveS> +1 16:01:23 <mesteban> +1 16:01:23 <Ashok> =1 16:01:24 <SteveBattle> +1 16:01:24 <rgarcia> +1 16:01:25 <TallTed> +1 16:01:30 <cygri> +1 16:01:32 <nmihindu> +1 16:01:33 <JohnArwe> +1 16:01:59 <Arnaud> Resolved: Use Andy's proposal http://lists.w3.org/Archives/Public/public-ldp-wg/2013Mar/0058.html as the basis for solving issue-17 16:02:15 <sandro> (test) 16:03:07 <Arnaud> lunch break for 30mn 16:28:10 <bhyland> bhyland has joined #ldp 16:35:40 <TallTed> scribenick: TallTed 16:36:10 <TallTed> cody: valueSets are another way of describing LDPCs, as I hear it 16:37:14 <TallTed> …LDPC is a concept, which should be concisely defineable. 16:37:28 <TallTed> …if you can't do that, it seems it's really more than one concept. 16:37:42 <rgarcia> rgarcia has joined #ldp 16:38:41 <TallTed> …reworded definition will be typed in! 16:39:15 <TallTed> s/reworded/excellently reworded/ 16:39:15 <SteveS> SteveS has joined #ldp 16:39:29 <cody> A concise (an in my opinion, more proper) definition of an LDPC: 16:39:51 <TallTed> Arnaud: best way to make progress, is to make concrete proposals, like that 16:40:19 <roger> roger has joined #ldp 16:40:29 <TallTed> sandro: starting point is sometimes 10 minutes finding out whether others share my pain, vs spending a week to come up with a proposal nobody else cares about 16:40:31 <cody> "An LDPR representing a collection of same-subject, same-predicate triples, which are uniquely identified by a URI that responds to client requests for creation, modification, and enumeration of its members." 16:40:53 <TallTed> s/which are/which is/ 16:41:12 <TallTed> issue-15? 16:41:12 <trackbot> ISSUE-15 -- sharing binary resources and metadata -- open 16:41:12 <trackbot> http://www.w3.org/2012/ldp/track/issues/15 16:41:18 <TallTed> subtopic: ISSUE-15: sharing binary resources and metadata 16:41:39 <cody> In the Trminology section of the spec, I think it may be more helpful to have such concise definitions rather than a sort of "cop out" pointer to the lengthy section (calling that the definition). 16:41:54 <SteveBattle> However, this definition doesn't mention the additional metadata that an LDPC may have, eg. for defining mebership predicates. 16:42:24 <SteveBattle> s/mebership/membership/ 16:42:25 <TallTed> Arnaud: idea that when you post a binary to a container, 2 resources are created, 1 being metadata. question is which of these is the "member" and which is "external" 16:43:41 <TallTed> ericP: paraphrasing richard, expectation had been that when a resource was got from a container, it would return RDF 16:44:43 <SteveBattle> q+ 16:45:15 <cygri> q+ 16:45:22 <Arnaud> ack steveb 16:47:37 <SteveBattle> Is the POSTed binary added to the container, and if _not_ how do you get the correct deltion behaviour? 16:47:39 <TallTed> ericP: issue is the "extra magic" of how to delete extraneous material (and what that is) when the member is deleted 16:47:58 <Arnaud> ack cygri 16:48:26 <SteveBattle> My own preferred magic sauce is to have the metadata live inside the container, so it's naturally deleted along with the container. 16:48:54 <TallTed> cygri: the argument that made me object yesterday was the consistency... 16:49:12 <TallTed> … that the client knows that when it iterates through a container, it gets RDF back from all its members 16:49:48 <TallTed> … now we know that we want these to be very generic things, and their handling as well 16:50:37 <TallTed> … members are just links, at the end of the day, and just because you use an LDPC to manage these objects, doesn't mandate that they must all be LDPRs 16:50:59 <SteveS> q+ 16:51:33 <TallTed> ericP: value of membershipPredicate pointing at newly created resource is higher than pre-knowing the type of all those resources 16:51:50 <JohnArwe> q+ 16:52:27 <TallTed> cygri: an LDPC might refuse to accept a POSTed image -- if *that* LDPC only contained Turtle files... 16:52:53 <Arnaud> ack steves 16:52:57 <TallTed> … we're basically telling the client they cannot rely on LDPC members being LDPRs 16:54:03 <JohnArwe> q- 16:54:22 <TallTed> SteveS: common pattern is to make the POSTed resource's URI the member value. changing that will mean changing much more. 16:54:28 <davidwood> q+ 16:54:40 <Arnaud> ack david 16:55:09 <TallTed> davidwood: has it been decided how a client will know it's talking to an LDP server, and if so, what kind of LDP server? 16:55:29 <TallTed> Arnaud: discovery is part of ISSUE-32. we have a proposal to flesh that out. 16:56:05 <TallTed> sandro: question is are you talking to an LDPC, or an LDPR (not to an LDP server). 16:56:27 <sandro> issue-32? 16:56:27 <trackbot> ISSUE-32 -- How can clients discover that a resource is an LDPR or LDPC, and what features are supported? -- open 16:56:27 <trackbot> http://www.w3.org/2012/ldp/track/issues/32 16:57:26 <TallTed> davidwood: I've determined I'm not talking to either LDPR or LDPC, but an image. should I not know I'm talking to an LDP server? 16:57:46 <TallTed> sandro: should be able to follow Link: rel header, and determine the answer... 16:58:08 <roger> it could be that if a resource has links to its value-sets, then it is a LDPR, otherwise it is something else .. (?) 17:00:11 <TallTed> Arnaud: pulling back to the agenda... discussion of how cygri concluded that he was OK with yesterday's breakout proposal 17:00:40 <TallTed> ericP: I feel like we should come up with an answer about DELETE, but can see backward compatibility with existing application patterns has value 17:01:29 <JohnArwe> david, in your new issue please be as clear as possible what it this buys you that introspection of the resource [server's] capabilities ala 21/32 discussions will not. or at least which aspects of the server's behavior you'd certainly want a client to discover via your issue. 17:02:09 <davidwood> ok 17:02:44 <Arnaud> proposed: POST whatever you want to the container, and it gets given a URI I and returned as normal, but ALSO a metadata resources P is created. When you GET I, you get back a LINK header leading youto P. When you GET P, there's some triple with the same link information, leading you to I. 17:03:10 <SteveBattle> I agree with John & Eric, the DELETE behaviour is under-specified. 17:03:10 <rgarcia> q+ 17:03:21 <Arnaud> ack rgarcia 17:03:40 <cygri> q+ 17:04:11 <Arnaud> ack cygri 17:04:16 <TallTed> [back-and-forth about whether I and P are or can be the same URI] 17:05:03 <TallTed> cygri: MUST, MAY, SHOULD? 17:05:59 <TallTed> JohnArwe: [composing spec vocally] 17:06:23 <SteveBattle> q+ 17:06:51 <Arnaud> ack steveb 17:06:59 <TallTed> cygri: all this is optional anyway... so the server may do this additional? 17:07:14 <JohnArwe> Assuming the existing qualifications that POST is optional, and supporting "binary" media types is optional: #17:07:49 <Zakim> -WG-meeting 17:07:50 <Zakim> SW_LDP(F2F)8:30AM has ended 17:07:50 <Zakim> Attendees were bblfish, WG-meeting 17:08:16 <davidwood> Zakim, this is SW_LDP 17:08:16 <Zakim> davidwood, I see SW_LDP(F2F)8:30AM in the schedule but not yet started. Perhaps you mean "this will be SW_LDP". 17:08:28 <davidwood> Zakim, this will be SW_LDP 17:08:28 <Zakim> ok, davidwood; I see SW_LDP(F2F)8:30AM scheduled to start 278 minutes ago 17:08:37 <SteveBattle> The metadata resource does not only comprise server-managed properties, a client may add additional metadata. 17:09:17 <JohnArwe> ... The expected response to a post for create is a 201, with location header whose URI identifies the resource whose representation matches the POST input, and the response MAY include a Link header rel="meta" href= another URI identifying the resource whose state is the server-managed properties. 17:09:23 <SteveBattle> It's may not be a simple LDPR URI, but possibly a hash URI within an LDPR 17:09:41 <JohnArwe> ...those two URIs MAY be distinct. 17:10:54 <TallTed> [vocal tinkering...] 17:11:28 <bblfish> bblfish has joined #ldp 17:12:25 <JohnArwe> PROPOSAL: Assuming the existing qualifications that POST is optional, and supporting "binary" media types is optional: The expected response to a post for create is a 201, with location header whose URI I identifies the resource whose representation matches the POST input, and the response MAY include a Link header rel="meta" href= another URI P identifying the resource whose state is the server-managed properties. 17:12:25 <JohnArwe> When the object of a membership triple (I) is DELETEd, the server MUST automatically deletes any resource P that it created previously. 17:12:46 <Zakim> SW_LDP(F2F)8:30AM has now started 17:12:53 <Zakim> +bblfish 17:12:58 <JohnArwe> ...The URIs I and P MAY be distinct, but this is not required. 17:12:59 <Ashok> s/any/any related/ 17:13:11 <roger> +1 17:13:14 <bblfish> back, travelled from Paris to Fontainebleau during break 17:13:19 <davidwood> I suggest changing "MAY include a Link" to "SHOULD include a Link". 17:13:22 <bblfish> can't hear anything 17:13:31 <SteveBattle> Even for an RDF resource? 17:13:33 <Zakim> +WG-meeting 17:13:36 <bblfish> thanks 17:13:38 <bblfish> +! 17:13:44 <davidwood> …in order to ensure we don't conflict with any later resolution related to discoverability. 17:14:06 <SteveBattle> q+ 17:14:09 <cygri> q+ 17:14:13 <mesteban> JohnArwe, should we discourage then sending DELETE to P? 17:14:20 <Arnaud> ack steveb 17:14:30 <TallTed> davidwood: my only change would be MAY to SHOULD for Link header 17:14:37 <Arnaud> ack cygri 17:14:37 <JohnArwe> @miguel, fine by me 17:14:43 <TallTed> SteveBattle: seems redundant if POST was turtle 17:15:01 <TallTed> cygri: proposal now reads as if this happens even for turtle. not sure if that's the intentional. 17:15:04 <bblfish> logger? 17:15:10 <TallTed> s/intentional/intention/ 17:15:24 <Arnaud> strawpoll: 1) what john wrote (with MAY), 2) same with SHOULD instead of MAY 17:15:52 <bblfish> zakim pointer? 17:15:54 <TallTed> cygri: the way this is described, "here's a useful pattern that servers may want to use in a certain case" 17:16:11 <bblfish> got it thansk :-) 17:16:19 <Ashok> q+ 17:16:52 <TallTed> cygri: there will be implementations that don't want to deal with binary resources, and SHOULD forces extra work there 17:17:05 <Ashok> q- 17:17:07 <Arnaud> ack ashok 17:17:08 <TallTed> davidwood: implementations aren't required to support binaries, but if they *do*, they SHOULD do it this way 17:17:17 <bblfish> +1 for davidwood 17:17:27 <TallTed> Ashok: echoes davidwood. 17:17:36 <SteveBattle> "When the object of a membership triple (I) is DELETEd" - In the case of an inverse membership property, the binary is the subject. 17:17:51 <davidwood> 0 +1 17:17:52 <TallTed> Arnaud: strawpoll: 1) what john wrote (with MAY), 2) same with SHOULD instead of MAY 17:17:59 <JohnArwe> steve b: correct 17:18:03 <cygri> 1 -0.2 17:18:10 <Ashok> 0,1 17:18:16 <TallTed> 0, +1 17:18:18 <mesteban> 0,+1 17:18:21 <JohnArwe> ...needs to factor inverses in, but we also need something to start w/ before changing it I hope. 17:18:22 <SteveS> 0, 0 17:18:27 <cody> 0,0 17:18:47 <krp> 0,+0.8 17:18:56 <nmihindu> 0, +1 17:18:56 <TallTed> cygri: don't see why we're getting into specifying patterns for metadata of binary resources... 17:18:58 <bblfish> Mhh, I don't understand this proposal 17:19:06 <JohnArwe> 1,1 17:19:15 <SteveBattle> 1,0 (subject to rewording of "object of membership triple") 17:19:19 <cody> my 0,0, is pass (out of ignorance) 17:19:29 <rgarcia> +1, 0 17:19:46 <Ashok> Henry, MAY ad metadata or SHOULD add metadata 17:19:48 <davidwood> s/0 +1/-π +1/ 17:19:56 <mesteban> Then my voyte should be +1, +1. 17:20:06 <mesteban> s/voyte/vote/ 17:21:30 <bblfish> ah ok I got it 17:21:31 <SteveS> +1, +1 should have been my vote -- I want this text for binary resources and associated meta resource, neutral on whether it should be MAY or SHOULD 17:21:43 <roger> roger has joined #ldp 17:22:14 <bblfish> +1,0 ( 17:22:29 <bblfish> oops 17:22:36 <bblfish> I mean 0,+1 17:23:00 <Arnaud> Arnaud has joined #ldp 17:23:00 <bblfish> I can still hear arnaud 17:23:18 <Arnaud> Proposed: Close issue-15 with: Assuming the existing qualifications that POST is optional, and supporting "binary" media types is optional: The expected response to a post for create is a 201, with location header whose URI I identifies the resource whose representation matches the POST input, and the response SHOULD include a Link header rel="meta" href= another URI P identifying the resource whose state is the server-managed properties. When the object of a membership triple (I) is DELETEd, the server MUST automatically deletes any resource P that it created previously. 17:23:35 <SteveBattle> 0 17:23:46 <TallTed> "...The URIs I and P MAY be distinct, but this is not required." 17:24:28 <bblfish> +1 17:24:45 <TallTed> drafting and redrafting... 17:25:33 <JohnArwe> PROPOSAL: Assuming the existing qualifications that POST is optional, and supporting "binary" media types is optional: The expected response to a post for create that creates a non-LDPR is a 201, with location header whose URI I identifies the resource whose representation matches the POST input, and the response SHOULD include a Link header rel="meta" href= another URI P identifying the resource whose state is the server-managed properties. When the object of a membership triple (I) is DELETEd, the server MUST automatically deletes any related resource P that it created previously. 17:25:57 <SteveS> +1 17:26:14 <cygri> -0.2 17:26:14 <TallTed> +1 17:26:15 <mesteban> Shouldn't we include Ted's clarification? 17:26:19 <krp> +1 17:26:21 <Ashok> +1 17:26:22 <rgarcia> -1 17:26:23 <jmvanel> jmvanel has joined #ldp 17:26:24 <bblfish> +1 17:26:30 <nmihindu> +1 17:26:35 <davidwood> +1 17:26:35 <TallTed> s/PROPOSAL: Assuming/PROPOSAL: close issue-15 with: Assuming/ 17:26:56 <SteveBattle> 1 (subject to rewording of "object of membership triple" in the case of inverse membership properties) 17:27:51 <JohnArwe> PROPOSAL: Close issue-15 by saying: Assuming the existing qualifications that POST is optional, and supporting "binary" media types is optional: The expected response to a post for create that creates a non-LDPR is a 201, with location header whose URI I identifies the resource whose representation matches the POST input, and the response SHOULD include a Link header rel="meta" href= another URI P identifying the resource whose state is the server-managed properties. The URIs I and P MAY be distinct, but this is not required. When the object of a membership triple (I) is DELETEd, the server MUST automatically deletes any related resource P that it created previously. 17:27:56 <TallTed> seventeenth time's the charm! 17:28:33 <rgarcia> +1 17:28:33 <TallTed> +1 17:28:39 <ericP> +1 17:28:40 <SteveS> +1 17:28:40 <nmihindu> +1 17:28:40 <cygri> -0.21 17:28:41 <roger> +1 17:28:43 <mesteban> +1 17:28:45 <krp> +1 17:28:48 <SteveBattle> 1 (subject to rewording of "object of membership triple" in the case of inverse membership properties) 17:29:02 <davidwood> +1 17:29:03 <bblfish> +1 17:29:05 <JohnArwe> +1 17:29:52 <TallTed> mesteban: what happens when we send a DELETE for P? 17:30:18 <JohnArwe> Miguel raised a question earlier... one way to address that might be: LDPC servers SHOULD NOT allow clients to delete 17:30:18 <JohnArwe> server-managed resources like P. 17:30:21 <SteveBattle> P is deleted? 17:30:24 <Arnaud> Resolved: Close issue-15 by saying: Assuming the existing qualifications that POST is optional, and supporting "binary" media types is optional: The expected response to a post for create that creates a non-LDPR is a 201, with location header whose URI I identifies the resource whose representation matches the POST input, and the response SHOULD include a Link header rel="meta" href= another URI P identifying the resource whose state is the server-managed properties. The URIs I and P MAY be distinct, but this is not required. When the object of a membership triple (I) is DELETEd, the server MUST automatically deletes any related resource P that it created previously. 17:31:17 <TallTed> PROPOSAL: LDPC servers SHOULD NOT allow clients to delete server-managed resources like P. 17:31:20 <SteveBattle> q+ 17:31:39 <bblfish> ? 17:31:42 <TallTed> SteveBattle: I don't agree that these properties are only server-managed 17:31:51 <JohnArwe> LDPC servers SHOULD NOT allow clients to delete resources like P. 17:32:00 <SteveBattle> q- 17:32:00 <Arnaud> ack steveb 17:32:14 <SteveBattle> 0 17:32:23 <bblfish> ah you mean one should not be able to delete the metadata about a binary if the binary exists. 17:32:46 <davidwood> I disagree with TallTed. 17:34:28 <davidwood> TallTed is saying something like, "A server MAY decide to create and separately manage metadata about its resources. Clients MAY NOT be allowed to delete server-created resources." 17:34:52 <cygri> For the record: I prefer LDP to be concerned only with managing RDF representations, with the possibility to extend it for other kinds of data. This decision adds a half-baked protocol for managing non-RDF resources, and I don't think that should be in LDP. 17:35:32 <TallTed> rgarcia: the server decided to create that additional resource, so it shouldn't allow deletion 17:35:54 <rgarcia> s/rgarcia/mesteban/ 17:36:26 <TallTed> (2 minute break...) 17:36:28 <bblfish> I'll go make good coffée too here... 17:41:26 <TallTed> (reconvene) 17:41:39 <TallTed> Arnaud: do we continue pursuing this? or leave it at that? 17:42:18 <TallTed> davidwood: small group conversation... server can create its own server-managed metadata that clients can't touch. 17:42:18 <TallTed> …server can also create LDPRs or LDPCs on its own that are exposed to client interaction. 17:42:29 <TallTed> …if server decides to create metadata that only it controls, it can do that 17:42:56 <TallTed> Ashok: 2 kinds of metadata. which one does the link header point to? 17:43:36 <TallTed> …could have multiple Link headers! 17:43:46 <davidwood> Good question! Could a server expose metadata to a client that no client is allowed to act upon? 17:44:02 <cygri> q+ 17:44:10 <SteveBattle> …nothing to stop user-managed and server-managed triples being in the same LDPR 17:44:24 <TallTed> davidwood: I like software systems that eat their own dogfood. where high level functionality is built on the low level functionality. 17:44:52 <TallTed> … way to implement an LDP server is for that server to make use of all this RDF stuff it has floating around, REST interactions, etc. 17:45:26 <TallTed> … if that server already has some sort of permissions structure, it's easy to use that on its own created metadata 17:45:34 <bblfish> Agree: the ACL system can be used to give permissions on resources and metadata 17:46:19 <Arnaud> ack cygri 17:46:24 <cygri> q- 17:46:34 <SteveBattle> Sounds like we need a separate issue about server-managed properties and ACL's? 17:46:54 <TallTed> P = container, 2 contained resources, 1 for server, 1 for client. :-) 17:47:22 <JohnArwe> @SB: "need" implies you are requesting a change, so if so... yes 17:47:52 <TallTed> Arnaud: what do we do next? administrivia awaits (review RAISED issues, etc.) <tallted> topic: Disposition of Raised Issues <tallted> subtopic: ISSUE-51: Linking from a Resource to its Containers 17:49:07 <TallTed> issue-51? 17:49:07 <trackbot> ISSUE-51 -- Linking from a Resource to its Containers (aka 'backlinks') -- raised 17:49:07 <trackbot> http://www.w3.org/2012/ldp/track/issues/51 17:51:49 <bblfish> ah ok. The title is very misleading 17:53:02 <TallTed> [rewording to correct intent] 17:55:45 <JohnArwe> q+ 17:55:49 <cygri> Linking from a membershipSubject to its containers 17:56:12 <cygri> q+ 17:56:34 <SteveS> <c, ldl:membershipSubject, r> 17:57:00 <SteveS> q+ 17:57:55 <Arnaud> ack john 17:58:18 <TallTed> JohnArwe: will expose the cognitive double-entendres 17:58:30 <davidwood> ISSUE-51 may be a tautology: If a resource is referenced, we don't need to separately reference them... 17:58:54 <Arnaud> ack cygri 17:59:27 <SteveBattle> q+ 17:59:47 <bblfish> The problem is that one needs now something saying that this is NOT backlinks 18:00:06 <Arnaud> ack steves 18:00:06 <davidwood> +1 to bblfish 18:00:07 <SteveS> <c, ldl:membershipSubject, r> 18:00:36 <TallTed> "ISSUE-51: Linking from a Resource to the Containers which it contains (not the containers the resource is in)" 18:00:50 <TallTed> which makes the Resource a Container 18:01:50 <TallTed> SteveS: example on Net Worth, 1.9, may be relevant... 18:02:32 <Arnaud> ack steveb 18:03:28 <bblfish> q+ 18:03:33 <TallTed> how do you get from an LDPR to the valueSets (a/k/a LDPCs) of which it is Subject? 18:03:36 <Arnaud> ack bblfish 18:04:02 <ericP> <containerPage1> { <http://example.org/netWorth/nw1> o:asset <a1>,<a2>. <a1> a o:Stock . <a2> a o:Cash> 18:04:06 <ericP> } 18:04:08 <ericP> <a1> { <a1> a o:Stock ; o:value 100.00 ; dcterms:title "IBM" } 18:04:11 <ericP> <a2> { <a2> a o:Cash ; o:value 50.00 ; } 18:04:48 <bblfish> perhaps put that in the issue then 18:05:21 <SteveBattle> I only just grokked that a value-set is what was formerly known as an LDPC. 18:06:01 <davidwood> bblfish, the diagram roger drew looks something like this: A container (A) links to a resource (B), resource (B) in turn links to containers (C) and (D). ISSUE-51 is about the links from B to C and B to D. 18:06:05 <JohnArwe> henry you can also look at ex 2 from the LDP spec; in that context, the question is how a client "finds" /nw1 (and any other containers) from a resource like <> 18:06:29 <bblfish> ok. 18:06:51 <bblfish> Just take a picture of the picture and post the above explanation in the issue report 18:06:55 <JohnArwe> ...and do that WITHOUT implying somehow that <> MUST be a container (which was the problem with the "child link" alternative, that it suggested this unwanted effect) 18:07:41 <SteveBattle> I need concrete written examples before I can process this properly. 18:08:06 <bblfish> but if B links to C and D what is the issue? 18:08:13 <TallTed> roger: wants a MUST that you get :steve'sFriends ldp:membershipSubject :Steve when you dereference :Steve... 18:08:31 <davidwood> bblfish, That's what we are trying to articulate :) 18:08:45 <davidwood> Frankly, I'm confused, or at least I think I am. 18:08:46 <bblfish> does it matter, any relation will do no? 18:09:20 <bblfish> ( well not any relation, but there could be many relations relating a resource to a container - an infinity to be precise ) 18:09:31 <TallTed> roger: is accustomed to getting :Steve in ?subject position for all relevant statements, not used to looking at ?object as well 18:10:04 <bblfish> if you want to say something is a container. then you can have { B link C . C a ldp:Container .} 18:10:05 <Arnaud> q? 18:10:09 <JohnArwe> I could try it as a variation on LDP spec ex 2: instead of <> being a container itself, imagine that it *has* two containers, one for assets and one for liabilities. If a client is given the URL for <>, how does the client find out about the assets and liabilities containers? 18:10:54 <Arnaud> resolved: Open issue-51 18:11:07 <Arnaud> reopen issue-51 18:11:07 <trackbot> Re-opened ISSUE-51 Linking from a Resource to its Containers (not the containers the resource is in). 18:11:47 <bblfish> should the title not be "Linking from a Resource to containers"? 18:11:52 <TallTed> Arnaud: moving on... issue52 <tallted> subtopic: ISSUE-52: base & ISSUE-54: Which URIs should replace null relative URIs provided in LDPR representations 18:11:55 <TallTed> issue-52? 18:11:55 <trackbot> ISSUE-52 -- base -- raised 18:11:55 <trackbot> http://www.w3.org/2012/ldp/track/issues/52 18:13:37 <davidwood> Possible duplicate with ISSUE-54 18:13:42 <davidwood> ISSUE-54? 18:13:42 <trackbot> ISSUE-54 -- Which URIs should replace null relative URIs provided in LDPR representations? -- raised 18:13:42 <trackbot> http://www.w3.org/2012/ldp/track/issues/54 18:14:00 <TallTed> bblfish: logged based on email to the list. looked at spec as-of-today, and saw confusion about the meaning of <> 18:15:02 <bblfish> http://www.w3.org/TR/2013/WD-ldp-20130307/#http-post-1 18:15:04 <roger> @TallTed, just for the record, looking at the ?object doesn't freak me out entirely, I just want to be follow the signposts simply, rather then pre-assuming knowledge of the destination to find forward signposts. 18:15:10 <bblfish> 5.4.8 In RDF representations, LDPC servers must interpret the 18:15:10 <bblfish> null relative URI for the subject of triples in the LDPR 18:15:10 <bblfish> representation in the request entity body as referring to the 18:15:12 <bblfish> entity in the request body. Commonly, that entity is the model 18:15:14 <bblfish> for the “to be created” LDPR, so triples whose subject is the 18:15:16 <bblfish> null relative URI will usually result in triples in the created 18:15:18 <bblfish> resource whose subject is the created resource. 18:16:03 <davidwood> q+ to suggest combining ISSUE-52 and ISSUE-54 by pulling ISSUE-54 content into ISSUE-52 and closing ISSUE-54 as duplicate. ISSUE-52 should be opened. 18:16:09 <TallTed> bblfish: this suggests that the parser behavior must be changed 18:16:18 <Arnaud> ack david 18:16:18 <Zakim> davidwood, you wanted to suggest combining ISSUE-52 and ISSUE-54 by pulling ISSUE-54 content into ISSUE-52 and closing ISSUE-54 as duplicate. ISSUE-52 should be opened. 18:17:24 <SteveBattle> q+ 18:17:43 <TallTed> PROPOSED: merge content of issue-52 and issue-54, closing 52, and OPENing 54 for future discussion/resolution 18:17:47 <cygri> +1 18:17:54 <SteveBattle> q- 18:18:02 <SteveBattle> +1 18:19:09 <bblfish> q+ 18:20:18 <Arnaud> ack bblfish 18:21:26 <bblfish> ok 18:21:29 <JohnArwe> +54 ... or +52 18:21:32 <TallTed> Arnaud: +1 18:21:43 <SteveS> +1 18:21:57 <nmihindu> +1 18:21:59 <mesteban> +1 18:22:01 <cody> +1 18:22:03 <rgarcia> +1 18:22:05 <bblfish> +1 to closing 52 and add 52 as a solution to 54 18:22:07 <davidwood> +1 18:22:11 <roger> +1 18:22:14 <TallTed> RESOLVED: Merge content of issue-52 and issue-54, closing 52, and OPENing 54 for future discussion/resolution <tallted> subtopic: ISSUE-53: Which Content Types should be returned to bots? 18:22:42 <bblfish> Issue-53 18:22:42 <trackbot> ISSUE-53 -- Which Content Types should be returned to bots? -- raised 18:22:42 <trackbot> http://www.w3.org/2012/ldp/track/issues/53 18:23:42 <TallTed> Arnaud: issue 53. oh yes. seems clearly justified. let's open it. 18:23:49 <TallTed> Arnaud: opened by acclamation. 18:23:53 <Arnaud> resolved: Open issue-53 18:24:03 <Arnaud> reopen issue-53 18:24:03 <trackbot> Re-opened ISSUE-53 Which Content Types should be returned to bots?. <tallted> subtopic: ISSUE-55: Hypermedia as the Engine of Application State (HATEOAS) Compliance 18:24:21 <TallTed> issue;55? 18:24:24 <TallTed> issue-55? 18:24:24 <trackbot> ISSUE-55 -- Hypermedia as the Engine of Application State (HATEOAS) Compliance -- raised 18:24:24 <trackbot> http://www.w3.org/2012/ldp/track/issues/55 18:24:41 <TallTed> Arnaud: issue 55 also seems to have a valid point, may resonate with Roger 18:25:49 <TallTed> [discussion - some past comments comes to mind here, but no resolution is remembered] 18:26:02 <TallTed> Arnaud: without objection.... opening issue-55 18:26:09 <Arnaud> resolved: Open issue-55 18:26:14 <Arnaud> reopen issue-55 18:26:14 <trackbot> Re-opened ISSUE-55 Hypermedia as the Engine of Application State (HATEOAS) Compliance. 18:26:17 <cygri> strong +1 to opening 55 <tallted> subtopic: ISSUE-56: How can clients discover LDPR PUT URLs? 18:26:30 <bblfish> Issue-56 18:26:30 <trackbot> ISSUE-56 -- How can clients discover LDPR PUT URLs? -- raised 18:26:30 <trackbot> http://www.w3.org/2012/ldp/track/issues/56 18:28:00 <TallTed> TallTed: open it 18:29:37 <mesteban> +1 to davidwood 18:29:57 <Arnaud> resolved: Open issue-56 18:30:02 <Arnaud> reopen issue-56 18:30:02 <trackbot> Re-opened ISSUE-56 How can clients discover LDPR PUT URLs?. 18:30:05 <TallTed> sandro: a good answer may be "don't do that. only PUT on something you can GET" 18:30:10 <cygri> sandro: Only ever do a PUT when you can do a GET <tallted> subtopic: ISSUE-57: How can a client determine that it is in communication with an LDP service? 18:31:09 <bblfish> Issue-57 18:31:09 <trackbot> ISSUE-57 -- How can a client determine that it is in communication with an LDP service? -- raised 18:31:09 <trackbot> http://www.w3.org/2012/ldp/track/issues/57 18:31:32 <TallTed> Arnaud: issue:57 -- identifying an LDP service 18:31:43 <cygri> Duplicate of ISSUE-32? 18:31:51 <TallTed> davidwood: several other issues touch on this, but I think it's cleaner to resolve them all generally, than each as a special case 18:32:13 <bblfish> do an HTTP GET on the resource ? 18:32:19 <davidwood> cygri, please note the text in the issue: "NB: The answer to ISSUE-32 may or may not provide an answer to this issue as well. If so, this issue may be closed concurrently." 18:32:26 <bblfish> or have the other resource describe it as a ldp:Resource . 18:32:33 <SteveBattle> q+ 18:33:23 <Arnaud> ack steveb 18:36:37 <SteveBattle> Are there precedents for services/servers/resources advertising themselves via an HTTP header? 18:36:49 <Ashok> Ashok has joined #ldp 18:37:14 <davidwood> SteveBattle, sure, Web servers tell you what they are. 18:37:30 <TallTed> arnaud: "service" to be changed to "service" in the issue 18:37:32 <bblfish> q+ 18:37:44 <TallTed> Arnaud: barring objection... open issue 57 18:38:10 <TallTed> s/"service" to be changed to "service"/"service" to be changed to "server"/ 18:38:55 <Arnaud> resolved: Open issue-57 18:39:04 <Arnaud> reopen issue-57 18:39:05 <trackbot> Re-opened ISSUE-57 How can a client determine that it is in communication with an LDP server?. <tallted> subtopic: ISSUE-58: Property for asserting that complete description of members is included in LDPC representation 18:39:13 <TallTed> issue-58? 18:39:13 <trackbot> ISSUE-58 -- Property for asserting that complete description of members is included in LDPC representation -- raised 18:39:13 <trackbot> http://www.w3.org/2012/ldp/track/issues/58 18:39:35 <bblfish> how long is the break for? 18:40:24 <SteveBattle> q+ 18:40:33 <TallTed> Arnaud: [summarizes issue description] 18:40:46 <TallTed> +1 open 18:40:55 <bblfish> ah ok, so this is a bit like an atom:feed containing atom:entry 18:41:14 <bblfish> so that you get something of a description in the LDPC ? 18:41:21 <Arnaud> ack bblfish 18:41:23 <SteveS> q+ 18:41:59 <Arnaud> ack steveb 18:42:06 <cody> q+ 18:42:23 <TallTed> SteveBattle: is this continuing with LDPCs being valueSets? 18:42:27 <cody> Could use clarification on the meaning of " So that a client doesn't have to dereference each member in order to be sure that it has complete data." 18:42:33 <JohnArwe> Henry: let's say that your LDPC server has 4 triples about a member. If GETting the LDPC returns 2 of those member's triples, Richard's flag would be off. If the LDPC returns all 4, the flag would be on. 18:42:54 <bblfish> ah ok. 18:42:59 <JohnArwe> The flag is essentially an optimization to allow clients to know there is no value in GETing the member; they can, but they will obtain no new triples. 18:43:19 <SteveBattle> So I've just grokked that value-sets can also contain item-level properties. 18:43:27 <TallTed> SteveS: could use the pagination indicators, include next=NULL or similar 18:44:25 <Arnaud> ack steves 18:44:31 <Arnaud> ack cody 18:44:40 <bblfish> It makes sense to open it, but I think it is very odd. 18:44:49 <TallTed> Arnaud: look to example 3 in the spec... cygri wants to know whether there are more triples to be retrieved about <a1> than are present in this example, without GETting <a1> 18:44:51 <TallTed> +1 open 18:44:54 <roger> +1 18:44:57 <davidwood> +1 18:45:00 <SteveS> I was saying have <a1, ldp:nextPage, rdf:nil> 18:45:03 <SteveS> +1 18:45:07 <Arnaud> resolved: Open issue-58 18:45:09 <TallTed> Arnaud: objections to opening issue-58? none? open. 18:45:11 <JohnArwe> +1 18:45:36 <bblfish> the problem I see is that you have an ldp:thisIsAllThereIS , then that is a relation between a document and something. 18:45:39 <cygri> SteveBattle, the model is that a container is a set of triples where they all have the same s and p. But when you GET a container, it may give you some other triples besides those 18:45:43 <Arnaud> reopen issue-58 18:45:43 <trackbot> Re-opened ISSUE-58 Property for asserting that complete description of members is included in LDPC representation. 18:45:56 <bblfish> My guess is that you will find merging information about these things a bit odd. 18:48:33 <bblfish> ah yes, so how long is the break now? 18:50:21 <JohnArwe> 15 mins 18:50:30 <JohnArwe> sorry 15 total only 10 left now 18:56:46 <bblfish> opening some wine here, and preparing dinner 19:01:23 <cody> Photos of the F2F2 working group posted to: http://www.w3.org/2012/ldp/wiki/Special:ListFiles (Panorama.png.zip, IMG0981.JPG.zip, IMG_0980.JPG.zip, IMG_0979.JPG.zip) 19:01:32 <davidwood> Nice! Think of us while we are flying :) 19:02:17 <SteveBattle> Cygri, even if those triples are defined in separate LDPRs? This behaviour isn't defined for LDPCs (I guess it isn't outlawed). 19:02:56 <rgarcia> rgarcia has joined #ldp 19:03:21 <cygri> SteveBattle, I think the NetWorth example in the spec does this (inlining parts of the member descriptions) 19:05:01 <cygri> q+ 19:05:25 <SteveS> Scribe: SteveS 19:05:39 <SteveS> Arnaud: Steve is scribe, thank you <steves> topic: LDP Specification - Pending Issues (continues) 19:05:50 <davidwood> ISSUE-49? 19:05:50 <trackbot> ISSUE-49 -- Canonical URL - how to communicate its value to clients -- open 19:05:50 <trackbot> http://www.w3.org/2012/ldp/track/issues/49 19:05:58 <SteveS> subTopic: ISSUE-49: Canonical URL - how to communicate its value to clients 19:06:28 <SteveS> Ashok: this is not special for LDP and consider removing 4.1.4 19:06:50 <davidwood> q+ to ask whether a server will always have a canonical URL for a resource 19:07:08 <SteveS> cygri: agree is with Ashok it is not just and LDP problem, consider moving to deployment guide to warn/help implementers 19:07:30 <SteveS> sandro: Google supports rel = canonical 19:07:37 <Arnaud> ack cygri 19:08:06 <Arnaud> ack david 19:08:06 <Zakim> davidwood, you wanted to ask whether a server will always have a canonical URL for a resource 19:08:11 <SteveS> Ashok: in order to support it the server would need to know what this is 19:08:31 <SteveBattle> cygri, you're correct re: NetWorth example - thanks. 19:08:34 <SteveS> Arnaud: Ashok, so you are ok with deployment guid? 19:08:38 <SteveS> Ashok: yes 19:08:44 <sandro> http://tools.ietf.org/html/rfc6596 rel=canonical 19:08:55 <SteveS> davidwood: ok with it being non-normatively defined 19:09:05 <SteveS> sandro: this is new, not even a year old 19:09:20 <SteveS> davidwood: who supports this? 19:09:26 <SteveS> sandro: servers support it, I think 19:10:06 <SteveS> sandro: though Google says they prefer it, they prefer 303 redirect 19:10:54 <SteveS> davidwood: asking if there is a mechanism, 3xx or link conancial 19:11:03 <SteveS> Ashok: said support removing it 19:11:38 <SteveS> JohnArwe: Yves pointed out a security issue with different URLs 19:11:49 <SteveS> …who recommended not to go there 19:12:31 <davidwood> PROPOSAL: Close ISSUE-49 saying that LDP will not further restrict HTTP in this area. 19:13:01 <SteveS> Proposal: CLOSE-49 removing 4.1.4 and consider giving some guidance in the deployment guide 19:13:07 <TallTed> +1 19:13:11 <Ashok> +1 19:13:16 <SteveBattle> +1 19:13:19 <sandro> +1 19:13:19 <nmihindu> +1 19:13:21 <mesteban> +1 19:13:24 <cygri> +1 19:13:27 <rgarcia> +1 19:13:27 <SteveS> +1 19:13:28 <davidwood> +1 19:13:29 <Arnaud> s/CLOSE-49/Close Issue-49/ 19:13:30 <krp> +1 19:13:33 <roger> +1 19:14:33 <SteveS> davidwood: prefer to have a more descriptive proposal 19:14:49 <davidwood> PROPOSAL: Close ISSUE-49 saying that LDP will not further restrict HTTP in this area. Remove section 4.1.4 from the spec and consider giving some guidance in the deployment guide. 19:15:13 <SteveBattle> +1 19:15:21 <davidwood> +1 19:15:24 <SteveS> RESOLVED: Close ISSUE-49 saying that LDP will not further restrict HTTP in this area. Remove section 4.1.4 from the spec and consider giving some guidance in the deployment guide. 19:15:32 <mesteban> +1 19:17:05 <SteveS> subTopic: ISSUE-35: POSTing to a container MUST yield a fresh URI 19:17:11 <SteveS> ISSUE-35? 19:17:11 <trackbot> ISSUE-35 -- POSTing to a container MUST yield a fresh URI -- open 19:17:11 <trackbot> http://www.w3.org/2012/ldp/track/issues/35 19:18:02 <SteveS> Arnaud: give some background and origins around delete and previous language about server reusing URLS 19:18:42 <TallTed> q+ 19:18:57 <SteveS> cygri: related to previous delete issue but be better to say POSTing to create a resource, it creates a new URL 19:19:17 <SteveS> …later if server creates another resource, it should never reuse a URL 19:19:19 <Arnaud> ack tallted 19:19:53 <SteveS> TallTed: not sure a client would expect this behavior, due to a number of factors such as restarts, restores, etc 19:20:25 <SteveS> ericP: it is like w3c doesn't have to honor its URLs 19:20:50 <SteveS> cygri: if domain changes owner, the new domain will violate if it reuses URLs 19:21:19 <SteveS> TallTed: hard to what the old server, app was hosting and never use 19:22:42 <SteveBattle> What about weakining this to SHOULD rather than MUST? 19:22:42 <bblfish> q+ 19:22:57 <Arnaud> ack bblfish 19:22:59 <SteveS> cygri: not saying related to delete, just focused on new URLs for POST 19:23:16 <SteveS> bblfish: should this be a should? must seems to strong 19:24:02 <Arnaud> q+ 19:24:06 <SteveS> ericP: if relaxed to should, client can't depend on the behavior 19:25:14 <Arnaud> ack Arnaud 19:25:16 <SteveS> cygri: there are an extreme to have some unexpected failures 19:25:37 <rgarcia> q+ 19:25:49 <SteveS> Arnaud: wonders if this is a quality of service thing, like coolURIs don't change 19:26:21 <TallTed> q+ 19:26:30 <Arnaud> ack rgarcia 19:26:34 <SteveS> cygri: if you want to implement a reliable service, a should sounds weak 19:26:59 <SteveS> rgarcia: it is impossible to test a server violates it 19:27:16 <SteveS> sandro: it is hard but if you get a dupe you know it failed 19:27:18 <Arnaud> ack tallted 19:27:45 <SteveS> davidwood: hard for a server to keep track of it 19:27:52 <SteveS> sandro: there are a number of ways to keep track of it 19:28:16 <SteveS> TallTed: we are forbidding reuse of URLs on POST but not of PUT 19:28:36 <davidwood> This is already a best practice ("Cool URIs don't change", PURLs, "Cool URIs for the Semantic Web"…) 19:28:40 <SteveS> cygri: POST we say a URLs is minted, PUT is replacing the state 19:28:51 <davidwood> LDP shouldn't separately define this, I think. 19:29:22 <SteveS> TallTed: there is no difference if the content is replaced behind it, using PUT 19:29:28 <JohnArwe> q? 19:30:18 <SteveS> davidwood: thinks this is an HTTP issue and not a LDP thing 19:30:20 <Arnaud> strawpoll: add 1) MUST not reuse 2) SHOULD not reuse 3) nothing 19:30:41 <bblfish> +1,+1,0 19:30:41 <TallTed> -1, +1, 0 19:31:01 <rgarcia> -1, +1, 0 19:31:09 <SteveBattle> 0, +1, 0 19:31:11 <SteveS> sandro: it is valid HTTP POST cases that using URIs 19:31:16 <nmihindu> -0, +1, 0 19:31:23 <sandro> +1 -0.99 -0.99 19:31:30 <cygri> +1 -1 -1 19:31:30 <mesteban> 0, +1, 0 19:31:30 <roger> 0, +1, +1 19:31:36 <davidwood> -1 0 +1 19:31:40 <SteveS> +1, +1, 0 19:31:58 <Ashok> 0,1,1 19:32:00 <SteveS> JohnArwe: there is some discussion of this in the delete section 19:32:20 <ericP> +1, -1, 01 19:32:34 <JohnArwe> +1,0,-0.5 19:32:35 <ericP> +1, -1, -1 19:32:53 <krp> +1,+1,0 19:33:51 <SteveS> cygri: as a server implementer I have a good reason to not do this, if should it allow servers to reuse and they'd comply 19:33:54 <davidwood> RFC 2119: 19:33:54 <davidwood> SHOULD This word, or the adjective "RECOMMENDED", mean that there 19:33:54 <davidwood> may exist valid reasons in particular circumstances to ignore a 19:33:54 <davidwood> particular item, but the full implications must be understood and 19:33:54 <davidwood> carefully weighed before choosing a different course. 19:34:06 <davidwood> https://www.ietf.org/rfc/rfc2119 19:34:36 <davidwood> MAY This word, or the adjective "OPTIONAL", mean that an item is 19:34:36 <davidwood> truly optional. 19:34:57 <SteveS> TallTed: fact that content has same abs urls, that server needs to keep track it and generate things unique 19:35:05 <SteveBattle> I'm convinved by Ted's argument. When you completely reset a server it should have no memory of it's previous state. 19:35:19 <SteveS> cygri: it is possible to keep track of every resource you create 19:35:47 <bblfish> everybody is speaking together 19:35:50 <SteveS> sandro: gets complicated if support Slug or client indicated URLs 19:35:59 <SteveBattle> Yes - this should happen during the lifetime of a server instance. But not beyond that lifetime. 19:36:15 <davidwood> bblfish, we need a Babel Fish :) 19:36:16 <SteveS> Arnaud: there is a burden, it is reasonable for servers to do this 19:36:23 <bblfish> :-) 19:36:56 <SteveS> ericP: LDP wouldn't be very useful if URIs were reused, it does come down to URIs 19:37:23 <sandro> q+ 19:37:24 <SteveS> on the RDF validator, if you want a picture you get with a URI, which only lasts for about 10 minutes 19:37:56 <roger> roger has left #ldp 19:38:03 <Arnaud> ack sandro 19:38:38 <bblfish> good idea +1 for sandro 19:38:39 <SteveS> sandro: in the spirit of consensus we could follow the SHOULD statement 19:39:01 <SteveS> explaining the cases which it is allowed to violate 19:39:16 <sandro> sandro: ... with a very strongly worded explanation of WHY 19:39:27 <cygri> q+ 19:39:43 <Arnaud> ack cygri 19:39:48 <SteveS> Arnaud: wants to hear from those who think it is so expensive to do 19:41:01 <nmihindu> +q 19:41:13 <TallTed> 6. Guidance in the use of these Imperatives 19:41:13 <TallTed> Imperatives of the type defined in this memo must be used with care 19:41:13 <TallTed> and sparingly. In particular, they MUST only be used where it is 19:41:13 <TallTed> actually required for interoperation or to limit behavior which has 19:41:14 <TallTed> potential for causing harm (e.g., limiting retransmisssions) For 19:41:14 <TallTed> example, they must not be used to try to impose a particular method 19:41:16 <TallTed> on implementors where the method is not required for 19:41:18 <TallTed> interoperability. 19:41:22 <SteveS> cygri: understanding that certain acts of nature or things hard to predict will affect many of the conformance statements, and size of data, running out of storage, etc 19:42:41 <Arnaud> ack nmihindu 19:42:45 <SteveS> …other factors like domain moves 19:43:26 <davidwood> TallTed: This is not an appropriate use for MUST in accordance with RFC 2119 because it is not required for interoperabilty. 19:43:33 <SteveS> nmihindu: a use case, i work for upm, I no longer work for them so they delete my URI and then I rejoin and they may recreate a URI for me 19:44:35 <SteveS> cygri: it is possible to use something like PUT to backfill a resource at a previous URI 19:45:15 <davidwood> The LDP WG ironically redefines Ouroboros 19:45:38 <sandro> sandro: we're just talking about the case where you WANT a dispenser of fresh URLs. 19:45:44 <bblfish> what does HTTP say about POST? 19:45:59 <sandro> nothing, bblfish 19:46:10 <bblfish> q+ 19:46:26 <Arnaud> ack bblfish 19:46:29 <sandro> this has nothing to do with HTTP or POST. It's about whether a network service can be defined to hand out fresh URLs. 19:46:35 <TallTed> refresh strawpoll: add 1) MUST not reuse 2) SHOULD not reuse 3) nothing 19:46:38 <SteveS> davidwood: proposing that we let people think about it and come back to it 19:46:58 <TallTed> -1, +1, 0 19:47:02 <SteveBattle> 0, +1, 0 19:47:05 <cygri> +1 -1 -1 19:47:06 <SteveS> bblfish: wanted to see if anyone changes 19:47:10 <sandro> +1 -.99 -.99 19:47:12 <bblfish> +1,+1,-1 19:47:14 <ericP> +1, -1, -1 19:47:16 <SteveS> +1, +1, 0 19:47:20 <nmihindu> 0, +1, 0 19:47:21 <sandro> +1 -.5 -.5 19:47:23 <mesteban> 0, +1, -1 19:47:26 <krp> 0,+1,-0.5 19:47:32 <JohnArwe> no chg 19:47:37 <Ashok> 0,1,1 19:47:45 <rgarcia> -1, +1, -1 19:47:49 <cygri> ISSUE-44? 19:47:49 <trackbot> ISSUE-44 -- 4.1.9. is obscure or too restrictive -- open 19:47:49 <trackbot> http://www.w3.org/2012/ldp/track/issues/44 19:47:50 <SteveS> subTopic: ISSUE-44: 4.1.9. is obscure or too restrictive 19:50:22 <SteveS> JohnArwe: explains motivation that it is trying to avoid the more complex case 19:51:18 <SteveS> cygri: thinks that we don't need to say this within the spec or deployment guide 19:51:19 <davidwood> PROPOSAL: Close ISSUE-44 by removing section 4.1.9 from the spec. 19:51:27 <rgarcia> +1 19:51:30 <SteveBattle> +1 19:51:33 <davidwood> +1 19:51:35 <bblfish> +1 19:51:40 <TallTed> +1 19:51:43 <krp> +1 19:51:43 <nmihindu> +1 19:51:49 <Ashok> +1 19:51:50 <SteveS> +1 19:51:53 <mesteban> +1 19:52:01 <JohnArwe> +1 19:52:09 <SteveS> RESOLVED: Close ISSUE-44 by removing section 4.1.9 from the spec. 19:52:33 <SteveS> Arnaud: thanks davidwood you did find an easy one 19:52:45 <bblfish> Issue-13? 19:52:45 <trackbot> ISSUE-13 -- Include clarifications about BPC representations that include member triples -- open 19:52:45 <trackbot> http://www.w3.org/2012/ldp/track/issues/13 19:52:57 <SteveS> subTopic: ISSUE-13: Include clarifications about BPC representations that include member triples 19:53:30 <bblfish> I have had too much wine 19:54:11 <bblfish> s/$/ Can't follow... (hic)/ 19:55:28 <SteveS> PROPOSAL: CLOSE ISSUE-13 as editorial - answering- BPCs can have members that are not BPRs? 19:55:49 <davidwood> PROPOSAL: Close ISSUE-13 by saying that the spec editor will align sections 4.1.2 and 5.2.6. Also, BPCs can have members that are BPRs. 19:56:28 <davidwood> s/are BPRs/are non-BPRs/ 19:57:08 <rgarcia> +1 19:57:08 <SteveS> +1 19:57:10 <davidwood> +1 19:57:14 <nmihindu> +1 19:57:14 <krp> +1 19:58:20 <cygri> q+ 19:58:51 <Arnaud> ack cygri 19:59:09 <SteveS> JohnArwe: spec is silent on this so left open 19:59:34 <SteveS> cygri: if a client updates/puts triples in the container representation, we should be clear on this. 19:59:56 <SteveS> …perhaps goes in client deployment guide, highlighting how a client might deal with this 20:00:35 <roger> roger has joined #ldp 20:01:28 <SteveS> Arnaud: take the first resolution on the first part of it, then 2nd part as updating of resources 20:01:35 <TallTed> PROPOSAL: Address first part of ISSUE-13 by saying that the spec editor will align sections 4.1.2 and 5.2.6. Also, BPCs can have members that are non-BPRs. 20:03:07 <SteveS> cygri: should probably say that a client should not make this can of request (update resource data through a container) and what it can't 20:03:16 <SteveS> seems to be good at saying what a server can do 20:03:21 <JohnArwe> must step out for mtg now 20:03:24 <davidwood> q+ to suggest a path to resolution: Close ISSUE-13's core concern and allow Raul to open a new issue if his other questions aren't answered. 20:03:44 <TallTed> +1 davidwood 20:04:22 <SteveS> Resolved: Address first part of ISSUE-13 by saying that the spec editor will align sections 4.1.2 and 5.2.6. Also, BPCs can have members that are non-BPRs. 20:04:32 <davidwood> q- 20:05:59 <SteveBattle> q+ 20:06:07 <davidwood> PROPOSAL: Close the remainder of ISSUE-13 by saying that the membership of BPCs may not be directly modified by clients; membership is modified solely via actions on resources. 20:06:58 <TallTed> davidwood - "mimic 5.5.1 from PUT under 5.4 POST and/or 5.8 PATCH" 20:07:00 <TallTed> ? 20:07:11 <bblfish> q+ 20:07:38 <Arnaud> ack steveb 20:07:48 <SteveS> SteveBattle: wonders if it can update data about a container from a resource or about the member resource within a container 20:08:25 <davidwood> TallTed, yes, I think so 20:08:27 <SteveS> cygri: explains the container representation in example 2 20:08:46 <Arnaud> ack bblfish 20:09:14 <rgarcia> PROPOSAL: Close the remainder of ISSUE-13 by saying that members of a container cannot be updated through PUT/PATCH to a container 20:09:23 <SteveS> bblfish: might be nice to leave patch open a container, where you can patch remove a bunch of members of a container 20:09:53 <SteveBattle> -1 20:10:40 <JohnArwe> henry: the question here is whether or not a put/patch on the container is allowed to modify contents of members. since a container MAY return those member triples on a GET against the container. 20:11:44 <bblfish> perhaps the solution is to move this remainder to another issue 20:11:51 <bblfish> a more precise one 20:12:03 <JohnArwe> +1 to henry 20:12:13 <cygri> PROPOSAL: Close the remainder of ISSUE-13 by saying that servers may refuse to update inlined members through PUT/PATCH to a container 20:12:26 <davidwood> +1 20:13:02 <SteveS> SteveBattle: think that it is hard to know the boundaries of resources isn't clear, whether to update the container and member resource 20:13:48 <SteveS> cygri: the spec says that a container is only putting member information for convenience on a GET response 20:14:18 <SteveS> +1 20:14:20 <sandro> +1 20:14:23 <rgarcia> +1 20:14:24 <bblfish> ah with the may it's sounds ok 20:14:30 <JohnArwe> +1 20:14:32 <bblfish> +1 20:14:34 <krp> +1 20:14:34 <nmihindu> +1 20:14:35 <TallTed> +1 20:14:47 <sandro> eric: +1 20:15:09 <mesteban> -1 20:15:58 <SteveS> Arnaud: could be cases where the member resources only exist in container rep, such as <#a1> 20:16:10 <SteveS> cygri: that is why it is a may, to allow for this 20:17:31 <SteveS> Arnaud: declaring no consensus and scribe is expiring <steves>topic: Wrap-up 20:18:04 <SteveS> Arnaud: on Monday we have informal call 20:18:25 <SteveS> will hope to have minutes out (but you want be able to see it if he doesn't) 20:18:40 <SteveS> Arnaud: meeting adjourned 20:18:42 <bblfish> ok, thanks all folks. 20:18:49 <bblfish> enjoy your evening. 20:18:53 <mesteban> bye. 20:18:58 <Zakim> -bblfish 20:19:04 <JohnArwe> night henry 20:19:08 <TallTed> for a bit of RDF fun, http://chatlogs.planetrdf.com/swig/2013-03-15 20:34:29 <bblfish> bblfish has joined #ldp 20:37:25 <sandro> RRSAgent, pointer? 20:37:25 <RRSAgent> See http://www.w3.org/2013/03/15-ldp-irc#T20-37-25