07:44:11 RRSAgent has joined #ldp 07:44:11 logging to http://www.w3.org/2013/06/18-ldp-irc 07:44:13 RRSAgent, make logs public 07:44:13 Zakim has joined #ldp 07:44:15 Zakim, this will be LDP 07:44:15 ok, trackbot; I see SW_LDP(F2F)2:30AM scheduled to start 74 minutes ago 07:44:16 Meeting: Linked Data Platform (LDP) Working Group Teleconference 07:44:16 Date: 18 June 2013 07:44:25 zakim, who's on the phone? 07:44:25 SW_LDP(F2F)2:30AM has not yet started, JohnArwe 07:44:27 On IRC I see RRSAgent, JohnArwe, SteveS, rgarcia, Arnaud, mielvds, Ashok, nmihindu, betehess, jmvanel, gavinc, Yves, sandro, trackbot, ericP, thschee 07:44:27 zakim, who is on the phone? 07:44:27 SW_LDP(F2F)2:30AM has not yet started, nmihindu 07:44:29 On IRC I see RRSAgent, JohnArwe, SteveS, rgarcia, Arnaud, mielvds, Ashok, nmihindu, betehess, jmvanel, gavinc, Yves, sandro, trackbot, ericP, thschee 07:45:28 mesteban has joined #ldp 07:46:03 Introductions 07:51:25 mielvds1 has joined #ldp 07:51:59 roger has joined #ldp 07:52:02 BartvanLeeuwen has joined #ldp 07:53:17 Ashok has joined #ldp 07:53:34 SW_LDP(F2F)2:30AM has now started 07:53:40 +??P0 07:54:05 Zakim, ??p0 is me 07:54:05 +BartvanLeeuwen; got it 07:54:11 hi Bart 07:54:14 we're dialing in 07:54:44 + +34.91.336.aaaa 07:54:57 okay, gives me time for coffee 07:59:23 Topic: UCR 07:59:56 Arnaud: There have been comments on UCR 08:00:34 ... we don't have Steve Battle here 08:00:59 ... Great review by Miguel 08:01:39 roger has joined #ldp 08:01:58 ... sometimes UCR and spec are not in sync 08:03:36 Miguel: We should annotate UCR document saying what we cover and what we delay to next version 08:03:51 BartvanLeeuwen, we have rgarcia, mesteban, Arnaud, mielvds, Ashok, nmihindu, JohnArwe, SteveS, gavinc, roger, kevin 08:04:15 ... for the use cases we cover we should have pointers in the spec 08:05:00 s/in/to/ 08:05:42 Arnuad: You sent mail on UCR but you did not get a response 08:06:22 ACTION-42 on MIguel to review UCR can be closed 08:09:19 Arnaud: Miguel, would you like to be editor for the UCR 08:09:38 s/UCR/UCR?/ 08:11:25 Discussion about which direction the pointers should go 08:12:01 UCR->spec 08:12:11 or spec -> UCR 08:13:02 SteveS has joined #ldp 08:14:07 AndyS has joined #ldp 08:14:32 krp has joined #ldp 08:15:16 zakim, aaaa is the F2F meeting (can't hurt to try) 08:15:16 I don't understand you, JohnArwe 08:15:21 zakim, aaaa is m 08:15:21 +m; got it 08:17:29 Arnaud has joined #ldp 08:19:35 Arnaud: Please all look at Miguel's comments 08:20:14 ... Miguel, could you follow up with Steve Battle 08:21:03 Topic: LDP spec 08:21:56 Arnaud: We should review the issues and see which ones we need to close 08:23:52 ... we have 2 main isues ... container and membership predicate and there is the one about affordances 08:26:02 Arnaud bring up list of issues to discuss which ones we address 08:27:12 mielvds has joined #ldp 08:27:33 Arnaud: ISSUE-16 has no proposal. Mark as "at risk"? 08:29:03 John: There is nothing to be done ... spec does not need to change 08:29:50 Arnaud: ISSUE-32 needs to be addressed 08:30:31 Arnaud: ISSUE-37 ... Steve was going to add an itroduction to spec 08:30:41 John: Non-normative text 08:30:56 Arnaud: ISSUE-50 08:31:46 Steve: I think we address this .... needs sign-off from Henry 08:32:12 Arnaud: Duplicate of 54? 08:34:08 Arnaud: ISSUE-51 08:34:34 Discussion as to whether this is inverse of the membership predicate 08:35:34 Roger: We can close issue in order to make progress 08:36:26 Arnaud: Let's leave open for now ... let's see how discussion on membership predicate work 08:38:12 Arnaud: ISSUE-56 let's leave open ... related to ISSUE-16? 08:39:50 Arnaud: ISSUE-57 ... related to ISSUE-32 08:41:54 Arnaud: ISSUE-58 ... let's look at latest proposal 08:42:13 John: I suggest leave as "at risk" 08:43:07 Arnaud: ISSUE-62 ... we need proposal for this 08:43:25 Roger: There is an issue here. I will create a proposal 08:43:58 ... related to membershipXXX 08:45:11 Arnaud: ISSUE-66 Robust pagination 08:45:18 ... suggest we close 08:48:47 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 Arnaud: ISSUE-68 ... do not have a proposal ... can be closed 08:51:45 Arnaud: ISSUE-71 needs discussion 08:52:50 Arnaud: ISSUE-72 needs discussion 08:53:21 Arnaud: ISSUE-73 needs discussion 08:53:38 Arnaud: ISSUE-75 needs discussion 08:53:55 Arnaud: ISSUE-77 needs discussion 08:54:15 Arnaud: ISSUE-78 may be editorial 08:55:28 Arnaud: ISSUE-79 needs discussion 08:55:46 Arnaud: ISSUE-80 needs discussion 08:56:34 Arnaud: There are 6 issues marked as Pending Review 08:57:26 Cody: How do you create the first container 08:57:49 +[GVoice] 08:58:00 Zakim, [GVoice] is me 08:58:00 +ericP; got it 09:02:34 -BartvanLeeuwen 09:08:06 +Sandro 09:15:13 anyone willing to try a google+ hangout, so remote folks can see you? 09:17:10 if so, i'm ericW3C@gmail.com 09:18:17 Ah. 09:19:06 rgarcia has joined #ldp 09:20:29 JohnArwe going to scribe temporarily while Ashok makes his points on issue-66 robust pagination 09:21:24 topic: ISSUE-66 09:21:34 issue-66 09:21:34 ISSUE-66 -- Robust pagination -- open 09:21:34 http://www.w3.org/2012/ldp/track/issues/66 09:22:06 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 Ashok: SQL has something called "cursor stability" equivalent 09:22:29 ...to robust pagination 09:22:41 Henry arrives in F2F room 09:22:53 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 basically "nextPageSameState" as a link would do that. or maybe "nextPage" could optionally have those semantics. 09:23:50 ... 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 @sandro, question would be "same state as what?" the page URL could be from a query made a year ago. 09:25:16 ashok: should at least give client a way to know that page content has changed. 09:25:35 Topic: ISSUE-65 09:25:45 The spec does not address this 09:25:46 how i had imagined robust pagination: 09:25:46 { rdfs:member , . :nextPage } 09:25:46 after DELETEs of and : 09:25:46 { :nextPage } # page<3> is preserved though empty 09:25:52 JohnArwe, same state as the resource was when this content was serialized. 09:26:00 s/65/66/ 09:26:48 Yes, Eric that's one way .... but it will have pages with holes in them 09:26:55 q? 09:26:59 definitely 09:27:35 q+ 09:27:47 i'm perfectly happy to punt on it 09:27:49 q+ 09:27:50 ack sandro 09:27:50 @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 Arnaud: Should we investigate how we could provide robust pagination? 09:28:32 +1 to understanding how an extension could do it making it safe to punt 09:29:30 Sandro described a design for robust pagination 09:29:32 i suspect that ldp:nextPatch and ldp:longPollPatch are in that category 09:29:46 ack krp 09:30:12 Kevin: Argues we need robust pagination 09:30:36 krp: if you care about consistency in a page, is it specifically NOT a container at that point? 09:30:43 q+ 09:30:48 ack sandro 09:30:56 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 has joined #ldp 09:31:22 q+ 09:31:32 Sandro, any server can provide robust pagination using version number in the URL 09:32:06 ... you coukd provide two versioin stable and not stable 09:32:36 s/coukd/could/ 09:32:41 ack steves 09:32:43 s/versioin/version/ 09:32:52 .... discusses StableNextPage predicate 09:32:55 sandro: so have a stableNextPage predicate, defined by us or somebody else 09:34:33 Yves? can weakt ETag validation be applied here? 09:35:10 Ashok: Without robust pagination you get into trouble when the resource you are working on gets deleted 09:35:35 Henry: Discusses a timestamp version of the universe 09:36:39 Arnaud: There should be a mechanism to tell the client that a page has changed 09:37:09 maybe ldp:resourceState ? 09:37:43 http stuff doesn't help, since it's about the page, not about the thing behind all the pages. 09:37:53 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 maybe ldp:overallState 09:38:20 ack eric 09:38:20 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 Discussion about whether etags can be used 09:38:53 +??P0 09:39:03 Zakim, ??P0 is me 09:39:03 +BartvanLeeuwen; got it 09:39:04 Eric: Anything we add to spec would paint us into a corner 09:39:23 perhaps a pageOfEtag header, to accompany ldp:pageOf 09:39:52 q+ 09:40:00 +1 SteveS pageOfEtag. That's nice. 09:40:18 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 q? 09:40:26 Arnaud: If soemone wants to make a proposal please send soon to the list 09:40:28 ack steves 09:40:35 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 krp, both 09:41:11 +1 JohnArwe 09:41:14 Steve: Let's wait till next version 09:41:17 +1 JohnArwe 09:41:28 a HEAD request for checking the ETag of the container is too much overhead? 09:41:28 +1 JohnArwe 09:41:36 +1 JohnArwe 09:42:22 Meil: Do a HEAD request to container to check if it has changed 09:42:39 You could do a HEAD for LastModified, not ETag, AFTER getting the page. That would work. 09:42:41 s/Meil/Miel/ 09:42:46 Steve: It get's you someone 09:43:12 s/someone/somewhere/ 09:43:18 s/someone/somewhere/ 09:44:03 Arnaud: I think spec says pagination is not robust 09:45:37 Arnaud: Editors to check what the spec says 09:47:47 Arnaud: Let's wait and see if we get a proposal 09:47:50 my googling so far seems to support the 1-second resolution for last-modified. making it useless for HEAD this way. 09:49:25 Topic: ISSUE-57 How can client tell he is communicating with a LDP server 09:50:01 bblfish has joined #ldp 09:50:07 Arnaud: Can you rely on RDF to tell you what the interaction model is 09:50:15 hi 09:50:38 ... others say conatiner tells you interaction model 09:50:59 ... some suggest changing the media type, that seems like a high cost 09:51:35 ... Coulkd we have a special header? 09:51:40 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 s/Coulkd/Could/ 09:52:00 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 why knowing a priori that it's an LDP server is better than knowing it a posteriori 09:52:23 Arnaud: You could use a special header 09:52:50 q+ to say this is a way to do affordances in general 09:53:17 ack sandro 09:53:17 sandro, you wanted to say this is a way to do affordances in general 09:53:53 Sandro: I like this approach ... profile can be each LDP feature 09:54:21 ... one link header per page 09:55:13 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 Arnaud: ISSUE-33 brings up issue of servers with different capabilities 09:55:26 Issue-33? 09:55:26 ISSUE-33 -- Pagination for non-container resources -- closed 09:55:26 http://www.w3.org/2012/ldp/track/issues/33 09:56:23 +1 Arnaud "If you're this kind of server, then you MUST do ...." instead of all our MAY and SHOULDs 09:56:39 header on each ldp RESPONSE 09:56:49 Did arnaud meant Issue-33? 09:56:49 what is the page that shows these options? 09:56:51 mielvds1 has joined #ldp 09:56:57 mesteban_ has joined #ldp 09:56:59 issue-33? 09:56:59 ISSUE-33 -- Pagination for non-container resources -- closed 09:56:59 http://www.w3.org/2012/ldp/track/issues/33 09:57:02 Arnaud1 has joined #ldp 09:57:05 nmihindu_ has joined #ldp 09:57:08 issue-32? 09:57:08 ISSUE-32 -- How can clients discover that a resource is an LDPR or LDPC, and what features are supported? -- open 09:57:08 http://www.w3.org/2012/ldp/track/issues/32 09:57:34 (this was about issue-32) 09:57:42 q? 10:01:19 And the wiki page http://www.w3.org/2012/ldp/wiki/ISSUE-32 10:03:31 q+ 10:05:14 ack steves 10:05:39 strawpoll: use profile link headers to advertise ldp capabilities 10:05:49 discussion about when to use link headers vs new RDF types 10:06:28 http://tools.ietf.org/html/rfc6906 10:07:13 +1 link header to identify an ldp-capable server 10:08:30 krp has joined #ldp 10:08:53 bblfish has joined #ldp 10:09:42 hi 10:10:10 roger has joined #ldp 10:10:13 hello !! 10:10:25 We are talking also about http://tools.ietf.org/html/rfc6903, section 6 10:11:11 Ashok has joined #ldp 10:13:47 what is the straw poll? 10:14:23 strawpoll: use link headers to advertise ldp capabilities 10:14:29 +1 10:14:31 +1 10:14:33 +1 10:14:34 +1 10:14:34 +1 10:14:35 +1 10:14:36 +1 10:14:38 +1 10:14:40 +1 10:14:42 +1 10:14:49 0 10:15:33 RFC6906? 10:16:10 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 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 Sandro: I have not read RFC 6906 10:18:06 @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 Sandro: what's the value of a profile 10:19:29 John: Profile is defining a particular P 10:19:36 ... o is the URL 10:19:37 :context :linkRelationType :target . 10:20:10 Sandro: You dereference o and you get the type info 10:20:37 this is what I would expect the header to look like: Link: ; rel=profile 10:21:47 @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 issue-57? 10:21:53 ISSUE-57 -- How can a client determine that it is in communication with an LDP server? -- open 10:21:53 http://www.w3.org/2012/ldp/track/issues/57 10:22:28 Oh, I guess one can have multiple profiles at once. 10:22:35 1+ 10:22:37 q+ 10:22:39 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 q+ 10:22:54 ack bblfish 10:23:03 Ashok: We don't need to define profiles in the spec 10:23:37 q+ 10:24:20 I heard "read-only" as a shorthand for a named set/profile of features 10:24:49 ack nmihindy 10:24:59 ack nmihindu 10:25:57 q+ 10:28:39 ack ashok 10:29:17 Issue-32? 10:29:17 ISSUE-32 -- How can clients discover that a resource is an LDPR or LDPC, and what features are supported? -- open 10:29:17 http://www.w3.org/2012/ldp/track/issues/32 10:29:25 discussion about how granular the introspection capabilities needs to be from issue-32 10:29:32 Wiki page: http://www.w3.org/2012/ldp/wiki/ISSUE-32 10:29:33 what is the URL for the issue-32 10:29:42 which shows the different types of things? 10:29:51 ack bblfish 10:30:44 q+ 10:31:13 ack steves 10:32:17 Ashok has joined #ldp 10:32:33 @henry: email w/ 3 profile strawman is at http://lists.w3.org/Archives/Public/public-ldp-wg/2013Apr/0139.html 10:32:39 ...in pdf attachment 10:33:01 Arnaud: Can we agree that to solve ISSUe-57 is to create a link header 10:33:36 s/ISSUe-57/ISSUE-57/ 10:34:20 +1 bblfish using rdf:type relation IN LINK HEADER for ldp:Resource 10:35:32 PROPOSAL: close issue-57, adding that LDP servers MUST advertise LDP with a link header: Link: ; rel=profile 10:36:16 q+ to ask why profile instead of type? (sorry) 10:36:37 @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 ack sandro 10:36:43 sandro, you wanted to ask why profile instead of type? (sorry) 10:36:57 Ashok: And, Sandro type = rdf:type 10:37:04 roger has joined #ldp 10:38:06 q+ 10:38:07 So I guess bblfish is saying servers that offer rdf:type LDPResource should offer LDP functionality, else it's their problem? 10:38:18 @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 ack steves 10:38:46 Arnaud: Sandro, please type in proposal 10:39:07 Steve: We could add profile types to the spec 10:39:28 +q 10:39:32 ack roger 10:39:51 PROPOSED: close ISSUE-57, adding that LDP servers MUST advertise LDP with a link header: Link: ; 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 Roger: We need client to be generic ... that should be in the content 10:40:18 ...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', , that CMS is a liar. 10:41:02 +1 10:41:04 +1 10:41:13 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 +1 10:41:47 +1 10:42:48 +-0 (not sure about what happens with containers) 10:42:48 +1 10:42:56 +0.5 10:43:04 +.5 (not sure 'type' matches as closely as 'profile') 10:43:16 +0.5 10:43:18 bblfish has joined #ldp 10:43:19 +.5 10:43:39 (I prefer 'type' to 'profile' because we get clear semantics for the the link target) 10:43:42 -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 +1 for the ldp:Resource version ( missing the def cause I got kicked out ) 10:44:37 John: This does not give you an ironclad guarantee 10:44:40 codyburleson has joined #ldp 10:46:12 Arnaud: How would server put a type in automatically? 10:46:40 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 +1 (not perfect; can live with it) 10:47:15 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 I don't think that can be done, roger. 10:48:11 codyburleson_ has joined #ldp 10:48:28 sandro, should it be done ? 10:48:51 RESOLVED: close ISSUE-57, adding that LDP servers MUST advertise LDP with a link header: Link: ; 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 Arnaud: Does anyone want to change their vote? 10:49:14 No response 10:49:28 Arnaud: ISSUE is resolved 10:51:37 Arnaud: Raul is asking 'what happens to containers' ... do we need a different type 10:51:53 Sandro: Containers are a type of LDPR 10:52:47 where is the definition for the 'type' link relations btw? 10:52:55 Link: ; rel="rdf:type"; ; rel="rdf:type" 10:53:17 http://tools.ietf.org/html/rfc6903#section-6 10:53:26 eric, we just decided it was ldp:Resource not ldp:LDPR 10:53:41 eric, that would be: Link: ; rel="rdf:type"; ; rel="rdf:type" 10:53:50 roger that 10:54:00 q? 10:54:02 so it's: and it's rel="type" not rel="rdf:type" 10:54:24 That is: Link: ; rel="type"; ; rel="type" 10:55:11 oh right 10:56:20 Arnaud: This solves whether you are in an LDP context or not 10:56:28 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 Arnaud: Do we need separate headers for resources and containers? 10:57:08 note that we have an issue open to 'move' create from containers to ldp:Resource's 10:57:29 Sandro: We need to look at other affordances 10:57:40 This is really related to the issue on Inssue-78 10:58:03 sandro: how we handle Containers will need to depend on how we do other affordances. 10:58:03 Arnaud: Let's leave it as LDPR for now 10:58:21 BREAK FOR LUNCH 10:58:43 One hour break 10:59:04 -BartvanLeeuwen 10:59:09 -Sandro 10:59:18 -ericP 11:39:18 bhyland has joined #ldp 12:04:35 I knew they 1h wouldn't work in spain :) 12:04:36 +[GVoice] 12:04:52 heh 12:05:30 Zakim, [GVoice] is me 12:05:30 +ericP; got it 12:09:38 +??P13 12:09:43