00:27:15 <jmvanel> jmvanel has joined #ldp
01:05:10 <jmv> jmv has joined #ldp
06:55:24 <RRSAgent> RRSAgent has joined #ldp
06:55:24 <RRSAgent> logging to http://www.w3.org/2013/06/20-ldp-irc
06:55:26 <trackbot> RRSAgent, make logs public
06:55:26 <Zakim> Zakim has joined #ldp
06:55:28 <trackbot> Zakim, this will be LDP
06:55:28 <Zakim> ok, trackbot; I see SW_LDP(F2F)2:30AM scheduled to start 25 minutes ago
06:55:29 <trackbot> Meeting: Linked Data Platform (LDP) Working Group Teleconference
06:55:29 <trackbot> Date: 20 June 2013
06:59:12 <nandana> nandana has joined #ldp
07:01:35 <SteveS> SteveS has joined #ldp
07:10:17 <Ashok> Ashok has joined #ldp
07:14:36 <krp> krp has joined #ldp
07:14:41 <JohnArwe> JohnArwe has joined #ldp
07:15:10 <Arnaud> agenda: http://www.w3.org/2012/ldp/wiki/F2F3#Day_3_-_Thursday_June_20
07:15:16 <Arnaud> scribe: john
07:15:19 <Arnaud> chair: Arnaud
07:18:38 <JohnArwe> Topic: Next Face to Face meeting
07:18:46 <JohnArwe> to have or not to have, that is the question
07:19:28 <JohnArwe> done soon, Last Call in July, assuming 8 weeks review period, then question is what happens next
07:19:44 <JohnArwe> better to plan for F2F and cancel if we decide it's unneeded, rather than the reverse
07:21:22 <JohnArwe> Question if we should co-locate with RDF validation WG at MIT-Boston Sept 10-11 2013, so we'd meet Thu/Fri that week (12-13th)
07:23:25 <JohnArwe> W3C Team also had asked if we're going to attend TPAC in November.
07:24:23 <krp> http://iswc2013.semanticweb.org/
07:24:40 <krp> ^ Semantic Web Conference in Sydney 21-25 Oct
07:24:49 <mesteban_> mesteban_ has joined #ldp
07:24:59 <nmihindu> http://iswc2013.semanticweb.org/
07:25:53 <Ashok> Ashok has joined #ldp
07:27:18 <JohnArwe> Resolved: tentative plan is to have F2F4 at MIT in Boston Sept 12-13, which is Thu-Fri.
07:27:40 <JohnArwe> Arnaud will ask ericp/sandro if they're OK to host
07:28:48 <JohnArwe> Topic: Issue-66
07:29:51 <bblfish> bblfish has joined #ldp
07:29:54 <bblfish> q+
07:30:24 <Arnaud> ack bblfish
07:30:24 <mielvds> mielvds has joined #ldp
07:37:25 <Arnaud1> Arnaud1 has joined #ldp
07:37:30 <mielvds> mielvds has joined #ldp
07:37:41 <bblfish> bblfish has joined #ldp
07:38:09 <SteveS> SteveS has joined #ldp
07:38:43 <nmihindu> nmihindu has joined #ldp
07:39:42 <JohnArwe> JohnArwe has joined #ldp
07:40:08 <JohnArwe> Discussion about paging stability
07:40:15 <JohnArwe> q?
07:40:34 <cody> cody has joined #ldp
07:40:38 <Ashok> Ashok has joined #ldp
07:40:41 <rgarcia> rgarcia has joined #ldp
07:42:34 <JohnArwe> Proposal from Arnaud: close Issue-66 saying we will put it on the wish list. If someone comes in with a concrete proposal that people can quickly agree to, we can still do that later.
07:42:55 <JohnArwe> i.e. for now it gets handled at the app level
07:43:02 <rgarcia> +1
07:43:07 <krp> +1
07:43:10 <SteveS> +1
07:43:11 <nmihindu> +1
07:43:18 <JohnArwe> +1
07:43:25 <mielvds> +1
07:43:56 <Arnaud1> Resolved: Close Issue-66 saying we will put it on the wish list. If someone comes in with a concrete proposal that people can quickly agree to, we can still do that later.
07:44:00 <mesteban> mesteban has joined #ldp
07:44:40 <JohnArwe> Topic: Issue-16
07:44:47 <JohnArwe> issue-16?
07:44:47 <trackbot> ISSUE-16 -- Redirection of non-information resources to BPRs -- open
07:44:47 <trackbot> http://www.w3.org/2012/ldp/track/issues/16
07:45:06 <mesteban> mesteban has joined #ldp
07:48:27 <JohnArwe> Proposal from Arnaud: close issue-16 without making any changes (as is)
07:48:44 <bblfish> +1
07:48:49 <krp> +1
07:48:52 <mesteban> +1
07:48:53 <SteveS> +1
07:49:08 <rgarcia> +1
07:49:08 <Ashok> +1
07:49:09 <nmihindu> +1
07:49:13 <mielvds> +1
07:49:18 <Arnaud> Resolved: Close issue-16 without making any changes (as is)
07:49:29 <JohnArwe> Resolved: Close Issue-16 without making any changes (as is)
07:49:50 <JohnArwe> Topic: Issue-56
07:49:52 <JohnArwe> issue-56?
07:49:52 <trackbot> ISSUE-56 -- How can clients discover LDPR PUT URLs? -- open
07:49:52 <trackbot> http://www.w3.org/2012/ldp/track/issues/56
07:51:58 <JohnArwe> 2616  10.3.4 303 See Other
07:51:58 <JohnArwe>    The response to the request can be found under a different URI and
07:51:58 <JohnArwe>    SHOULD be retrieved using a GET method on that resource. This method
07:51:58 <JohnArwe>    exists primarily to allow the output of a POST-activated script to
07:51:58 <JohnArwe>    redirect the user agent to a selected resource. The new URI is not a
07:51:58 <JohnArwe>    substitute reference for the originally requested resource. The 303
07:51:58 <JohnArwe>    response MUST NOT be cached, but the response to the second
07:51:59 <JohnArwe>    (redirected) request might be cacheable.
07:52:10 <JohnArwe> ...
07:52:11 <JohnArwe>    The different URI SHOULD be given by the Location field in the
07:52:11 <JohnArwe>    response. Unless the request method was HEAD, the entity of the
07:52:11 <JohnArwe>    response SHOULD contain a short hypertext note with a hyperlink to
07:52:11 <JohnArwe>    the new URI(s).
07:53:48 <roger> roger has joined #ldp
08:00:12 <JohnArwe> Proposal: Close Issue-56 without changing the specification.  Update Guidelines document to suggest that a 303 response of this type should include the describedby header; perhaps mention the OPTIONS pattern, but leaning against it.
08:01:12 <roger> +1
08:01:14 <cody> +1
08:01:15 <nmihindu> +1
08:01:15 <krp> +1
08:01:16 <mielvds> +1
08:01:22 <SteveS> +1
08:01:26 <rgarcia> +1
08:01:28 <mesteban> +0.5
08:01:34 <bblfish> +1 (why could the described by header not be in the initial 303 ? )
08:01:54 <Arnaud> Resolved: Close Issue-56 without changing the specification.  Update Guidelines document to suggest that a 303 response of this type should include the describedby header; perhaps mention the OPTIONS pattern, but leaning against it.
08:02:56 <Ashok_> Ashok_ has joined #ldp
08:04:24 <cody> topic: issue 37
08:05:11 <cody> The problem is that everyone has their own view of what "Data Model" and "Interaction Model" really means/implies
08:06:12 <JohnArwe> topic: issue-37
08:06:59 <bblfish> http://www.w3.org/2012/ldp/wiki/ISSUE-37
08:11:44 <JohnArwe> ashok: give me an action to work on it
08:12:00 <JohnArwe> steves: has been open for 6 months; can reassign action 53
08:12:21 <roger> Nandana: some of the issue 37 stuff will be in the primer too
08:12:26 <JohnArwe> nandana: some of the content would be appropriate for primer
08:12:53 <JohnArwe> bblfish: have wiki page with input from several (url above)
08:13:23 <bblfish> wiki page on issue-37 is here http://www.w3.org/2012/ldp/wiki/ISSUE-37
08:13:32 <JohnArwe> Proposal from Arnaud: close issue-37 as is, and let Ashok address it within the next 2 weeks as part of the normal editorial process.
08:14:29 <bblfish> +1 It's non normative issue
08:14:32 <JohnArwe> Note that this issue is not normative
08:14:39 <nmihindu> +1
08:14:57 <JohnArwe> +1
08:14:58 <SteveS> +!
08:14:58 <krp> +1
08:15:11 <SteveS> +1!
08:15:15 <roger> +1
08:15:16 <mesteban> +1
08:15:16 <rgarcia> +1
08:15:31 <Arnaud> Resolved: Close issue-37 as is, and let Ashok address it within the next 2 weeks as part of the normal editorial process of informative content.
08:16:15 <AndyS> AndyS has joined #ldp
08:17:00 <Ashok_> Hi Andy ... you there?  I have a question
08:21:49 <rgarcia> rgarcia has joined #ldp
08:30:32 <AndyS> Hello.
08:30:50 <AndyS> Askok_ : was that this "Andy"?
08:31:06 <AndyS> Ashok_ : was that this "Andy"?
08:31:12 <roger> everyone is coffee'ing ....
08:31:14 <roger> apart from me
08:33:54 <Ashok_> Yes ... we were talking about RDF patch and you had an interesting idea about how to do it
08:34:05 <Ashok_> ... did you make any progress on it?
08:34:37 <SteveS> SteveS has joined #ldp
08:35:36 <JohnArwe> everyone was here at 9 too... apart from roger ;-)
08:35:38 <AndyS> TriG based formats (or Talis changesets) don't scale, dont work with bnodes and don't work with datasets (latter less of a problem for LDP).
08:35:47 <AndyS> and they don't stream so scaling problems.
08:36:21 <AndyS> This analysis has lead to (early draft alert!) http://cwiki.apache.org/confluence/display/JENA/RDF+Delta
08:36:48 <Ashok_> Sandro said that.  So, that's where we are?
08:37:00 <AndyS> which is little more than n-triples + a add/delete marker.
08:37:02 <JohnArwe> Topic: Issue-62
08:37:06 <bblfish> http://www.w3.org/2012/ldp/track/issues/62
08:37:16 <JohnArwe> Roger's issue.  We wonder where his proposal, due yesterday, is.
08:37:25 <JohnArwe> Currently labeled "at risk"
08:37:29 <cody> cody has joined #ldp
08:37:48 <JohnArwe> Roger objects to dropping w/o more discussion.
08:38:06 <JohnArwe> http://piratepad.net/ge4VKecQWa
08:38:46 <Ashok> Ashok has joined #ldp
08:38:54 <AndyS> That's where I am ... this is being developed for a need we have but I'm more than happy to work in LDP on it.
08:39:31 <Ashok> ok ... I think It's important, that's why I'm asking
08:40:25 <AndyS> Great - let me know what the WG thinks after the F2F discussions.
08:41:38 <JohnArwe> issue-62?
08:41:38 <trackbot> ISSUE-62 -- Creating containers associated with LDPRs -- open
08:41:38 <trackbot> http://www.w3.org/2012/ldp/track/issues/62
08:44:48 <JohnArwe> SteveS: application can do that outside of LDP
08:45:12 <JohnArwe> Arnaud: spec as it is today allows several ways... enumerates
08:45:23 <JohnArwe> ...App level, as SteveS said
08:45:34 <JohnArwe> ...PUT to create the container
08:45:57 <JohnArwe> Arnaud: natural for people to read spec and ask how the starting point came to be.
08:46:24 <JohnArwe> bblfish: the top level "off the screen" resource could be a container itself.
08:46:46 <JohnArwe> roger: my assumption is that the starting point is a just an LDPR, not necessarily an LDPC
08:47:14 <JohnArwe> pasting example from pirate pad area for minutes...
08:47:25 <JohnArwe> Starting with
08:47:25 <JohnArwe> <>
08:47:25 <JohnArwe>    a o:NetWorth ;
08:47:25 <JohnArwe>    o:netWorthOf <http://example.org/users/JohnZSmith>;\
08:47:25 <JohnArwe> ... which doesn't have the liabilities and assets containers :(
08:47:34 <JohnArwe> If I want a way to create liabilities and assets, I need a way to make some LDPCs
08:47:34 <JohnArwe> <>
08:47:34 <JohnArwe>    a o:NetWorth, ldp:Container;
08:47:34 <JohnArwe>    o:netWorthOf <http://example.org/users/JohnZSmith>;
08:47:34 <JohnArwe>    ldp:membershipSubject <>;
08:47:34 <JohnArwe>    ldp:membershipPredicate ldp:has_ldpc.
08:47:44 <JohnArwe> Now after POSTing the following to <>
08:47:44 <JohnArwe>    a ldp:Container;
08:47:44 <JohnArwe>    ldp:membershipSubject <.>;
08:47:44 <JohnArwe>    ldp:membershipPredicate o:asset.
08:47:55 <JohnArwe> Now he gets
08:47:56 <JohnArwe> <>
08:47:56 <JohnArwe>    a o:NetWorth, ldp:Container;
08:47:56 <JohnArwe>    o:netWorthOf <http://example.org/users/JohnZSmith>;
08:47:56 <JohnArwe>    ldp:membershipSubject <.>;
08:47:56 <JohnArwe>    ldp:membershipPredicate ldp:has_ldpc;
08:47:56 <JohnArwe>    ldp:has_ldpc <assetContainer/>
08:47:56 <JohnArwe> <assetContainer/>
08:47:57 <JohnArwe>    a ldp:Container;
08:47:57 <JohnArwe>    ldp:membershipSubject <.>;
08:47:57 <JohnArwe>    ldp:membershipPredicate o:asset.
08:48:18 <JohnArwe> comparing to ex 3 in LDP spec
08:49:59 <bblfish> hi
08:50:14 <JohnArwe> Arnaud: what is the issue then?
08:52:23 <JohnArwe> Roger: not saying its the best solution, but once you create from the LDPR I get an answer for the other issue I gave up on (links from LDPRs to the containers they use to manage sets of domain-specific links)
08:54:00 <rgarcia> rgarcia has joined #ldp
08:54:25 <JohnArwe> SteveS: the RDF links in the membership triples do contain the information, although the links are in the opposite direction. if the server returns the container's triples (including membership triples) along with the LDPR's representation, you have what you need.
08:54:51 <JohnArwe> Arnaud: are you convinced the spec itself has no gap?  perhaps we do need deployment info.
08:55:43 <JohnArwe> steves: (1) uber container that server stitches together (2) morph LDPR into container ...server has to allow that (3) PUT-create as you showed in pad.  Spec allows all of those today.
08:56:18 <JohnArwe> Arnaud: if this is about how elegant the solutions are vs their feasibility, we could also put it on the wish list
08:56:46 <JohnArwe> ...appear to have consensus in the room that primer/guidelines should clarify this set of possibilities
08:58:20 <JohnArwe> Roger: 4th possibility is templatization ... LDPR links to template containers with no URLs, and to another resource that exists and is capable of instantiating templates.... that is what we did pre-LDP
08:58:34 <JohnArwe> ... if looking to close this issue, pls action deployment guid
08:59:46 <JohnArwe> Proposal from Arnaud: close issue-62 by updating the best practices or primer or deployment guide to enumerate what the spec allows for solving this
08:59:55 <mielvds> +1
08:59:58 <JohnArwe> ...e.g. as shown in (1)-(3) above
09:00:02 <rgarcia> +1
09:00:04 <nmihindu> +1
09:00:06 <bblfish> +1
09:00:07 <SteveS> +1
09:00:08 <roger> +1
09:00:12 <krp> +1
09:00:56 <Arnaud> Resolved: Close issue-62 by updating the best practices or primer or deployment guide to enumerate what the spec allows for solving this
09:01:56 <Zakim> SW_LDP(F2F)2:30AM has now started
09:01:57 <bblfish> Issue-51?
09:01:57 <trackbot> ISSUE-51 -- Linking from a Resource to its Containers (not the containers the resource is in) -- open
09:01:57 <trackbot> http://www.w3.org/2012/ldp/track/issues/51
09:01:57 <JohnArwe> Topic: Issue-51
09:02:03 <Zakim> +[GVoice]
09:02:25 <bblfish> q+
09:02:35 <JohnArwe> coming ericp
09:03:00 <JohnArwe> people here admiring your enthusiasm (or insomnia)
09:03:04 <SteveS> You can get the relation today, using the example from before as: <assetContainer/> ldp:membershipSubject <.>.
09:03:13 <Zakim> +m
09:03:18 <bblfish> q?
09:03:47 <rgarcia> ericP, we just called
09:04:21 <bblfish> <> a ldp:Container;  ldp:created <child/> . <child/> a ldp:Container .
09:04:37 <SteveS> q+
09:04:46 <SteveS> ack bblfish
09:05:28 <roger> @SteveS, does a child know who it's parent is, or is it a parent who knows who it's child is ?
09:05:42 <JohnArwe> bblfish: is that it?  roger: no (no, no, no, no)
09:06:12 <nandana> nandana has joined #ldp
09:06:49 <bblfish> Ah, I missed this notion of { <.> ldp:hasContainer <assetContainer>. }
09:07:19 <bblfish> q+
09:07:20 <JohnArwe> Roger: I was looking for < LDPR , ... , LDPR's container > but see now that same info exists with subj/obj swapped
09:07:25 <Arnaud> ack steves
09:10:00 <JohnArwe> Discussion about separation of "interaction-related" triples and "domain triples", which people prefer/loathe to varying degrees based on mental models.
09:10:25 <JohnArwe> Roger mentions the evil blank-node word.  scribe ducks.
09:11:05 <JohnArwe> Henry: use ldp:contains, that's the right answer
09:11:22 <JohnArwe> Arnaud separates the combatants
09:12:53 <stevebattle4> stevebattle4 has joined #ldp
09:17:44 <JohnArwe> Roger reminds people that he's thought LDPRs were on top since before Christmas, and this shows through in his examples from back then, although did not expect anyone to support such a change.
09:18:11 <JohnArwe> ...Henry and Miel see how that could work, and might even in a perfect world be preferable.
09:19:22 <bblfish> q?
09:19:22 <JohnArwe> Roger: Containers are very constrained, cannot add just any properties.  Mass confusion and shouts of "what about non-member properties then" from the crowd; constraint on contrainers is there's only one membership triple pattern.
09:19:27 <SteveS> q+
09:20:01 <JohnArwe> Roger: we had 'value set' at F2F2, never really took hold
09:20:16 <JohnArwe> many respond with 'that's just a naming problem'
09:20:30 <SteveS> ack bblfish
09:20:39 <JohnArwe> Henry: containers are just about creating members, and when you do that other relations get added elsewhere
09:20:50 <JohnArwe> Roger: disagree with that strongly
09:20:57 <Arnaud> ack steves
09:21:00 <JohnArwe> ...several others chime in
09:21:37 <JohnArwe> ...we have had the "are containers [just] about create, or about listing membership" several times already at this F2F
09:22:14 <JohnArwe> Arnaud: so can we close the issue?
09:22:39 <bblfish> I said Containers are very simple at its core: they just create resources ( and describe metadata on the created resources or on in the future restrictions on the container, as well as perhaps how creating a resource creates a relation to something else )
09:22:40 <JohnArwe> Roger: we spend a half hour?  I expected it to take 2 mins.  [laughing]  I was ready to close it before.
09:24:15 <SteveS> informative part of spec says: "…few simple non-member properties are retrieved. In real world situations more complex cases are likely, such as those that add other predicates to containers, for example providing validation information and associating SPARQL endpoints. [SPARQL-QUERY]"
09:25:06 <JohnArwe> Proposal: Close issue-51 without normative changes to specification.  Editors may make informative changes to text around containers, and may (assume we do) need more info in companion documents.  Need to clarify that containers can be bigger than the minimum we describe, so you can do other things; e.g. you can have an LDPR that is also an LDPC.
09:25:37 <bblfish> background talk: an ldlc is a controller
09:25:46 <JohnArwe> s/ldlc/LDPC/
09:26:19 <nmihindu> s/background talk/cody
09:26:56 <SteveS> +1
09:27:01 <rgarcia> +1
09:27:02 <nmihindu> +1
09:27:02 <krp> +1
09:27:04 <roger> +1
09:27:05 <mesteban> +1
09:27:10 <Ashok> +1
09:27:19 <JohnArwe> editors happy to accept citations of sections where readers might be likely to read too narrowly.
09:27:37 <bblfish> +1
09:27:43 <Arnaud> Resolved: Close issue-51 without normative changes to specification.  Editors may make informative changes to text around containers, and may (assume we do) need more info in companion documents.  Need to clarify that containers can be bigger than the minimum we describe, so you can do other things; e.g. you can have an LDPR that is also an LDPC.
09:27:47 <mielvds> +1
09:28:48 <cody> I need to get my group photo before people start breaking for airport.
09:28:54 <JohnArwe> @steveb: ashok suggests you look at issues closed yesterday, one of your loved ones was in there.
09:29:00 <Ashok> stevebattle are you on the phone?
09:29:20 <JohnArwe> ...the minutes are available already, although arnaud might not have finished polish-editing them
09:29:26 <JohnArwe> Topic: Issue-50
09:29:29 <JohnArwe> issue-50?
09:29:29 <trackbot> ISSUE-50 -- Intuitive Containers: better support for relative URIs -- open
09:29:29 <trackbot> http://www.w3.org/2012/ldp/track/issues/50
09:30:09 <JohnArwe> bblfish: you can use relative URIs in POST, but cannot use others like . and .. because you don't know the path the server will choose
09:32:38 <roger> i think this cannot be in the spec, but, why not something for the deployment guide ?
09:33:02 <Ashok> q+
09:33:11 <JohnArwe> ...suggesting adding subclass whose server-chosen URI will be the container's URI, a slash (if not present on the container's URI), and then a single URI path segment (as defined in RFC 3986), full stop.
09:33:21 <roger> +q
09:33:39 <krp> http://piratepad.net/ge4VKecQWa
09:33:49 <JohnArwe> @roger, spec allows a server to behave that way but LDP gives no way for a server to communicate that intent
09:34:13 <roger> that why it is guideline only !
09:34:38 <JohnArwe> @roger: not disagreeing, just clarifying what spec-as-it-stands permits
09:34:41 <Arnaud> ack roger
09:35:05 <JohnArwe> Personally, I'm allergic to adding any hard constraints on how servers construct URIs
09:35:37 <JohnArwe> Roger: do see use in this, just think it's guidelines not normative
09:36:10 <Arnaud> ack ashok
09:36:24 <JohnArwe> Ashok: what is base URI for these relative URIs?
09:37:17 <SteveS> See new spec section: "5.4.8.1 For RDF representations, LDPC servers must assign the base-URI for [RFC3987] relative-URI resolution to be the URI of the created subject resource."
09:38:13 <krp> q+
09:38:50 <roger> +q
09:38:54 <JohnArwe> bblfish: all relative to the document/resource created.  the problem is that LDP allows the newly created resource's uri to be anything (including on another server).  I want it to be within this container, so that if a client uses the .. notation in the input the results are fully predictable.
09:39:30 <JohnArwe> kevin: good impln choice, in guidelines.
09:39:50 <JohnArwe> bblfish: that's why I want a subclass
09:40:30 <JohnArwe> kevin: so why isn't that uri convention subclass something in your namespace?
09:40:53 <JohnArwe> bblfish: idea is very simple, subclass adds this convention.
09:41:10 <Arnaud> ack krp
09:41:14 <JohnArwe> kevin: you're talking about specifying this convention in the spec however
09:41:51 <JohnArwe> roger: how does this work with membership triples in the general case?
09:42:04 <Arnaud> ack roger
09:42:13 <JohnArwe> bblfish: same way; relative uri would be different
09:43:15 <JohnArwe> ... you make a good point; many of the current examples assume you allocate URIs this way
09:43:44 <JohnArwe> others point out that spec only uses . when creating resources
09:44:17 <SteveS> What would a server do with:
09:44:26 <JohnArwe> bblfish: you cannot use . on create to speak about your container if you assume the URIs can be fully arbitrary
09:44:37 <SteveS> POST with a Slug of foo/bar/abc
09:45:47 <JohnArwe> nandana: not disputing it's a requirement, but you do have workaround already.  you can add the triples you need after create finished and the resource's URI is known
09:46:10 <Zakim> +Sandro
09:47:10 <nmihindu> relative uri patterns - http://www.rfc-editor.org/rfc/rfc1808.txt
09:47:18 <JohnArwe> Sandro, not sure if you're a 3986 weenie in particular, if so you joined in the middle of a spirited discussion of issue 50
09:48:04 <JohnArwe> careful nandana - 1808 superseded by 3986
09:48:06 <SteveS> q+
09:48:29 <Arnaud> ack steves
09:48:34 <nmihindu> JohnArwe, yeah. Just noticed your link. My rfc searches are not so good apparently :)
09:48:38 <JohnArwe> Arnaud: not a gap in the spec; personally do not see new class being worthwhile.
09:49:26 <JohnArwe> steves: could we fix this with more guidance on how servers process slug?  or would we need one?
09:49:38 <JohnArwe> bblfish: the slug value could not contain /s
09:50:08 <JohnArwe> steves: see usefulness, kind of late, have the workaround nandana pointed out so "not now" is my preference
09:50:26 <JohnArwe> Arnaud: add to wish list while bblfish gets more impln experience?
09:50:54 <JohnArwe> bblfish: can we add it to ontology now so the URL is stable?
09:51:12 <JohnArwe> steves: would have to mark it unstable
09:51:19 <JohnArwe> bblfish: ok with unstable
09:52:26 <JohnArwe> ashok: would this new kind of container only allow creates via post?
09:53:01 <JohnArwe> John clarifies: POST narrorwly, or also PUT/PATCH-create?  Ashok: all 3
09:53:34 <JohnArwe> discussion - somewhat uneasy reserving name, creates expectation wg will deliver on it someday when we might not
09:54:20 <JohnArwe> Proposal: close issue-50 without change to normative spec, editors to check examples to any untoward use of relative uris, and companion documents to discuss this common pattern for allocating URIs
09:54:37 <bblfish> +1
09:54:38 <JohnArwe> s/to any/to find any/
09:54:38 <krp> +1
09:54:41 <cody> +1
09:54:43 <roger> +1
09:54:44 <rgarcia> +1
09:54:45 <SteveS> +1
09:54:46 <mesteban> +1
09:54:46 <ericP> +1
09:54:47 <JohnArwe> +1
09:54:50 <nmihindu> +1
09:54:52 <mielvds> +1
09:54:54 <Arnaud> Resolved: Close issue-50 without change to normative spec, editors to check examples to any untoward use of relative uris, and companion documents to discuss this common pattern for allocating URIs
09:55:34 <roger> so maybe, the LDPC is the controller, the LDPR is the view, and graph on the server is the model ?
09:55:41 <bblfish> q?
09:55:43 <JohnArwe> Topic: Issue-78
09:55:46 <JohnArwe> issue-78?
09:55:46 <trackbot> ISSUE-78 -- inferencing levels -- open
09:55:46 <trackbot> http://www.w3.org/2012/ldp/track/issues/78
09:56:34 <bblfish> ldp:membershipPredicate [ owl:inverseInverseOF foaf:loves ]
09:56:45 <bblfish> <> ldp:membershipPredicate [ owl:inverseInverseOF foaf:loves ]
09:56:53 <JohnArwe> bblfish: if you wanted to say [what bblfish posted above]
09:57:13 <ericP> the reason we don't use the OWL idiom for inverseMembershipPredicate is 'cause we're wusses and afraid to use the word "OWL"
09:57:43 <JohnArwe> bblfish: people reacted to that by saying "ick that drags OWL" and then Sir Robin soiled his armor
09:58:41 <JohnArwe> eric: slightly more parsing but would still be using standard terms
09:59:33 <JohnArwe> bblfish: intelligent clients can do as much inferencing as they want, question is how much to we require?
10:01:08 <JohnArwe> arnaud: explains background ... members have been saying we don't want to require any reasonsers; bblfish feels that membershipPredicate etc is just a form of inferencing, not all members agree (in the sense that it's not requiring RDF/OWL reasoning)
10:02:26 <JohnArwe> ericp: do we need text = this document includes/defines a number of predicates/terms, and every client/server interaction should directly include those triples instead of relying on clients implementing inferencing to derive some of the triples from representations.
10:03:17 <JohnArwe> ... i.e. no inferencing required to get at data in the payload that's mentioned in the LDP spec.
10:05:12 <JohnArwe> ...it's fine if implementations want to use RDFS in "their" portions of the payloads, just not required to interpret the LDP portions
10:06:02 <JohnArwe> discussion of whether this is requirement or best practice ... unanimous(?) consensus that it's a normative reqt for client interop
10:06:39 <JohnArwe> kevin notes that having text in spec does not prevent us from also having text in informative companion docs
10:08:17 <ericP> PROPOSED: close issue-38 with normative text like "separating the payload into an LDP-specified part and an application part, the LDP-specific part of LDP messages MUST NOT require inference."
10:08:19 <cody> cody has joined #ldp
10:08:34 <ericP> PROPOSED: close issue-78 with normative text like "separating the payload into an LDP-specified part and an application part, the LDP-specific part of LDP messages MUST NOT require inference."
10:08:45 <rgarcia> +1
10:08:49 <SteveS> +1
10:08:50 <ericP> +1
10:08:53 <JohnArwe> +1
10:08:54 <roger> roger has joined #ldp
10:08:54 <nmihindu> +1
10:09:05 <bblfish> +1 "must not require inferencing on the client for the protocol to work successfully"
10:09:11 <roger> +1
10:09:18 <mesteban> +1
10:09:51 <cody> +1
10:10:12 <Arnaud> Resolved: close issue-78 with normative text like "separating the payload into an LDP-specified part and an application part, the LDP-specific part of LDP messages MUST NOT require inference."
10:10:28 <stevebattle4> stevebattle4 has joined #ldp
10:10:48 <mielvds> +1 (showing support anyway, ha)
10:10:56 <krp> +1
10:12:00 <Zakim> +SteveBattle
10:14:25 <JohnArwe> Topic: issue-71
10:14:29 <JohnArwe> issue-71?
10:14:29 <trackbot> ISSUE-71 -- No membershipSubject or membershipPredicate -- open
10:14:29 <trackbot> http://www.w3.org/2012/ldp/track/issues/71
10:15:23 <JohnArwe> pause for group picture
10:16:06 <JohnArwe> pardon, we're figuring out how many engineers it takes to take 1 group photo
10:17:07 <JohnArwe> kevin leaves for the day
10:17:26 <JohnArwe> bblfish: back to piratepad for example to get feedback
10:19:16 <JohnArwe> ... basic idea is to wrap membershipXXX predicates in a blank node, to allow >1 such relation in the future
10:21:23 <JohnArwe> ...i.e. to do that now in LDP, rather than (in the future when someone wants >1 relation) having one syntax for the first one and a different syntax for subsequent ones; you'd need a different syntax, like a blank node to wrap the membershipXXX relations since they occur in pairs/triples
10:21:49 <JohnArwe> for example (snapshot from pirate pad)
10:21:50 <JohnArwe> <> a ldp:Container;
10:21:50 <JohnArwe>     ldp:rel [ ldp:membershipPredicate foaf:knows;
10:21:50 <JohnArwe>                 ldp:membershipSubject <#wife>;
10:21:50 <JohnArwe>                 ldp:membershipObject foaf:primaryTopic ],
10:21:50 <JohnArwe>               [ ldp:membershipPredicate foaf:knows;
10:21:50 <JohnArwe>                 ldp:membershipSubject <#me>;
10:21:50 <JohnArwe>                 ldp:membershipObject foaf:primaryTopic ] .
10:23:38 <JohnArwe> bblfish: this might also solve the [already closed, after yesterday] monotonicity problem in a different way
10:23:40 <stevebattle4> Is Henry's argument one of reductio ad absurdum? - ie. this is so silly we should do away with it entirely - I can't gauge the level of irony remotely.
10:23:56 <JohnArwe> no irony that I can detect
10:24:34 <JohnArwe> my sense is that he's pursuing a single common syntax for >=1
10:25:07 <JohnArwe> q+ roger
10:26:41 <nmihindu> JohnArwe, it seems so. It is more generic and extensible. It would be nice to see what are the use cases for this.
10:27:44 <Arnaud> ack roger
10:27:52 <nmihindu> q+
10:28:09 <JohnArwe> raul: ...lost question sorry
10:28:26 <stevebattle4> Henry - you've convinced me we should do away with membershipXXX
10:28:58 <JohnArwe> john: if client uses domain relations to enumerate members, would it have to union them or would either work?
10:29:02 <Arnaud> ack nmihindu
10:29:46 <SteveS> q+
10:30:36 <JohnArwe> nandana: to keep track of what a container created, and these would be "other relations" outside of LDP
10:31:25 <Arnaud> ack steves
10:31:28 <JohnArwe> bblfish: agree; notes that he feels we already have this problem now
10:32:32 <JohnArwe> Steves: do not see strong need for >1 based on my impln experience.  client can always create those other relations.  someone might next make the leap to insert a template generation rule so a bunch of side effects.
10:33:18 <JohnArwe> ericp: I would have written all these implications (membershipXXX) in OWL because the interactions are getting complex.
10:33:34 <JohnArwe> bblfish: we're no more complicated than what we have today
10:33:45 <JohnArwe> s/we're/this/
10:34:10 <roger_> roger_ has joined #ldp
10:34:24 <JohnArwe> ericp: what you're saying here now is that these act as conjoins (ANDs).  easy to imagine that next I want disjoints (ORs).
10:34:26 <nmihindu> ericP, +1 this is providing a contract
10:35:03 <JohnArwe> bblfish: right, had not thought that through.  no no no, ...
10:35:56 <JohnArwe> ericp: one interpretation is ... another...
10:36:09 <JohnArwe> bblfish: I can see why this is confusing, bug in the on-the-fly example
10:37:23 <JohnArwe> arnaud: issue in front of us is whether or not to remove membershipXXX, not how to add more of them.  can we agree on how to deal with the issue in front of us (remove what's there or not), and assume we think through the extensions in a future version?
10:38:16 <JohnArwe> bblfish: this helps clarify what you're doing.  this is much more general than container membership, we spent a lot of time misunderstanding each other already.
10:38:43 <JohnArwe> Arnaud: companion docs (Primer etc) should handle this, late in version 1 to add this.
10:38:53 <JohnArwe> bblfish: same as we have now
10:38:57 <JohnArwe> roger: does not work for me
10:39:02 <JohnArwe> raul: concept is different
10:39:38 <JohnArwe> Arnaud: if you want to open a new issue [soft sobs of "no, no" heard on phone]
10:40:42 <JohnArwe> bblfish: if you object to the general form and we still have membershipXXX, not especially a problem
10:40:57 <Arnaud> PROPOSAL: Close Issue-71, no changes, all related issues have been closed.
10:41:05 <rgarcia> +1
10:41:06 <bblfish> +1
10:41:07 <roger> +1
10:41:09 <mesteban> +1
10:41:09 <mielvds> +1
10:41:15 <SteveS> +1
10:41:17 <nmihindu> +1
10:41:19 <cody> +1
10:41:20 <stevebattle4> 0 (I would cull membershipXXX)
10:41:23 <JohnArwe> +1
10:41:31 <Arnaud> Resolved: Close Issue-71, no changes, all related issues have been closed.
10:41:37 <ericP> +1
10:41:58 <JohnArwe> Topic: issue-58
10:42:00 <JohnArwe> issue-58?
10:42:00 <trackbot> ISSUE-58 -- Property for asserting that complete description of members is included in LDPC representation -- open
10:42:00 <trackbot> http://www.w3.org/2012/ldp/track/issues/58
10:48:14 <Arnaud> options previously put forward: http://lists.w3.org/Archives/Public/public-ldp-wg/2013May/0085.html
10:48:37 <JohnArwe> re-loading of wetware caches takes a few minutes
10:52:01 <roger> +q
10:53:42 <JohnArwe> clarifying leads to info that bblfish is not objecting to the idea of avoiding the GETs, it's the form by which the examples did that.
10:53:46 <Arnaud> ack roger
10:54:09 <JohnArwe> ericp can you recap your stmt?
10:54:50 <nmihindu> +q to ask whether this is a best practices issue i.e. if that servers should not inline when truth changes based on that
10:55:50 <Arnaud> ack nmihindu
10:55:50 <Zakim> nmihindu, you wanted to ask whether this is a best practices issue i.e. if that servers should not inline when truth changes based on that
10:56:32 <JohnArwe> 1 hour lunch break folks
10:56:33 <Zakim> -m
10:56:39 <Zakim> -SteveBattle
10:56:46 <Zakim> -ericP
10:56:48 <Zakim> SW_LDP(F2F)2:30AM has ended
10:56:48 <Zakim> Attendees were ericP, m, Sandro, SteveBattle
10:57:06 <roger> my question is that, in ex 3 of the spec, is the defs of the LDPC's considered as "inlining" - just to clarify.
10:57:16 <roger> ... for after lunch.
11:09:39 <mesteban__> mesteban__ has joined #ldp
11:41:49 <krp> krp has joined #ldp
12:03:16 <bhyland> bhyland has joined #ldp
12:06:30 <Zakim> SW_LDP(F2F)2:30AM has now started
12:06:37 <Zakim> +SteveBattle
12:09:01 <Zakim> +[GVoice]
12:29:43 <Zakim> +m
12:29:44 <cody> cody has joined #ldp
12:29:46 <rgarcia> rgarcia has joined #ldp
12:31:01 <Ashok> Ashok has joined #ldp
12:32:43 <SteveS> SteveS has joined #ldp
12:34:01 <JohnArwe> JohnArwe has joined #ldp
12:34:09 <JohnArwe> Scribe: Miel
12:34:23 <bblfish> bblfish has joined #ldp
12:34:37 <roger> roger has joined #ldp
12:35:29 <mielvds> Arnaud: resume with issue 58
12:36:05 <mielvds> Ashok: I recommend to agree on having an indicator on the container and on each member
12:36:43 <mielvds> JohnArwe: inline like in the examples is semantically broken from a semweb view
12:37:09 <mielvds> … henry and I discussed it over lunch, we found a way
12:37:50 <mielvds> bblfish: looking at the pad. Essentially everything that does ldp:memberInlined <a1>, <a2>...
12:38:14 <mielvds> …if a1 and a2 are somehow contradictory, this does not work
12:38:43 <mielvds> second problem is that when merging information, you don't know which information came from which, unless they are disjunct
12:39:20 <mielvds> EricP: no machine can enforce that nothing is contradictory
12:39:41 <mielvds> bblfish: remove memberinline and quote it
12:40:48 <mielvds> … to the pad!
12:40:51 <mielvds>  <a2> log:semantics {
12:40:51 <mielvds>    <a2>
12:40:51 <mielvds>       a o:Bond;
12:40:51 <mielvds>       o:value 20000.
12:40:51 <mielvds>  }
12:41:29 <nmihindu> log semantics -> http://www.w3.org/2000/10/swap/doc/Reach
12:41:52 <mielvds> using log:semantics to quote this. client can say: I believe this and take it out
12:42:12 <mielvds> Arnaud: we don't have a syntax supporting this, so it's a showstopper
12:42:50 <mielvds> Atom also quotes the content and adds limited metadata
12:43:00 <stevebattle4> q+
12:43:06 <mielvds> Arnaud: can you only do this by only quoting the whole content?
12:43:49 <mielvds> bblfish: you create a relation ldp:content to quote everything
12:43:56 <Arnaud> ack steveb
12:44:10 <ericP> q+
12:44:11 <mielvds> stevebattle4: would it be quicker to have a query parameter?
12:44:34 <JohnArwe> TallTed at F2F2 refused to admit anything less than member-granularity in-lining
12:44:35 <Arnaud> ack eric
12:44:54 <stevebattle4> eg. http://mycontainer?inlined
12:45:01 <SteveS> q+
12:45:19 <mielvds> EricP: the server has the best knowledge on this; if we look at a controlled system like bugtrakcing there is no issue
12:45:33 <mielvds> clients can tell where triples come from
12:45:41 <mielvds> the issue comes up with generic triple stores
12:45:41 <JohnArwe> s/kcing/cking/
12:45:51 <SteveS> FYI, client requested "inlining" is on wish list http://www.w3.org/2012/ldp/wiki/LDPNext#Embedded_representations
12:45:57 <mielvds> it can assert statements about resources that are not in its control
12:47:09 <mielvds> if you constrain the problem to risk-free cases only, we will end up with stating 'here is safe to inline', and others will be communicated with media type
12:47:31 <mielvds> bblfish: bu example is more complex, they can contain info about other resources
12:48:01 <nmihindu> bblfish,  The thread on the turtle data type discussion on the semantic-web@w3.org might be relevant here as well http://lists.w3.org/Archives/Public/semantic-web/2013May/0194.html
12:48:01 <mielvds> Arnaud: quetion I lost track of: is this application dependent question?
12:48:13 <JohnArwe> s/quetion/question/
12:48:44 <mielvds> bblfish: if you get the quotation right, it will always be safe
12:48:50 <roger> +q
12:49:14 <SteveS> q-
12:49:22 <Arnaud> ack steves
12:49:32 <bblfish> q?
12:49:33 <Arnaud> ack roger
12:49:48 <mielvds> roger: I said this before: inlining is about any resource, not only containers
12:50:13 <mielvds> linked data community  should have some answer. We can do it for any resource
12:50:17 <SteveS> q+
12:50:23 <mielvds> it's a generic requirement
12:50:44 <stevebattle4> And we might specify an inlining depth
12:50:51 <stevebattle4> snap!
12:50:52 <Arnaud> ack steves
12:50:53 <mielvds> Arnaud: the mapping between the rdf resources and the webresources are the problem here
12:51:17 <JohnArwe> depth is orthogonal; nothing on the table talks about how clients request this
12:51:29 <ericP> there is still a large class of resources which can be safely inlined.
12:51:51 <ericP> the question is whether we want to standardize a way for them to do that or let them invent it on their own.
12:52:02 <JohnArwe> the question here is how the server tells clients which resources have been in-lined.  that is a flat list, regardless of how the server constructed its list.
12:52:21 <Arnaud> q?
12:53:05 <mielvds> bblfish: I think there is a case where inlining is wanted
12:53:15 <roger> +q
12:53:28 <stevebattle4> This seems to point towards resource-centric inlining metadata, that works for both LDPC and LDPR.
12:53:48 <mielvds> saying something about a resource defined somewhere else is important
12:54:05 <mielvds> fully inlining however
12:54:23 <mielvds> Arnaud: this does not say its about always fully inlined
12:54:37 <ericP> sandro, i think your reading is accurate and that we both understand the risks; i just think that it's worth giving folks more rope.
12:54:53 <mielvds> bblfish: if one uses this, you need more information on the dangers
12:55:13 <mielvds> if you are not familiar with linked data, ..
12:55:40 <JohnArwe> q+
12:55:45 <ericP> i think people are going to invent this semantics privately anyways; we may as well provide a standard handle for it
12:56:03 <mielvds> Arnaud: can't we have this example in the spec?
12:56:10 <mielvds> example 5
12:56:48 <mielvds> Arnaud: it seems it would be reasonable to have a resolution for danger warning in best practices document
12:57:50 <mielvds> John: the spec could include ldp server should/must not do inlining if they meet contraints
12:58:13 <mielvds> Arnaud: which normative section do we have now? => none
12:58:30 <mielvds> JohnArwe: this was the proposal
12:59:16 <mielvds> … at a minimum: "here are the problems that can arise" added to were the spec this introduces this
12:59:25 <Arnaud> ack roger
12:59:30 <JohnArwe> q-
12:59:50 <mielvds> roger: pierre-antoine had a proposal that was pretty good
12:59:54 <ericP> JohnArwe:'s text sounds good to me
13:00:23 <mielvds> JohnArwe: I thing that's a syntax q, not a semantics q (what is the case here)
13:00:43 <mielvds> roger: he had an argument contradicting this
13:01:12 <mielvds> … networth linking to container or inverse
13:01:18 <mielvds> are they inlined?
13:01:41 <mielvds> if you are linking to the container, it makes more sens to call that inlined
13:02:09 <mielvds> you not inlining something you are not pointing to, because you're not pointing to it
13:02:48 <mielvds> Arnaud: to clarify, there is a more fundamental issue behind this
13:03:14 <mielvds> Arnaud: seperate this, let's decide on the concept of inlining
13:03:40 <mielvds> Arnaud: we can have a best practice, baware OR we can have an informative section in the spec warning people
13:03:56 <mielvds> sould that address bblfish concerns?
13:04:01 <JohnArwe> s/seperate/separate/
13:04:04 <ericP> simplest failure mode: <C> ldp:membershipPredicate ldp:membershipPredicate ; ldp:membershipPredicate <r1> .
13:04:12 <JohnArwe> s/baware/beware/
13:04:17 <JohnArwe> s/sould/should/
13:04:48 <Arnaud> PROPOSAL: Add an informative section on the possible dangers of inlining resources
13:04:54 <rgarcia> +1
13:04:57 <ericP> +1
13:04:58 <mielvds> +1
13:05:04 <nmihindu> +1
13:05:05 <stevebattle4> +1
13:05:10 <cody> +1
13:05:10 <JohnArwe> +1
13:05:37 <roger> +1
13:05:50 <SteveS> +1
13:05:58 <bblfish> +1
13:06:02 <Arnaud> Resolved: Add an informative section on the possible dangers of inlining resources
13:06:25 <JohnArwe> ericp's example reminds me of contests to see how much function can be included on a single source line (usually of C)
13:06:30 <mielvds> Arnaud: now we can go back to issue 58
13:07:00 <ericP> JohnArwe, would you be willing to judge an obfuscated RDF contest?
13:07:22 <mielvds> Arnaud: Do we do anything if I want to know if I got everything
13:07:34 <mielvds> Arnaud: we had several proposals
13:07:39 <JohnArwe> @ericp, sure, I like pain.  although I rather thought that was a large component of the last 3 elapsed-time days
13:07:56 <ericP> q
13:08:52 <mielvds> Arnaud: proposal is all or nothing for all members
13:09:47 <mielvds> JohnArwe: if we do anything with this, make it at risk, but I want it in there for scaling
13:10:26 <Arnaud> s/proposal/original proposal/
13:11:16 <mielvds> ericP: we arived to the conclusion that the flag does not introduce more danger than before
13:11:37 <mielvds> s/arived/arrived/
13:11:56 <mielvds> riger: this is still container specific...
13:12:24 <mielvds> JohnArwe: this could be a list saying: you have all the triples of these resources
13:13:01 <Zakim> +Sandro
13:14:49 <stevebattle4> Alternatively, you could include the eTag for an LDPR so that the client can sniff the eTag for a resource and not re-download if it has all the data already. Even an inlined resource might change and we need to re-download.
13:15:56 <mielvds> bblfish: it is a page saying something about this resource
13:16:12 <mielvds> roger: you can't know if it is inlined
13:16:28 <mielvds> bblfish: you can only know when you use quotation
13:16:30 <JohnArwe> Proposal: close issue-58 to add a new predicate; ldp:fullyInlinedContentForUri, the object of which is a URI for which the response representation includes all triples in the state of the resource named by the URI.  Add a second new predicate, ldp:containerFullyInlined, domain ldp:Container, saying that all its membership triple objects' URIs have been inlined (i.e. it is a container-specific shortcut for listing each member URI using the first predicate).
13:16:39 <stevebattle4> Nobody expects linked data to be quoted.
13:17:03 <stevebattle4> 0 (I don't think we understand the issue enough to decide).
13:17:07 <mielvds> in O.O. you are never dealing in different point of information, only when working with graphs and interpretations
13:17:51 <mielvds> in SPARQL graphs are an example
13:18:06 <mielvds> JohnArwe: there is a proposal, go through it!
13:18:27 <bblfish> previous resolution: inlining can loose provenance information when inlined - especially if the information overlaps. ( But even otherwise it is not clear what triples came from what resource )
13:19:23 <bblfish> ( one would need to make some very non-semanitc web constraints of how to interpret graphs - e.g.: if you said that RDF was not about graphs but about forward links between resources )
13:21:18 <JohnArwe> need to amend: domain should be either ldp:Container or ldp:Page
13:21:24 <JohnArwe> thx SteveS
13:21:58 <cody> s/SPARQL graphs/SPARQL named graphs
13:24:06 <stevebattle4> q+
13:24:58 <Arnaud> ack steveb
13:25:26 <mielvds> stevebattle: linked data can change, in general we need: do I have current version, did it change?
13:25:38 <AndyS> AndyS has left #ldp
13:25:53 <stevebattle4> Yes exactly
13:26:06 <mielvds> Arnaud: was raised before, ETag issue, it was fully inlined with this ETag
13:26:54 <mielvds> isn't it always true that you get a bunch of triples and that they change
13:27:28 <Zakim> +EricP
13:29:01 <mielvds> bblfish: easily solved with quotation, go to turtle group and ask for way to do it
13:29:08 <stevebattle4> Can't we just drop inlining - it'd be simpler.
13:29:53 <TallTed> TallTed has joined #ldp
13:30:29 <mielvds> Arnaud: 2things: 1) RDF working group is expiring, 2) limit amount of information, isn't that saying ...  subject is container
13:31:25 <mesteban__> q+
13:31:31 <stevebattle4> No inlining, no problems :)
13:31:37 <mielvds> Arnaud: looks like you're saying: do not do inlining
13:31:40 <Arnaud> ack mesteban
13:31:42 <stevebattle4> ...and no quotation either
13:32:00 <sandro> We HAVE a quotation mechanism for graphs, bblfish.   It's called RDF Datasets.
13:32:25 <sandro> ... which is the way to do inlining properly, IMHO.
13:32:52 <mielvds> mesteban: is there really a need that the contents are merged within a single graph?
13:33:31 <mielvds> why not go for HTTP solution like multipart responses
13:33:57 <mielvds> SteveS: it requires you to know entire size and chunk it
13:34:11 <Zakim> -EricP
13:34:13 <mielvds> server needs to know what the entire blob is
13:34:18 <mielvds> client needs to keep track
13:34:39 <mielvds> JohnArwe: why is this different from one chunk?
13:35:05 <mielvds> SteveS: its like paging ate byte level
13:37:10 <mielvds> Arnaud: this needs to be thought thru, that's clear
13:37:35 <mielvds> it would be unreasonable to keep building now
13:37:47 <stevebattle4> Yay to that
13:38:11 <mielvds> ashok: don't want to put it to the wishlist; people are going to inline
13:38:32 <stevebattle4> They can inline outside the spec at their own risk.
13:39:42 <mielvds> bblfish: we need an action to contact semweb community to find out how to do it
13:40:14 <mielvds> mesteban: close it now, but discuss it in the best practices!
13:41:55 <mielvds> Arnaud: can we still go with John's proposal?
13:42:35 <stevebattle4> The proposal bakes in too many misunderstandings.
13:43:06 <JohnArwe> miel: kind of last minute/hasty
13:44:32 <mielvds> Arnaud: we can do both parts of John's proposal or go for some parts of it (more or less original proposal)
13:45:11 <mielvds> stevebattle: I think inlining is just the wrong proposal; do nothing
13:46:29 <JohnArwe> q+ ericp
13:47:08 <stevebattle4> quotation isn't simple!
13:47:18 <sandro> QUOTATION IS SOLVED
13:47:30 <sandro> (it's called Datasets)
13:48:01 <Arnaud> ack eric
13:48:34 <mielvds> ericP: we should have people implement their own solutions for this and deprecate them afterwards
13:48:39 <stevebattle4> Sandro, what's a good URL for that?
13:49:44 <sandro> https://dvcs.w3.org/hg/rdf/raw-file/default/rdf-concepts/index.html#section-dataset
13:49:48 <Arnaud> PROPOSAL: add close Issue-58, per Richard's proposal, marking the feature AT RISK
13:50:19 <cody> +1
13:50:26 <ericP> +1
13:50:46 <mesteban__> -0
13:50:49 <mielvds> +0
13:50:53 <JohnArwe> issue-58?
13:50:53 <trackbot> ISSUE-58 -- Property for asserting that complete description of members is included in LDPC representation -- open
13:50:53 <trackbot> http://www.w3.org/2012/ldp/track/issues/58
13:51:07 <SteveS> +1
13:51:09 <JohnArwe> +1
13:51:11 <Ashok> +0.5
13:51:12 <stevebattle4> 0 (I'd rather close with no inlining prediciate - it's insufficient)
13:51:24 <sandro> richards proposal:  PROPOSAL: Add a property 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.
13:51:27 <nmihindu> 0
13:51:30 <mesteban__> agree with stevebattle4
13:51:38 <sandro> +1
13:51:43 <bblfish> mind you I did a find a bunch of urls for formats http://www.w3.org/ns/formats/
13:51:48 <rgarcia> -0 (also would prefer not to have it)
13:52:19 <roger> 0
13:52:55 <Arnaud> Resolved: add close Issue-58, per Richard's proposal (described in the decription of the issue), marking the feature AT RISK
13:53:33 <stevebattle4> s/prediciate/predicate/
13:55:56 <Arnaud> PROPOSAL: add a predicate ldp:inlinedResource the object of which is a URI of a linked resource that is fully inlined
13:56:43 <Arnaud> PROPOSAL: add a predicate ldp:inlinedResource the object of which is a URI of a linked resource that is fully inlined, marked as AT RISK
13:56:56 <ericP> +1
13:56:58 <stevebattle4> Didn't the zero's outnumber the 1's (and halves) on that last vote?
13:56:59 <Ashok> +1
13:57:04 <roger> +1
13:57:04 <SteveS> +1
13:57:17 <JohnArwe> +1
13:57:23 <rgarcia> -0
13:57:26 <mielvds> +0
13:57:26 <mesteban__> -0
13:57:28 <stevebattle4> 0 (The predicate is still insufficient and we know that right now)
13:57:28 <nmihindu> 0
13:57:28 <bblfish> +0 for at risk, much happier if we move to quad store format, as that is the only really way to solve this problem.
13:57:57 <Arnaud> Resolved: add a predicate ldp:inlinedResource the object of which is a URI of a linked resource that is fully inlined, marked as AT RISK
13:58:04 <JohnArwe> @steveb 0's are usually taken to mean "don't care", hence things like -0.5 which I interpret as "not crazy about it, but not willing to lay in the tracks over it either"
13:58:15 <stevebattle4> Didn't the zeroes win?
13:58:52 <stevebattle4> mmmm....
13:58:54 <Ashok> Zeroes mean abstain
13:58:55 <ericP> the apathy vote caries
13:59:22 <stevebattle4> I'm going to use -1 a lot more in the future then.
14:01:02 <JohnArwe> Topic: issue-5
14:01:06 <JohnArwe> issue-5?
14:01:06 <trackbot> ISSUE-5 -- Add a section explaining how LDBP is related to Graph Store Protocol -- postponed
14:01:06 <trackbot> http://www.w3.org/2012/ldp/track/issues/5
14:01:20 <stevebattle4> So we can't distinguish between a vote against and a veto?
14:01:44 <ericP> veto is -1
14:02:06 <stevebattle4> I thought zero was vote against
14:02:16 <roger> +q
14:02:22 <ericP> q+
14:02:27 <roger> -q
14:02:34 <stevebattle4> I never saw the zeros win before
14:02:36 <mielvds> Arnaud: we still have a postponed issue
14:02:48 <Arnaud> ack eric
14:02:49 <mesteban___> mesteban___ has joined #ldp
14:02:50 <mielvds> Graph store vs LDP
14:03:17 <bhyland> bhyland has joined #ldp
14:03:19 <mielvds> ericP: GSP thingy post adds more triples, while LDP creates something
14:03:39 <roger> +q
14:03:43 <bblfish> q?
14:03:47 <bblfish> q+
14:03:49 <mielvds> I don't thing having a container is a problem for having graphs
14:04:07 <bblfish> http://www.w3.org/TR/sparql11-http-rdf-update/
14:04:18 <mielvds> Arnaud: it's a very basic spec that addresses HTTP spec
14:04:32 <mielvds> they address boundaries by graph names
14:04:41 <mielvds> that's their advantage
14:05:00 <davidwood> davidwood has joined #ldp
14:05:40 <mielvds> Arnaud: we go beyond. Compatibility distinction is on post
14:06:05 <Arnaud> ack roger
14:06:36 <ericP> q+ to say that he's implemented BGP and LDP in the same server
14:06:36 <mielvds> roger: could be wrong, but GSP is a protocol for manipultion graphs
14:06:51 <mielvds> LDP manipulates is more, manipulating linked data
14:07:18 <mielvds> bblfish, what is missing from GSP for what you want to do?
14:07:35 <mielvds> bblfish: I like the post for creating resources
14:08:06 <mielvds> could one use a search put to pose a sparql query on a container
14:08:48 <mielvds> if you want to do something on a graph, do it on the graph, not with ?graph-name
14:09:24 <mielvds> Arnaud: LDP introduces containers and their functionality
14:09:37 <roger> LDP is manipulating one graph, and GSP is manipulating multiple graphs - that's the way I'm viewing it anyway :)
14:09:43 <Arnaud> ack bblfish
14:10:05 <mielvds> ericP: to respond to ?graph-name
14:10:09 <Arnaud> ack eric
14:10:09 <Zakim> ericP, you wanted to say that he's implemented BGP and LDP in the same server
14:10:44 <Zakim> -Sandro
14:10:52 <mielvds> there is a difference in the URL
14:11:16 <sandro> (sorry, need to be in GLD WG meeting at this time)
14:11:24 <mielvds> if I posted to ldp:Container, it appended triples to the graph
14:11:57 <mielvds> Arnaud: despite the name, it does not depend on SPARQL
14:13:15 <mielvds> ericP: using a post to append was controversial, so they called it SPARQL
14:14:26 <mielvds> Arnaud: somebody who is knowledgeable in both specifications to take an action and compare
14:14:50 <mielvds> ericP: didn't Steve already do that? => no, it was rather high level
14:17:00 <mielvds> me: I will take an action in comparing both specs
14:17:12 <Arnaud> action: mielvds to take another look at how LDP and GSP compare and report back
14:17:12 <trackbot> Created ACTION-82 - Take another look at how LDP and GSP compare and report back [on Miel Vander Sande - due 2013-06-27].
14:17:45 <ericP> mielvds, maybe http://www.w3.org/2012/Talks/1211-egp-ldp/#(14) can serve as a starting point
14:18:09 <mielvds> thx ericP
14:18:56 <ericP> @JohnArwe, controversy was just that HTTP uses POST for many purposes and that saying that every RDF resource which gets RDF POSTed to it will append rules out lots of use cases
14:19:01 <ericP> (like LDPCs)
14:19:32 <stevebattle4> (claps)
14:21:24 <stevebattle4> Arnaud is trying to drum up additional attendees for his workshop :)
14:21:40 <nmihindu> mielvds, do you want to print your boarding pass too ?
14:22:04 <Arnaud> MEETING ADJOURNEd
14:22:39 <stevebattle4> bye all
14:22:43 <Zakim> -SteveBattle
14:22:46 <mielvds> mielvds has left #ldp
14:22:47 <Zakim> -m
14:23:05 <Zakim> -ericP
14:23:06 <Zakim> SW_LDP(F2F)2:30AM has ended
14:23:06 <Zakim> Attendees were SteveBattle, ericP, m, Sandro
14:23:16 <stevebattle4> stevebattle4 has left #ldp
14:23:18 <Arnaud> trackbot, end meeting
14:23:18 <trackbot> Zakim, list attendees
14:23:18 <Zakim> sorry, trackbot, I don't know what conference this is
14:23:26 <trackbot> RRSAgent, please draft minutes
14:23:26 <RRSAgent> I have made the request to generate http://www.w3.org/2013/06/20-ldp-minutes.html trackbot
14:23:27 <trackbot> RRSAgent, bye
14:23:27 <RRSAgent> I see 1 open action item saved in http://www.w3.org/2013/06/20-ldp-actions.rdf :
14:23:27 <RRSAgent> ACTION: mielvds to take another look at how LDP and GSP compare and report back [1]
14:23:27 <RRSAgent>   recorded in http://www.w3.org/2013/06/20-ldp-irc#T14-17-12