Chatlog 2013-03-15

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