13:54:07 <RRSAgent> RRSAgent has joined #ldp
13:54:07 <RRSAgent> logging to http://www.w3.org/2013/04/01-ldp-irc
13:54:09 <trackbot> RRSAgent, make logs public
13:54:09 <Zakim> Zakim has joined #ldp
13:54:11 <trackbot> Zakim, this will be LDP
13:54:11 <Zakim> ok, trackbot; I see SW_LDP()10:00AM scheduled to start in 6 minutes
13:54:12 <trackbot> Meeting: Linked Data Platform (LDP) Working Group Teleconference
13:54:12 <trackbot> Date: 01 April 2013
13:54:20 <Arnaud> Arnaud has changed the topic to: Linked Data Platform WG -- http://www.w3.org/2012/ldp/ -- current agenda http://www.w3.org/2012/ldp/wiki/Meetings:Telecon2013.04.01
13:57:55 <nmihindu> nmihindu has joined #ldp
13:58:25 <JohnArwe> JohnArwe has joined #ldp
13:58:46 <cody> cody has joined #ldp
13:58:52 <Zakim> SW_LDP()10:00AM has now started
13:58:59 <Zakim> +OpenLink_Software
13:59:05 <Zakim> +Sandro
13:59:09 <TallTed> Zakim, OpenLink_Software is temporarily me
13:59:09 <Zakim> +TallTed; got it
13:59:11 <TallTed> Zakim, mute me
13:59:11 <Zakim> TallTed should now be muted
13:59:56 <Zakim> +JohnArwe
14:00:21 <Zakim> +??P4
14:00:27 <Zakim> +[IPcaller]
14:00:47 <SteveS> SteveS has joined #ldp
14:00:52 <cody> zakinm, IPCaller is Cody
14:00:55 <Zakim> +Arnaud
14:01:01 <nmihindu> Zakim, ??P4 is nmihindu
14:01:01 <Zakim> +nmihindu; got it
14:01:08 <Ashok> Ashok has joined #ldp
14:01:19 <cody> Zakim, IPCaller is Cody
14:01:19 <Zakim> +Cody; got it
14:01:30 <Ashok> zakim, code?
14:01:30 <Zakim> the conference code is 53794 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), Ashok
14:01:35 <rgarcia> rgarcia has joined #ldp
14:02:05 <Zakim> +Ashok_Malhotra
14:02:16 <TallTed> Zakim, who's here?
14:02:16 <Zakim> On the phone I see TallTed (muted), Sandro, JohnArwe, nmihindu, Cody, Arnaud, Ashok_Malhotra
14:02:18 <Zakim> On IRC I see rgarcia, Ashok, SteveS, cody, JohnArwe, nmihindu, Zakim, RRSAgent, TallTed, jmvanel, ericP, bblfish, Arnaud, davidwood, thschee, sandro, Yves, trackbot
14:02:31 <Zakim> +[IBM]
14:02:35 <JohnArwe> regrets: cygri, sergio, serena, pierre-antoine
14:02:41 <SteveS> zakim, [IBM] is me
14:02:41 <Zakim> +SteveS; got it
14:03:22 <ericP> Zakim, please dial ericP-office
14:03:22 <Zakim> ok, ericP; the call is being made
14:03:24 <Zakim> +EricP
14:03:37 <JohnArwe> scribe: JohnArwe
14:04:06 <Zakim> +??P11
14:04:17 <rgarcia> zakim, ??P11 is me
14:04:17 <Zakim> +rgarcia; got it
14:05:18 <SteveS> I have not looked
14:05:18 <cody> +1
14:05:23 <nmihindu> +1
14:05:46 <JohnArwe> RESOLVED: approve minutes March 24
14:05:50 <JohnArwe> s/24/25
14:07:32 <JohnArwe> Arnaud: any holidays next week?  no response.
14:08:10 <JohnArwe> http://www.timeanddate.com/holidays/  might be useful.  only 1 listed for next Mon, appears to be Jewish holiday.
14:08:15 <Kalpa> Kalpa has joined #ldp
14:08:28 <JohnArwe> pending actions: none
14:08:56 <JohnArwe> open actions completed: none
14:08:57 <Kalpa> zakim, who is on IRC?
14:08:57 <Zakim> I don't understand your question, Kalpa.
14:09:05 <JohnArwe> zakim, who's on irc?
14:09:05 <Zakim> I don't understand your question, JohnArwe.
14:09:15 <JohnArwe> zakim, who is on the call?
14:09:15 <Zakim> On the phone I see TallTed (muted), Sandro, JohnArwe, nmihindu, Cody, Arnaud, Ashok_Malhotra, SteveS, EricP, rgarcia
14:09:26 <JohnArwe> zakim, who's here?
14:09:26 <Zakim> On the phone I see TallTed (muted), Sandro, JohnArwe, nmihindu, Cody, Arnaud, Ashok_Malhotra, SteveS, EricP, rgarcia
14:09:28 <Zakim> On IRC I see Kalpa, rgarcia, Ashok, SteveS, cody, JohnArwe, nmihindu, Zakim, RRSAgent, TallTed, jmvanel, ericP, bblfish, Arnaud, davidwood, thschee, sandro, Yves, trackbot
14:10:26 <JohnArwe> Arnaud: please work on issues gating forward progress.  Let's use concrete proposals to progress; the default would be whatever the originator proposes, but others are welcome.
14:10:44 <JohnArwe> Topic: Issue-53
14:10:54 <TallTed> Zakim, unmute me
14:10:54 <Zakim> TallTed should no longer be muted
14:10:57 <TallTed> q+
14:11:03 <SteveS> q+
14:11:12 <JohnArwe> issue-53?
14:11:12 <trackbot> ISSUE-53 -- Which Content Types should be returned to bots? -- open
14:11:12 <trackbot> http://www.w3.org/2012/ldp/track/issues/53
14:11:27 <ericP> -1 to silent
14:11:34 <TallTed> q-
14:11:39 <Arnaud> ack steves
14:11:40 <JohnArwe> Arnaud summarizes: bots will not necessarily find Turtle (our current default) useful
14:11:58 <ericP> q+
14:12:00 <JohnArwe> SteveS: prefer non-silence; perhaps relax MUST
14:12:05 <Arnaud> ack ericp
14:12:34 <TallTed> q+
14:13:26 <TallTed> his concern seems to be "Google doesn't index Turtle (plain-text)" except that they do...
14:14:10 <Arnaud> ack tallted
14:14:14 <JohnArwe> ericp: we're concerned with machine-machine, issue is to make that work with existing infrastructure.  Would like to say: if no accept header/preference, unless you have reason to believe based on other info (like user-agent) that the requestor would not find turtle useful.
14:14:36 <sandro> they will?   or they do?
14:14:44 <JohnArwe> tallted: crawlers WILL index turtle, so what's the problem?
14:14:48 <betehess> betehess has joined #ldp
14:16:47 <JohnArwe> arnaud summarizes 3 options: (1) if client has preference, require them to express it (stay MUST turtle), (2) leave door open (SHOULD turtle), (3) remove it entirely aka remain silent.  Don't hear anyone clamoring for (3).  Is that right?
14:17:25 <sandro> how about "SHOULD" with an explanation that there may be app-specific reasons to do something differnt
14:18:49 <JohnArwe> discussion about "SHOULD in MUST's clothing"
14:19:44 <rgarcia> Google already indexes OWL and RDF files. E.g., https://www.google.es/search?q=%22the+person-related+classes+have+been+refactored%22&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:es-ES:official&client=firefox-a
14:21:34 <Arnaud> Proposed: close Issue-53 changing MUST to SHOULD, adding a note on why it may be ok to send something else than Turtle (e.g., client info)
14:22:16 <SteveS> +1
14:22:18 <TallTed> +1
14:22:19 <ericP> +1
14:22:24 <cody> +1
14:22:24 <Ashok> +1
14:22:29 <rgarcia> +0.5
14:22:30 <JohnArwe> +1
14:22:33 <nmihindu> +1
14:22:35 <Kalpa> +1
14:22:47 <Arnaud> Resolved: close Issue-53 changing MUST to SHOULD, adding a note on why it may be ok to send something else than Turtle (e.g., client info)
14:22:56 <JohnArwe> RESOLVED: close Issue-53 changing MUST to SHOULD, adding a note on why it may be ok to send something other than Turtle (e.g., client info)
14:23:08 <cody> Maybe he just means that he wants to present something that is actually useful to index (in the case of search results); such as a human-readable representation of a resource.
14:23:32 <JohnArwe> TOPIC: Issue-54
14:23:36 <JohnArwe> issue-54?
14:23:36 <trackbot> ISSUE-54 -- Which URIs should replace null relative URIs provided in LDPR representations? -- open
14:23:36 <trackbot> http://www.w3.org/2012/ldp/track/issues/54
14:24:20 <TallTed> q+
14:24:56 <Arnaud> ack tallted
14:25:33 <SteveS> q+
14:25:42 <JohnArwe> tallted: if server is just storing the content as a text file, should not resolve.
14:26:06 <Arnaud> ack steve
14:26:20 <JohnArwe> ...trouble with having base directives available means Created resource not always right base URI for what's inside them.
14:27:34 <JohnArwe> SteveS: server mints URI, stores content, impl is allowed to keep them separate (store the content as text) and then serve it up as it needs to... e.g. if serving RDF, then resolve the URIs according to this rule.
14:28:08 <JohnArwe> Arnaud: Tallted, are you worried about how it's stored or something else?  If how stored, impl problem no?
14:28:54 <JohnArwe> TallTed: what spec says now is that incoming Turtle with relative URIs MUST be adjusted prior to storage.  No longer have the SIMPLE LDP server we've been talking about.
14:29:43 <ericP> i propose something like s/must resolve/must be interpreted as.../
14:29:49 <JohnArwe> Arnaud: had not read it that way... as you're reading it, would agree we do not want to impose that on servers.
14:30:30 <JohnArwe> TallTed: to me this means clients cannot use base URIs in a number of scenarios where they'd otherwise make perfect sense
14:31:15 <JohnArwe> ericp: usually say "is" rather than "must be interpreted" etc to sidestep this kind of problem.  "is" talks about behavior.
14:32:08 <SteveS> +1 to ericP's description of using "is" base uri
14:32:21 <JohnArwe> Arnaud: Ted, do we agree that the newly minted URI is the base URI of the newly created resource?  yes.
14:32:40 <JohnArwe> TallTed: need to see revised wording to know if I'm ok with that.
14:32:50 <Arnaud> james: A LDPC receiving a POST of an RDF document D MUST resolve all relative URIs in D using the URI of the  created resource.
14:32:52 <TallTed> http://www.w3.org/2012/ldp/track/issues/54
14:33:13 <cody> 5.4.8 In RDF representations, LDPC servers MUST interpret the null relative URI for the subject of triples in the LDPR representation in the request entity body as referring to the entity in the request body. Commonly, that entity is the model for the “to be created” LDPR, so triples whose subject is the null relative URI will usually result in triples in the created resource whose subject is the created resource.
14:33:13 <cody> ISSUE-20
14:33:13 <trackbot> ISSUE-20 -- Identifying and naming POSTed resources -- closed
14:33:13 <trackbot> http://www.w3.org/2012/ldp/track/issues/20
14:33:28 <ericP> -> http://www.w3.org/TR/2013/WD-ldp-20130307/#ldpc-5_4_8 text in question
14:33:48 <Arnaud> A LDPC receiving a POST of an RDF document D MUST interpret all relative URIs in D using the URI of the created resource as the base.
14:34:02 <ericP> s/LDPC servers MUST interpret the null relative URI for the subject of triples in the LDPR representation in the request entity body as referring to the entity in the request body
14:34:53 <ericP>  /the base IRI per RFC3986 ladder diagram is IRI of the created resource
14:36:47 <ericP> 5.4.8 In RDF representations, the base URI for RFC3987 relative URI resolution is the IRI of the created resource.
14:37:31 <sandro> q?
14:38:24 <Arnaud> proposed: close issue-54, adding to sectino 5.4.8: In RDF representations, the base URI for RFC3987 relative URI resolution is the IRI of the created resource.
14:38:29 <ericP> +1
14:39:04 <sandro> q+ to ask about the RDF Model
14:39:14 <sandro> issue-54?
14:39:14 <trackbot> ISSUE-54 -- Which URIs should replace null relative URIs provided in LDPR representations? -- open
14:39:14 <trackbot> http://www.w3.org/2012/ldp/track/issues/54
14:40:02 <sandro> q-
14:40:03 <ericP> PROPOSED: close ISSUE-54 channging the first sentence of 5.4.8 to "In RDF representations, the base URI for RFC3987 relative URI resolution is the IRI of the created resource."
14:40:31 <JohnArwe> I think in both cases the second sentence simply describes a consequence of the first.  It adds no new normative requirements that I can see.
14:43:14 <sandro> +1
14:43:25 <ericP> +1
14:43:31 <SteveS> +1
14:43:32 <TallTed> +1
14:43:34 <bblfish> That's what I proposed right?
14:43:40 <rgarcia> +1
14:43:47 <sandro> (modulo IRI vs URI)
14:43:50 <bblfish> ( sorry am in a teleconf )
14:43:56 <nmihindu> +1
14:44:03 <sandro> No, bblfish, it gets rid of a MUST we didnt like.
14:44:43 <bblfish> ah ok. sounds ok still
14:44:47 <JohnArwe> some discussion as to equivalence between Henry's proposal and eric's
14:44:55 <JohnArwe> +1
14:44:58 <cody> +0.5 (could use some additional word-smithing in my opinion)
14:45:02 <ericP> bblfish, it changes the "MUST resolve" language to "the base URI *is* "
14:45:23 <bblfish> +1  seems ok to me.
14:45:28 <sandro> Arnaud: We're leaving it to the editors to fine-tune the wording.  This is only about intent.
14:45:33 <Arnaud> Resolved: close ISSUE-54 channging the first sentence of 5.4.8 to "In RDF representations, the base URI for RFC3987 relative URI resolution is the IRI of the created resource."
14:45:34 <cody> +1
14:45:53 <JohnArwe> topic: issue-58
14:46:03 <sandro> issue-55?
14:46:03 <trackbot> ISSUE-55 -- Hypermedia as the Engine of Application State (HATEOAS) Compliance -- open
14:46:03 <trackbot> http://www.w3.org/2012/ldp/track/issues/55
14:46:09 <JohnArwe> topic: issue-55
14:46:25 <JohnArwe> Chair, Chair's voice, WG members waffle
14:49:36 <JohnArwe> Arnaud: one advantage of current approach is that it's more under client control. have discussed this issue with erik previously as well, several possible approaches could be used.
14:49:55 <Arnaud> q?
14:50:36 <JohnArwe> SteveS: related but tangled.  you'd always get non-member properties in the first page?
14:51:00 <JohnArwe> Arnaud: yes.  could use link headers (erik did not think that was commonly done)
14:51:25 <JohnArwe> SteveS: one argument for exposing URI templates ... not sure how that would work, some sort of home document
14:51:33 <JohnArwe> s/for/was for/
14:52:07 <JohnArwe> Arnaud: either we give up on feature altogether, or get off of specific URLs
14:52:43 <JohnArwe> Arnaud: this seems to need more time, perhaps move on to 58
14:54:17 <JohnArwe> SteveS: does the binary resource resolution from the F2F influence our thinking here?  about how to advertise it, instead of using a fixed string.
14:54:52 <JohnArwe> topic: issue-58
14:55:03 <JohnArwe> zakim, who is making noise?
14:55:14 <Zakim> JohnArwe, listening for 10 seconds I heard sound from the following: TallTed (31%), Arnaud (15%), rgarcia (26%)
14:55:30 <rgarcia> zakim,mute me
14:55:30 <Zakim> rgarcia should now be muted
14:56:36 <SteveS> q+
14:56:58 <Arnaud> ack steve
14:57:05 <Ashok> q+
14:57:49 <JohnArwe> SteveS: no problem with it; one option is using existing predicate instead, i.e. say nextpage=nil.
14:57:53 <Arnaud> ack ashok
14:58:29 <JohnArwe> I don't think we can safely overload nextpage=nil.  that only works of the response is not paged.
14:58:37 <JohnArwe> s/of the/if the/
14:58:50 <cody> q+
14:58:56 <Arnaud> ack cody
14:59:35 <JohnArwe> counter-example: I serve a 2-page response with 10% of the member triples in-lined.  The client sees nextpage=nil on final page, should it interpret that as "all member triples inlined"?  clearly not.
15:01:01 <JohnArwe> TallTed: would need a nextpage triple about each subject; some members might be nil and others not-nil
15:02:05 <JohnArwe> Arnaud: back to cygri's proposal.  We can always change the name later if we want to.
15:02:25 <JohnArwe> Scribe notes that mtg is running over.
15:02:34 <Arnaud> Proposed: close issue-58, Adding a property (e.g, ldp:membersInlined) true/false. The default (if  not specified) is false. If true, it means that a complete description  of all members [on the current page] are inlined with the container  document [or page], and therefore clients SHOULD NOT do GET on the  member URIs to retrieve additional triples.
15:03:05 <TallTed> TallTed has joined #ldp
15:03:11 <SteveS> +1 agree that membersInlined is not an ideal name
15:03:23 <JohnArwe> above is cygri's proposal; editors allowed to change the predicate name
15:03:25 <Arnaud> Proposed: close issue-58, Adding a property (e.g, ldp:membersInlined) true/false. The default (if  not specified) is false. If true, it means that a complete description  of all members [on the current page] are inlined with the container  document [or page], and therefore clients SHOULD NOT do GET on the  member URIs to retrieve additional triples.
15:04:09 <rgarcia> +1 (I would prefer replacing "SHOULD NOT do" with "don to need to do GET")
15:04:22 <JohnArwe> +0.5 (fine with first part, the SHOULD NOT consequence is an example to me)
15:04:26 <Zakim> -Ashok_Malhotra
15:04:32 <JohnArwe> abandoning poll until next week.
15:04:38 <TallTed> +1 rgarcia
15:04:45 <Zakim> -SteveS
15:04:46 <Zakim> -EricP
15:04:46 <Zakim> -nmihindu
15:04:48 <Zakim> -TallTed
15:04:49 <Arnaud> meeting adjourned
15:04:51 <cody> cody has left #ldp
15:04:51 <Zakim> -Sandro
15:04:54 <rgarcia> s/don to/do not/
15:04:55 <Zakim> -Arnaud
15:04:57 <Zakim> -Cody
15:05:00 <Zakim> -JohnArwe
15:05:09 <Zakim> -rgarcia
15:05:10 <Zakim> SW_LDP()10:00AM has ended
15:05:10 <Zakim> Attendees were Sandro, TallTed, JohnArwe, Arnaud, nmihindu, Cody, Ashok_Malhotra, SteveS, EricP, rgarcia
15:05:29 <Kalpa> Kalpa has left #ldp
15:46:03 <SteveS> SteveS has joined #ldp
17:08:44 <Zakim> Zakim has left #ldp
18:28:56 <SteveS> SteveS has joined #ldp
19:47:56 <SteveS> SteveS has joined #ldp
20:44:18 <cody> cody has joined #ldp