13:04:01 <RRSAgent> RRSAgent has joined #ldp
13:04:01 <RRSAgent> logging to http://www.w3.org/2013/09/12-ldp-irc
13:04:03 <trackbot> RRSAgent, make logs public
13:04:03 <Zakim> Zakim has joined #ldp
13:04:05 <trackbot> Zakim, this will be LDP
13:04:05 <Zakim> ok, trackbot; I see SW_LDP()8:30AM scheduled to start 34 minutes ago
13:04:06 <trackbot> Meeting: Linked Data Platform (LDP) Working Group Teleconference
13:04:06 <trackbot> Date: 12 September 2013
13:04:31 <Arnaud> Arnaud has changed the topic to: LDPWG: http://www.w3.org/2012/ldp/wiki/Main_Page -  Today's agenda: http://www.w3.org/2012/ldp/wiki/F2F4
13:04:47 <Arnaud> zakim, who's on the phone?
13:04:47 <Zakim> SW_LDP()8:30AM has not yet started, Arnaud
13:04:48 <Zakim> On IRC I see RRSAgent, SteveS, nmihindu, rgarcia, Arnaud, jmvanel, bblfish, gavinc, Yves, trackbot, thschee, sandro, ericP
13:05:13 <Zakim> SW_LDP()8:30AM has now started
13:05:20 <Zakim> +??P3
13:05:32 <rgarcia> zakim, ??P3 is me
13:05:32 <Zakim> +rgarcia; got it
13:06:11 <cody> cody has joined #ldp
13:07:51 <Arnaud> hi guys
13:08:03 <Arnaud> we're still setting things up in the room
13:08:11 <Arnaud> we'll be starting shortly
13:10:37 <Zakim> +Workshop_room
13:10:57 <Arnaud> zakim, who's on the phone?
13:10:57 <Zakim> On the phone I see rgarcia, Workshop_room
13:11:30 <rgarcia> zakim, mute me
13:11:30 <Zakim> rgarcia should now be muted
13:11:59 <SteveS> Scribe: SteveS
13:12:23 <SteveS> Topic: F2F Agenda Review
13:13:01 <SteveS> Reviewing http://www.w3.org/2012/ldp/wiki/F2F4
13:13:56 <SteveS> Arnaud: Shorter F2F meeting than usual (2 days) and need to prioritize what we need to do
13:14:48 <SteveS> Arnaud: reviewing last call handling of comments and reaching CR (or another LC)
13:15:29 <davidwood> davidwood has joined #ldp
13:15:42 <Ashok> Ashok has joined #ldp
13:16:30 <SteveS> …pretty sure we'll need to go to another last call based on how we handle TBL's comments
13:17:32 <roger> roger has joined #ldp
13:18:05 <rgarcia> Now the sound is better
13:19:13 <SteveS> Arnaud: primarily will be working on TBLs feedback/issues the next couple of days
13:21:12 <SteveS> Arnaud: Only have 4 deliverables in the charter itself and others not
13:21:56 <rgarcia> I will be during the mornings, so I prefer that we talk about the test suite then
13:22:01 <SteveS> not sure there is much to cover with UCR but will defer until Steve Battle is around
13:22:03 <rgarcia> Today or tomorrow (better tomorrow)
13:22:24 <SteveS> davidwood: has conflict 1-2:30 today
13:22:36 <SteveS> sandro: has conflict 11-12 today
13:23:32 <SteveS> Arnaud: looking to cover patch at some point but would like to get Andy in for that, perhaps only cover for a fixed time
13:24:17 <SteveS> Topic: Specification last call comments
13:25:01 <SteveS> Arnaud: screwing with agenda
13:26:47 <SteveS> See tracker https://www.w3.org/2006/02/lc-comments-tracker/55082/ldp/
13:27:08 <SteveS> Arnaud: put Tim's comments into this, including others
13:27:58 <SteveS> proposing that when we want to address a handle an issue from comment, we open an issue in tracker to record WG resolution
13:28:15 <Zakim> +bblfish
13:28:50 <bblfish> hi
13:29:50 <SteveS> JohnArwe: it is possible that the WG addresses a comment that the commenter doesn't agree with
13:30:26 <SteveS> Arnaud: yes but we work to get them to agree with resolution is the preferred way of handling, but not always possible
13:31:21 <SteveS> (discussion back and forth on handling or not handling comments, formal objections, w3c process)
13:31:58 <SteveS> JohnArwe: Do I propose the proposal to the WG to get their blessing before reaching out to commenter?
13:32:11 <SteveS> Arnaud: yes, we should get WG consensus on it before we distribute
13:32:49 <TallTed> TallTed has joined #ldp
13:32:50 <betehess_> betehess_ has joined #ldp
13:33:15 <SteveS> Want to make sure we don't provide direct feedback to commenters on resolutions unless we are sure we have WG consensus
13:34:16 <Arnaud> https://www.w3.org/2006/02/lc-comments-tracker/55082/ldp/2812
13:34:38 <SteveS> Topic: Mark Baker's comment LC-2812
13:35:09 <SteveS> JohnArwe: Mark pokes on the redefinition of DELETE in our spec
13:35:57 <SteveS> sandro: not sure why HTTP didn't require a true DELETE of the resource
13:36:54 <SteveS> davidwood: done in a way in that it is hard/impossible to enforce a true delete
13:38:12 <bblfish> q+
13:38:52 <Arnaud> ack bblfish
13:39:30 <davidwood> bblfish: We should ask Mark what danger he sees if we redefine HTTP DELETE
13:39:32 <SteveS> bblfish: we should go back and ask what exactly he thinks will break
13:39:59 <SteveS> JohnArwe: has interaction with mark and he thinks LDP client should be same as a generic HTTP client
13:40:48 <SteveS> bblfish: wonders if he has any issue with container specific behavior
13:41:33 <SteveS> Ashok: do we agree that clients are generic?
13:41:54 <SteveS> Arnaud: seems to be a common question we keep hearing
13:42:12 <bblfish> yes, so for example an LDPC has a certain way of behaving that is defined by an LDPC: I wonder what mark baker makes of this.
13:42:24 <bblfish> q+
13:43:06 <SteveS> Arnaud: hard to imagine how a client that wouldn't see a switch to know it is a LDP server it is working with and need to go done that code path
13:43:28 <Arnaud> ack bblfish
13:43:45 <SteveS> davidwood: we have the liberty to expand on what is in HTTP and need specialized LDP interaction
13:44:33 <TallTed> q+
13:45:05 <SteveS> bblfish: an LDP client should work with any LDP server, without having to learn from web site admin…is why TBL is saying this
13:45:07 <davidwood> bblfish, yes, we agree on that
13:45:22 <roger> roger has joined #ldp
13:45:40 <roger> +q
13:46:03 <Arnaud> ack TallTed
13:47:13 <SteveS> TallTed: how does a generic client with a specific server?  curl is a sample of this, the end user has the logic to interact with the server
13:47:22 <bblfish> q+
13:47:40 <SteveS> sandro: is curl or LDP client??
13:48:06 <Arnaud> s/or LDP/an LDP/
13:48:28 <Arnaud> ack roger
13:48:33 <SteveS> JohnArwe: curl is http client
13:49:51 <SteveS> roger: thinks that we can improve over time how generic an LDP client can be, having some limitations in initial spec
13:49:51 <Arnaud> ack bblfish
13:50:46 <SteveS> bblfish: agrees that curl is example of generic HTTP client, a generic LDP clients knows the specifics of LDPRs and LDPCs + interactions
13:51:54 <SteveS> roger: not quite enough as we need new extension for which types of resources
13:52:33 <SteveS> bblfish: recaps discussion from madrid and his proposal on expressing which types of things that can be put into a container
13:52:55 <SteveS> Arnaud: looking back to Mark's specific comment
13:53:11 <bblfish> Arnaud: can you make a recap of the discussion on the talks that you were at?
13:53:42 <roger> I think we need to be explicit about these hypermedia related 'gaps' in the state of LDP alone - that we recognise these gaps, but we are looking to fill them !!
13:53:47 <SteveS> Arnaud: looking back on Ted's point, wondering what breaks on generic HTTP clients (like curl) with DELETE
13:54:43 <SteveS> sandro: doesn't see anything in spec that would make curl a non-conformant LDP client, i.e. wouldn't break anything
13:55:05 <SteveS> …requires the human to respect some of the LDP rules
13:55:31 <SteveS> JohnArwe: some of the other points Mark makes is some of best practices
13:55:57 <SteveS> sandro: sees conformance as if a product advertises, but doesn't do it…I could get my money back
13:56:17 <SteveS> …I think these pass that test (are conformance criteria) and don't agree with Mark here
13:56:52 <bblfish> q+
13:57:36 <SteveS> JohnArwe: Mark doesn't want a specialized LDP client (recapping) and also that an HTTP client (not saying generic) can work with an LDP (any) server
13:58:11 <SteveS> sandro: thinks that we can decide we can restrict an LDP server
13:59:30 <SteveS> ericP: POSTing to an HTTP server is anything in HTTP spec, where in LDP we refine/restrict it to be create.
13:59:51 <SteveS> sandro: is saying his bottle of water may be a compliant http server
14:01:28 <SteveS> TallTed: sees that an HTTP client should work with an LDP server using it as HTTP server, but if it uses LDP capability it must conform to LDP spec
14:02:24 <Arnaud> ack bblfish
14:02:31 <sandro> q?
14:02:52 <nmihindu> q+
14:03:10 <Ashok> q+
14:03:52 <davidwood> q+ to discuss generic HTTP clients operating on LDP servers
14:04:03 <sandro> so any http server is an ldp server -- it just might not happen to have any LDPRs or LDPCs.
14:04:06 <SteveS> bblfish: LDP server can be an HTTP server, just need that the LDP-resources behave according to the LDP spec…leave any resource on the web to remain to HTTP to define
14:04:10 <Arnaud> ack nmihindu
14:04:59 <Arnaud> ack Ashok
14:05:00 <SteveS> nmihindu: agrees with sandro in that the behavior server but more on the specific web resource
14:05:21 <davidwood> +1 to nmihindu. Many of the MUSTs relate to content.
14:05:33 <SteveS> Ashok: how can I tell resource is an LDPR or just a plain thing?
14:05:50 <TallTed> TallTed: LDP can roughly be defined as extensions/restrictions on HTTP.  *within* LDP functionality space, LDP client/server must xyz, but when LDP functionality/LDPC/LDPR are not being addressed, an LDP client/server is just an HTTP client/server
14:05:50 <TallTed> TallTed: any LDP server is an HTTP server; any HTTP server is not necessarily an LDP server.  any LDP client is an HTTP client; any HTTP client is not necessarily an LDP client.
14:05:50 <TallTed> TallTed: (human + curl) can be LDP client.  curl alone is an HTTP client.
14:05:58 <sandro> you do an HTTP interaction with it.
14:06:22 <SteveS> SteveS: you can inspect the Link header with type ldp:Resource
14:06:36 <ericP> q?
14:06:38 <SteveS> as a response to any request, OPTIONS is the lightest
14:06:53 <Arnaud> ack davidwood
14:06:53 <Zakim> davidwood, you wanted to discuss generic HTTP clients operating on LDP servers
14:07:55 <SteveS> davidwood: looked through spec of MUSTs in what would break if I used vanilla HTTP interactions, don't see anything would break.  Suggest turning to Mark to point out specifically what will break
14:08:27 <nmihindu> TallTed, (script + curl) could be an LDP client too, isn't it ?
14:09:22 <TallTed> nmihindu - yes, human effectively delegates to script
14:10:55 <sandro> I was talking about: 4.5.5 An LDPR client MUST preserve all triples retrieved using HTTP GET that it doesn’t change whether it understands the predicates or not, when its intent is to perform an update using HTTP PUT.  The use of HTTP PATCH instead of HTTP PUT for update avoids this burden for clients [RFC5789].
14:11:37 <bblfish> q+
14:13:11 <SteveS> davidwood: says that we can't prevent authenticated client from garbage in from garbage out, rude for clients to through out stuff it doesn't understand
14:13:13 <Arnaud> ack bblfish
14:13:55 <SteveS> bblfish: believes that this could be an access control, allowing then only additive and can preserve
14:14:55 <SteveS> TallTed: can be that someone with more permissions to be able to still remove it
14:15:45 <SteveS> sandro: good to define well-defined client behavior in that a client shouldn't throw stuff out it
14:16:23 <bblfish> The discussion seems to be about: what can a generic client do that would be bad and should the spec be talking about it. Not sure why this is the discussion point.
14:19:08 <SteveS> miguel: is there a case where we require a genetic HTTP client to an LDP server on LDP resources?
14:19:15 <SteveS> TallTed: not sure this is any
14:19:34 <SteveS> Arnaud: what do we need to get back with Mark
14:20:14 <SteveS> JohnArwe: than an HTTP client can interact with an LDP server, all behaviors with constraints on LDPRs and LDPRs still are within bounds of HTTP
14:20:37 <sandro> An LDP Server is an HTTP Server which offers one or more LDPC or LDPR.
14:20:44 <bblfish> I think we agree here. +1
14:21:15 <davidwood> +1
14:21:18 <bblfish> distinguish LDP Resources, LDP Clients and HTTP Clients . LDP Cleints are subsets of HTTP Clients. LDP resources are a subset of HTTP resources
14:22:15 <timbl> timbl has joined #ldp
14:23:08 <sandro> q+
14:23:29 <SteveS> TallTed: thinks we make it hard for server implementers as the have to go through the spec and clearly list out what a server needs to do
14:23:47 <bblfish> I'd say LDP Server =def a Server that servers LDPR resource
14:24:02 <sandro> q+ to say that maybe there is no LDP Client -- instead these are requirements/suggestions for all clients interacting with LDPRs and LDPCs.
14:24:35 <SteveS> Arnaud: believe that we has it by server criteria, and needed some change
14:24:35 <sandro> Maybe "An 'ldp client' is an HTTP client that is interacting with an LDPR or LDPC."
14:25:10 <Arnaud> ack sandro
14:25:10 <Zakim> sandro, you wanted to say that maybe there is no LDP Client -- instead these are requirements/suggestions for all clients interacting with LDPRs and LDPCs.
14:25:24 <SteveS> JohnArwe: we made it clear which criteria are for clients vs server by preceding each req
14:25:58 <nmihindu> +1 to sandro. May be a client who is aware of LDP restrictions that is interacting with an LDPR or LDPC.
14:26:12 <SteveS> sandro: changing opinion that there isn't an LDP client, in that there is rules for HTTP clients that interact with LDP resources/servers.
14:26:58 <roger> roger has joined #ldp
14:27:06 <bblfish> q+
14:28:12 <SteveS> TallTed: sees that GET/PUT and the separate client activity on the data and the rest is the protocol
14:28:21 <bblfish> q?
14:28:52 <SteveS> sandro: see it as an action, such as patch, where you the entirety to complete that action is to get, only mod what you want, then put
14:28:54 <Arnaud> ack bblfish
14:29:14 <SteveS> bblfish: question of what is an LDP client?
14:29:31 <davidwood> q+ to discuss the lack of transactionality
14:29:40 <sandro> Proposed: an "LDP Client" is an HTTP Client, interacting with an LDPR and LDPC, following the restriction in this spec.
14:30:15 <SteveS> SteveS: optimization, an LDPC is an LDPR
14:32:07 <SteveS> TallTed: curl is generic HTTP client that can be used to interact with WebDav server.  It is the end user who would not be well-behaved in webdav interaction
14:32:11 <Arnaud> ack davidwood
14:32:11 <Zakim> davidwood, you wanted to discuss the lack of transactionality
14:32:14 <sandro> thanks steve.
14:33:45 <SteveS> davidwood: http is based on stateless interaction, you can't guarantee that another client modified a behind another one
14:34:08 <SteveS> sandro: you can use stags and if-modified header to prevent concurrent mods
14:34:13 <davidwood> However, an LDP server can use ETag matching to issue a 405 in the event of a conflict.
14:34:23 <davidwood> s/stags/etags/
14:36:15 <sandro> So....    We reply to Mark, saying a conforming ldp client is an http client that is following the behavior specified in this spec (when accessing an ldpr); and a conforming ldp server is an http server that is following the bheavior specified in this spec (when serving an ldpr).
14:36:22 <SteveS> Arnaud: not hearing any disagreement within the group on this approach, so John can draft a response and get group feedback
14:37:23 <SteveS> Arnaud: not hearing a normative change to a spec
14:37:34 <SteveS> JohnArwe: agree, perhaps some editorial
14:37:55 <bblfish> I think that is not the definition we were using of a Generic HTTP client. A browser is a specialised HTTP Client. Curl is a generic HTTP Client.
14:38:21 <bblfish> ( we have to be careful to distinguish those )
14:38:48 <bblfish> ( A browser is a generic HTML+http client )
14:39:06 <TallTed> +1 bblfish
14:40:08 <sandro> PROPOSAL: We reply to Mark Baker, saying a conforming ldp client is an http client that is following the behavior specified in this spec (when accessing an ldpr); and a conforming ldp server is an http server that is following the bheavior specified in this spec (when serving an ldpr).
14:40:16 <sandro> +1
14:40:30 <nmihindu> +1
14:40:31 <SteveS> +1
14:40:40 <nmihindu> +1 for mesteban
14:40:49 <TallTed> +1
14:40:52 <rgarcia> +1
14:41:42 <roger> +! and we say that we are working on the  gap (hateoas shaped)
14:41:43 <ericP> +1
14:41:43 <davidwood> +1
14:41:52 <SteveS> +1 for JohnArwe
14:41:54 <roger> +!
14:41:58 <roger> +1
14:42:05 <sandro> RESOLVED: We reply to Mark Baker, saying a conforming ldp client is an http client that is following the behavior specified in this spec (when accessing an ldpr); and a conforming ldp server is an http server that is following the bheavior specified in this spec (when serving an ldpr).
14:42:11 <davidwood> ☃
14:42:27 <davidwood> Sorry, that should be +☃
14:43:07 <bblfish> 🍹
14:43:16 <bblfish> 🍹?
14:43:38 <bblfish> 👍
14:49:52 <cody> cody has joined #ldp
14:59:26 <SteveS> SteveS has joined #ldp
15:02:02 <davidwood> Back from break
15:02:12 <cody> cody has joined #ldp
15:02:25 <davidwood> scribenick: davidwood
15:02:59 <davidwood> Arnaud: Reviewing outstanding comments, issues and features at risk
15:03:21 <davidwood> …There is quite a bit of work to do.
15:03:36 <sandro> (watching IRC from 30m away, sitting in another meeting)
15:04:21 <davidwood> …The issue regarding inlined resources came up.
15:04:57 <roger> https://www.w3.org/2006/02/lc-comments-tracker/55082/ldp/2837
15:06:10 <davidwood> …inlining is currently at-risk:  https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp.html#member-inlining-returning-all-of-a-container-page-s-members-in-a-response
15:06:25 <davidwood> …propose to remove it from the spec.
15:07:32 <Ashok> q+
15:08:23 <Arnaud> ack ashok
15:08:46 <davidwood> Ashok: Is inlining a requirement?  If so, it should be fixed.
15:08:47 <SteveS> q+
15:09:21 <davidwood> The spec currently says, "One of the most commonly cited scenarios for resource inlining is to save clients enumerating a container of m members from having to perform m+1 HTTP requests".  How would that common use case be addressed?
15:09:39 <davidwood> Arnaud: It would not be addressed under this proposal.
15:10:36 <Arnaud> ack SteveS
15:11:09 <davidwood> John, Eric: Addressing this requirement out of band is not addressing it in an interoperable way.
15:12:06 <davidwood> SteveS: Clients need to know the boundaries of what they can GET or query.  We could drop it, but try to put it back in later.
15:12:18 <davidwood> Ashok: Maybe just leave it as a feature at risk.
15:13:38 <davidwood> Arnaud: I don't think we have time to fix it.
15:14:36 <bblfish> the problem is that this requires TriG and N3 for it to work.
15:14:57 <bblfish> q+
15:15:17 <SteveS> or multi-part/mixed
15:15:18 <davidwood> TriG is on the Rec track.
15:15:25 <Arnaud> ack bblfish
15:15:49 <davidwood> bblfish: We need TriG, and the spec might be ready.  We could do it later.
15:15:59 <SteveS> not sure we need TriG, could split the HTTP responses in a multi-part/mixed response
15:16:08 <davidwood> Arnaud: We would need to evaluate multiple proposals, and don't have time.
15:16:32 <bblfish> ah yes and there is SPEEDY too
15:17:46 <davidwood> SPDY proposal at IETF: https://tools.ietf.org/html/draft-mbelshe-httpbis-spdy-00
15:17:54 <bhyland> bhyland has joined #ldp
15:17:54 <Arnaud> PROPOSAL: drop inlining from the spec, put it on the wish list for LDPnext
15:18:03 <rgarcia> +1
15:18:07 <nmihindu> +1
15:18:08 <Ashok> 0
15:18:10 <roger> +1
15:18:15 <nmihindu> +1 for mesteban
15:18:17 <davidwood> +0
15:18:35 <bblfish> +1
15:18:42 <TallTed> +1
15:19:23 <davidwood> Arnaud: A problem is that you don't know the boundaries of a container.  You might get data back that transcends a boundary you presume.
15:20:32 <davidwood> John and SteveS discuss the boundary problem.
15:20:36 <bblfish> good axplanation from arnaud: it's like you ask for a driectory and you don't just get back the directory, but you get back the directory and the files but you don't know where one file starts and the other ends.
15:21:56 <SteveS> +1
15:21:59 <ericP> +1
15:22:30 <Arnaud> RESOLVED: drop inlining from the spec, put it on the wish list for LDPnext
15:22:31 <davidwood> RESOLVED: drop inlining from the spec, put it on the wish list for LDPnext
15:25:46 <davidwood> ISSUE: Should inlining be dropped from the LDP spec due to time and complexity to fix?
15:25:46 <trackbot> Error creating an ISSUE: an internal error occurred.  Please mail <sysreq@w3.org> with details about what happened.
15:26:51 <TallTed> issue-81?
15:26:51 <trackbot> issue-81 -- Confusing membership* predicate names and other possible improvements -- raised
15:26:51 <trackbot> http://www.w3.org/2012/ldp/track/issues/81
15:26:58 <davidwood> ISSUE-83?
15:26:58 <trackbot> ISSUE-83 -- Should inlining be dropped from the LDP spec due to time and complexity to fix? -- raised
15:26:58 <trackbot> http://www.w3.org/2012/ldp/track/issues/83
15:27:05 <davidwood> CLOSE ISSUE-83
15:27:05 <trackbot> Closed ISSUE-83.
15:27:20 <davidwood> ISSUE-81
15:27:20 <trackbot> ISSUE-81 -- Confusing membership* predicate names and other possible improvements -- raised
15:27:20 <trackbot> http://www.w3.org/2012/ldp/track/issues/81
15:28:15 <davidwood> John: Readers are confused by the membership predicate names.
15:28:24 <davidwood> Arnaud: Open ISSUE-81?
15:28:38 <davidwood> OPEN ISSUE-81
15:28:41 <TallTed> +1 open it
15:28:53 <Arnaud> PROPOSAL: Open ISSUE-81
15:29:01 <nmihindu> +1
15:29:02 <rgarcia> +1
15:29:03 <TallTed> +81
15:29:07 <Ashok> +1
15:29:09 <roger> +1
15:29:12 <nmihindu> +1 for mesteban
15:29:16 <SteveS> +1
15:29:34 <davidwood> REOPEN ISSUE-81
15:29:34 <trackbot> Re-opened ISSUE-81.
15:29:38 <Arnaud> RESOLVED: Open ISSUE-81
15:30:41 <davidwood> SteveS: Discussing how membership is expressed in an LDPC
15:31:10 <davidwood> …ldp:membershipObject is confusing compared with other membership* predicates.
15:31:12 <roger> +q
15:32:44 <davidwood> …ldp:membershipPredicate and ldp:membershipPredicateInverse also confusing.  ldp:membershipPredicateInverse turns membershipPredicateSubject into an Object...
15:33:34 <davidwood> John: ldp:membershipPredicateInverse is poorly named - cannot explain it well to people.
15:35:50 <Arnaud> http://www.w3.org/2012/ldp/track/issues/81
15:36:35 <davidwood> SteveS: Walking through proposals in ISSUE-81
15:39:25 <davidwood> TallTed: The old way allowed a client to know that a container is either in the subject or object position - not both or either.
15:39:30 <bblfish> q+
15:39:39 <davidwood> …This proposal will cause more confusion.
15:41:22 <Arnaud> ack roger
15:42:00 <davidwood> …By referring to a predicate in an object position, it makes it hard to read.  Not supposed to force readers to be RDF experts.
15:42:45 <davidwood> John: The inverse case is more common.
15:42:59 <davidwood> SteveS: slightly - maybe 60/40
15:43:19 <davidwood> Arnaud: Do not want to reopen an issue just for terminology.
15:44:15 <Arnaud> ack bblfish
15:44:59 <davidwood> bblfish: Propose to have a member relation that points to a blank node with spo properties.
15:45:24 <TallTed> maybe s/ldp:membershipPredicateInverse/{ ldp:containmentPredicate | ldp:containershipPredicate }/
15:45:31 <bblfish>  ldp:consequence [ lpd:subject ... ; ldp:object ...; ldp:predicate ]
15:47:04 <davidwood> John: SteveS's proposal does address part of what bblfish wants.
15:47:37 <davidwood> Arnaud: We only need a different syntax to use for the design we already have.
15:48:27 <roger> +q
15:48:57 <Arnaud> ack roger
15:50:33 <davidwood> EricP: What pattern will a user look to in order to find out how to traverse an LDPC?
15:52:05 <ericP> Arnaud: and what pattern will the server invoke when a client POSTs a new resource
15:52:39 <roger> i am just saying that by grouping the three membership* predicates (and potentially giving that group a URI), then it makes predicates on a LDPC look simpler.
15:52:42 <bblfish> so I was thinking the above could be <> ldp:consequence <some#x> .  And then in <some> could have <#x> ldp:subject ...; ldp:oject ...; ldp:predicate ... ] .
15:53:36 <bblfish> so I was thinking the above could be <> ldp:consequence <some#x> .  And then in <some> could have <#x> ldp:subject s;  ldp:oject o ; ldp:predicate p ] .
15:54:48 <bblfish> and then <#x> is something like a rule that can be formed by replacing s, o and p in it. What that rule would be is an interesting question. Perhaps a SPARQL INSERT into <s> { s p o }  // it's not that but that's as much as I can get to
15:57:20 <ericP> davidwood: in callimacus, we run into the issues where we've left cardinalities implicit and we end up seeing e.g. n HTTP <title/>s
15:57:28 <davidwood> davidwood: Encourage the editors to define any implicit cardinalities.
16:09:16 <davidwood> davidwood: Propose to change the terms to use meaningful names instead of Subject, Predicate, Object.
16:09:31 <davidwood> …e.g. ldp:consistentResourceURI
16:09:49 <davidwood> Discussion ensues
16:09:51 <TallTed> ldp:membershipCollectiveName ldp:membershipRelationshipName ldb:membershipMemberName
16:10:42 <TallTed> or
16:10:42 <TallTed> ldp:membershipAggregateeName ldp:membershipAggregateRelationship ldb:membershipAggregateElement
16:11:31 <TallTed> or better
16:11:31 <TallTed> ldp:membershipAggregateeName ldp:membershipAggregateRelation ldb:membershipAggregateElement
16:12:29 <davidwood> Arnaud: We will break on this for now to let people think about naming.
16:12:34 <SteveS> SteveS has joined #ldp
16:12:42 <davidwood> …and maybe even a change in design.
16:13:37 <davidwood> Breaking 30 minutes for lunch.
16:13:42 <Zakim> -rgarcia
16:16:56 <Zakim> -bblfish
16:16:57 <AndyS> AndyS has joined #ldp
16:22:56 <deiu> deiu has joined #ldp
16:29:18 <JohnArwe> JohnArwe has joined #ldp
16:32:00 <SteveS> SteveS has joined #ldp
16:49:25 <timbl> timbl has joined #ldp
16:51:42 <sandro> scribe: sandro
16:51:47 <sandro> RRSAgent, pointer?
16:51:47 <RRSAgent> See http://www.w3.org/2013/09/12-ldp-irc#T16-51-47
16:51:54 <sandro> RRSAgent, make logs public
16:52:17 <sandro> topic: LC-2815 (Ashok)
16:52:25 <sandro> Ashok, I think we resolved this one already.
16:53:49 <SteveS> SteveS has joined #ldp
16:54:03 <sandro> Ashok, We didn't address containers within containers -- how does ordering work?
16:56:29 <sandro> Ashok: can you have a container of containers and other resources?
16:56:53 <sandro> SteveS: Yes.  Ordering is in the data.   An LDPC is an LDPR.
16:57:30 <sandro> SteveS: You could order on the non-member properties
16:57:47 <sandro> Ashok: If you want to order containers within a container, you can only use the non-membership properties?
16:58:16 <sandro> SteveS: Would you want to order the member resources of the subcontainer within the top-level container?
16:58:45 <sandro> SteveS: I don't know why why anyone WOULD order the membership URIs, but I don't see any reason to forbid it.
17:00:22 <sandro> Arnaud: In my app, I have some ......   the spec allows it
17:00:49 <sandro> Ashok: It's not spelled out.   I'd like a line saying if there are containers within containers, you can order the contained containers.
17:01:16 <sandro> ted: It's just like ordering anything else within a container.   Why do we have to be specific.
17:01:30 <sandro> Ashok: It might confuse people.
17:02:09 <sandro> SteveS: IBM usernames example
17:02:33 <sandro> .. #steve, #john, ...
17:03:04 <sandro> cody: Isn't it likely the containers wont have the same properties?
17:03:14 <sandro> SteveS: Yes.
17:04:00 <sandro> Arnaud: Can we close this by having the editors add something to the spec saying yes you can order the containers within a container.
17:04:17 <sandro> Arnaud: in main spec, not best practice.
17:04:41 <sandro> cody: But aren't the properties going to be different?
17:05:00 <sandro> SteveS: You don't ask for sorting -- the server just tells you how it's sorting.
17:05:17 <sandro> Arnaud: Ordered by that property, but several resources don't have that property.
17:05:27 <Zakim> +bblfish
17:06:00 <sandro> sandro: Servers can make sure all the contained elements have the sort property you want
17:07:00 <sandro> cody: but aren't containers likely to have different properties?
17:07:18 <Arnaud> PROPOSED: dispose of second part of LC-285 by clarifying the intent in the spec: LDPCs are LDPRs and sorted the same way
17:07:24 <sandro> JohnArwe: The server picks the sorting, and just tells the client what it is.
17:07:27 <sandro> +1
17:07:31 <SteveS> +1
17:07:52 <sandro> should be LC-2815
17:07:53 <Ashok> +1
17:07:57 <TallTed> +1
17:08:02 <Arnaud> s/LC-285/2185/
17:08:04 <TallTed> s/LC-285/LC-2815
17:08:12 <nmihindu> +1
17:08:19 <nmihindu> +1 for mesteban
17:08:26 <Arnaud> RESOLVED: dispose of second part of LC-2815 by clarifying the intent in the spec: LDPCs are LDPRs and sorted the same way
17:08:39 <TallTed> s/of 2185 by/of LC-2815 by/
17:08:48 <sandro> topic: LC-2816
17:09:06 <sandro> Ashok: close this - it was an error on my part
17:09:35 <SteveS> http://lists.w3.org/Archives/Public/public-ldp-comments/2013Aug/0005.html
17:10:30 <sandro> topic: LC-2813
17:10:33 <sandro> https://www.w3.org/2006/02/lc-comments-tracker/55082/ldp/2813
17:10:49 <sandro> Ashok: From our product guys: What do we do about auth and acls?
17:11:26 <sandro> Arnaud: In the presentations I give, I include a slide "What We Are Not Doing".   These are obvious questions.  Let's provide this pro-actively.
17:11:53 <sandro> roger: This is in line with my comment this morning.  Pre-emptively, why are you not Type-4 Restful.
17:12:00 <SteveS> Enough to point to HTTP 11. Access Authentication http://www.w3.org/Protocols/rfc2616/rfc2616-sec11.html#sec11
17:12:28 <sandro> JohnArwe: Just point to http
17:12:43 <sandro> Ashok: They ask "should I use oauth", etc
17:13:00 <sandro> Arnaud: Let's have a non-normative security section.
17:13:53 <sandro> Ashok: Do we need a Security Considerations?
17:14:05 <sandro> sandro: No, that's IETF (eg Media Types) not W3C
17:15:19 <sandro> cody: So will we say something like Ashok suggests?
17:16:01 <Arnaud> PROPOSED: dispose of LC-2813 by adding a non-normative section on security setting the expectation right, pointing out that this isn't covered in LDP
17:16:13 <SteveS> +1
17:16:14 <sandro> +1
17:16:33 <TallTed> +1
17:16:34 <Ashok> +1
17:16:36 <roger> roger has joined #ldp
17:16:36 <nmihindu> +1
17:16:56 <nmihindu> +1 for mesteban
17:17:04 <bblfish> +1
17:17:07 <roger> +1
17:17:16 <Arnaud> RESOLVED: dispose of LC-2813 by adding a non-normative section on security setting the expectation right, pointing out that this isn't covered in LDP
17:18:09 <sandro> topic: Primer
17:19:18 <sandro> Arnaud: Roger, Nandana?
17:19:55 <roger> https://dvcs.w3.org/hg/ldpwg/raw-file/tip/ldp-primer/ldp-primer.html
17:19:55 <sandro> nmihindu: We have the examples.     Most of the content is done
17:21:01 <sandro> roger: It's a primer for understanding the spec, rather than for supporting massive use of LDP.   It's got a lot of detail about the spec.    It's a lot more than just Hello World, explained.
17:21:36 <sandro> roger: There's still a gap.  There's still a need for the 2-minute intro to LDP.   What it is, and why to use it.
17:22:11 <sandro> nmihindu: Let's do like with the use cases.   WG review...
17:22:27 <sandro> Arnaud: We need to get it to the point where the editors call it done.
17:22:41 <sandro> roger: I meant to get my part done by the F2F2.    But we're way more than 50%
17:23:06 <sandro> john: Is it done enough to have people review it?
17:24:53 <sandro> sandro: The process is (WD)* (WGNote)+
17:25:14 <sandro> nmihindu: If we go for a public comment draft.  It would be nice to have this with LC2.
17:25:38 <sandro> john: Point to it as informative reference from LC2
17:26:12 <sandro> sandro: Yeah - so we publish on the same day.
17:27:55 <sandro> Arnaud: So, when is it really going to be ready for WG review, for FPWD?
17:28:05 <sandro> nmihindu: Henry and Ashok agreed to review it.
17:28:08 <bblfish> q+
17:28:19 <Arnaud> ack bblfish
17:29:03 <sandro> bblfish: the WebID WG was just about to publish three WebID specs....
17:29:07 <sandro> sandro: There is no WebID WG
17:29:15 <cody> cody has joined #ldp
17:29:30 <sandro> Arnaud: Does that relate to the primer?
17:29:50 <TallTed> it's the WebID CG ... which is generally orthogonal, until we get to access control and the like
17:30:17 <sandro> bblfish: Just a bit of advertising here.
17:30:56 <sandro> sandro: WebID can ask LDPWG to review its spec.
17:31:05 <nmihindu> bblfish, we will talk about security in the primer referring to the access control note
17:31:06 <sandro> Arnaud: Sure, but let's talk about that later, not under Primer.
17:31:08 <bblfish> yes, I understand. It's just that there is one year to go https://dvcs.w3.org/hg/WebID/raw-file/tip/spec/index.html
17:31:23 <bblfish> and if you guys are interested to have this let me know.
17:31:43 <sandro> roger: We'll be done by the end of September.
17:31:56 <sandro> roger: 5-10 minutes feedback NOW would be excellent.
17:32:07 <sandro> q+
17:32:24 <Arnaud> ack sandro
17:32:46 <sandro> sandro: Why not make the Intro be the Hello World "primer"?
17:32:48 <bblfish> yes, the primer looks good
17:33:39 <sandro> sandro: the elevator pitch for LDP
17:33:48 <sandro> roger: Reasonable idea.
17:33:52 <cody> cody has joined #ldp
17:34:32 <bblfish> :-) Ah ok. I was going to say the same about it being Replace
17:34:34 <sandro> roger: My talk at RDFVal was a lot like the hello world
17:34:56 <sandro> roger: The pictures start to get not very useful, eg pagination.
17:37:17 <bblfish> q?
17:37:19 <bblfish> +q
17:37:58 <Arnaud> ack bblfish
17:37:59 <sandro> sandro: URLs should either be example.org or someone personally committed to maintaining them or hosted on W3C
17:38:15 <sandro> eric: like in the test harness.
17:39:17 <sandro> topic: TimBL's comments
17:39:31 <sandro> Arnaud: I tried to split Tim's comments up by topic.
17:40:00 <bblfish> Are you pointing at something?
17:40:05 <bblfish> a URL?
17:40:09 <sandro> https://www.w3.org/2006/02/lc-comments-tracker/55082/ldp/?status=open&
17:40:30 <sandro> subtopic: Vanilla
17:40:32 <sandro> https://www.w3.org/2006/02/lc-comments-tracker/55082/ldp/2833
17:41:00 <sandro> Arnaud: This is what we talked to Tim on the phone about
17:41:28 <sandro> Arnaud: Tim comes from a different point of view.  I want a generic server that would never drop my triples.
17:42:02 <sandro> .. We talked about important use case of domain-specific servers.   OSLC demo on bugzilla, turning it into LDP server.
17:42:28 <sandro> .. If the hard requirement is every server has to manage any kind of server, then things like that would never be LDP servers.
17:42:35 <sandro> .. He understood where we were coming from.
17:42:44 <sandro> .. He said maybe two levels of compliance
17:43:09 <sandro> SteveS: This bugzilla facada requires no storage.
17:43:34 <sandro> SteveS: You COULD put a triple store into the facade, but that adds a lot of implementation burden.
17:43:55 <sandro> Ashok: Difficulty is that the spec does not speak of app-specific servers and generic ones.
17:44:14 <sandro> Ashok: Let's talk about it early in the spec.   "You can do both of these things..... "
17:44:33 <bblfish> q+
17:44:39 <sandro> john: A lot of the SHOULDS become MUSTS
17:45:00 <sandro> SteveS: PUT "may" ...
17:45:09 <sandro> john: The adulteration stuff wouldn't be allowed
17:45:30 <sandro> q+
17:45:47 <Arnaud> ack bblfish
17:46:00 <sandro> SteveS: How would you detect if it's a chocolate or vanilla server
17:46:17 <sandro> bblfish: We need a way for a client to tell when there are restrictions or not.
17:46:30 <sandro> bblfish: Maybe a report on the Validation Workshop
17:46:47 <SteveS> q+
17:47:18 <sandro> .. I still believe you can come up with one relation that gives you a restriction.    Because RDF is a restriction of classes of things.   Relation from LDPC ....
17:47:42 <sandro> .. we don't need to wait for RDF Validation to be done.
17:47:46 <sandro> .. just define that relation
17:48:36 <sandro> 4.2.10 LDPR servers MUST advertise their LDP support by exposing a HTTP Link header with a target URI of http://www.w3.org/ns/ldp/Resource
17:49:07 <sandro> bblfish: Maybe the restriction is a ... something
17:49:17 <Arnaud> ack sandro
17:50:01 <roger> +q
17:50:21 <TallTed> sandro: seems like a simple solution is to build off current restriction, every LDPR is identified as such by type header
17:50:44 <TallTed> ... add generic_LDPR and restricted_LDPR subclasses
17:51:07 <sandro> SteveS: What are all the normative statements that would be different?
17:51:17 <bblfish> I was looking at the issue of a POST. In the case of an LDPC you could create a relation that says you can only POST a subset of all possible documents to that container. There remains the question of restrictions on PUT
17:51:27 <Arnaud> ack SteveS
17:51:31 <sandro> SteveS: Eg Tim requires Put-Creates, while I forbid Put-Creates.
17:51:44 <sandro> john: What are all the ways the client interaction model is different.
17:51:47 <Arnaud> ack roger
17:52:51 <sandro> roger: I don't see it as two different types.   If there's no guidance, you can put whatever you want.   ither the server says nothing and can accept everything...   or it gives you some constraints.
17:53:30 <sandro> sandro: Tim wants something more defined now.
17:53:42 <sandro> roger: I'd think what we have now would be prefect for Tim
17:53:52 <sandro> sandro: But he says it's not.
17:54:10 <sandro> Arnaud: 4.2.10 link header, type ldp:Resource
17:55:04 <bblfish> yes, create a subclass of ldp:Resource
17:55:13 <Ashok> q+
17:55:20 <bblfish> q+
17:55:29 <sandro> Arnaud: What if I don't know the ldp:Resource subclass?
17:55:55 <sandro> sandro: either client does subclass inference, OR the server enumerates all the classes in different Link type=   headers
17:56:49 <sandro> q+ to talk about Steve's Create issue
17:57:18 <sandro> roger: the thing advertises what it neads, to be involved
17:57:36 <sandro> john: Just because I feed a container RDF does not mean I get LDP
17:57:58 <sandro> Arnaud: Tim says "As long as I can figure out if this is my kind of server, then I'm fine".
17:57:58 <Arnaud> ack ashok
17:58:32 <sandro> Ashok: When you store these things, in my database or triples.  How do I store LDPRs differeent from other resources.
17:59:01 <Arnaud> ack bblfish
17:59:11 <sandro> sandro: I think you store metadata on most stuff you pull from the web
17:59:14 <sandro> Ashok: okay
17:59:24 <bblfish> To take the PUT case: an ldp that is constrained say to allow only specific types of bugzilla bugs would be an as section 4.2.10  says would advertise in the header that the resource is Link: <http://bugzilla.org/ont/Bug>; rel=type
18:00:01 <sandro> bblfish: Instead of resources advertise themselves as LDPR, advertise theselves as type "Bug" or whatever.
18:00:28 <sandro> bblfish: then that Bug URLs will at some point have some kind of description of what the restriction is.
18:00:42 <sandro> +1 (except also with server doing the inference)
18:00:46 <sandro> q?
18:00:58 <Arnaud> ack sandro
18:00:58 <Zakim> sandro, you wanted to talk about Steve's Create issue
18:03:10 <roger> +q
18:04:06 <sandro> PROPOSED: We'll add a subclass of LDPR for Tim's use cases, and say that servers offering such an LDPR must add link header, rel=type, ldp:VanillaServer (or whatever the class is called)
18:05:40 <sandro> roger: Henry's proposal doesn't work for me, I need parameterized classes or something
18:06:03 <sandro> roger: At some point I have a bug tracker for "ComplexBug" which needs more details
18:06:59 <sandro> roger: Second reason -- I think LDP should work without typed resources.
18:07:14 <roger> nothing against typed resource too ... :)
18:07:22 <roger> I just don't they need to be mandatory
18:07:26 <sandro> Arnaud: We could invent LDP:UnconstraintedResource
18:08:38 <Arnaud> ack roger
18:09:48 <bblfish> q+
18:10:00 <sandro> sandro: But Put-to-Create isn't really on a resource.    It's on a URI space?   Or maybe it's on an LDPC.
18:10:13 <sandro> bblfish: You could have a constraint relation.
18:10:48 <sandro> bblfish: And for now write out the constrains in English.
18:10:50 <Arnaud> ack bblfish
18:11:07 <sandro> sandro: WHat problem is that solving?
18:11:44 <sandro> bblfish: If something has a constraint and you can't understand the constraint, then you should know that you can't do certain things with it.
18:12:01 <roger> it is leaving the space open to put in the outcome of rdfval (possilbly), but, also to put in some kind of human documenation ...
18:12:20 <roger> and the human documentation will probably arrive before the rdfval output
18:12:31 <sandro> bblfish: I want both kinds of clients without having to wait for the WG to define everything.
18:12:40 <roger> +q
18:13:05 <gavinc> gavinc has joined #ldp
18:13:13 <sandro> bblfish: The Vanilla thing is too gross.   It's not solving the problem, just getting the spec through.
18:13:30 <bblfish> Q+
18:13:34 <sandro> Arnaud: Maybe in the future we can do something more sophisticated.
18:13:42 <roger> for reference, the priority for the rdfval workshop were prioritized: 1 declarative defintion of the structure of a graph for validation and description 2 extensible to address specialized use cases 3 there will be a mechanism to associate descriptions with data
18:14:02 <roger> ... and Henry seems to be asking for number 3 i think
18:14:15 <roger> if no.3 doesn't exist, then it's vanillia
18:14:25 <roger> i.e. if the property don't exist
18:16:06 <sandro> (scribe gives up for now)
18:18:32 <JohnArwe> JohnArwe has joined #ldp
18:18:45 <roger> +q
18:19:07 <Arnaud> ack roger
18:20:15 <JohnArwe> middle ground?  Link: rel=constraint, href=ldp:Unconstrained ...the only one LDP defines (Tim's set), but in the end it's open.
18:21:19 <Arnaud> ack bblfish
18:21:55 <sandro> sandro: either constraints or the classes of things which meet that constraint.    isomorphic framings.
18:22:11 <TallTed> +1 JohnArwe
18:23:35 <sandro> JohnArwe: We peel off the class of servers we need to address for Tim.   The others we leave to be addressed at some point.
18:25:22 <TallTed> http://www.iana.org/assignments/link-relations/link-relations.xhtml
18:25:28 <JohnArwe> ...seems completely compatible with henry's points
18:25:30 <sandro> cody: can we just use RDFS?
18:25:58 <sandro> sandro: Alas, RDFS and OWL have different semantics.   See Clark & Parsia work/products using altered semantics for OWL to use it for validation.
18:26:02 <bblfish> -1
18:26:18 <bblfish> -1 on the simple Constrained relation
18:26:42 <JohnArwe> how is that different from what you were positing henry?
18:26:56 <TallTed> rel=lrdd  -->  "Refers to further information about the link's context, expressed as a LRDD ("Link-based Resource Descriptor Document") resource. See [RFC6415] for information about processing this relation type in host-meta documents. When used elsewhere, it refers to additional links and other metadata. Multiple instances indicate additional LRDD resources. LRDD resources MUST have an "application/xrd+xml" representation, and MAY
18:26:57 <TallTed>  have others."
18:27:03 <bblfish> I am for a Link: <http://mozilla.org/bugs/ont#bug>; rel=constraint
18:27:30 <TallTed> see http://tools.ietf.org/html/rfc6415
18:27:40 <JohnArwe> So you want the absence of the constraint header to imply vanilla/unconstrained?
18:28:15 <JohnArwe> ...vs simply that you're dealing with an http resource
18:29:40 <TallTed> downside is requirement that LRDD resources must be available as XML.
18:29:44 <sandro> sandro: graph shape constraints are quite different from protocol action constraints.
18:30:22 <bblfish> ( ie rel=constraint ) And I am ok that this ends up the same as type statement, since a constraint creates a type
18:30:36 <sandro> sandro: A resource that handles Delete a particular way is clearly a particular class of resource.
18:30:45 <sandro> .. so let's use the classificaiton machiniery we have.
18:31:01 <sandro> Arnaud: Maybe we jumped ahead to far.  Let's go back to Tim's comment.
18:31:38 <sandro> Arnaud: Tim wanted MUSTS where we had SHOULDS, because of all sorts of constraints that stop a server from behaving a particular way, eg Read-Only Servers!
18:31:52 <JohnArwe> maybe I'm dense, but I still feel like you and are violently agreeing henry.
18:32:07 <bblfish> yes, agree there are different types of constraints: Data contraints, HTTP contstraints, consequences
18:34:13 <JohnArwe> s/you and are/Henry and I/
18:34:27 <sandro> sandro: Some constraints are good for the client -- agreement to do nice things for client -- and some are not -- agreement to do nice things for OTHER people.
18:35:59 <sandro> sandro: Maybe go through the differences from Tims
18:36:59 <bblfish> agree: I'd think the HTTP level should be as close together as possible
18:37:24 <bblfish> q+
18:38:04 <Arnaud> ack bblfish
18:38:52 <bblfish> yes, there is out of band contract which is the big problem, and there is efficiency is important.
18:39:27 <sandro> arnaud: I think part of the problem is Tim wants some pressure for folks to implement all the things his clients want.
18:40:12 <JohnArwe> Here's the wiki table Sandro: http://www.w3.org/2012/ldp/wiki/ISSUE-32
18:42:16 <bblfish> Tim also asked us to look at the MUSTs for the client and write those up.
18:43:16 <ericP> TallTed: we can identify a potentially inefficient contract that permits a client without an advanced contract to learn about a server
18:43:55 <TallTed> SteveS: compliance statements are unclear -- LDPR Server, LDPC Server, LDP Server -- conformance testing seems to start from profile statement
18:44:01 <Arnaud> scribe: TallTed
18:44:44 <TallTed> ... current examples include LDPR, LDPC; we're talking about adding constrained; question about writeable
18:45:32 <JohnArwe> @sandro: looking at the issue 32 wiki page and the "create constraints" case, no row for 5.4.9 despite that being an old MAY ... so I didn't count that as an "affordance"
18:45:52 <TallTed> ericP: generic, then containers, then resources...  behavior we have for posting to container to create resources is not expected of generic client?
18:46:42 <TallTed> ... intend a PUTtable (PATCHable) container?  what are all the graph shapes you might get as result?
18:46:45 <davidwood> davidwood has joined #ldp
18:47:02 <TallTed> ... may need to constrain containers to have same interactions whether backed by triple store or otherwise...
18:49:55 <bblfish> I agree
18:52:07 <bblfish> yes, I agree that there are LDPC and LDPR that are constrained  and so for constrained Resources we need to sepcify the constraint
18:52:09 <bblfish> q+
18:52:27 <Arnaud> ack bblfish
18:53:02 <TallTed> bblfish: the need is to specify constraints applying on the server side, such that the client can understand them
18:53:16 <bblfish> yes
18:53:51 <davidwood> "LDP servers capable of storing arbitrary data" vs. "LDP servers capable of storing only pre-specified data elements"
18:54:44 <bblfish> which one?
18:55:42 <TallTed> Arnaud: timbl gave several hints about what might work, which we should explore
18:56:18 <TallTed> ... setting multiple levels of compliance is easier than handling all the different types of constraints
18:56:59 <TallTed> ... he also said something like, a silent failure is terrifying.  this is true, and we have several points with silent failure (or success).
18:57:52 <TallTed> ... the struggle comes down to, we're not telling the client whether something failed, and if it *did* fail, how/why
18:58:10 <roger> either the client calls the shots, or the server does.
18:58:32 <roger> if the client calls the shots, the server needs to be ready for anything (i.e. vanilla)
18:58:44 <TallTed> ericP: during the RDF Validation workshop, there was a big debate about whether you can specify that a server only accepts a subset of triples
18:58:55 <roger> if the server calls the shots, the client does what it is told.
18:59:12 <TallTed> ... if a server throws away some of your triples, should you get a 2xx or 4xx result?
18:59:16 <bblfish> q+
18:59:51 <bblfish> q-]
18:59:53 <bblfish> q-
19:00:59 <TallTed> davidwood: it's worth spending time on the general-purpose use cases, since this all started from a fairly specific-case analysis
19:01:37 <TallTed> ... writing a client, I would love to know that working against LDP Server A, I get different results than against LDP Server B, without recoding...
19:02:01 <TallTed> (20 minute break)
19:21:56 <SteveS> SteveS has joined #ldp
19:22:48 <davidwood> davidwood has joined #ldp
19:23:12 <TallTed> (convo resumes)
19:24:15 <bblfish> hi
19:24:31 <bblfish> yes, I am back.
19:25:15 <bblfish> we can't solve all the problems
19:25:53 <bblfish> q+
19:26:39 <TallTed>   rel=type  type=ldpServer       implies unconstrained;
19:26:39 <TallTed> + rel=type  type=URI             dereference leads to constraint definition
19:26:41 <Arnaud> ack bblfish
19:27:37 <TallTed> bblfish: constraints on http methods seem different from constraints on content
19:28:07 <TallTed> ... one is on the type of speech actions, the other is on the type (or specifics) of content
19:28:34 <sandro> "content constraints" and "behavior constraints"
19:28:59 <TallTed> sandro: validation workshop was all about content constraints; we know we're not solving that here
19:29:01 <bblfish> we can't solve the content constraints but we can provide the hook.
19:29:27 <TallTed> davidwood: early spec version said that LDP servers would only support a limited vocabulary
19:30:10 <TallTed> ... we could solve content constraints in a limited way, by allowing server to advertise URI to RDF graph specifying that server's supported vocabularies, data types, predicates, etc.
19:30:35 <TallTed> ... client could detect that, and know what it could (not) do on that basis
19:31:49 <TallTed> ... could have a sample/standard/basic version of this in w3 space, with ability for server-specific local
19:33:10 <TallTed> Arnaud: the "silent" aspect isn't addressed there...  we need to start opening a set of issues on these points
19:34:06 <TallTed> ... what exactly are we missing?  "content constraints" won't be solved, but we need to somehow communicate to the client whether there *is* a set of such constraints
19:35:01 <TallTed> ... do we need to advertise "I'm a vanilla server"? does silence somewhere imply that? does silence imply something else?
19:35:38 <JohnArwe> JohnArwe has joined #ldp
19:35:41 <TallTed> roger: maybe we should define a predicate that targets the graph constraints document.  if it's there, constrained.  if not, vanilla/unconstrained.
19:36:34 <bblfish> I am +1 with haiving a relation with domain ldp:Resource and range a subset of foaf:Document .
19:37:01 <TallTed> Arnaud: could be within the content, could be in the header, best to be in both
19:37:04 <bblfish> yes, the link header is rdf
19:37:52 <TallTed> SteveS: rel=describedby could be the one to use
19:38:22 <TallTed> sandro: likes roger's idea of the constraint spec through a header URI
19:38:36 <roger> +q
19:38:39 <TallTed> Ashok: what happens for violations?
19:38:56 <TallTed> sandro: protocol question. could be silent failure, could be error, etc.
19:39:36 <TallTed> Arnaud: need to do something about transparency of partial success/failure, etc.
19:39:56 <davidwood> Ashok, davidwood not happy with silent failures
19:39:58 <TallTed> sandro: if you're a shape-constraining server, you have to validate immediately, and provide results
19:40:09 <bblfish> q+
19:41:03 <TallTed> Ashok: I've heard 3 ideas -- (1) application specific; (2) code says partial storage, partial drop, or delete not done; (3) validation
19:41:07 <Arnaud> ack roger
19:41:08 <TallTed> ... is this enough?
19:41:14 <JohnArwe> I do find I'm reacting badly to the notion that absence means unconstrained (vs having no knowledge of constraints), although I have trouble articulating exactly why.
19:41:38 <TallTed> roger: in terms of constraining, have to constrain content if you want to PUT to it, different constraints apply to POST
19:41:58 <sandro> +1 roger   ldpc needs a shape for itself and a shape for things that are POSTed to it.
19:42:00 <bblfish> The point is not to do the constraint language here, other than allow an rdfs:comment on the linked to resource that describes in human language what the constraint is.
19:42:07 <TallTed> ... describedby is good for PUT and POST, but not for GET.  accepts might be viable
19:42:17 <bblfish> Agree that we need different relation for an LDPC what needs to be POSTed
19:42:41 <bblfish> q-
19:42:42 <TallTed> sandro: LDPC needs 2 shapes -- one for PUT, another for POST -- one for exists, one for doesn't exist
19:43:22 <TallTed> Arnaud: need to communicate that there are no constraints
19:43:26 <bblfish> q+
19:43:37 <TallTed> sandro: absence of any constraints means it's a vanilla graph
19:44:14 <TallTed> ... one predicate is graph restraints for LDPR, another predicate is member constraints for LDPC
19:44:15 <Arnaud> ack bblfish
19:45:58 <TallTed> Arnaud: what does the proposal look like?  I am a client, doing a GET on resource... how do I know I'm dealing with an LDP Server? that the resource is LDPR, LDPC, etc?
19:46:34 <bblfish> it's a Link header
19:46:49 <bblfish> Arnaud it's a Link header of rel = somethypetobedecidedlater
19:46:57 <TallTed> sandro: if the server wants to limit the shape of LDPR content, it will have a Link header to that effect. if if wants to limit shape of LDPC submission, it has a Link header to that effect.
19:47:33 <bblfish> seems good to me
19:48:14 <TallTed> sandro: objection might come from Bugzilla-facade (and similar) space, who'd have to include an extra header
19:50:16 <sandro> PROPOSED: When a server answers a GET or HEAD on an LDPR for which the RDF graph is somehow constrained MUST include a Link header giving a URL for the given constraint.   We wont actually specify at this time how those constraints are specified.   Natural language is okay for now.
19:51:10 <bblfish> IT also constrains the GET
19:51:15 <sandro> (this is independent of possible variablity in protocol behaviors, like silent failure of DELETE)
19:51:33 <bblfish> +1
19:51:47 <TallTed> +1
19:51:55 <JohnArwe> I think we also need to MUST that on 4xx responses that fail due to violation of the constraints.
19:51:58 <davidwood> +0.5, I would really like to see an RDF vocab developed and used for these descriptions
19:52:01 <roger> +1 and I beleive we need to do this for POST at this stage too.
19:52:06 <ericP> +1
19:52:08 <sandro> the constraint is on the possible graph shapes -- so it affects GET and PUT and PATCH.
19:52:22 <nmihindu> +0.5 for the same reasons as davidwood
19:52:25 <sandro> +1
19:52:35 <SteveS> +1
19:52:36 <sandro> The absense of this header means the absense of such a constraint.
19:52:50 <nmihindu> +0.5 - mesteban for the same reasons as davidwood
19:52:52 <sandro> +0.5
19:52:57 <Ashok> 0.5 also want to see protocol constraints
19:53:27 <bblfish> +0.5 I think in HTTP one can do things like that.
19:53:37 <Arnaud> RESOLVED: When a server answers a GET or HEAD on an LDPR for which the RDF graph is somehow constrained MUST include a Link header giving a URL for the given constraint.   We wont actually specify at this time how those constraints are specified.   Natural language is okay for now. The absense of this header means the absense of such a constraint.
19:54:10 <Arnaud> RESOLVED: When a server answers a GET or HEAD on an LDPR for which the RDF graph is somehow constrained it MUST include a Link header giving a URL for the given constraint.   We wont actually specify at this time how those constraints are specified.   Natural language is okay for now. The absense of this header means the absense of such a constraint.
19:54:30 <JohnArwe> Proposal: we also MUST that on 4xx responses that fail due to violation of the constraints.
19:55:27 <JohnArwe> q+ to get consensus on 4xx proposal
19:55:36 <bblfish> +1 that we should specify what error messages happen on partial acceptance
19:55:39 <Arnaud> ack john
19:55:39 <Zakim> JohnArwe, you wanted to get consensus on 4xx proposal
19:56:01 <sandro> +1 so you can see what caused the failure
19:56:07 <TallTed> +1
19:56:22 <davidwood> +1
19:56:33 <nmihindu> +1
19:57:02 <bblfish> +1
19:57:48 <roger> +1
19:57:55 <SteveS> cody +1
19:57:59 <ericP> +1
19:58:01 <SteveS> +1
19:58:14 <nmihindu> +1 for mesteban
19:58:24 <bblfish> ah I see
19:59:03 <Arnaud> RESOLVED: servers MUST also have that header on 4xx responses that fail due to violation of the constraints.
19:59:04 <bblfish> one gets the constraint header on a 40x or 208.5 if there was an error on constraint
19:59:35 <TallTed> RESOLVED: servers MUST also have that header on 4xx responses to any verb (PUT, POST, etc.) that fail due to violation of the constraints.
19:59:52 <bblfish> +1 for better wording by TallTed
20:00:39 <TallTed> sandro: this explicitly bifurcates LDPRs into constrained and unconstrained.  how do we handle relevant specs MUSTs, SHOULDs, etc?
20:01:21 <bblfish> Proposal: Same as above for 208.5
20:01:48 <betehess_mit> are authentication and authorization constraints as well?
20:02:11 <bblfish> betehess_mit: we are dealing with content constraints only
20:02:22 <TallTed> [...chatter...]
20:02:37 <bblfish> betehess_mit: graph constraints, or even mime type constraints I suppose
20:03:03 <betehess_mit> well that's important, because the shape constraints could be based on the user
20:03:26 <JohnArwe> Sandro: does this new header bifurcate the spec further, along the lines of "if your data is constrained, MUST, else 'not MUST'"
20:04:10 <TallTed> sandro: do we now need CLDPRs, CLDPCs?
20:04:27 <TallTed> SteveS: and/or WCLDPRs (writeable)?
20:04:43 <bblfish> q+
20:05:35 <TallTed> JohnArwe: the 208.5 discussion was outcome of "server did sort of what you wanted, and here are the results of what I did"
20:05:57 <Arnaud> ack bblfish
20:06:50 <TallTed> bblfish: might invent another code where the server returns the triples it didn't accept -- no second GET needed
20:07:54 <JohnArwe> @sandro: see 4.5.1 for current text ... MUST with a MAY escape clause
20:09:07 <TallTed> ericP: maybe we want a request header that says "accept all or nothing -- no 208.5, only 200 or 4xx"
20:09:20 <bblfish> I agree we may not care now.
20:09:26 <bblfish> We should perhaps wait to see if we need it
20:09:38 <TallTed> Arnaud: do we have a use case for this "throw stuff at the wall" scenario?
20:09:59 <bblfish> yes, that was a 203.5
20:12:02 <TallTed> SteveS: I can think of FDA scenarios that want to keep everything possible, but not sure whether that means it keeps *everything*
20:12:18 <bblfish> q+
20:12:19 <TallTed> SteveS: the norm is failing when constraints are not met
20:12:25 <Arnaud> ack bblfish
20:12:56 <sandro> q?
20:13:00 <TallTed> bblfish: if you want to be flexible, don't put constraints...
20:13:47 <TallTed> Arnaud: I see 2 use cases.  want the server to accept anything/everything, or only application-specific.
20:14:02 <TallTed> Ashok: what if you send 100 triples, half validate, half do not... ?
20:14:46 <TallTed> consensus: you should get an error
20:14:56 <bblfish> agree with Arnaud for the moment on the whole for the moment: either make constriants more general if you can accept more, or if you can't accept it all then the client may be trying to say something: eg I want to buy some size xx shoes, and the server accepts that you wanted to buy shoes
20:15:11 <TallTed> sandro: the way we're using it, POST is CREATE, so it has to result in a valid starting state for the created resource
20:15:33 <bblfish> or say I create a command for a minature matchbox car, and the server accepts this and charges me for a 2CV car
20:15:35 <TallTed> ... PUT is wholesale replacement, so it also has to result in valid starting state
20:16:07 <TallTed> Arnaud: points to 4.5.4 "... LDPR server could discard triples ..."
20:16:56 <bblfish> yes we can always add a 203.5 later
20:16:59 <TallTed> sandro: I think we're leaning toward the server MUST accept all or none, partial silent discard is a definite issue
20:18:17 <bblfish> q+
20:18:24 <SteveS> q+
20:18:44 <TallTed> cody: if I have a commenting engine (v1), with a certain schema.  at some point, (v2) two properties are no longer relevant, so schema has changed, and clients are now submitting useless fields
20:18:59 <TallTed> ... don't want to have to update all clients to update the server
20:19:09 <Arnaud> ack bblfish
20:20:27 <Arnaud> ack steve
20:21:36 <bblfish> ok, I agree the use case makes sense
20:22:01 <TallTed> SteveS: if I GET a resource (bug report), modify it, PUT back -- want system to ignore the "date I got it"
20:22:28 <JohnArwe> I also poked cody to make sure this is captured in UC&R; if we forgot it once, we'll do so again ;-)
20:22:40 <TallTed> Arnaud: so we have use cases for this.  how do we address it?
20:22:55 <bblfish> can we write up that use case in detail?
20:23:37 <SteveS> bblfish, who are you asking?
20:23:48 <SteveS> which use case?
20:23:59 <TallTed> JohnArwe: could add new status code; use warning header (nobody uses it, but it's defined); go to soft vs hard requests; else?
20:24:39 <bblfish> the use case where the server changes and stops accepting certain fields. What kind of fields wree thought to be unimportant later?
20:25:23 <TallTed> ... two proposals -- can use existing status codes when client intent is known.  harder to address when client intent unknown.
20:25:57 <bblfish> q+
20:26:08 <bblfish> q-
20:26:15 <SteveS> The spec lists some of them, prime example is dc:modified or modifiedBy, these are things that a server computes on write.  A client would have these in the content it GETs and would need to strip these "server managed" before PUTing back the content, with modified prroperty
20:27:13 <bblfish> q+
20:27:22 <Arnaud> ack bblfish
20:27:34 <TallTed> [ ... discussion about response codes ... ]
20:28:41 <TallTed> bblfish: trying to order a matchbox car shouldn't result in ordering a full-size, so need the "all or nothing" request ability
20:29:53 <TallTed> sandro: none of the existing 2xx codes fit what we want
20:29:58 <bblfish> http://en.wikipedia.org/wiki/Http_error_codes#2xx_Success
20:30:11 <bblfish> 207 Multi-Status (WebDAV; RFC 4918)
20:30:24 <bblfish> 208 Already Reported (WebDAV; RFC 5842)
20:30:34 <bblfish> 226 IM Used (RFC 3229)
20:31:37 <bblfish> I am not suggesting those, just saying that others have created new 20x codes
20:31:50 <bblfish> here http://en.wikipedia.org/wiki/Http_error_codes#2xx_Success
20:31:52 <bblfish> Arnaud:
20:32:03 <davidwood> https://en.wikipedia.org/wiki/List_of_HTTP_status_codes
20:34:49 <TallTed> Arnaud: we're agreed we don't want to leave the spec as-is, with silent failure
20:35:23 <bblfish> +1 we don't leave things as is
20:36:55 <Arnaud> PROPOSED: change the spec, somehow, so that in case the server discards some of triples the client sent it informs the client
20:37:12 <TallTed> +1
20:37:15 <SteveS> +1
20:37:21 <nmihindu> +1
20:37:21 <sandro> +1 yes we can fallback on to a Link Header, in the worst case
20:37:27 <roger> +1
20:37:30 <SteveS> +1 for Cody
20:37:30 <Ashok> +1
20:37:38 <nmihindu> +1 for mesteban
20:37:46 <Arnaud> RESOLVED: change the spec, somehow, so that in case the server discards some of triples the client sent it informs the client
20:38:35 <Arnaud> ACTION: Steve to investigate how to change the spec so that in case the server discards some of triples the client sent it informs the client
20:38:35 <trackbot> 'Steve' is an ambiguous username. Please try a different identifier, such as family name or username (e.g., sbattle2, sspeiche).
20:38:51 <Arnaud> ACTION: SteveSto investigate how to change the spec so that in case the server discards some of triples the client sent it informs the client
20:38:51 <trackbot> Error finding 'SteveSto'. You can review and register nicknames at <http://www.w3.org/2012/ldp/track/users>.
20:38:59 <Arnaud> ACTION: SteveS to investigate how to change the spec so that in case the server discards some of triples the client sent it informs the client
20:39:00 <trackbot> Created ACTION-93 - Investigate how to change the spec so that in case the server discards some of triples the client sent it informs the client [on Steve Speicher - due 2013-09-19].
20:39:12 <roger> +q to do the same link header we did a while back but for POST instead ...
20:40:00 <bblfish> q+
20:41:41 <Arnaud> ack roger
20:41:41 <Zakim> roger, you wanted to do the same link header we did a while back but for POST instead ...
20:41:47 <TallTed> Arnaud: how about this 4.5.6 "MUST allow PUT"?
20:43:04 <Arnaud> ack bblfish
20:44:17 <roger> roger has joined #ldp
20:45:59 <TallTed> action: steves to investigate clarified presentation of Client and Server requirements
20:45:59 <trackbot> Created ACTION-94 - Investigate clarified presentation of client and server requirements [on Steve Speicher - due 2013-09-19].
20:46:39 <TallTed> Arnaud: is there anything else needing discussion in https://www.w3.org/2006/02/lc-comments-tracker/55082/ldp/2833
20:47:13 <TallTed> ... what about the DELETE, in 4.6.2?
20:47:53 <bblfish> what are we looking at?
20:49:00 <bblfish> q+
20:51:14 <bblfish> So there is a waitress with whome a server is intimate...
20:51:33 <TallTed> ... what is the scope of the DELETE method being issued?
20:52:01 <TallTed> ... limited to the server being addressed?
20:52:07 <Arnaud> ack bblfish
20:52:54 <TallTed> bblfish: we delete an LDPR, the created should be deleted from the LDPC... but how do we maintain truth?
20:53:15 <TallTed> ... is there a problem if we don't specify something now, that we might have to specify in the future?
20:53:56 <TallTed> ... can't spec something now that will break clients in the future
20:54:19 <JohnArwe> Seems to me that 4.6.2 is just a restatement of http, with a tiny bit of specificity to rdf.
20:55:15 <TallTed> ...seems related to the creation ripples -- when you create something, triples may be added elsewhere
20:55:49 <TallTed> JohnArwe: 4.6.2 is LDPR specific, and really restates HTTP
20:56:30 <TallTed> davidwood: when a resource is added to Calimachus, we put it into a named graph, and provenance into another named graph
20:56:51 <TallTed> ... deleting the resource, we leave the provenance, but drop the resource's named graph
20:57:43 <JohnArwe> Proposal: make 4.6.2 informative, clarify that it re-states what http allows, and in fact it applies to all methods not just delete.
20:58:17 <davidwood> s/Calimachus/Callimachus/
20:59:17 <Ashok> Ashok has joined #ldp
21:00:33 <TallTed> +1
21:00:45 <SteveS> +1
21:00:56 <davidwood> +1
21:01:16 <nmihindu> +1
21:02:39 <nmihindu> +1 for mesteban
21:02:44 <roger> ++1
21:03:00 <Arnaud> RESOLVED: make 4.6.2 informative, clarify that it re-states what http allows, and in fact it applies to all methods not just delete.
21:03:01 <JohnArwe> +1
21:03:57 <JohnArwe> arnaud points out that this also hits 5.6.2, second sentence
21:05:05 <Zakim> -bblfish
21:05:08 <bblfish> oops
21:06:27 <Zakim> +bblfish
21:06:30 <Zakim> -Workshop_room
21:06:32 <Zakim> +Workshop_room
21:08:03 <bblfish> It's late for me
21:09:30 <bblfish> where?
21:10:32 <SteveS> 4.10.2.3
21:10:49 <Arnaud> PROPOSED: change SHOULD to MUST in 4.10.2.3 LDPR servers that initiate paging SHOULD respond to request ...
21:11:04 <JohnArwe> +1
21:11:05 <TallTed> +1
21:11:07 <sandro> +1
21:11:09 <Ashok> +1
21:11:21 <roger> +1
21:11:32 <nmihindu> +1
21:11:34 <davidwood> +1
21:11:35 <SteveS> +1
21:11:39 <nmihindu> +1 for mesteban
21:11:42 <Arnaud> RESOLVED: change SHOULD to MUST in 4.10.2.3 LDPR servers that initiate paging SHOULD respond to request ...
21:11:42 <SteveS> +1 for Cody
21:14:34 <bblfish> q+
21:15:17 <Arnaud> ack bblfish
21:17:36 <davidwood> http://www.ietf.org/rfc/rfc2616.txt in Section 14.30 (Location header)
21:17:53 <bblfish> The meaning of Location header has changed in the latest http 2.0 specs btw.
21:17:54 <SteveS> Looking at HTTP-bis drafts http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-23
21:18:11 <bblfish> http1.1 is out of date
21:19:35 <bblfish> earlier I said: that I noticed that 303 in RDF is required for when one is dereferencing an object that is not an information resource, but that this is not the issue at all here. We are just pointing to another resource. So it could be that the Location header works here.
21:20:42 <bblfish> http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-23#section-7.1.2
21:20:55 <bblfish> 7.1.2.  Location
21:20:55 <bblfish>    The "Location" header field is used in some responses to refer to a
21:20:55 <bblfish>    specific resource in relation to the response.  The type of
21:20:57 <bblfish>    relationship is defined by the combination of request method and
21:20:59 <bblfish>    status code semantics.
21:21:01 <bblfish>      Location = URI-reference
21:21:53 <davidwood> Location headers also seem to be undefined in http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-23#section-7.1.2
21:23:22 <bblfish> http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-23#section-7.1.2
21:30:52 <bblfish> q+
21:31:20 <Arnaud> ack bblfish
21:37:50 <JohnArwe> I would truly love it if TallTed is able to locate something indicating that 200+Location is usable for our purposes.
21:37:58 <JohnArwe> ...have wished for same thing myself.
21:38:42 <bblfish> ok, guys its close to midnight here
21:38:46 <bblfish> (wavE)
21:38:50 <Zakim> -bblfish
21:45:00 <Zakim> -Workshop_room
21:45:01 <Zakim> SW_LDP()8:30AM has ended
21:45:01 <Zakim> Attendees were rgarcia, Workshop_room, bblfish
21:46:46 <Arnaud> trackbot, end meeting
21:46:46 <trackbot> Zakim, list attendees
21:46:46 <Zakim> sorry, trackbot, I don't know what conference this is
21:46:54 <trackbot> RRSAgent, please draft minutes
21:46:54 <RRSAgent> I have made the request to generate http://www.w3.org/2013/09/12-ldp-minutes.html trackbot
21:46:55 <trackbot> RRSAgent, bye
21:46:55 <RRSAgent> I see 4 open action items saved in http://www.w3.org/2013/09/12-ldp-actions.rdf :
21:46:55 <RRSAgent> ACTION: Steve to investigate how to change the spec so that in case the server discards some of triples the client sent it informs the client [1]
21:46:55 <RRSAgent>   recorded in http://www.w3.org/2013/09/12-ldp-irc#T20-38-35
21:46:55 <RRSAgent> ACTION: SteveSto investigate how to change the spec so that in case the server discards some of triples the client sent it informs the client [2]
21:46:55 <RRSAgent>   recorded in http://www.w3.org/2013/09/12-ldp-irc#T20-38-51
21:46:55 <RRSAgent> ACTION: SteveS to investigate how to change the spec so that in case the server discards some of triples the client sent it informs the client [3]
21:46:55 <RRSAgent>   recorded in http://www.w3.org/2013/09/12-ldp-irc#T20-38-59
21:46:55 <RRSAgent> ACTION: steves to investigate clarified presentation of Client and Server requirements [4]
21:46:55 <RRSAgent>   recorded in http://www.w3.org/2013/09/12-ldp-irc#T20-45-59