Chatlog 2013-04-08

See original RRSAgent log or preview nicely formatted version.

Please justify/explain all edits to this page, in your "edit summary" text.

<arnaud> present: Arnaud, Ashok_Malhotra, SteveS, EricP, svillata, pchampin, JohnArwe, Sandro, rgarcia, cody, nmihindu, TallTed, AndyS, Yves
13:50:36 <RRSAgent> RRSAgent has joined #ldp
13:50:36 <RRSAgent> logging to http://www.w3.org/2013/04/08-ldp-irc
13:50:38 <trackbot> RRSAgent, make logs public
13:50:38 <nmihindu> nmihindu has joined #ldp
13:50:38 <Zakim> Zakim has joined #ldp
13:50:40 <trackbot> Zakim, this will be LDP
13:50:40 <Zakim> ok, trackbot; I see SW_LDP()10:00AM scheduled to start in 10 minutes
13:50:41 <trackbot> Meeting: Linked Data Platform (LDP) Working Group Teleconference
13:50:41 <trackbot> Date: 08 April 2013
13:58:35 <svillata> svillata has joined #ldp
13:59:00 <Ashok> Ashok has joined #ldp
13:59:54 <Ashok> zakim, code?
13:59:54 <Zakim> the conference code is 53794 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), Ashok
14:00:10 <Zakim> SW_LDP()10:00AM has now started
14:00:14 <Zakim> +Arnaud
14:00:29 <Zakim> +[IBM]
14:00:31 <Zakim> +Ashok_Malhotra
14:00:43 <SteveS> zakim, [IBM] is me
14:00:43 <Zakim> +SteveS; got it
14:01:00 <Zakim> +??P12
14:01:03 <pchampin> pchampin has joined #ldp
14:01:07 <Zakim> +EricP
14:01:21 <cody> cody has joined #ldp
14:01:23 <svillata> Zakim, ??P12 is me
14:01:23 <Zakim> +svillata; got it
14:01:43 <JohnArwe> JohnArwe has joined #ldp
14:01:50 <Zakim> +??P15
14:01:57 <rgarcia> rgarcia has joined #ldp
14:02:18 <Zakim> +??P18
14:02:24 <Zakim> +??P20
14:02:25 <Zakim> +JohnArwe
14:02:27 <Zakim> +Sandro
14:02:43 <Zakim> -??P18
14:02:44 <JohnArwe> regrets: steve battle, sergio
14:03:02 <Zakim> +??P24
14:03:09 <nmihindu> zakim, ??P18 is me
14:03:09 <Zakim> I already had ??P18 as ??P18, nmihindu
14:03:17 <rgarcia> zakim, ??P24 is me
14:03:17 <Zakim> +rgarcia; got it
14:03:21 <pchampin> scribe: pchampin
14:03:43 <Zakim> +[IPcaller]
14:04:04 <nmihindu> zakim, ??P20 is me
14:04:04 <Zakim> +nmihindu; got it
14:04:10 <cody> zakim, +[IPcaller] is me
14:04:10 <Zakim> sorry, cody, I do not recognize a party named '+[IPcaller]'
14:04:23 <cody> zakim IPcaller is me
14:04:38 <Zakim> +[OpenLink]
<pchampin> topic: Admin
14:04:39 <pchampin> subtopic: Announcement
14:04:48 <TallTed> Zakim, [OpenLink] is temporarily me
14:04:48 <Zakim> +TallTed; got it
14:05:05 <pchampin> Arnaud: Erik Wilde has renounced chairing this group
14:05:19 <Kalpa> Kalpa has joined #ldp
14:05:29 <pchampin> ... I've been offered to find a new co-chair, but declined.
14:05:41 <pchampin> ... I'll chair alone, if that's ok with everyone.
14:06:00 <pchampin> subtopic: Last week minutes
14:06:32 <pchampin> PROPOSAL: approve minutes of april 1st
14:06:40 <pchampin> RESOLVED: approve minutes of april 1st
14:07:09 <pchampin> subtopic: next F2F
14:07:25 <SteveS> Zakim, who is here?
14:07:25 <Zakim> On the phone I see SteveS, Arnaud, Ashok_Malhotra, svillata, EricP, pchampin, nmihindu, JohnArwe, Sandro, rgarcia, [IPcaller], TallTed
14:07:28 <Zakim> On IRC I see Kalpa, rgarcia, JohnArwe, cody, pchampin, Ashok, svillata, Zakim, nmihindu, RRSAgent, AndyS, cygri, TallTed, stevebattle2, SteveS, oberger, jmvanel, davidwood, Arnaud,
14:07:28 <Zakim> ... betehess, ericP, thschee, sandro, Yves, trackbot
14:07:38 <pchampin> Arnaud: Arun proposed to host next F2F in Madrid
14:07:44 <Zakim> +[IPcaller.a]
14:07:50 <Zakim> +??P39
14:07:51 <AndyS> zakim, IPCaller.a is me
14:07:51 <Zakim> +AndyS; got it
14:08:01 <rgarcia> s/Arun/Raul/
14:08:04 <TallTed> Zakim, mute me
14:08:04 <Zakim> TallTed should now be muted
14:09:00 <SteveS> I'm good with proposed dates June 18-20
14:09:08 <pchampin> ... goal is to issue a LC after that F2F if we haven't done so before.
14:09:31 <Arnaud> Proposed: hold our F2F3 on June 18-20, 2013 in Madrid
14:09:42 <JohnArwe> +1
14:09:44 <rgarcia> +1
14:09:46 <svillata> +1
14:09:46 <nmihindu> +1
14:09:46 <SteveS> +1
14:09:51 <cody> +1
14:09:53 <Ashok> +1
14:10:01 <sandro> -0 I can't travel for LDP
14:10:16 <ericP> +1
14:10:26 <pchampin> -0 (unavailable from 19)
14:10:28 <TallTed> -0  I won't be physically present
14:11:07 <Arnaud> Resolved: hold our F2F3 on June 18-20, 2013 in Madrid
14:11:38 <pchampin> Arnaud: I'll update the wiki page http://www.w3.org/2012/ldp/wiki/F2F3
14:11:56 <pchampin> ... Raul can update it as well with info on venue, accommodation, etc.
14:12:07 <pchampin> topic: Tracking of actions and issues
14:12:36 <pchampin> Arnaud: anyone claiming victory on open actions?
14:13:27 <Ashok> q+
14:13:35 <pchampin> ... We are not very strict on setting due dates to actions,
14:13:41 <Arnaud> ack ashok
14:13:50 <pchampin> ... but please complete your actions, as they help us move forward.
14:14:03 <ericP> is targeted, public humiliation in order?
14:15:05 <pchampin> Ashok: re. ACTION-48, can we talk about it during next telecon?
14:15:29 <pchampin> ... the question is: how far can we dictate what the engine should/can do.
14:15:40 <pchampin> Arnaud: ok, I'll put it on the agenda for next week.
14:16:13 <pchampin> EricP: in the meantime, it would be good that Ashok set a low bar and a high bar, to give a starting point to the discussion.
14:16:26 <Arnaud> q?
<pchampin> topic: Open Issues
<pchampin> subtopic: ISSUE-58: Property for asserting that complete description of members is included in LDPC representation
14:17:21 <pchampin> issue-58?
14:17:21 <trackbot> ISSUE-58 -- Property for asserting that complete description of members is included in LDPC representation -- open
14:17:21 <trackbot> http://www.w3.org/2012/ldp/track/issues/58
14:18:31 <pchampin> Arnaud: my method is to put forward a proposal made by someone, and let people comment on it
14:18:59 <pchampin> ... not meaning that that proposal is what the group should do, but makes a good starting point.
14:19:46 <svillata> q?
14:19:48 <SteveS> q+
14:19:55 <Arnaud> ack steves
14:20:05 <TallTed> q+
14:20:06 <TallTed> Zakim, unmute me
14:20:07 <Zakim> TallTed should no longer be muted
14:20:29 <pchampin> ISSUE-58 is to prevent people making a useless GET to a resource when they already got complete information from the container
14:21:06 <Arnaud> yes
14:21:17 <AndyS> Hard to make a complete judgement without seeing a complete set of properties that we will have.  Unclear about whether critical or just useful/nice. Include for now - review in context in complete draft.
14:21:31 <pchampin> SteveS: I see some value in it, but not sure many would implement it
14:21:57 <Ashok> q+
14:22:16 <Arnaud> ack tallted
14:22:25 <pchampin> Arnaud: the property is applied to the container; but it could be applies to each individual resource in the container.
14:22:47 <pchampin> ... Also, not fan of the name of the property: it is not about being inlined, but about being *completely* inlined.
14:23:02 <Arnaud> ack ashok
14:23:07 <JohnArwe> @andy, IIRC in the f2f discussion is was ack'd by some as a performance optimization.
14:23:10 <pchampin> TallTed: prefer to state this at the resource level; and not fan on the property name either.
14:23:34 <AndyS> This touches on layering - what's core (all systems ... MUST provide) and what's on top of that core (optional).
14:23:51 <pchampin> Ashok: would pagination help solve this?
14:24:00 <AndyS> JohnArwe - makes sense - is there deployed experience?  Caching also plays to this.
14:24:13 <pchampin> Arnaud: this is orthogonal to pagination.
14:24:51 <JohnArwe> @Andy this is something this WG invented, not part of submission, no impl experience.
14:25:23 <pchampin> TallTed: sparing GET resources is not only important for the client; it is even more important for the server.
14:25:52 <AndyS> @john can we treat this as cache control? Are there other such features in that space? (more a rhetorical question)
14:26:09 <pchampin> q+
14:26:18 <Arnaud> ack pchampin
14:27:24 <JohnArwe> @andy I'm suspecting not directly amenable to cc, since the request-uri for container != request-uri for members.  It would take an LDP-aware cache to build a bridge between those two peaks of Mt Kili.
14:27:41 <pchampin> pchampin: do we really need extra vocabulary for that
14:27:58 <pchampin> ... one way for the server to state that the container items are completely described
14:28:51 <AndyS> @john good point but I would have though LDP-aware cache is likely (to the point of absolutely necessary :-) in the client impl.
14:29:03 <pchampin> ... is to use #-URIs for its items
14:29:37 <ericP> q?
14:29:41 <pchampin> TallTed: this is not a solution; what if the resource description is completely inlined today, but not tomorrow?
14:29:45 <betehess> betehess has joined #ldp
14:29:47 <Arnaud> Proposed: Close ISSUE-58: Property for asserting that the complete description of a member resource is included in LDPC representation, adding a property ldp:fullyInlined, values of true/false. The default (if not specified) is false. If true,  it means that a complete description of the member resource is inlined with the container document (or page), and therefore  clients SHOULD NOT do GET on the member URIs to retrieve additional triples.
14:30:15 <TallTed> suggest s/ldp:fullyInlined/ldp:descriptionComplete/
14:30:19 <pchampin> q+
14:30:27 <Arnaud> ack pchampin
14:30:47 <rgarcia> q+
14:30:58 <Arnaud> ack rgarcia
14:31:26 <pchampin> q+
14:31:47 <JohnArwe> @andy: I would not want to Require any caching on the client side (certainly allowed); that would smell like leaving out thin clients, like simple scripts.
14:31:53 <Arnaud> Arnaud has joined #ldp
14:32:06 <SteveS> q+
14:32:07 <pchampin> rgarcia: would prefer to state that GET is not required
14:32:21 <pchampin> ericP: or "GET will not provide annotional triples"
14:32:23 <Arnaud> ack pchampin
14:32:47 <pchampin> Arnaud: concerns have been expressed about the server getting too many GETs
14:33:03 <ericP> pchampin: i'm concearned about the value of the property
14:33:17 <ericP> ... i don't consider it a property of the resource
14:33:27 <AndyS> @john except thin/slow clients really need caching:-) but yes - not require.
14:33:28 <ericP> ... it's a relationship between the resource and the container
14:33:32 <AndyS> q+
14:33:57 <pchampin> pchampin: should probably be a relation btw the resource and the container, rather than a boolean property
14:34:09 <pchampin> ... as this is not something intrinsic to the resource
14:34:51 <pchampin> ... ldp:fullyInlinedBy <container>
14:35:13 <TallTed> Zakim, unmute me
14:35:13 <Zakim> TallTed was not muted, TallTed
14:35:21 <JohnArwe> q+
14:35:43 <AndyS> q-
14:35:48 <Arnaud> ack steves
14:35:57 <pchampin> Arnaud: let's not spend too much time on this
14:35:57 <ericP> pchampin: rather than asserting <resource> ldp:descriptionComplete "true", assert <resource> ldp:descriptionComplete <someContainer>,
14:36:02 <TallTed> resourceURI ldp:descriptionComplete {containerURI, resourceURI}
14:36:14 <pchampin> ... let's have somebody make a proposal
14:36:21 <TallTed> "complete description for this resource GOT from container/resource"
14:36:47 <pchampin> SteveS: we should better define what "fully inlined by" means;
14:36:53 <TallTed> you could also do a GET on the individual resource -- to *just* get *its* description -- and not the descriptions of the 100 other resources in that container
14:37:22 <pchampin> ... triples can be added very quickly
14:37:25 <AndyS> Another viewpoint is that this is a statement about the reply (c.f. paging, HTTP header stuff)
14:37:33 <Arnaud> ack john
14:38:08 <pchampin> JohnArwe: agree with what Andy just wrote on the IRC
14:38:15 <pchampin> ... should be a property of a specific response
14:39:01 <JohnArwe> seems debatable to include response properties in any resource's triples
14:39:01 <pchampin> Arnaud: any volunteer for making a new proposal?
14:39:41 <pchampin> @JohnArwe: a Link header pointing to all resources that are completely inlined?
14:39:42 <JohnArwe> ... HTTP would use headers for that (and it has named classes of headers for this sort of thing)
14:40:01 <AndyS> @john Should the client be allowed/able to influence the server response? (hmm ... probably over engineering)
<pchampin> subtopic: ISSUE-14: Include clarifications about ordering in BPC representations
14:40:19 <SteveS> issue-14?
14:40:20 <trackbot> ISSUE-14 -- Include clarifications about ordering in BPC representations -- open
14:40:20 <trackbot> http://www.w3.org/2012/ldp/track/issues/14
14:40:21 <nmihindu> issue-14?
14:40:21 <trackbot> ISSUE-14 -- Include clarifications about ordering in BPC representations -- open
14:40:21 <trackbot> http://www.w3.org/2012/ldp/track/issues/14
14:40:21 <davidwood> davidwood has joined #ldp
14:41:09 <JohnArwe> Actually I did not assert using Link headers.  I simply asked if we had agreement that whether or not a member was inlined is really a property of the message response/interaction flow, or not.  Ted asserted it must allowed to vary with each request/response pair, and I heard no objections to that.
14:41:17 <SteveS> q+
14:41:22 <Arnaud> ack steves
14:41:34 <Ashok> q+
14:41:35 <pchampin> Raul: (described his proposal about ISSUE-14, but scribed didn't get it all)
14:41:58 <JohnArwe> @andy: perfect world, sure.  clear enough to demand "littering" the spec with it, much less sure (and leaning against that)
14:42:05 <nmihindu> yes, that is what I meant.
14:42:29 <Arnaud> q?
14:42:34 <Arnaud> ack ashok
14:43:14 <pchampin> Ashok: someone argued that you have to allow the server to decide on the order, if it is not specified
14:43:49 <pchampin> SteveS: we are only saying how to specify the order
14:44:20 <pchampin> TallTed: how do we define a container? same Subject-Predicate or only same Subject?
14:44:43 <Ashok> s/someone/Erik/
14:44:47 <cody> a collection of same-subject, same-predicate triples,
14:45:01 <pchampin> Arnaud: see definition of LDPC
14:45:13 <pchampin> TallTed: ok, so that's same Subject-Predicate
14:45:25 <pchampin> SteveS: and if it has no sortPredicate, the order is unspecified
14:45:50 <pchampin> ... If it has a sortPredicate, it should be ordered by the value of that predicate in the items.
14:46:05 <pchampin> ... But there are some problems with locales.
14:46:35 <pchampin> Ashok: you can have the ordering specified by the unicode specification.
14:47:23 <pchampin> Arnaud: I agree that we will have to tackle the local/i18n problems at some point,
14:47:34 <pchampin> ... but would like to see if we get a general agreement on this issue
14:49:06 <pchampin> SteveS: as I understand it, Raul's proposal of an index property is not to add it to the LDP vocabulary,
14:49:10 <nmihindu> yes. completely.
14:49:34 <pchampin> ... but an example on how the problem could be solved in a service-specific way.
14:49:36 <nmihindu> I just wanted to show how it can  be done in that specific case,
14:52:08 <pchampin> TallTed: this proposal is problematic for me: you can not order by a property that is not present
14:52:34 <pchampin> ... so if it is same subject+predicate, you can not sort by anything else than the object.
14:53:08 <pchampin> ... Even if that ordering information is something that the server knows in the background.
14:53:21 <sandro> q?
14:53:42 <sandro> TallTed, the Object is a like a ROW, not a String.
14:53:44 <pchampin> ... As inlining is optional, we can not rely on that. It's too complex.
14:54:26 <Ashok> Sandro, I think he is saying the value of the object is a string
14:54:54 <AndyS> Can include a numeric index (much safer to sort on)
14:55:21 <sandro> objects don't have values as strings.
14:55:39 <sandro> (unless they are literals)
14:55:42 <Arnaud> q?
14:56:21 <pchampin> SteveS: it seems to me that Ted's issue is different from what ISSUE-14 is about.
14:56:26 <pchampin> Arnaud: clearly not in a position to close this now. Let's move one
<pchampin> subtopic: ISSUE-59: Reconsider usage of Aggregate/Composite construct to get predictable container delete behavior
14:56:37 <pchampin> issue-59?
14:56:37 <trackbot> ISSUE-59 -- Reconsider usage of Aggregate/Composite construct to get predictable container delete behavior -- open
14:56:37 <trackbot> http://www.w3.org/2012/ldp/track/issues/59
14:57:13 <pchampin> Arnaud: we have this distinction btw 2 kinds of containers,
14:57:17 <pchampin> ... that nobody really likes.
14:57:37 <pchampin> ... SteveS proposed that they emerged because of different need re. DELETE.
14:58:06 <Ashok> q+
14:58:17 <pchampin> ... Only one type of container, and DELETE only deletes the container, not the members. Leaves recursive delete to a future spec.
14:58:19 <AndyS> +1 to focusing on a single, simple, minimal container proposal.
14:58:38 <Arnaud> ack ashok
14:58:38 <pchampin> ... But DELETE should not create dangling resources.
14:58:45 <Ashok> make container management dependent on how resources were added to the container. if they were POSTed to it, they are contained and get DELETEd. if they were linked, they are associated and only the link gets DELETEd.
14:59:09 <SteveS> q+
14:59:36 <Ashok> q+
14:59:36 <Arnaud> ack steves
14:59:43 <TallTed> q+
14:59:44 <pchampin> Arnaud: am I right in thinking that the group wants to unify those two kinds of containers?
14:59:55 <sandro> +1 single type of container
15:00:04 <rgarcia> +1
15:00:11 <cody> +1
15:00:13 <nmihindu> +1
15:00:54 <pchampin> SteveS: the problem of dangling link exist as long as we delete a resource; it is not limited to the container-member relation.
15:01:22 <Arnaud> ack ashok
15:01:23 <pchampin> ... It should be up to the server to do what they need to do.
15:01:26 <JohnArwe> +1 single type of container
15:01:54 <pchampin> Ashok: if we have only one kind of container, do we only have one kind of DELETE?
15:02:14 <pchampin> Arnaud: the idea would be to have one kind of DELETE, and add other kinds later on.
15:02:15 <sandro> How does one add another "type of DELETE" to HTTP?
15:02:16 <Arnaud> ack tallted
15:02:47 <JohnArwe> ashok: http://lists.w3.org/Archives/Public/public-ldp-wg/2013Apr/0018.html details under (b) the proposed delete behavior
15:03:04 <pchampin> TallTed: aggregation should be the only kind of container
15:04:26 <Zakim> -Ashok_Malhotra
15:04:28 <Zakim> -SteveS
15:04:28 <Zakim> -Sandro
15:04:29 <Zakim> -TallTed
15:04:29 <Zakim> -svillata
15:04:31 <Zakim> -Yves
15:04:32 <Zakim> -JohnArwe
15:04:33 <Zakim> -[IPcaller]
15:04:35 <Zakim> -AndyS
15:04:36 <Zakim> -EricP
15:04:38 <Zakim> -rgarcia
15:04:42 <cody> cody has left #ldp
15:04:44 <Arnaud> MEETING ADJOURNED
15:04:46 <Zakim> -nmihindu
15:04:50 <Zakim> -Arnaud
15:04:57 <Zakim> -pchampin
15:04:59 <Zakim> SW_LDP()10:00AM has ended
15:04:59 <Zakim> Attendees were Arnaud, Ashok_Malhotra, SteveS, EricP, svillata, pchampin, JohnArwe, Sandro, rgarcia, [IPcaller], nmihindu, TallTed, AndyS, Yves
15:05:09 <AndyS> AndyS has left #ldp
15:05:57 <Kalpa> Kalpa has left #ldp
15:21:38 <AndyS> AndyS has joined #ldp
# SPECIAL MARKER FOR CHATSYNC.  DO NOT EDIT THIS LINE OR BELOW.  SRCLINESUSED=00000281