IRC log of ldp on 2013-06-18
Timestamps are in UTC.
- 07:44:11 [RRSAgent]
- RRSAgent has joined #ldp
- 07:44:11 [RRSAgent]
- logging to http://www.w3.org/2013/06/18-ldp-irc
- 07:44:13 [trackbot]
- RRSAgent, make logs public
- 07:44:13 [Zakim]
- Zakim has joined #ldp
- 07:44:15 [trackbot]
- Zakim, this will be LDP
- 07:44:15 [Zakim]
- ok, trackbot; I see SW_LDP(F2F)2:30AM scheduled to start 74 minutes ago
- 07:44:16 [trackbot]
- Meeting: Linked Data Platform (LDP) Working Group Teleconference
- 07:44:16 [trackbot]
- Date: 18 June 2013
- 07:44:25 [JohnArwe]
- zakim, who's on the phone?
- 07:44:25 [Zakim]
- SW_LDP(F2F)2:30AM has not yet started, JohnArwe
- 07:44:27 [Zakim]
- On IRC I see RRSAgent, JohnArwe, SteveS, rgarcia, Arnaud, mielvds, Ashok, nmihindu, betehess, jmvanel, gavinc, Yves, sandro, trackbot, ericP, thschee
- 07:44:27 [nmihindu]
- zakim, who is on the phone?
- 07:44:27 [Zakim]
- SW_LDP(F2F)2:30AM has not yet started, nmihindu
- 07:44:29 [Zakim]
- On IRC I see RRSAgent, JohnArwe, SteveS, rgarcia, Arnaud, mielvds, Ashok, nmihindu, betehess, jmvanel, gavinc, Yves, sandro, trackbot, ericP, thschee
- 07:45:28 [mesteban]
- mesteban has joined #ldp
- 07:46:03 [Ashok]
- Introductions
- 07:51:25 [mielvds1]
- mielvds1 has joined #ldp
- 07:51:59 [roger]
- roger has joined #ldp
- 07:52:02 [BartvanLeeuwen]
- BartvanLeeuwen has joined #ldp
- 07:53:17 [Ashok]
- Ashok has joined #ldp
- 07:53:34 [Zakim]
- SW_LDP(F2F)2:30AM has now started
- 07:53:40 [Zakim]
- +??P0
- 07:54:05 [BartvanLeeuwen]
- Zakim, ??p0 is me
- 07:54:05 [Zakim]
- +BartvanLeeuwen; got it
- 07:54:11 [Arnaud]
- hi Bart
- 07:54:14 [Arnaud]
- we're dialing in
- 07:54:44 [Zakim]
- + +34.91.336.aaaa
- 07:54:57 [BartvanLeeuwen]
- okay, gives me time for coffee
- 07:59:23 [Ashok]
- Topic: UCR
- 07:59:56 [Ashok]
- Arnaud: There have been comments on UCR
- 08:00:34 [Ashok]
- ... we don't have Steve Battle here
- 08:00:59 [Ashok]
- ... Great review by Miguel
- 08:01:39 [roger]
- roger has joined #ldp
- 08:01:58 [Ashok]
- ... sometimes UCR and spec are not in sync
- 08:03:36 [Ashok]
- Miguel: We should annotate UCR document saying what we cover and what we delay to next version
- 08:03:51 [nmihindu]
- BartvanLeeuwen, we have rgarcia, mesteban, Arnaud, mielvds, Ashok, nmihindu, JohnArwe, SteveS, gavinc, roger, kevin
- 08:04:15 [Ashok]
- ... for the use cases we cover we should have pointers in the spec
- 08:05:00 [Ashok]
- s/in/to/
- 08:05:42 [Ashok]
- Arnuad: You sent mail on UCR but you did not get a response
- 08:06:22 [Ashok]
- ACTION-42 on MIguel to review UCR can be closed
- 08:09:19 [Ashok]
- Arnaud: Miguel, would you like to be editor for the UCR
- 08:09:38 [Ashok]
- s/UCR/UCR?/
- 08:11:25 [Ashok]
- Discussion about which direction the pointers should go
- 08:12:01 [Ashok]
- UCR->spec
- 08:12:11 [Ashok]
- or spec -> UCR
- 08:13:02 [SteveS]
- SteveS has joined #ldp
- 08:14:07 [AndyS]
- AndyS has joined #ldp
- 08:14:32 [krp]
- krp has joined #ldp
- 08:15:16 [JohnArwe]
- zakim, aaaa is the F2F meeting (can't hurt to try)
- 08:15:16 [Zakim]
- I don't understand you, JohnArwe
- 08:15:21 [JohnArwe]
- zakim, aaaa is m
- 08:15:21 [Zakim]
- +m; got it
- 08:17:29 [Arnaud]
- Arnaud has joined #ldp
- 08:19:35 [Ashok]
- Arnaud: Please all look at Miguel's comments
- 08:20:14 [Ashok]
- ... Miguel, could you follow up with Steve Battle
- 08:21:03 [Ashok]
- Topic: LDP spec
- 08:21:56 [Ashok]
- Arnaud: We should review the issues and see which ones we need to close
- 08:23:52 [Ashok]
- ... we have 2 main isues ... container and membership predicate and there is the one about affordances
- 08:26:02 [Ashok]
- Arnaud bring up list of issues to discuss which ones we address
- 08:27:12 [mielvds]
- mielvds has joined #ldp
- 08:27:33 [Ashok]
- Arnaud: ISSUE-16 has no proposal. Mark as "at risk"?
- 08:29:03 [Ashok]
- John: There is nothing to be done ... spec does not need to change
- 08:29:50 [Ashok]
- Arnaud: ISSUE-32 needs to be addressed
- 08:30:31 [Ashok]
- Arnaud: ISSUE-37 ... Steve was going to add an itroduction to spec
- 08:30:41 [Ashok]
- John: Non-normative text
- 08:30:56 [Ashok]
- Arnaud: ISSUE-50
- 08:31:46 [Ashok]
- Steve: I think we address this .... needs sign-off from Henry
- 08:32:12 [Ashok]
- Arnaud: Duplicate of 54?
- 08:34:08 [Ashok]
- Arnaud: ISSUE-51
- 08:34:34 [Ashok]
- Discussion as to whether this is inverse of the membership predicate
- 08:35:34 [Ashok]
- Roger: We can close issue in order to make progress
- 08:36:26 [Ashok]
- Arnaud: Let's leave open for now ... let's see how discussion on membership predicate work
- 08:38:12 [Ashok]
- Arnaud: ISSUE-56 let's leave open ... related to ISSUE-16?
- 08:39:50 [Ashok]
- Arnaud: ISSUE-57 ... related to ISSUE-32
- 08:41:54 [Ashok]
- Arnaud: ISSUE-58 ... let's look at latest proposal
- 08:42:13 [Ashok]
- John: I suggest leave as "at risk"
- 08:43:07 [Ashok]
- Arnaud: ISSUE-62 ... we need proposal for this
- 08:43:25 [Ashok]
- Roger: There is an issue here. I will create a proposal
- 08:43:58 [Ashok]
- ... related to membershipXXX
- 08:45:11 [Ashok]
- Arnaud: ISSUE-66 Robust pagination
- 08:45:18 [Ashok]
- ... suggest we close
- 08:48:47 [Ashok]
- Discussion on what the issue creator really wants. If all he wants to find if the pagination has changed we could do it with e-tags/if-match
- 08:51:18 [Ashok]
- Arnaud: ISSUE-68 ... do not have a proposal ... can be closed
- 08:51:45 [Ashok]
- Arnaud: ISSUE-71 needs discussion
- 08:52:50 [Ashok]
- Arnaud: ISSUE-72 needs discussion
- 08:53:21 [Ashok]
- Arnaud: ISSUE-73 needs discussion
- 08:53:38 [Ashok]
- Arnaud: ISSUE-75 needs discussion
- 08:53:55 [Ashok]
- Arnaud: ISSUE-77 needs discussion
- 08:54:15 [Ashok]
- Arnaud: ISSUE-78 may be editorial
- 08:55:28 [Ashok]
- Arnaud: ISSUE-79 needs discussion
- 08:55:46 [Ashok]
- Arnaud: ISSUE-80 needs discussion
- 08:56:34 [Ashok]
- Arnaud: There are 6 issues marked as Pending Review
- 08:57:26 [Ashok]
- Cody: How do you create the first container
- 08:57:49 [Zakim]
- +[GVoice]
- 08:58:00 [ericP]
- Zakim, [GVoice] is me
- 08:58:00 [Zakim]
- +ericP; got it
- 09:02:34 [Zakim]
- -BartvanLeeuwen
- 09:08:06 [Zakim]
- +Sandro
- 09:15:13 [sandro]
- anyone willing to try a google+ hangout, so remote folks can see you?
- 09:17:10 [ericP]
- if so, i'm ericW3C@gmail.com
- 09:18:17 [sandro]
- Ah.
- 09:19:06 [rgarcia]
- rgarcia has joined #ldp
- 09:20:29 [JohnArwe]
- JohnArwe going to scribe temporarily while Ashok makes his points on issue-66 robust pagination
- 09:21:24 [Arnaud]
- topic: ISSUE-66
- 09:21:34 [nmihindu]
- issue-66
- 09:21:34 [trackbot]
- ISSUE-66 -- Robust pagination -- open
- 09:21:34 [trackbot]
- http://www.w3.org/2012/ldp/track/issues/66
- 09:22:06 [ericP]
- i think that SQL cursors are good for a single session, and essentially amount to the server copying the entire result set for a query
- 09:22:13 [JohnArwe]
- Ashok: SQL has something called "cursor stability" equivalent
- 09:22:29 [JohnArwe]
- ...to robust pagination
- 09:22:41 [JohnArwe]
- Henry arrives in F2F room
- 09:22:53 [ericP]
- the analogy in LDP would have the server holding state for a client which have registered a cursor and promises to release it
- 09:23:40 [sandro]
- basically "nextPageSameState" as a link would do that. or maybe "nextPage" could optionally have those semantics.
- 09:23:50 [JohnArwe]
- ... we've said we're not going to do "all this database stuff" like transactions, robust paging, etc. If we're going to do a r/w web we have to do these kinds of things.
- 09:24:48 [JohnArwe]
- @sandro, question would be "same state as what?" the page URL could be from a query made a year ago.
- 09:25:16 [JohnArwe]
- ashok: should at least give client a way to know that page content has changed.
- 09:25:35 [Ashok]
- Topic: ISSUE-65
- 09:25:45 [Ashok]
- The spec does not address this
- 09:25:46 [ericP]
- how i had imagined robust pagination:
- 09:25:46 [ericP]
- <page3> { <C> rdfs:member <R6>, <R7> . <page3> :nextPage <page4> }
- 09:25:46 [ericP]
- after DELETEs of <R6> and <R7>:
- 09:25:46 [ericP]
- <page3> { <page3> :nextPage <page4> } # page<3> is preserved though empty
- 09:25:52 [sandro]
- JohnArwe, same state as the resource was when this content was serialized.
- 09:26:00 [Ashok]
- s/65/66/
- 09:26:48 [Ashok]
- Yes, Eric that's one way .... but it will have pages with holes in them
- 09:26:55 [sandro]
- q?
- 09:26:59 [ericP]
- definitely
- 09:27:35 [sandro]
- q+
- 09:27:47 [ericP]
- i'm perfectly happy to punt on it
- 09:27:49 [krp]
- q+
- 09:27:50 [Arnaud]
- ack sandro
- 09:27:50 [JohnArwe]
- @sandro, fine if you then add (in the general case) ... for this user. With your version Sandro, does "when it was serialized" have a well-known definition? vs being "since (the last time)..."
- 09:28:20 [Ashok]
- Arnaud: Should we investigate how we could provide robust pagination?
- 09:28:32 [ericP]
- +1 to understanding how an extension could do it making it safe to punt
- 09:29:30 [Ashok]
- Sandro described a design for robust pagination
- 09:29:32 [ericP]
- i suspect that ldp:nextPatch and ldp:longPollPatch are in that category
- 09:29:46 [Arnaud]
- ack krp
- 09:30:12 [Ashok]
- Kevin: Argues we need robust pagination
- 09:30:36 [ericP]
- krp: if you care about consistency in a page, is it specifically NOT a container at that point?
- 09:30:43 [sandro]
- q+
- 09:30:48 [Arnaud]
- ack sandro
- 09:30:56 [JohnArwe]
- the trivial way to support it via an extension is to have the server add information (header or predicate) saying the equivalent of "all paging is stable" i.e. the server always implements stable paging
- 09:31:09 [SteveS]
- SteveS has joined #ldp
- 09:31:22 [SteveS]
- q+
- 09:31:32 [Ashok]
- Sandro, any server can provide robust pagination using version number in the URL
- 09:32:06 [Ashok]
- ... you coukd provide two versioin stable and not stable
- 09:32:36 [JohnArwe]
- s/coukd/could/
- 09:32:41 [Arnaud]
- ack steves
- 09:32:43 [JohnArwe]
- s/versioin/version/
- 09:32:52 [Ashok]
- .... discusses StableNextPage predicate
- 09:32:55 [sandro]
- sandro: so have a stableNextPage predicate, defined by us or somebody else
- 09:34:33 [ericP]
- Yves? can weakt ETag validation be applied here?
- 09:35:10 [Ashok]
- Ashok: Without robust pagination you get into trouble when the resource you are working on gets deleted
- 09:35:35 [Ashok]
- Henry: Discusses a timestamp version of the universe
- 09:36:39 [Ashok]
- Arnaud: There should be a mechanism to tell the client that a page has changed
- 09:37:09 [sandro]
- maybe ldp:resourceState ?
- 09:37:43 [sandro]
- http stuff doesn't help, since it's about the page, not about the thing behind all the pages.
- 09:37:53 [ericP]
- q+ to propose that say that we have several choices to make a stability and that we should say nothing to avoid painting people into a corner.
- 09:38:04 [sandro]
- maybe ldp:overallState
- 09:38:20 [Arnaud]
- ack eric
- 09:38:20 [Zakim]
- ericP, you wanted to propose that say that we have several choices to make a stability and that we should say nothing to avoid painting people into a corner.
- 09:38:24 [Ashok]
- Discussion about whether etags can be used
- 09:38:53 [Zakim]
- +??P0
- 09:39:03 [BartvanLeeuwen]
- Zakim, ??P0 is me
- 09:39:03 [Zakim]
- +BartvanLeeuwen; got it
- 09:39:04 [Ashok]
- Eric: Anything we add to spec would paint us into a corner
- 09:39:23 [SteveS]
- perhaps a pageOfEtag header, to accompany ldp:pageOf
- 09:39:52 [SteveS]
- q+
- 09:40:00 [sandro]
- +1 SteveS pageOfEtag. That's nice.
- 09:40:18 [krp]
- ericP: is that in terms of not stating a solution to stability; or no mechanism for indicating changes to either/or pages or the resource being paged?
- 09:40:26 [sandro]
- q?
- 09:40:26 [Ashok]
- Arnaud: If soemone wants to make a proposal please send soon to the list
- 09:40:28 [Arnaud]
- ack steves
- 09:40:35 [JohnArwe]
- We should at least set client expectations, e.g. "Clients should assume that container membership and page contents can change across successive HTTP requests, unless the server advertises/offers other behavior."
- 09:41:06 [ericP]
- krp, both
- 09:41:11 [sandro]
- +1 JohnArwe
- 09:41:14 [Ashok]
- Steve: Let's wait till next version
- 09:41:17 [mesteban]
- +1 JohnArwe
- 09:41:28 [mielvds]
- a HEAD request for checking the ETag of the container is too much overhead?
- 09:41:28 [krp]
- +1 JohnArwe
- 09:41:36 [ericP]
- +1 JohnArwe
- 09:42:22 [Ashok]
- Meil: Do a HEAD request to container to check if it has changed
- 09:42:39 [sandro]
- You could do a HEAD for LastModified, not ETag, AFTER getting the page. That would work.
- 09:42:41 [JohnArwe]
- s/Meil/Miel/
- 09:42:46 [Ashok]
- Steve: It get's you someone
- 09:43:12 [SteveS]
- s/someone/somewhere/
- 09:43:18 [Ashok]
- s/someone/somewhere/
- 09:44:03 [Ashok]
- Arnaud: I think spec says pagination is not robust
- 09:45:37 [Ashok]
- Arnaud: Editors to check what the spec says
- 09:47:47 [Ashok]
- Arnaud: Let's wait and see if we get a proposal
- 09:47:50 [sandro]
- my googling so far seems to support the 1-second resolution for last-modified. making it useless for HEAD this way.
- 09:49:25 [Ashok]
- Topic: ISSUE-57 How can client tell he is communicating with a LDP server
- 09:50:01 [bblfish]
- bblfish has joined #ldp
- 09:50:07 [Ashok]
- Arnaud: Can you rely on RDF to tell you what the interaction model is
- 09:50:15 [bblfish]
- hi
- 09:50:38 [Ashok]
- ... others say conatiner tells you interaction model
- 09:50:59 [Ashok]
- ... some suggest changing the media type, that seems like a high cost
- 09:51:35 [Ashok]
- ... Coulkd we have a special header?
- 09:51:40 [sandro]
- Arnaud: if you use new media type or a profile, you need new versions of every rdf syntax. so maybe use another header.
- 09:51:58 [Ashok]
- s/Coulkd/Could/
- 09:52:00 [Yves]
- if the issue is for the client to figure out if its' talking to a LDP capable server, then at worst doing an interaction not supported by the server will fail
- 09:52:21 [Yves]
- why knowing a priori that it's an LDP server is better than knowing it a posteriori
- 09:52:23 [Ashok]
- Arnaud: You could use a special header
- 09:52:50 [sandro]
- q+ to say this is a way to do affordances in general
- 09:53:17 [Arnaud]
- ack sandro
- 09:53:17 [Zakim]
- sandro, you wanted to say this is a way to do affordances in general
- 09:53:53 [Ashok]
- Sandro: I like this approach ... profile can be each LDP feature
- 09:54:21 [Ashok]
- ... one link header per page
- 09:55:13 [bblfish]
- Sandro is suggesting another option where it is not a relation to one link header, but to a file much more complex that this, with finer details per ldp.
- 09:55:18 [Ashok]
- Arnaud: ISSUE-33 brings up issue of servers with different capabilities
- 09:55:26 [bblfish]
- Issue-33?
- 09:55:26 [trackbot]
- ISSUE-33 -- Pagination for non-container resources -- closed
- 09:55:26 [trackbot]
- http://www.w3.org/2012/ldp/track/issues/33
- 09:56:23 [sandro]
- +1 Arnaud "If you're this kind of server, then you MUST do ...." instead of all our MAY and SHOULDs
- 09:56:39 [sandro]
- header on each ldp RESPONSE
- 09:56:49 [bblfish]
- Did arnaud meant Issue-33?
- 09:56:49 [bblfish]
- what is the page that shows these options?
- 09:56:51 [mielvds1]
- mielvds1 has joined #ldp
- 09:56:57 [mesteban_]
- mesteban_ has joined #ldp
- 09:56:59 [sandro]
- issue-33?
- 09:56:59 [trackbot]
- ISSUE-33 -- Pagination for non-container resources -- closed
- 09:56:59 [trackbot]
- http://www.w3.org/2012/ldp/track/issues/33
- 09:57:02 [Arnaud1]
- Arnaud1 has joined #ldp
- 09:57:05 [nmihindu_]
- nmihindu_ has joined #ldp
- 09:57:08 [sandro]
- issue-32?
- 09:57:08 [trackbot]
- ISSUE-32 -- How can clients discover that a resource is an LDPR or LDPC, and what features are supported? -- open
- 09:57:08 [trackbot]
- http://www.w3.org/2012/ldp/track/issues/32
- 09:57:34 [sandro]
- (this was about issue-32)
- 09:57:42 [Arnaud1]
- q?
- 10:01:19 [SteveS]
- And the wiki page http://www.w3.org/2012/ldp/wiki/ISSUE-32
- 10:03:31 [SteveS]
- q+
- 10:05:14 [Arnaud]
- ack steves
- 10:05:39 [Arnaud]
- strawpoll: use profile link headers to advertise ldp capabilities
- 10:05:49 [JohnArwe]
- discussion about when to use link headers vs new RDF types
- 10:06:28 [SteveS]
- http://tools.ietf.org/html/rfc6906
- 10:07:13 [Yves]
- +1 link header to identify an ldp-capable server
- 10:08:30 [krp]
- krp has joined #ldp
- 10:08:53 [bblfish]
- bblfish has joined #ldp
- 10:09:42 [bblfish]
- hi
- 10:10:10 [roger]
- roger has joined #ldp
- 10:10:13 [roger]
- hello !!
- 10:10:25 [SteveS]
- We are talking also about http://tools.ietf.org/html/rfc6903, section 6
- 10:11:11 [Ashok]
- Ashok has joined #ldp
- 10:13:47 [bblfish]
- what is the straw poll?
- 10:14:23 [Arnaud]
- strawpoll: use link headers to advertise ldp capabilities
- 10:14:29 [sandro]
- +1
- 10:14:31 [bblfish]
- +1
- 10:14:33 [ericP]
- +1
- 10:14:34 [rgarcia]
- +1
- 10:14:34 [krp]
- +1
- 10:14:35 [nmihindu_]
- +1
- 10:14:36 [JohnArwe]
- +1
- 10:14:38 [SteveS]
- +1
- 10:14:40 [roger]
- +1
- 10:14:42 [mielvds1]
- +1
- 10:14:49 [mesteban_]
- 0
- 10:15:33 [bblfish]
- RFC6906?
- 10:16:10 [Ashok]
- Arnaud: You don't want to use 'profile' beacause it is not a recognized term ... you don't want to use RFC 6906?
- 10:16:51 [JohnArwe]
- lots of discussion to clarify that, in the sense that these link headers might be thought of as 'types', that the set of rdf:type triples in the content (RDF resource types) might (and in fact needs to, in cases like a CMS) might differ from the 'types' exposed via link headers since the latter describes the server's interaction capabilities for the resouce not its content.
- 10:17:08 [Ashok]
- Sandro: I have not read RFC 6906
- 10:18:06 [JohnArwe]
- @sandro: what I've heard second hand from ErikW reads differently to me from the words I see in http://tools.ietf.org/html/rfc6906#section-3.1
- 10:18:29 [Ashok]
- Sandro: what's the value of a profile
- 10:19:29 [Ashok]
- John: Profile is defining a particular P
- 10:19:36 [Ashok]
- ... o is the URL
- 10:19:37 [ericP]
- :context :linkRelationType :target .
- 10:20:10 [Ashok]
- Sandro: You dereference o and you get the type info
- 10:20:37 [Arnaud]
- this is what I would expect the header to look like: Link: <http://www.w3.org/ns/ldp/profile>; rel=profile
- 10:21:47 [JohnArwe]
- @ericp: right that is the general form of 5988 headers; 6906 defines a particular link relation type (profile, as a short string not a uri/iri)
- 10:21:53 [sandro]
- issue-57?
- 10:21:53 [trackbot]
- ISSUE-57 -- How can a client determine that it is in communication with an LDP server? -- open
- 10:21:53 [trackbot]
- http://www.w3.org/2012/ldp/track/issues/57
- 10:22:28 [sandro]
- Oh, I guess one can have multiple profiles at once.
- 10:22:35 [bblfish]
- 1+
- 10:22:37 [bblfish]
- q+
- 10:22:39 [JohnArwe]
- As Sandro notes, if we use profile, and LDP has 20 optional features, then you need one target IRI for each *combination* which is a lot, and scales badly
- 10:22:45 [nmihindu_]
- q+
- 10:22:54 [Arnaud]
- ack bblfish
- 10:23:03 [Ashok]
- Ashok: We don't need to define profiles in the spec
- 10:23:37 [Ashok]
- q+
- 10:24:20 [krp]
- I heard "read-only" as a shorthand for a named set/profile of features
- 10:24:49 [Arnaud]
- ack nmihindy
- 10:24:59 [Arnaud]
- ack nmihindu
- 10:25:57 [bblfish]
- q+
- 10:28:39 [Arnaud]
- ack ashok
- 10:29:17 [bblfish]
- Issue-32?
- 10:29:17 [trackbot]
- ISSUE-32 -- How can clients discover that a resource is an LDPR or LDPC, and what features are supported? -- open
- 10:29:17 [trackbot]
- http://www.w3.org/2012/ldp/track/issues/32
- 10:29:25 [JohnArwe]
- discussion about how granular the introspection capabilities needs to be from issue-32
- 10:29:32 [SteveS]
- Wiki page: http://www.w3.org/2012/ldp/wiki/ISSUE-32
- 10:29:33 [bblfish]
- what is the URL for the issue-32
- 10:29:42 [bblfish]
- which shows the different types of things?
- 10:29:51 [Arnaud]
- ack bblfish
- 10:30:44 [SteveS]
- q+
- 10:31:13 [Arnaud]
- ack steves
- 10:32:17 [Ashok]
- Ashok has joined #ldp
- 10:32:33 [JohnArwe]
- @henry: email w/ 3 profile strawman is at http://lists.w3.org/Archives/Public/public-ldp-wg/2013Apr/0139.html
- 10:32:39 [JohnArwe]
- ...in pdf attachment
- 10:33:01 [Ashok]
- Arnaud: Can we agree that to solve ISSUe-57 is to create a link header
- 10:33:36 [Ashok]
- s/ISSUe-57/ISSUE-57/
- 10:34:20 [sandro]
- +1 bblfish using rdf:type relation IN LINK HEADER for ldp:Resource
- 10:35:32 [Arnaud]
- PROPOSAL: close issue-57, adding that LDP servers MUST advertise LDP with a link header: Link: <http://www.w3.org/ns/ldp/profile>; rel=profile
- 10:36:16 [sandro]
- q+ to ask why profile instead of type? (sorry)
- 10:36:37 [JohnArwe]
- @sandro, are you saying that the link relation type = 'rdf:type' or 'type' ? 'type' is in the IANA registry, has the semantics I related before, so has the problem with any existing CMS that I related before.
- 10:36:43 [Arnaud]
- ack sandro
- 10:36:43 [Zakim]
- sandro, you wanted to ask why profile instead of type? (sorry)
- 10:36:57 [Ashok]
- Ashok: And, Sandro type = rdf:type
- 10:37:04 [roger]
- roger has joined #ldp
- 10:38:06 [SteveS]
- q+
- 10:38:07 [mielvds1]
- So I guess bblfish is saying servers that offer rdf:type LDPResource should offer LDP functionality, else it's their problem?
- 10:38:18 [JohnArwe]
- @sandro: an existing CMS; it exposes every rdf:type it finds in RDF-based resources as Link: "type", "rdf:type URI" headers.
- 10:38:30 [Arnaud]
- ack steves
- 10:38:46 [Ashok]
- Arnaud: Sandro, please type in proposal
- 10:39:07 [Ashok]
- Steve: We could add profile types to the spec
- 10:39:28 [roger]
- +q
- 10:39:32 [Arnaud]
- ack roger
- 10:39:51 [sandro]
- PROPOSED: close ISSUE-57, adding that LDP servers MUST advertise LDP with a link header: Link: <http://www.w3.org/ns/ldp/Resource>; rel=type (and noting that we consider rel=type to be shorthand for the rdf:type property). And we/others can subclass ldp:Resource as needed later.
- 10:40:14 [Ashok]
- Roger: We need client to be generic ... that should be in the content
- 10:40:18 [JohnArwe]
- ...if you plunk a LDPR representation into that, and it has rdf:type=ldp:Resource in the representation, then the CMS would expose that. The CMS has not violated any spec, but it does not treat the resource as anything more than RDF (it's RDF, not LDP). If we re-use Link: 'type',<ldp:Resource> , that CMS is a liar.
- 10:41:02 [ericP]
- +1
- 10:41:04 [sandro]
- +1
- 10:41:13 [Ashok]
- Sandro: You don't want to have to look at header if you don't want to? You can take your chances.
- 10:41:25 [BartvanLeeuwen]
- +1
- 10:41:47 [roger]
- +1
- 10:42:48 [rgarcia]
- +-0 (not sure about what happens with containers)
- 10:42:48 [Ashok]
- +1
- 10:42:56 [mesteban_]
- +0.5
- 10:43:04 [SteveS]
- +.5 (not sure 'type' matches as closely as 'profile')
- 10:43:16 [nmihindu_]
- +0.5
- 10:43:18 [bblfish]
- bblfish has joined #ldp
- 10:43:19 [krp]
- +.5
- 10:43:39 [sandro]
- (I prefer 'type' to 'profile' because we get clear semantics for the the link target)
- 10:43:42 [JohnArwe]
- -0.15 ... will learn to live with it, but recognize it's not as iron-clad as a link relation type that LDP newly defines
- 10:43:46 [bblfish]
- +1 for the ldp:Resource version ( missing the def cause I got kicked out )
- 10:44:37 [Ashok]
- John: This does not give you an ironclad guarantee
- 10:44:40 [codyburleson]
- codyburleson has joined #ldp
- 10:46:12 [Ashok]
- Arnaud: How would server put a type in automatically?
- 10:46:40 [sandro]
- JohnArwe: I'm concerned that some systems will issue this link header automatically when they don't know anything about LDP, because they learned this information from somewhere (eg the content).
- 10:47:10 [mielvds1]
- +1 (not perfect; can live with it)
- 10:47:15 [roger]
- btw, what is the equivalent of a Link: header which could be used to encode a literal statement in a header element ?
- 10:47:31 [sandro]
- I don't think that can be done, roger.
- 10:48:11 [codyburleson_]
- codyburleson_ has joined #ldp
- 10:48:28 [roger]
- sandro, should it be done ?
- 10:48:51 [Arnaud]
- RESOLVED: close ISSUE-57, adding that LDP servers MUST advertise LDP with a link header: Link: <http://www.w3.org/ns/ldp/Resource>; rel=type (and noting that we consider rel=type to be shorthand for the rdf:type property). And we/others can subclass ldp:Resource as needed later.
- 10:49:05 [Ashok]
- Arnaud: Does anyone want to change their vote?
- 10:49:14 [Ashok]
- No response
- 10:49:28 [Ashok]
- Arnaud: ISSUE is resolved
- 10:51:37 [Ashok]
- Arnaud: Raul is asking 'what happens to containers' ... do we need a different type
- 10:51:53 [Ashok]
- Sandro: Containers are a type of LDPR
- 10:52:47 [bblfish]
- where is the definition for the 'type' link relations btw?
- 10:52:55 [ericP]
- Link: <http://www.w3.org/ns/ldp/LDPR>; rel="rdf:type"; <http://www.w3.org/ns/ldp/LDPC>; rel="rdf:type"
- 10:53:17 [krp]
- http://tools.ietf.org/html/rfc6903#section-6
- 10:53:26 [sandro]
- eric, we just decided it was ldp:Resource not ldp:LDPR
- 10:53:41 [Arnaud]
- eric, that would be: Link: <http://www.w3.org/ns/ldp/Resource>; rel="rdf:type"; <http://www.w3.org/ns/ldp/Container>; rel="rdf:type"
- 10:53:50 [ericP]
- roger that
- 10:54:00 [Arnaud]
- q?
- 10:54:02 [sandro]
- so it's: and it's rel="type" not rel="rdf:type"
- 10:54:24 [sandro]
- That is: Link: <http://www.w3.org/ns/ldp/Resource>; rel="type"; <http://www.w3.org/ns/ldp/Container>; rel="type"
- 10:55:11 [Arnaud]
- oh right
- 10:56:20 [Ashok]
- Arnaud: This solves whether you are in an LDP context or not
- 10:56:28 [roger]
- in my opinion, LDPRs are GETable only, and it's only the LDPC which are special (i.e. potentially support POST, PUT, PATCH), and may require these link headers.
- 10:56:59 [Ashok]
- Arnaud: Do we need separate headers for resources and containers?
- 10:57:08 [JohnArwe]
- note that we have an issue open to 'move' create from containers to ldp:Resource's
- 10:57:29 [Ashok]
- Sandro: We need to look at other affordances
- 10:57:40 [bblfish]
- This is really related to the issue on Inssue-78
- 10:58:03 [sandro]
- sandro: how we handle Containers will need to depend on how we do other affordances.
- 10:58:03 [Ashok]
- Arnaud: Let's leave it as LDPR for now
- 10:58:21 [Ashok]
- BREAK FOR LUNCH
- 10:58:43 [Ashok]
- One hour break
- 10:59:04 [Zakim]
- -BartvanLeeuwen
- 10:59:09 [Zakim]
- -Sandro
- 10:59:18 [Zakim]
- -ericP
- 11:39:18 [bhyland]
- bhyland has joined #ldp
- 12:04:35 [BartvanLeeuwen]
- I knew they 1h wouldn't work in spain :)
- 12:04:36 [Zakim]
- +[GVoice]
- 12:04:52 [ericP]
- heh
- 12:05:30 [ericP]
- Zakim, [GVoice] is me
- 12:05:30 [Zakim]
- +ericP; got it
- 12:09:38 [Zakim]
- +??P13
- 12:09:43 [BartvanLeeuwen]
- Zakim, ??P13 is me
- 12:09:43 [Zakim]
- +BartvanLeeuwen; got it
- 12:12:28 [Zakim]
- +Sandro
- 12:14:54 [Arnaud]
- Arnaud has joined #ldp
- 12:15:19 [mielvds]
- mielvds has joined #ldp
- 12:16:27 [Ashok]
- Ashok has joined #ldp
- 12:16:44 [Ashok]
- Resuming after lunch
- 12:17:49 [codyburleson]
- codyburleson has joined #ldp
- 12:17:53 [bblfish]
- bblfish has joined #ldp
- 12:20:04 [davidwood]
- davidwood has joined #ldp
- 12:20:51 [mesteban]
- mesteban has joined #ldp
- 12:20:53 [rgarcia]
- rgarcia has joined #ldp
- 12:20:59 [mesteban]
- scribe
- 12:21:15 [nmihindu]
- nmihindu has joined #ldp
- 12:21:59 [JohnArwe]
- is there anyone In There ?
- 12:22:14 [nmihindu]
- http://www.w3.org/2012/ldp/wiki/Primer
- 12:22:28 [sandro]
- what's that, John? I hear the meeting room, and see you on IRC.
- 12:22:35 [SteveS]
- SteveS has joined #ldp
- 12:22:56 [mesteban]
- scribe: me
- 12:23:07 [mesteban]
- scribe: mesteban
- 12:23:08 [JohnArwe]
- JohnArwe has joined #ldp
- 12:23:15 [mesteban]
- Topic: primer
- 12:23:16 [nmihindu]
- wiki - http://www.w3.org/2012/ldp/wiki/Primer
- 12:23:38 [mesteban]
- nmihindu: reporting on the status of the primer
- 12:23:57 [mesteban]
- ... current status available in the posted link.
- 12:24:34 [mesteban]
- ... is the structure proposed on the wiki what the project wants?
- 12:25:08 [mesteban]
- ... there are issues to be solved, that if address would allows us to deliver the Primer by the end of the month.
- 12:25:31 [mesteban]
- Arnaud: delivering is not a must (as it is not in the charter)
- 12:25:54 [mesteban]
- ... would rather prefer to focus effort on the LDP doc.
- 12:26:16 [krp]
- krp has joined #ldp
- 12:26:44 [mesteban]
- ... the proposal for the primer should be reviewed
- 12:27:01 [mesteban]
- ... Ashok volunteers.
- 12:27:59 [Arnaud]
- action: ashok to review the primer and send feedback
- 12:27:59 [trackbot]
- Created ACTION-70 - Review the primer and send feedback [on Ashok Malhotra - due 2013-06-25].
- 12:28:04 [Arnaud]
- action: henry to review the primer and send feedback
- 12:28:04 [trackbot]
- Created ACTION-71 - Review the primer and send feedback [on Henry Story - due 2013-06-25].
- 12:28:06 [mesteban]
- bblfish: would like to review
- 12:28:30 [mesteban]
- Arnaud: timing is not important
- 12:29:04 [mesteban]
- SteveS: it would be nice to have it when delivering the LDP spec.
- 12:29:25 [bblfish]
- yes. it's important to make sure the best practices are best practices.
- 12:29:42 [mesteban]
- Arnaud: we could this as a goal.
- 12:29:53 [mesteban]
- s/could this/could have this/
- 12:30:17 [mesteban]
- Arnaud: what is the purpose of the primer? Which is the target audience?
- 12:31:16 [mesteban]
- Arnaud: there is tension between documenting what to implement and how it is to be used.
- 12:31:35 [ericP]
- the text that's crafted to be precise and impossible to misinterpret is seldom the easiest read
- 12:31:54 [mesteban]
- ... the educational aspect should be focussed on LDP and not RDF.
- 12:33:01 [mesteban]
- nmihindu: the point is that maybe the examples provided are to complex for non-RDF/LD people.
- 12:33:17 [mesteban]
- ... and maybe some education to that respect is necessary
- 12:34:08 [mesteban]
- Roger: we should avoid communicating bad practices.
- 12:34:42 [mesteban]
- bblfish: we have a year to see developers which bad practices "learn" and clarify the primer accordingly
- 12:36:31 [mesteban]
- bblfish: we have to focuss on providing examples that do things properly
- 12:36:47 [Arnaud]
- q?
- 12:37:07 [mesteban]
- s/focuss/focus/
- 12:37:21 [SteveS]
- q+
- 12:37:49 [Arnaud]
- ack steves
- 12:38:03 [mesteban]
- Ashok: developers usually ask about things related on how to use the LDP spec, and that's what it should be covered on the Primer.
- 12:38:23 [bblfish]
- q+
- 12:40:26 [Arnaud]
- ack bblfish
- 12:41:45 [mesteban]
- bblfish: maybe in the end we end up providing something like "LD-atom".
- 12:42:28 [mesteban]
- Arnaud: we have an agreement that the purpose is not educate the people on general best practices,
- 12:42:48 [mesteban]
- ... just provide correct/good/valid examples.
- 12:43:05 [cody]
- cody has joined #ldp
- 12:43:49 [mesteban]
- nmihindu: we have used a patch format based on changesets for the examples
- 12:44:15 [mesteban]
- ... is it OK to keep them in the examples regardless nothing is said in the spec regarding PATCH?
- 12:44:21 [Ashok]
- q+
- 12:45:12 [mesteban]
- arnoud: there is a problem if we don't say anything in the spec to that respect
- 12:45:14 [Arnaud]
- ack ashok
- 12:46:51 [mesteban]
- ashok: what happened with work that was done regarding PATCH?
- 12:47:03 [sandro]
- +1 Arnaud's telling of the story
- 12:47:54 [sandro]
- arnaud: Sandro worked on a proposal for Patch, but didn't come up with anything he was happy with enough to propose to the group
- 12:47:59 [mesteban]
- arnaoud: if the LDP doesn't doesn't say anything about PATCH, the Primer shouldn't say a word either.
- 12:48:19 [sandro]
- cf http://www.w3.org/People/Sandro/datapatch if you're curious.
- 12:48:25 [mesteban]
- s/arnaoud/arnaud/
- 12:49:17 [mesteban]
- nmihindu: are we switching to Respec?
- 12:49:22 [mesteban]
- ... when?
- 12:49:42 [mesteban]
- Arnaud: you should switch as soon as possible.
- 12:50:02 [mesteban]
- Topic: LDP spec again
- 12:50:28 [bblfish]
- Issue-32?
- 12:50:28 [trackbot]
- ISSUE-32 -- How can clients discover that a resource is an LDPR or LDPC, and what features are supported? -- open
- 12:50:28 [trackbot]
- http://www.w3.org/2012/ldp/track/issues/32
- 12:50:41 [mesteban]
- Topic: ISSUE-32
- 12:52:23 [mesteban]
- JohnArwe: it would be better to focus on other issues more relevant to the LDP spec than starting discussion about affordances
- 12:53:54 [mesteban]
- Arnaud: should we wait to dig into affordances until other issues regarding compliance have been solved?
- 12:54:08 [mesteban]
- JohnArwe: definitely.
- 12:54:49 [SteveS]
- SteveS has joined #ldp
- 12:55:39 [bblfish]
- http://lists.w3.org/Archives/Public/public-ldp-wg/2013Apr/att-0139/W3CIssue32.pdf
- 12:55:59 [JohnArwe]
- http://lists.w3.org/Archives/Public/public-ldp-wg/2013Apr/0139.html
- 13:01:34 [mesteban]
- Arnaud: we have to focus on the broad categories more than on the specific tasks
- 13:02:57 [mesteban]
- ... do those tasks reflect the features that we want to expose?
- 13:03:17 [mesteban]
- ... then, how are we to advertise them? Profiles?
- 13:03:17 [sandro]
- q+
- 13:03:57 [Arnaud]
- ack sandro
- 13:04:31 [mesteban]
- Sandro: PATCH is a would use case for affordances.
- 13:04:43 [mesteban]
- s/a would/a good/
- 13:05:05 [mesteban]
- ... because of the PATCH format semantics
- 13:05:05 [SteveS]
- q+
- 13:05:28 [nmihindu]
- sandro, will that help http://tools.ietf.org/html/rfc5789#section-3.1 ?
- 13:05:47 [Arnaud]
- ack steves
- 13:08:54 [sandro]
- sandro: I think it makes sense to use HTTP PATCH with RDF, you just need some affordance signalling, and rel=type works fine for that as far as I can tell.
- 13:09:24 [nmihindu]
- mesteban: does the pdf in the email reflect the features of LDP correctly ?
- 13:09:24 [sandro]
- sandro: like <> a ldp:PatchableViaPatchLanguage3 --- lets clients know they can use HTTP PATCH with that language.
- 13:11:29 [mesteban]
- Arnaud: do we have then the "read-only" scenario?
- 13:12:13 [mesteban]
- rgarcia: is the enumeration of tasks in the "prifle" exhaustive?
- 13:12:48 [mesteban]
- Arnaud: if any other feature is found we would have to change the definition of the profile
- 13:14:30 [mesteban]
- JohnArwe, SteveS: beware the document does not reflect the latest status of the LDP spec.
- 13:15:12 [betehess]
- betehess has joined #ldp
- 13:16:21 [mesteban]
- Arnoud: it will be difficult capture all the business logic reqs. from applications
- 13:17:05 [SteveS]
- s/Arnoud/Arnaud/
- 13:17:10 [mielvds1]
- mielvds1 has joined #ldp
- 13:17:52 [mesteban]
- JohnArwe: we should at least point out the variability points, but not necessesarily making a proposal on the implementation details
- 13:18:17 [ericP]
- don't forget the ever-important CONNECT method
- 13:20:06 [mesteban]
- Arnaud: so it seems there are two big categories: read only and read+write.
- 13:21:01 [mesteban]
- ... does it makes sense a write only profile?
- 13:21:09 [Arnaud]
- q?
- 13:22:53 [mesteban]
- Arnaud: can the LDP spec stay without affordances?
- 13:23:51 [SteveS_]
- SteveS_ has joined #ldp
- 13:24:05 [mesteban]
- JohnArwe: I'm fine if for each variability point the LDP spec provides an instrospection mechanism for guessing the details from the implementation
- 13:24:40 [SteveS_]
- q+
- 13:24:57 [Arnaud]
- ack steves
- 13:25:12 [mesteban]
- bblfish: if we manage to identify the gaps (variability points) we could the later see if we can categorize them somehow.
- 13:25:26 [mesteban]
- s/could the later/could later/
- 13:27:12 [mesteban]
- SteveS_: we could just provide profiles for letting users know if only LDP Resources are supported or LDPR+LDPC and then provide introspection mechanisms for the other issues.
- 13:27:36 [mesteban]
- s/for the other issues/for the other variability points/
- 13:28:21 [roger]
- roger has joined #ldp
- 13:29:02 [JohnArwe]
- JohnArwe has joined #ldp
- 13:29:37 [mesteban]
- Arnaud: the only mechanism right now for discovering the capabilities is trial and error, and eventhough the errors might not real reflect the capabilities of the server
- 13:31:02 [mesteban]
- bblfish: we could assume that once we now the type of resource (LDPC or LDPR) it is take for granted that certain operations (HTTP verbs) should be supported
- 13:32:10 [roger]
- +q
- 13:32:13 [nmihindu]
- q+
- 13:32:25 [Ashok]
- Re: OPTIONS, the spec says This method allows the client to determine the options and/or requirements associated with a resource, or the capabilities of a server, without implying a resource action or initiating a resource retrieval.
- 13:32:30 [Arnaud]
- ack nmihindu
- 13:32:59 [rgarcia]
- http://lists.w3.org/Archives/Public/public-ldp-wg/2013May/0098.html
- 13:33:06 [Ashok]
- q+
- 13:33:22 [mesteban]
- nmihindu: the current draft of the spec reflects the usage of HEAD
- 13:33:25 [bblfish]
- http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.7
- 13:33:28 [JohnArwe]
- q+
- 13:33:40 [mesteban]
- ... but it might be better to support OPTIONS
- 13:33:58 [Arnaud]
- ack roger
- 13:34:22 [SteveS]
- q+
- 13:34:30 [Arnaud]
- ack ashok
- 13:34:45 [bblfish]
- q+ why does Allow not give us all we need: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.7
- 13:34:48 [mesteban]
- SteveS: but this would require defining the structure for the body of the response
- 13:34:58 [bblfish]
- q+ to why does Allow not give us all we need: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.7
- 13:35:08 [nmihindu]
- OPTIONS -> http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.2
- 13:35:17 [mesteban]
- Roger: we could just say we support OPTIONS without specifying the format of the response's body
- 13:35:46 [nmihindu]
- "A 200 response SHOULD include any header fields that indicate optional features implemented by the server and applicable to that resource (e.g., Allow), possibly including extensions not defined by this specification. The response body, if any, SHOULD also include information about the communication options."
- 13:36:14 [mesteban]
- JohnArwe: the options may apply to the server of the specific URI.
- 13:36:18 [bblfish]
- q?
- 13:36:21 [Arnaud]
- ack roger
- 13:36:33 [Arnaud]
- ack john
- 13:37:39 [mesteban]
- JohnArwe: as we already enforce GET and HEAD, and can simulate OPTIONS with them it might be better to stick to them to lower possible entry barriers.
- 13:38:35 [Arnaud]
- ack steves
- 13:38:39 [bblfish]
- q-
- 13:39:35 [TallTed]
- TallTed has joined #ldp
- 13:40:10 [krp]
- krp has joined #ldp
- 13:40:49 [JohnArwe]
- q+
- 13:41:08 [Arnaud]
- ack john
- 13:41:09 [JohnArwe]
- http://tools.ietf.org/html/rfc5789#section-3
- 13:41:14 [SteveS]
- SteveS: OPTIONS has the feature over HEAD in that you do not need to compute various GET-response headers, like: lastModified, etag, content-size, content-type
- 13:41:25 [bblfish]
- Options in HTTP spec http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.2
- 13:41:40 [nmihindu]
- q+ to say may be we can mention it in the deployment guide as always :)
- 13:42:19 [Arnaud]
- ack nmihindu
- 13:42:19 [Zakim]
- nmihindu, you wanted to say may be we can mention it in the deployment guide as always :)
- 13:43:00 [mesteban]
- nmihindu: SteveS notice makes sense in the deployment guide, and could be included in there
- 13:43:34 [mesteban]
- ... do we don't lose the point
- 13:44:15 [Arnaud]
- break for 15mn
- 13:52:31 [TallTed]
- TallTed has joined #ldp
- 13:57:42 [JohnArwe]
- yes cody
- 13:59:12 [SteveS]
- SteveS has joined #ldp
- 13:59:49 [cody]
- cody has joined #ldp
- 14:00:05 [rgarcia]
- rgarcia has joined #ldp
- 14:00:53 [Arnaud]
- scribe: krp
- 14:01:31 [krp]
- SteveS: If OPTIONS is a more efficient way to do it, perhaps that is what we should have in the spec
- 14:01:53 [krp]
- ... rather than HEAD, which requires everything as per GET but without the body
- 14:02:48 [JohnArwe]
- q+
- 14:02:52 [krp]
- roger: asks for an example of how we would do this with OPTIONS rather than HEAD
- 14:02:54 [Arnaud]
- ack john
- 14:03:35 [bblfish]
- q?
- 14:03:40 [krp]
- JohnArwe: if the allow has patch you also need to provide the allow-patch
- 14:04:04 [SteveS]
- s/allow-patch/Accept-Patch/
- 14:04:32 [krp]
- Arnaud: could we have an example of this and what the change to the spec would be by tomorrow?
- 14:04:35 [JohnArwe]
- tools.ietf.org/html/rfc5789#section-3.2
- 14:04:37 [cody]
- q+
- 14:04:48 [Arnaud]
- ack cody
- 14:05:15 [krp]
- cody: why does section 4.6.2 exist in the spec?
- 14:05:52 [krp]
- JohnArwe: it's a MUST because otherwise it would be optional by http default
- 14:06:36 [krp]
- Arnaud: Likes the rfc5789 example. it doesn't seem to include any required options document
- 14:06:42 [JohnArwe]
- OPTIONS = http://tools.ietf.org/html/rfc2616#section-9.2
- 14:07:01 [krp]
- ... if we were to do it like this example, it seems it does much of what we want
- 14:10:23 [krp]
- Arnaud: whether to change HEAD in 4.6 to OPTIONS, or add a new OPTIONS section after 4.6
- 14:10:55 [JohnArwe]
- Proposal: ADD: LDP Servers MUST indicate their support for HTTP Methods by responding to a HTTP OPTIONS request on the LDPR's URL. LDP Servers MUST include an 'Allow' header with the supported HTTP Methods. LDP Servers MUST include an 'Allow-Patch' header per RFC 5789, if the server supports PATCH.
- 14:11:10 [bblfish]
- +1
- 14:11:13 [SteveS]
- +1
- 14:11:15 [rgarcia]
- +1
- 14:11:25 [cody]
- +1
- 14:11:41 [nmihindu]
- +1
- 14:11:48 [krp]
- +1
- 14:11:49 [mesteban]
- +1
- 14:12:06 [BartvanLeeuwen]
- +1
- 14:12:11 [ericP]
- +1
- 14:12:16 [mielvds1]
- +1
- 14:12:37 [JohnArwe]
- +1
- 14:12:43 [JohnArwe]
- +1 (for Roger)
- 14:12:47 [Arnaud]
- RESOLVED: ADD: LDP Servers MUST indicate their support for HTTP Methods by responding to a HTTP OPTIONS request on the LDPR's URL. LDP Servers MUST include an 'Allow' header with the supported HTTP Methods. LDP Servers MUST include an 'Allow-Patch' header per RFC 5789, if the server supports PATCH.
- 14:13:31 [JohnArwe]
- trackbot, topic?
- 14:13:31 [trackbot]
- Sorry, JohnArwe, I don't understand 'trackbot, topic?'. Please refer to <http://www.w3.org/2005/06/tracker/irc> for help.
- 14:13:38 [krp]
- Arnaud: this has only added a section. what should we do with 4.6 (HEAD)?
- 14:14:32 [krp]
- SteveS: doesn't hurt anything to leave it a MUST. maybe say "If you support HEAD..."
- 14:14:49 [JohnArwe]
- part of issue-32
- 14:15:06 [nmihindu]
- issue-32
- 14:15:06 [trackbot]
- ISSUE-32 -- How can clients discover that a resource is an LDPR or LDPC, and what features are supported? -- open
- 14:15:06 [trackbot]
- http://www.w3.org/2012/ldp/track/issues/32
- 14:15:08 [krp]
- Arnaud: let's leave as is. SteveS to come back if there's a problem.
- 14:17:35 [krp]
- ... Any objections to closing issue-19 as is? This issue is too broad at the moment.
- 14:17:45 [JohnArwe]
- q+
- 14:18:21 [Arnaud]
- topic: issue-19
- 14:18:34 [krp]
- Ashok: if there are specific error cases we need to have them pointed out
- 14:19:25 [krp]
- JohnArwe: in the original email one resolution is that the errors are already covered by existing specs -- this seems to be the case
- 14:19:43 [krp]
- ... so can we close with that resolution?
- 14:21:43 [JohnArwe]
- q-
- 14:21:58 [Arnaud]
- PROPOSAL: Close Issue-19 as is, the spec already covers some error cases, if other specific cases need to be addressed they should be pointed out individually
- 14:22:10 [JohnArwe]
- +1
- 14:22:14 [krp]
- +1
- 14:22:23 [rgarcia]
- +1
- 14:22:27 [roger]
- +1
- 14:22:30 [sandro]
- issue-9?
- 14:22:30 [trackbot]
- ISSUE-9 -- Should properties used in BPR representations be BPRs? -- closed
- 14:22:30 [trackbot]
- http://www.w3.org/2012/ldp/track/issues/9
- 14:22:38 [SteveS]
- +1
- 14:22:41 [nmihindu]
- +1
- 14:22:45 [mesteban]
- +0.5
- 14:22:46 [Ashok]
- +1
- 14:22:47 [sandro]
- issue-19?
- 14:22:47 [trackbot]
- ISSUE-19 -- Adressing more error cases -- pending review
- 14:22:47 [trackbot]
- http://www.w3.org/2012/ldp/track/issues/19
- 14:22:48 [mielvds1]
- +1
- 14:22:50 [sandro]
- +1
- 14:23:33 [bblfish]
- +1
- 14:23:40 [BartvanLeeuwen]
- +1
- 14:23:57 [cody]
- +1
- 14:24:00 [Arnaud]
- RESOLVED: Close Issue-19 as is, the spec already covers some error cases, if other specific cases need to be addressed they should be pointed out individually
- 14:24:29 [krp]
- topic: ISSUE-63
- 14:24:43 [krp]
- issue-63
- 14:24:43 [trackbot]
- ISSUE-63 -- Need to be able to specify collation with container ordering -- pending review
- 14:24:43 [trackbot]
- http://www.w3.org/2012/ldp/track/issues/63
- 14:25:01 [ericP]
- yesss
- 14:25:17 [bblfish]
- q+
- 14:26:06 [Arnaud]
- PROPOSAL: Close Issue-63, per Ashok's proposal (adding ldp:containerSortCollation)
- 14:26:16 [krp]
- Arnaud: propose we close as per Ashok's resolution, does ericP agree?
- 14:26:38 [Arnaud]
- ack bblfish
- 14:26:59 [krp]
- bblfish: this looks like it's using default reasoning again?
- 14:27:40 [krp]
- arnaud: the issue is that it's an optional property
- 14:28:48 [krp]
- JohnArwe: so this should be a mandatory property
- 14:29:12 [krp]
- Ashok: but this adds a cost when it's not always needed
- 14:29:24 [bblfish]
- mu issue is a montonocity issue
- 14:29:33 [bblfish]
- just we need to be a bit careful
- 14:29:38 [krp]
- ericP: agrees. is it still worth having that control? how would we test it? how many people would implement it?
- 14:29:58 [krp]
- Ashok: this is going to be used by lots of people for lots of different applications, why handcuff it?
- 14:30:17 [krp]
- Arnaud: if there is a default value you would have to specify it
- 14:30:53 [mesteban]
- q+
- 14:31:10 [Arnaud]
- ack mesteban
- 14:31:21 [krp]
- mesteban: is this some information property about how the server works?
- 14:31:44 [ericP]
- q?
- 14:31:52 [krp]
- JohnArwe: when the server responds it says how the server ordered the information
- 14:32:20 [krp]
- ... doesn't enable the client to change the ordering
- 14:32:36 [krp]
- Arnaud: it gives the client enough information to reproduce the ordering
- 14:33:25 [krp]
- ericP: if the client gets items where the ordering is useful for presentation, the client needs to know how to reproduce that ordering as it can't get it from the rdf
- 14:34:22 [krp]
- bblfish: if the ordering doesn't matter, or it's not important to the client, it doesn't include the ordering. if it does it uses one of these. so there's no default.
- 14:34:44 [krp]
- Arnaud: so it's either unspecified, or specified with this property?
- 14:36:25 [krp]
- ... what do these collations look like?
- 14:36:53 [krp]
- JohnArwe: the compare function is defined in xpath.
- 14:39:39 [krp]
- bblfish: we need to make this work at a basic level for agents with low/near-zero reasoning. but we have to consider what happens for a client with reasoning.
- 14:40:19 [krp]
- Arnaud: e.g. you don't see the property as it's not there, you assume it's using a default, but then you find it's using the other compare
- 14:40:55 [JohnArwe]
- Some details on the 2-operand vs 3-operand behavior of fn:compare for strings...
- 14:41:27 [JohnArwe]
- SPARQL Query appears to say that the default collation for the 2-case is codepoint, see http://www.w3.org/TR/rdf-sparql-query/#OperatorMapping ...
- 14:41:55 [krp]
- ericP: you can't do anything with sorting until you've reached a document boundary
- 14:42:00 [JohnArwe]
- XPath allows SPARQL to do that explicitly http://www.w3.org/TR/xpath-functions/#func-compare
- 14:42:21 [krp]
- bblfish: on what property are you sorting? on the uris?
- 14:42:33 [krp]
- Ashok: no, that's another issue. you have specified what you're sorting
- 14:43:06 [JohnArwe]
- This sorting is for strings and untyped literals (which in RDF 1.1 will be treated as strings, and is how most implementations treat them today according to what I heard Sandro say at SemTech)
- 14:43:20 [Arnaud]
- q?
- 14:43:23 [nmihindu]
- bblfish, http://www.w3.org/2012/ldp/track/issues/14
- 14:43:58 [krp]
- JohnArwe: we defer the implementation to fn:compare to sparql query
- 14:44:58 [krp]
- Arnaud: what is important is that if it's not stated you don't know which it is
- 14:47:01 [Arnaud]
- PROPOSAL: Close Issue-63, adding a ldp:containerSortCollation, when set to http://www.w3.org/TR/rdf-sparql-query/#OperatorMapping, use compare(A,B), when set to something else, use compare(A, B, C)
- 14:47:28 [SteveS]
- +1
- 14:47:41 [bblfish]
- +1
- 14:48:50 [JohnArwe]
- 5.3.10 in editor's draft
- 14:49:04 [sandro]
- +0 sounds reasonable, but I can't see the text on the editor's machine
- 14:49:16 [krp]
- https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp.html
- 14:50:20 [JohnArwe]
- http://www.w3.org/2005/xpath-functions/collation/codepoint
- 14:51:03 [Arnaud]
- PROPOSAL: Close Issue-63, adding a ldp:containerSortCollation, when set to http://www.w3.org/2005/xpath-functions/collation/codepoint, use compare(A,B), when set to another collation, use compare(A, B, C)
- 14:51:33 [ericP]
- hey, that's my paragraph
- 14:51:35 [ericP]
- write your own!
- 14:52:04 [ericP]
- yeah
- 14:52:13 [ericP]
- i actually don't remember if i did or not
- 14:53:09 [SteveS]
- +1 (to proposal not ericP's ramblings)
- 14:53:22 [ericP]
- +1 (ditt)
- 14:53:24 [krp]
- +1
- 14:53:27 [mielvds1]
- +1
- 14:53:31 [BartvanLeeuwen]
- +1
- 14:53:43 [Ashok]
- +1
- 14:53:45 [ericP]
- s/ditt/ditto/
- 14:53:46 [cody]
- +0
- 14:53:49 [mesteban]
- +0
- 14:53:57 [sandro]
- +0 (sounds okay, but I don't understand it)
- 14:53:59 [rgarcia]
- +0
- 14:54:03 [nmihindu]
- +0
- 14:54:11 [JohnArwe]
- +1 + need to remove "impln dependent" from editor's draft, since that's not what sparql says
- 14:54:34 [JohnArwe]
- roger +1's
- 14:54:37 [bblfish]
- bblfish has joined #ldp
- 14:54:53 [cody]
- Henry +1
- 14:54:56 [Arnaud]
- Resolved: Close Issue-63, adding a ldp:containerSortCollation, when set to http://www.w3.org/2005/xpath-functions/collation/codepoint, use compare(A,B), when set to another collation, use compare(A, B, C)
- 14:55:36 [krp]
- issue-67
- 14:55:36 [trackbot]
- ISSUE-67 -- Full container membership without pagination -- pending review
- 14:55:36 [trackbot]
- http://www.w3.org/2012/ldp/track/issues/67
- 14:55:52 [bblfish]
- issue-67?
- 14:55:52 [trackbot]
- ISSUE-67 -- Full container membership without pagination -- pending review
- 14:55:52 [trackbot]
- http://www.w3.org/2012/ldp/track/issues/67
- 14:56:36 [krp]
- Arnaud: several people have said that it is impossible to guarantee this, so suggest closing this
- 14:56:49 [JohnArwe]
- q+
- 14:56:57 [krp]
- Ashok: there are valid reasons not to want paging
- 14:57:00 [nmihindu]
- topic: issue-67
- 14:57:16 [Zakim]
- -BartvanLeeuwen
- 14:57:47 [krp]
- mielvds: if the server will not satisfy the request return forbidden?
- 14:58:16 [krp]
- arnaud: surely returning a page (which is indicated) is better
- 14:59:54 [krp]
- bblfish: if you are a server and you would like to give clients that can take it the whole content then you can
- 15:01:11 [krp]
- roger: so the default (without paging) is to send the lot?
- 15:01:16 [krp]
- JohnArwe: yes
- 15:01:52 [bblfish]
- and a redirect ti the first page is a way for the server to say I can't deal with it all so you can only get pages
- 15:02:20 [krp]
- looking at http://lists.w3.org/Archives/Public/public-ldp-wg/2013May/0326.html
- 15:03:33 [bblfish]
- Issue-67?
- 15:03:33 [trackbot]
- ISSUE-67 -- Full container membership without pagination -- pending review
- 15:03:33 [trackbot]
- http://www.w3.org/2012/ldp/track/issues/67
- 15:03:57 [Arnaud]
- PROPOSAL: Close ISSUE-67: Full container membership without pagination, saying no.
- 15:04:13 [rgarcia]
- +1
- 15:04:21 [nmihindu]
- +1
- 15:04:23 [SteveS]
- +1
- 15:04:27 [mesteban]
- +1
- 15:04:28 [ericP]
- +1
- 15:04:31 [Zakim]
- -ericP
- 15:04:32 [Ashok]
- +1
- 15:04:33 [JohnArwe]
- +1 from roger
- 15:04:34 [krp]
- +1
- 15:04:36 [cody]
- +1
- 15:04:42 [mielvds1]
- +1
- 15:04:45 [sandro]
- +0
- 15:04:55 [bblfish]
- +1 the reason was that a GET on the resource will by default return the full resource if there is no paging
- 15:05:01 [Arnaud]
- Resolved: Close ISSUE-67: Full container membership without pagination, saying no.
- 15:05:30 [Zakim]
- +[GVoice]
- 15:08:11 [krp]
- issue-69
- 15:08:11 [trackbot]
- ISSUE-69 -- Query syntaxes for accessing the first and subsequent pages -- pending review
- 15:08:11 [trackbot]
- http://www.w3.org/2012/ldp/track/issues/69
- 15:08:35 [krp]
- ashok: why this is useful: if I'm on a cellphone I only want the first 5
- 15:09:21 [krp]
- ... does the server paginate differently based on client request
- 15:09:38 [krp]
- Arnaud: the server *may* -- it is implementation specific
- 15:09:40 [ericP]
- use cookies!
- 15:10:12 [krp]
- SteveS: it seems like there are use cases where this would be valuable -> wish list?
- 15:12:08 [krp]
- Arnaud: this issue is specifically on the difference in syntax between first and other pages. but all of them are opaque and not specified by the spec.
- 15:13:13 [Arnaud]
- PROPOSAL: close ISSUE-69, as is, the syntax is opaque and dependent on the implementation
- 15:13:43 [krp]
- JohnArwe: there is no way to find the 5th page. the right way to do it might be to expose a URI template, but we are too far ahead there to do so at this point
- 15:13:44 [SteveS]
- +1
- 15:13:48 [krp]
- +1
- 15:13:55 [JohnArwe]
- +1
- 15:13:56 [Ashok]
- +1
- 15:14:01 [roger]
- roger has joined #ldp
- 15:14:03 [roger]
- +1
- 15:14:04 [nmihindu]
- +1
- 15:14:12 [cody]
- +1
- 15:14:13 [rgarcia]
- +1
- 15:14:17 [sandro]
- +1
- 15:14:18 [mesteban]
- +1
- 15:14:26 [mielvds1]
- +1
- 15:14:35 [Arnaud]
- RESOLVED: Close ISSUE-69, as is, the syntax is opaque and dependent on the implementation
- 15:14:46 [bblfish]
- pat
- 15:16:05 [krp]
- issue-71
- 15:16:05 [trackbot]
- ISSUE-71 -- No membershipSubject or membershipPredicate -- open
- 15:16:05 [trackbot]
- http://www.w3.org/2012/ldp/track/issues/71
- 15:18:46 [Arnaud]
- topic: Issue-75
- 15:19:20 [krp]
- issue-75
- 15:19:20 [trackbot]
- ISSUE-75 -- non-monotonic ldp:membershipXXX relations -- open
- 15:19:20 [trackbot]
- http://www.w3.org/2012/ldp/track/issues/75
- 15:20:08 [krp]
- Arnaud: easy fix. you always have to specify membershipPredicate.
- 15:20:22 [krp]
- Ashok: on each container? (yes)
- 15:20:33 [SteveS]
- q+
- 15:20:54 [krp]
- bblfish: I would prefer there is something like ldpmember which we can always rely on (kind of a default)
- 15:21:21 [krp]
- ... think of membershipPredicate as a kind of rule, when you post here you're adding a triple and also doing something else
- 15:21:45 [roger]
- +q
- 15:21:58 [Arnaud]
- ack john
- 15:22:05 [krp]
- Arnaud: keeping the spec as is, there is an issue with non-monotinicity. can we scope to that question for the moment.
- 15:22:28 [krp]
- JohnArwe: I feel we conflate containership with creatorship
- 15:22:33 [krp]
- Arnaud: off-topic!
- 15:22:55 [Arnaud]
- ack steves
- 15:24:00 [JohnArwe]
- I continue to object to Henry's POST-centric characterization of how he thinks membership works, which he used in the course of his remarks *on this issue*
- 15:24:11 [krp]
- SteveS: I think this would come up when someone adds a property, then says this is a subclass of rdfs:member. so this problem can come up without a default when triples are added later?
- 15:24:22 [roger]
- +1 to John
- 15:24:30 [krp]
- ... so I don't understand how having a default or not in the spec solves this.
- 15:24:50 [ericP]
- what on earth would i do with a container if i didn't know the membership predicate?
- 15:24:53 [ericP]
- q+
- 15:25:34 [betehess_laptop]
- betehess_laptop has joined #ldp
- 15:25:59 [krp]
- bblfish: either: assume you don't know, or thinking of it declaratively and inferentially as a rule that transforms
- 15:26:13 [Arnaud]
- ack roger
- 15:26:17 [rgarcia]
- q+
- 15:26:45 [krp]
- roger: make membershipPredicate a MUST, and do not conflate LDPR and LDPC
- 15:27:06 [Arnaud]
- ack eric
- 15:27:27 [JohnArwe]
- not clear on what roger thinks are being conflated ... might agree with him if I did, cannot be sure
- 15:27:58 [krp]
- ericP: must always state membershipPredicate is reasonable. the reason for including that complexity might be better explained by examples (from IBM?)
- 15:28:39 [krp]
- ... any motivations to appeal to non-RDF folks (look how simple in RDF) goes away if we follow Henry's proposal
- 15:28:54 [roger]
- OK, to re-state my opinion in another way. membershipPredicate and membershipSubject MUST be declared. and the membershipSubject cannot refer to self.
- 15:29:32 [bblfish]
- q+
- 15:29:34 [krp]
- ... what do I want to do with a container if I don't know the membershipPredicate?
- 15:29:41 [SteveS]
- ericP I tried to summarize why there was some complexity added, see http://lists.w3.org/Archives/Public/public-ldp-wg/2013May/0250.html
- 15:29:43 [krp]
- ... it should always be expressed
- 15:29:51 [JohnArwe]
- +1 ericP, if we were to require both in many cases of interest to me (re-using existing collections by overlaying LDP onto them) the representation sizes would effectively double; so not only "not as simple", but obviously less scalable
- 15:29:53 [Arnaud]
- ack rgarcia
- 15:30:24 [Arnaud]
- ack bblfish
- 15:30:45 [krp]
- rgarcia: I don't think the resource representation to include the application model (referring to SteveS example of adding later triples)
- 15:31:01 [JohnArwe]
- @ericp: we're not talking about it, we're IRCing
- 15:31:56 [ericP]
- @JohnArwe, and maybe we reach concensus on that issue ready to resolve when we raise it
- 15:32:11 [krp]
- SteveS: we saw this repeating pattern; always posting in the same way, wanted to both support the domain model and keep a common interaction
- 15:34:32 [krp]
- bblfish: if when you post to a container like atom there's a default action. when you post something else, think of it as a rule -- as a consequence it add these other relationships
- 15:34:46 [ericP]
- PROPOSED: if membershipSubject and membershipPredicate remain in LDP, they MUST be expressed in every page of an LDPC
- 15:36:23 [krp]
- ... behind membership subject membershipPredicate there's already a simple rule language
- 15:36:40 [JohnArwe]
- s/in every page/in every container/
- 15:37:23 [Arnaud]
- PROPOSED: Close Issue-75, if membershipSubject, membershipPredicate, and membershipPredicateInverse remain in LDP, they MUST be expressed in every page of an LDPC
- 15:37:52 [Arnaud]
- PROPOSED: if membershipSubject and membershipPredicate remain in LDP, they MUST be expressed in every LDPC
- 15:38:33 [SteveS]
- +1
- 15:39:07 [roger]
- +1
- 15:39:26 [JohnArwe]
- +1
- 15:39:28 [rgarcia]
- +1
- 15:39:33 [mesteban]
- +1
- 15:39:33 [krp]
- +1
- 15:39:42 [nmihindu]
- +1
- 15:39:43 [ericP]
- +1
- 15:39:49 [sandro]
- +1
- 15:40:06 [roger]
- +q
- 15:40:18 [cody]
- +1
- 15:41:21 [mielvds1]
- +1 (but it will change anyway ;))
- 15:42:12 [krp]
- bblfish: what is it the client doesn't know when it doesn't have these (membershipSubject, membershipPredicate, and membershipPredicateInverse)?
- 15:42:22 [bblfish]
- +?
- 15:42:29 [krp]
- Arnaud: it doesn't know how to browse the membership of the container
- 15:42:35 [Arnaud]
- RESOLVED: Close Issue-75, if membershipSubject, membershipPredicate, and membershipPredicateInverse remain in LDP, they MUST be expressed in every LDPC
- 15:42:53 [krp]
- issue-71
- 15:42:53 [trackbot]
- ISSUE-71 -- No membershipSubject or membershipPredicate -- open
- 15:42:53 [trackbot]
- http://www.w3.org/2012/ldp/track/issues/71
- 15:43:12 [Arnaud]
- ack roger
- 15:43:22 [JohnArwe]
- editor's should factor in inverse member predicates when drafting issue-75 text
- 15:43:30 [JohnArwe]
- s/r's/rs/
- 15:44:12 [krp]
- roger: so you have these rules, so that once you've posted to it, gives you the equivalent to membershipPredicate in domain terms?
- 15:44:15 [JohnArwe]
- I have not been. agnostic on doing them now vs later.
- 15:44:52 [krp]
- ... how does it work if I'm interested in person likes/dislikes food. what happens if I post, I'm not asking the server to decide if I like of dislike
- 15:45:31 [krp]
- bblfish: post a resource that's the food, with a relationship going back to a container saying you like
- 15:45:40 [Arnaud]
- q?
- 15:46:31 [krp]
- roger: that's complicated. this needs to be simple for developers.
- 15:47:33 [krp]
- bblfish: when you're posting to a container, what you're not saying is if you don't know what the membershipPredicate there, you don't know what the contains relationship is
- 15:47:53 [krp]
- (see issue-79)
- 15:50:10 [Arnaud]
- http://lists.w3.org/Archives/Public/public-ldp-wg/2013May/0250.html
- 15:51:35 [krp]
- looking at section of email following "Let's take a look at bug 13 again:"
- 15:52:27 [ericP]
- Arnaud, could you paste your example into http://piratepad.net/ge4VKecQWa ?
- 15:54:35 [krp]
- bblfish: at least define contains, as this means we can say what we're missing what we don't know
- 15:54:46 [ericP]
- it's malformed, throw it away
- 15:56:20 [krp]
- ... I can discover via hateoas
- 15:56:40 [krp]
- ... it makes it explicit of what the attachments of the children are (if contains is there)
- 15:57:34 [krp]
- ... you have a default without having a default
- 15:57:46 [krp]
- arnaud: but you double the triples. is it worth it?
- 15:58:17 [krp]
- roger: don't think it's too bad for my normal usage patterns
- 15:58:51 [roger]
- .... because the LDPR is the one which is GETted
- 15:59:03 [krp]
- bblfish: sometimes I have to go and look at another document to find out what's in my container
- 15:59:21 [roger]
- +q
- 16:00:05 [krp]
- ... when you GET a document, it's the final absolute definition of that document, I shouldn't have to go somewhere else to know
- 16:00:22 [Arnaud]
- ack roger
- 16:00:29 [JohnArwe]
- q+
- 16:01:08 [krp]
- roger: appreciated explanation on mailing lists of semanticised atom. but could it be done the other way?
- 16:01:21 [krp]
- bblfish: you're requiring inference much earlier without this
- 16:04:20 [Arnaud]
- ack john
- 16:06:49 [krp]
- arnaud: will there always be two triples for each attachment? (with the ldp:contains)
- 16:07:14 [Ashok]
- q+
- 16:08:55 [mielvds1]
- You'll have inferencing either way
- 16:08:58 [krp]
- johnarwe: if an addition is made (an attachment) by patch, does the contains have to be added?
- 16:09:58 [mesteban]
- q+
- 16:10:07 [Arnaud]
- ack ashok
- 16:10:39 [krp]
- ashok: is how attachments/alh being added that way ok? or does it mean the server must add the corresponding ldp:contains?
- 16:11:23 [cody]
- cody has joined #ldp
- 16:11:28 [krp]
- johnarwe: this redefines the notion of membership as it is in the spec
- 16:12:02 [krp]
- q+
- 16:12:45 [sandro]
- how long are we going today?
- 16:12:48 [Arnaud]
- ack mesteban
- 16:12:52 [SteveS]
- q+
- 16:13:08 [krp]
- mesteban: there are two possible ways for updating the same thing
- 16:13:08 [JohnArwe]
- @sandro notionally, until 15 minutes ago ;-)
- 16:13:21 [krp]
- ... do I have to keep everything synchronised?
- 16:14:27 [Arnaud]
- ack krp
- 16:15:41 [Zakim]
- -ericP
- 16:15:55 [JohnArwe]
- My expectations are that any given resource would only allow one method of updating membership triples. We allowed PATCH primarily due to the scaling issues for large-membership containers (PUT does not scale past some client and/or server limit)
- 16:16:09 [Arnaud]
- sandro, I proposed to extend meeting by 1h
- 16:16:29 [Arnaud]
- we're getting close to that though
- 16:16:36 [JohnArwe]
- ...for small-enough cases, PUT is how you add membership "ptrs" to existing resources.
- 16:17:40 [JohnArwe]
- ...At some point you hit some limit on client or server, and PUT no longer functions so you're forced to PATCH.
- 16:18:40 [sandro]
- I propose Henry and Steve come to consensus over dinner.
- 16:18:52 [Arnaud]
- :)
- 16:19:04 [sandro]
- Once they do that, I might be able to follow this.
- 16:19:15 [Arnaud]
- I think we are going to stop here for today
- 16:19:19 [JohnArwe]
- I'm thinking that this may be a "profiles do that" answer.
- 16:19:39 [SteveS]
- q?
- 16:20:15 [Arnaud]
- ack steves
- 16:21:00 [sandro]
- I'm going to drop off. Having too much trouble following this. Back in the morning.
- 16:21:11 [Zakim]
- -Sandro
- 16:28:28 [betehess]
- betehess has joined #ldp
- 16:39:48 [mielvds1]
- mielvds1 has left #ldp
- 16:43:42 [Arnaud]
- meeting adjourned
- 17:02:05 [davidwood]
- davidwood has joined #ldp
- 17:52:59 [Arnaud]
- Arnaud has joined #ldp
- 17:54:49 [davidwood]
- davidwood has joined #ldp
- 17:55:22 [SteveS]
- SteveS has joined #ldp
- 17:56:28 [mesteban]
- mesteban has joined #ldp
- 18:25:56 [betehess_]
- betehess_ has joined #ldp
- 18:31:27 [betehess_laptop]
- betehess_laptop has joined #ldp
- 18:35:00 [Zakim]
- disconnecting the lone participant, m, in SW_LDP(F2F)2:30AM
- 18:35:01 [Zakim]
- SW_LDP(F2F)2:30AM has ended
- 18:35:01 [Zakim]
- Attendees were BartvanLeeuwen, +34.91.336.aaaa, m, ericP, Sandro
- 18:35:02 [bblfish_]
- bblfish_ has joined #ldp
- 18:45:18 [Zakim]
- Zakim has left #ldp
- 19:18:22 [cody]
- cody has joined #ldp
- 20:46:33 [bblfish]
- bblfish has joined #ldp
- 21:38:04 [bblfish]
- bblfish has joined #ldp
- 22:14:34 [bblfish]
- bblfish has joined #ldp
- 22:28:43 [krp]
- krp has joined #ldp
- 22:35:20 [SteveS]
- SteveS has joined #ldp
- 22:56:36 [roger]
- roger has joined #ldp
- 23:17:56 [krp]
- krp has joined #ldp
- 23:48:58 [krp]
- krp has joined #ldp