13:04:01 <RRSAgent> logging to http://www.w3.org/2013/09/12-ldp-irc
RRSAgent IRC Bot: logging to http://www.w3.org/2013/09/12-ldp-irc ←
13:04:03 <trackbot> RRSAgent, make logs public
Trackbot IRC Bot: RRSAgent, make logs public ←
13:04:05 <trackbot> Zakim, this will be LDP
Trackbot IRC Bot: Zakim, this will be LDP ←
13:04:05 <Zakim> ok, trackbot; I see SW_LDP()8:30AM scheduled to start 34 minutes ago
Zakim IRC Bot: 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
Arnaud Le Hors: 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?
Arnaud Le Hors: zakim, who's on the phone? ←
13:04:47 <Zakim> SW_LDP()8:30AM has not yet started, Arnaud
Zakim IRC Bot: 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
Zakim IRC Bot: 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
Zakim IRC Bot: SW_LDP()8:30AM has now started ←
13:05:20 <Zakim> +??P3
Zakim IRC Bot: +??P3 ←
13:05:32 <rgarcia> zakim, ??P3 is me
Raúl García Castro: zakim, ??P3 is me ←
13:05:32 <Zakim> +rgarcia; got it
Zakim IRC Bot: +rgarcia; got it ←
13:07:51 <Arnaud> hi guys
Arnaud Le Hors: hi guys ←
13:08:03 <Arnaud> we're still setting things up in the room
Arnaud Le Hors: we're still setting things up in the room ←
13:08:11 <Arnaud> we'll be starting shortly
Arnaud Le Hors: we'll be starting shortly ←
13:10:37 <Zakim> +Workshop_room
Zakim IRC Bot: +Workshop_room ←
13:10:57 <Arnaud> zakim, who's on the phone?
Arnaud Le Hors: zakim, who's on the phone? ←
13:10:57 <Zakim> On the phone I see rgarcia, Workshop_room
Zakim IRC Bot: On the phone I see rgarcia, Workshop_room ←
13:11:30 <rgarcia> zakim, mute me
Raúl García Castro: zakim, mute me ←
13:11:30 <Zakim> rgarcia should now be muted
Zakim IRC Bot: rgarcia should now be muted ←
13:11:59 <SteveS> Scribe: SteveS
(Scribe set to Steve Speicher)
<SteveS> chair: Arnaud
<SteveS> agenda: http://www.w3.org/2012/ldp/wiki/F2F4
13:12:23 <SteveS> Topic: F2F Agenda Review
13:13:01 <SteveS> Reviewing http://www.w3.org/2012/ldp/wiki/F2F4
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
Arnaud Le Hors: 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)
Arnaud Le Hors: reviewing last call handling of comments and reaching CR (or another LC) ←
13:16:30 <SteveS> …pretty sure we'll need to go to another last call based on how we handle TBL's comments
…pretty sure we'll need to go to another last call based on how we handle TBL's comments ←
13:18:05 <rgarcia> Now the sound is better
Raúl García Castro: Now the sound is better ←
13:19:13 <SteveS> Arnaud: primarily will be working on TBLs feedback/issues the next couple of days
Arnaud Le Hors: 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
Arnaud Le Hors: 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
Raúl García Castro: 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
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)
Raúl García Castro: Today or tomorrow (better tomorrow) ←
13:22:24 <SteveS> davidwood: has conflict 1-2:30 today
David Wood: has conflict 1-2:30 today ←
13:22:36 <SteveS> sandro: has conflict 11-12 today
Sandro Hawke: 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
Arnaud Le Hors: 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: Last Call Comments & Issues
13:25:01 <SteveS> Arnaud: tickering with agenda
Arnaud Le Hors: tickering with agenda ←
13:26:47 <SteveS> See tracker http://www.w3.org/2006/02/lc-comments-tracker/55082/ldp/
See tracker http://www.w3.org/2006/02/lc-comments-tracker/55082/ldp/ ←
13:27:08 <SteveS> Arnaud: put Tim's comments into this, including others
Arnaud Le Hors: 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
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
Zakim IRC Bot: +bblfish ←
13:28:50 <bblfish> hi
Henry Story: hi ←
13:29:50 <SteveS> JohnArwe: it is possible that the WG addresses a comment that the commenter doesn't agree with
John Arwe: 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
Arnaud Le Hors: 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)
(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?
John Arwe: 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
Arnaud Le Hors: yes, we should get WG consensus on it before we distribute ←
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
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> http://www.w3.org/2006/02/lc-comments-tracker/55082/ldp/2812
Arnaud Le Hors: http://www.w3.org/2006/02/lc-comments-tracker/55082/ldp/2812 ←
13:34:38 <SteveS> subTopic: Mark Baker's comment LC-2812
13:35:09 <SteveS> JohnArwe: Mark pokes on the redefinition of DELETE in our spec
John Arwe: 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
Sandro Hawke: 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
David Wood: done in a way in that it is hard/impossible to enforce a true delete ←
13:38:12 <bblfish> q+
Henry Story: q+ ←
13:38:52 <Arnaud> ack bblfish
Arnaud Le Hors: ack bblfish ←
13:39:30 <davidwood> bblfish: We should ask Mark what danger he sees if we redefine HTTP DELETE
Henry Story: We should ask Mark what danger he sees if we redefine HTTP DELETE [ Scribe Assist by David Wood ] ←
13:39:32 <SteveS> bblfish: we should go back and ask what exactly he thinks will break
Henry Story: we should go back and ask what exactly he thinks will break ←
13:39:59 <SteveS> JohnArwe: had interaction with mark and he thinks LDP client should be same as a generic HTTP client
John Arwe: had 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
Henry Story: wonders if he has any issue with container specific behavior ←
13:41:33 <SteveS> Ashok: do we agree that clients are generic?
Ashok Malhotra: do we agree that clients are generic? ←
13:41:54 <SteveS> Arnaud: seems to be a common question we keep hearing
Arnaud Le Hors: 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.
Henry Story: 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+
Henry Story: 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
Arnaud Le Hors: 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
Arnaud Le Hors: ack bblfish ←
13:43:45 <SteveS> davidwood: we have the liberty to expand on what is in HTTP and need specialized LDP interaction
David Wood: we have the liberty to expand on what is in HTTP and need specialized LDP interaction ←
13:44:33 <TallTed> q+
Ted Thibodeau: 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
Henry Story: 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
David Wood: bblfish, yes, we agree on that ←
13:45:40 <roger> +q
Roger Menday: +q ←
13:46:03 <Arnaud> ack TallTed
Arnaud Le Hors: 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
Ted Thibodeau: 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+
Henry Story: q+ ←
13:47:40 <SteveS> sandro: is curl or LDP client??
Sandro Hawke: is curl an LDP client?? ←
13:48:06 <Arnaud> s/or LDP/an LDP/
13:48:28 <Arnaud> ack roger
Arnaud Le Hors: ack roger ←
13:48:33 <SteveS> JohnArwe: curl is HTTP client
John Arwe: 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
Roger Menday: 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
Arnaud Le Hors: 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
Henry Story: 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
Roger Menday: 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
Henry Story: 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
Arnaud Le Hors: 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?
Arnaud Le Hors: can you make a recap of the discussion on the talks that you were at? [ Scribe Assist by Henry Story ] ←
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 !!
Roger Menday: 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
Arnaud Le Hors: 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
Sandro Hawke: 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
…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
John Arwe: 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
Sandro Hawke: 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
…I think these pass that test (are conformance criteria) and don't agree with Mark here ←
13:56:52 <bblfish> q+
Henry Story: 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
John Arwe: 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
Sandro Hawke: 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.
Eric Prud'hommeaux: 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
Sandro Hawke: 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
Ted Thibodeau: 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
Arnaud Le Hors: ack bblfish ←
14:02:31 <sandro> q?
Sandro Hawke: q? ←
14:02:52 <nmihindu> q+
Nandana Mihindukulasooriya: q+ ←
14:03:10 <Ashok> q+
Ashok Malhotra: q+ ←
14:03:52 <davidwood> q+ to discuss generic HTTP clients operating on LDP servers
David Wood: 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.
Sandro Hawke: 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
Henry Story: 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
Arnaud Le Hors: ack nmihindu ←
14:04:59 <Arnaud> ack Ashok
Arnaud Le Hors: ack Ashok ←
14:05:00 <SteveS> nmihindu: agrees with sandro in that the behavior server but more on the specific web resource
Nandana Mihindukulasooriya: 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.
David Wood: +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?
Ashok Malhotra: 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
Ted Thibodeau: 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 [ Scribe Assist by Ted Thibodeau ] ←
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.
Ted Thibodeau: 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. [ Scribe Assist by Ted Thibodeau ] ←
14:05:50 <TallTed> TallTed: (human + curl) can be LDP client. curl alone is an HTTP client.
Ted Thibodeau: (human + curl) can be LDP client. curl alone is an HTTP client. [ Scribe Assist by Ted Thibodeau ] ←
14:05:58 <sandro> you do an HTTP interaction with it.
Sandro Hawke: you do an HTTP interaction with it. ←
14:06:22 <SteveS> SteveS: you can inspect the Link header with type ldp:Resource
Steve Speicher: you can inspect the Link header with type ldp:Resource ←
14:06:36 <ericP> q?
Eric Prud'hommeaux: q? ←
14:06:38 <SteveS> as a response to any request, OPTIONS is the lightest
as a response to any request, OPTIONS is the lightest ←
14:06:53 <Arnaud> ack davidwood
Arnaud Le Hors: ack davidwood ←
14:06:53 <Zakim> davidwood, you wanted to discuss generic HTTP clients operating on LDP servers
Zakim IRC Bot: 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
David Wood: 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 ?
Nandana Mihindukulasooriya: TallTed, (script + curl) could be an LDP client too, isn't it ? ←
14:09:22 <TallTed> nmihindu - yes, human effectively delegates to script
Ted Thibodeau: 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].
Sandro Hawke: 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+
Henry Story: 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
David Wood: 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
Arnaud Le Hors: ack bblfish ←
14:13:55 <SteveS> bblfish: believes that this could be an access control, allowing then only additive and can preserve
Henry Story: 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
Ted Thibodeau: 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
Sandro Hawke: 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.
Henry Story: 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?
Miguel Esteban Gutiérrez: 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
Ted Thibodeau: not sure this is any ←
14:19:34 <SteveS> Arnaud: what do we need to get back with Mark
Arnaud Le Hors: 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
John Arwe: 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.
Sandro Hawke: 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
Henry Story: I think we agree here. +1 ←
14:21:15 <davidwood> +1
David Wood: +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
Henry Story: distinguish LDP Resources, LDP Clients and HTTP Clients . LDP Cleints are subsets of HTTP Clients. LDP resources are a subset of HTTP resources ←
14:23:08 <sandro> q+
Sandro Hawke: 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
Ted Thibodeau: 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
Henry Story: 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.
Sandro Hawke: 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
Arnaud Le Hors: 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."
Sandro Hawke: Maybe "An 'ldp client' is an HTTP client that is interacting with an LDPR or LDPC." ←
14:25:10 <Arnaud> ack sandro
Arnaud Le Hors: 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.
Zakim IRC Bot: 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
John Arwe: 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.
Nandana Mihindukulasooriya: +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.
Sandro Hawke: changing opinion that there isn't an LDP client, in that there is rules for HTTP clients that interact with LDP resources/servers. ←
14:27:06 <bblfish> q+
Henry Story: q+ ←
14:28:12 <SteveS> TallTed: sees that GET/PUT and the separate client activity on the data and the rest is the protocol
Ted Thibodeau: sees that GET/PUT and the separate client activity on the data and the rest is the protocol ←
14:28:21 <bblfish> q?
Henry Story: 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
Sandro Hawke: 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
Arnaud Le Hors: ack bblfish ←
14:29:14 <SteveS> bblfish: question of what is an LDP client?
Henry Story: question of what is an LDP client? ←
14:29:31 <davidwood> q+ to discuss the lack of transactionality
David Wood: 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.
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
Steve Speicher: 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
Ted Thibodeau: 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
Arnaud Le Hors: ack davidwood ←
14:32:11 <Zakim> davidwood, you wanted to discuss the lack of transactionality
Zakim IRC Bot: davidwood, you wanted to discuss the lack of transactionality ←
14:32:14 <sandro> thanks steve.
Sandro Hawke: 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
David Wood: 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
Sandro Hawke: you can use etags 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.
David Wood: 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).
Sandro Hawke: 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
Arnaud Le Hors: 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
Arnaud Le Hors: not hearing a normative change to a spec ←
14:37:34 <SteveS> JohnArwe: agree, perhaps some editorial
John Arwe: 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.
Henry Story: 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 )
Henry Story: ( we have to be careful to distinguish those ) ←
14:38:48 <bblfish> ( A browser is a generic HTML+http client )
Henry Story: ( A browser is a generic HTML+http client ) ←
14:39:06 <TallTed> +1 bblfish
Ted Thibodeau: +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 behavior specified in this spec (when serving an LDPR).
PROPOSED: 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 behavior specified in this spec (when serving an LDPR). ←
14:40:16 <sandro> +1
Sandro Hawke: +1 ←
14:40:30 <nmihindu> +1
Nandana Mihindukulasooriya: +1 ←
14:40:31 <SteveS> +1
+1 ←
14:40:40 <nmihindu> +1 for mesteban
Nandana Mihindukulasooriya: +1 for mesteban ←
14:40:49 <TallTed> +1
Ted Thibodeau: +1 ←
14:40:52 <rgarcia> +1
Raúl García Castro: +1 ←
14:41:42 <roger> +! and we say that we are working on the gap (hateoas shaped)
Roger Menday: +! and we say that we are working on the gap (hateoas shaped) ←
14:41:43 <ericP> +1
Eric Prud'hommeaux: +1 ←
14:41:43 <davidwood> +1
David Wood: +1 ←
14:41:52 <SteveS> +1 for JohnArwe
+1 for JohnArwe ←
14:41:54 <roger> +!
Roger Menday: +! ←
14:41:58 <roger> +1
Roger Menday: +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 behavior specified in this spec (when serving an LDPR).
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 behavior specified in this spec (when serving an LDPR). ←
14:42:11 <davidwood> ☃
David Wood: ☃ ←
14:42:27 <davidwood> Sorry, that should be +☃
David Wood: Sorry, that should be +☃ ←
14:43:07 <bblfish> 🍹
Henry Story: 🍹 ←
14:43:16 <bblfish> 🍹?
Henry Story: 🍹? ←
14:43:38 <bblfish> 👍
Henry Story: 👍 ←
15:02:02 <davidwood> Back from break
(No events recorded for 18 minutes)
David Wood: Back from break ←
15:02:25 <davidwood> scribenick: davidwood
(Scribe set to David Wood)
<davidwood> subtopic: Inlining - LC-2837
15:02:59 <davidwood> Arnaud: Reviewing outstanding comments, issues and features at risk
Arnaud Le Hors: Reviewing outstanding comments, issues and features at risk ←
15:03:21 <davidwood> …There is quite a bit of work to do.
…There is quite a bit of work to do. ←
15:03:36 <sandro> (watching IRC from 30m away, sitting in another meeting)
Sandro Hawke: (watching IRC from 30m away, sitting in another meeting) ←
15:04:21 <davidwood> …The issue regarding inlined resources came up.
…The issue regarding inlined resources came up. ←
15:04:57 <roger> http://www.w3.org/2006/02/lc-comments-tracker/55082/ldp/2837
Roger Menday: http://www.w3.org/2006/02/lc-comments-tracker/55082/ldp/2837 ←
15:06:10 <davidwood> …inlining is currently at-risk: http://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp.html#member-inlining-returning-all-of-a-container-page-s-members-in-a-response
…inlining is currently at-risk: http://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.
…propose to remove it from the spec. ←
15:07:32 <Ashok> q+
Ashok Malhotra: q+ ←
15:08:23 <Arnaud> ack ashok
Arnaud Le Hors: ack ashok ←
15:08:46 <davidwood> Ashok: Is inlining a requirement? If so, it should be fixed.
Ashok Malhotra: Is inlining a requirement? If so, it should be fixed. ←
15:08:47 <SteveS> q+
Steve Speicher: 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?
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.
Arnaud Le Hors: It would not be addressed under this proposal. ←
15:10:36 <Arnaud> ack SteveS
Arnaud Le Hors: ack SteveS ←
15:11:09 <davidwood> John, Eric: Addressing this requirement out of band is not addressing it in an interoperable way.
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.
Steve Speicher: 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.
Ashok Malhotra: Maybe just leave it as a feature at risk. ←
15:13:38 <davidwood> Arnaud: I don't think we have time to fix it.
Arnaud Le Hors: 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.
Henry Story: the problem is that this requires TriG and N3 for it to work. ←
15:14:57 <bblfish> q+
Henry Story: q+ ←
15:15:17 <SteveS> or multi-part/mixed
Steve Speicher: or multi-part/mixed ←
15:15:18 <davidwood> TriG is on the Rec track.
TriG is on the Rec track. ←
15:15:25 <Arnaud> ack bblfish
Arnaud Le Hors: ack bblfish ←
15:15:49 <davidwood> bblfish: We need TriG, and the spec might be ready. We could do it later.
Henry Story: 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
Steve Speicher: 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.
Arnaud Le Hors: We would need to evaluate multiple proposals, and don't have time. ←
15:16:32 <bblfish> ah yes and there is SPEEDY too
Henry Story: ah yes and there is SPEEDY too ←
15:17:46 <davidwood> SPDY proposal at IETF: http://tools.ietf.org/html/draft-mbelshe-httpbis-spdy-00
SPDY proposal at IETF: http://tools.ietf.org/html/draft-mbelshe-httpbis-spdy-00 ←
15:17:54 <Arnaud> PROPOSAL: Drop inlining from the spec, put it on the wish list for LDPnext
PROPOSED: Drop inlining from the spec, put it on the wish list for LDPnext ←
15:18:03 <rgarcia> +1
Raúl García Castro: +1 ←
15:18:07 <nmihindu> +1
Nandana Mihindukulasooriya: +1 ←
15:18:08 <Ashok> 0
Ashok Malhotra: 0 ←
15:18:10 <roger> +1
Roger Menday: +1 ←
15:18:15 <nmihindu> +1 for mesteban
Nandana Mihindukulasooriya: +1 for mesteban ←
15:18:17 <davidwood> +0
+0 ←
15:18:35 <bblfish> +1
Henry Story: +1 ←
15:18:42 <TallTed> +1
Ted Thibodeau: +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.
Arnaud Le Hors: 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.
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.
Henry Story: 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
Steve Speicher: +1 ←
15:21:59 <ericP> +1
Eric Prud'hommeaux: +1 ←
15:22:31 <davidwood> RESOLVED: Drop inlining from the spec, put it on the wish list for LDPnext
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?
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.
Trackbot IRC Bot: Error creating an ISSUE: an internal error occurred. Please mail <sysreq@w3.org> with details about what happened. ←
<davidwood> subtopic: ISSUE-81 - Confusing predicate names
15:26:51 <TallTed> issue-81?
15:26:51 <trackbot> issue-81 -- Confusing membership* predicate names and other possible improvements -- raised
Trackbot IRC Bot: ISSUE-81 -- Confusing membership* predicate names and other possible improvements -- raised ←
15:26:51 <trackbot> http://www.w3.org/2012/ldp/track/issues/81
Trackbot IRC Bot: 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
Trackbot IRC Bot: 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
Trackbot IRC Bot: http://www.w3.org/2012/ldp/track/issues/83 ←
15:27:05 <davidwood> CLOSE ISSUE-83
15:27:05 <trackbot> Closed ISSUE-83.
Trackbot IRC Bot: Closed ISSUE-83. ←
15:27:20 <davidwood> ISSUE-81
15:27:20 <trackbot> ISSUE-81 -- Confusing membership* predicate names and other possible improvements -- raised
Trackbot IRC Bot: ISSUE-81 -- Confusing membership* predicate names and other possible improvements -- raised ←
15:27:20 <trackbot> http://www.w3.org/2012/ldp/track/issues/81
Trackbot IRC Bot: http://www.w3.org/2012/ldp/track/issues/81 ←
15:28:15 <davidwood> John: Readers are confused by the membership predicate names.
John Arwe: Readers are confused by the membership predicate names. ←
15:28:24 <davidwood> Arnaud: Open ISSUE-81?
Arnaud Le Hors: Open ISSUE-81? ←
15:28:38 <davidwood> OPEN ISSUE-81
15:28:41 <TallTed> +1 open it
Ted Thibodeau: +1 open it ←
15:28:53 <Arnaud> PROPOSAL: Open ISSUE-81
15:29:01 <nmihindu> +1
Nandana Mihindukulasooriya: +1 ←
15:29:02 <rgarcia> +1
Raúl García Castro: +1 ←
15:29:03 <TallTed> +81
Ted Thibodeau: +81 ←
15:29:07 <Ashok> +1
Ashok Malhotra: +1 ←
15:29:09 <roger> +1
Roger Menday: +1 ←
15:29:12 <nmihindu> +1 for mesteban
Nandana Mihindukulasooriya: +1 for mesteban ←
15:29:16 <SteveS> +1
Steve Speicher: +1 ←
15:29:34 <davidwood> REOPEN ISSUE-81
15:29:34 <trackbot> Re-opened ISSUE-81.
Trackbot IRC Bot: 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
Steve Speicher: Discussing how membership is expressed in an LDPC ←
15:31:10 <davidwood> …ldp:membershipObject is confusing compared with other membership* predicates.
…ldp:membershipObject is confusing compared with other membership* predicates. ←
15:31:12 <roger> +q
Roger Menday: +q ←
15:32:44 <davidwood> …ldp:membershipPredicate and ldp:membershipPredicateInverse also confusing. ldp:membershipPredicateInverse turns membershipPredicateSubject into an Object...
…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.
John Arwe: ldp:membershipPredicateInverse is poorly named - cannot explain it well to people. ←
15:35:50 <Arnaud> http://www.w3.org/2012/ldp/track/issues/81
Arnaud Le Hors: http://www.w3.org/2012/ldp/track/issues/81 ←
15:36:35 <davidwood> SteveS: Walking through proposals in ISSUE-81
Steve Speicher: 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.
Ted Thibodeau: 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+
Henry Story: q+ ←
15:39:39 <davidwood> …This proposal will cause more confusion.
…This proposal will cause more confusion. ←
15:41:22 <Arnaud> ack roger
Arnaud Le Hors: 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.
…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.
John Arwe: The inverse case is more common. ←
15:42:59 <davidwood> SteveS: slightly - maybe 60/40
Steve Speicher: slightly - maybe 60/40 ←
15:43:19 <davidwood> Arnaud: Do not want to reopen an issue just for terminology.
Arnaud Le Hors: Do not want to reopen an issue just for terminology. ←
15:44:15 <Arnaud> ack bblfish
Arnaud Le Hors: ack bblfish ←
15:44:59 <davidwood> bblfish: Propose to have a member relation that points to a blank node with spo properties.
Henry Story: 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 }/
Ted Thibodeau: maybe s/ldp:membershipPredicateInverse/{ ldp:containmentPredicate | ldp:containershipPredicate }/ ←
15:45:31 <bblfish> ldp:consequence [ lpd:subject ... ; ldp:object ...; ldp:predicate ]
Henry Story: ldp:consequence [ lpd:subject ... ; ldp:object ...; ldp:predicate ] ←
15:47:04 <davidwood> John: SteveS's proposal does address part of what bblfish wants.
John Arwe: 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.
Arnaud Le Hors: We only need a different syntax to use for the design we already have. ←
15:48:27 <roger> +q
Roger Menday: +q ←
15:48:57 <Arnaud> ack roger
Arnaud Le Hors: ack roger ←
15:50:33 <davidwood> EricP: What pattern will a user look to in order to find out how to traverse an LDPC?
Eric Prud'hommeaux: 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
Arnaud Le Hors: and what pattern will the server invoke when a client POSTs a new resource [ Scribe Assist by Eric Prud'hommeaux ] ←
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.
Roger Menday: 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 ... ] .
Henry Story: 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 ] .
Henry Story: 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
Henry Story: 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
David Wood: in callimacus, we run into the issues where we've left cardinalities implicit and we end up seeing e.g. n HTTP <title/>s [ Scribe Assist by Eric Prud'hommeaux ] ←
15:57:28 <davidwood> davidwood: Encourage the editors to define any implicit cardinalities.
David Wood: 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.
(No events recorded for 11 minutes)
David Wood: Propose to change the terms to use meaningful names instead of Subject, Predicate, Object. ←
16:09:31 <davidwood> …e.g. ldp:consistentResourceURI
…e.g. ldp:consistentResourceURI ←
16:09:49 <davidwood> Discussion ensues
Discussion ensues ←
16:09:51 <TallTed> ldp:membershipCollectiveName ldp:membershipRelationshipName ldb:membershipMemberName
Ted Thibodeau: ldp:membershipCollectiveName ldp:membershipRelationshipName ldb:membershipMemberName ←
16:10:42 <TallTed> or
Ted Thibodeau: or ←
16:10:42 <TallTed> ldp:membershipAggregateeName ldp:membershipAggregateRelationship ldb:membershipAggregateElement
Ted Thibodeau: ldp:membershipAggregateeName ldp:membershipAggregateRelationship ldb:membershipAggregateElement ←
16:11:31 <TallTed> or better
Ted Thibodeau: or better ←
16:11:31 <TallTed> ldp:membershipAggregateeName ldp:membershipAggregateRelation ldb:membershipAggregateElement
Ted Thibodeau: ldp:membershipAggregateeName ldp:membershipAggregateRelation ldb:membershipAggregateElement ←
16:12:29 <davidwood> Arnaud: We will break on this for now to let people think about naming.
Arnaud Le Hors: We will break on this for now to let people think about naming. ←
16:12:42 <davidwood> …and maybe even a change in design.
…and maybe even a change in design. ←
16:13:37 <davidwood> Breaking 30 minutes for lunch.
Breaking 30 minutes for lunch. ←
16:13:42 <Zakim> -rgarcia
Zakim IRC Bot: -rgarcia ←
16:16:56 <Zakim> -bblfish
Zakim IRC Bot: -bblfish ←
16:51:42 <sandro> scribe: sandro
(No events recorded for 34 minutes)
(Scribe set to Sandro Hawke)
16:51:47 <sandro> RRSAgent, pointer?
RRSAgent, pointer? ←
16:51:47 <RRSAgent> See http://www.w3.org/2013/09/12-ldp-irc#T16-51-47
RRSAgent IRC Bot: See http://www.w3.org/2013/09/12-ldp-irc#T16-51-47 ←
16:51:54 <sandro> RRSAgent, make logs public
RRSAgent, make logs public ←
16:52:17 <sandro> subtopic: LC-2815 - Nested containers (Ashok's)
16:52:25 <sandro> Ashok, I think we resolved this one already.
Ashok, I think we resolved this one already. ←
16:54:03 <sandro> Ashok, We didn't address containers within containers -- how does ordering work?
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?
Ashok Malhotra: 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.
Steve Speicher: Yes. Ordering is in the data. An LDPC is an LDPR. ←
16:57:30 <sandro> SteveS: You could order on the non-member properties
Steve Speicher: 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?
Ashok Malhotra: 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?
Steve Speicher: 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.
Steve Speicher: 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
Arnaud Le Hors: 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.
Ashok Malhotra: 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.
Ted Thibodeau: 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.
Ashok Malhotra: It might confuse people. ←
17:02:09 <sandro> SteveS: IBM usernames example
Steve Speicher: IBM usernames example ←
17:02:33 <sandro> .. #steve, #john, ...
.. #steve, #john, ... ←
17:03:04 <sandro> cody: Isn't it likely the containers wont have the same properties?
Cody Burleson: Isn't it likely the containers wont have the same properties? ←
17:03:14 <sandro> SteveS: Yes.
Steve Speicher: 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.
Arnaud Le Hors: 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.
Arnaud Le Hors: in main spec, not best practice. ←
17:04:41 <sandro> cody: But aren't the properties going to be different?
Cody Burleson: 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.
Steve Speicher: 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.
Arnaud Le Hors: Ordered by that property, but several resources don't have that property. ←
17:05:27 <Zakim> +bblfish
Zakim IRC Bot: +bblfish ←
17:06:00 <sandro> sandro: Servers can make sure all the contained elements have the sort property you want
Sandro Hawke: 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?
Cody Burleson: 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
PROPOSED: dispose of second part of LC-2815 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.
John Arwe: The server picks the sorting, and just tells the client what it is. ←
17:07:27 <sandro> +1
+1 ←
17:07:31 <SteveS> +1
Steve Speicher: +1 ←
17:07:52 <sandro> should be LC-2815
should be LC-2815 ←
17:07:53 <Ashok> +1
Ashok Malhotra: +1 ←
17:07:57 <TallTed> +1
Ted Thibodeau: +1 ←
17:08:02 <Arnaud> s/LC-285/2185/
17:08:04 <TallTed> s/LC-285/LC-2815
17:08:12 <nmihindu> +1
Nandana Mihindukulasooriya: +1 ←
17:08:19 <nmihindu> +1 for mesteban
Nandana Mihindukulasooriya: +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
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> subtopic: LC-2816 - Ordering
17:09:06 <sandro> Ashok: close this - it was an error on my part
Ashok Malhotra: 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
Steve Speicher: http://lists.w3.org/Archives/Public/public-ldp-comments/2013Aug/0005.html ←
17:10:30 <sandro> subtopic: LC-2813 - Access control
17:10:33 <sandro> http://www.w3.org/2006/02/lc-comments-tracker/55082/ldp/2813
http://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?
Ashok Malhotra: 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.
Arnaud Le Hors: 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.
Roger Menday: 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
Steve Speicher: 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
John Arwe: Just point to http ←
17:12:43 <sandro> Ashok: They ask "should I use oauth", etc
Ashok Malhotra: They ask "should I use oauth", etc ←
17:13:00 <sandro> Arnaud: Let's have a non-normative security section.
Arnaud Le Hors: Let's have a non-normative security section. ←
17:13:53 <sandro> Ashok: Do we need a Security Considerations?
Ashok Malhotra: Do we need a Security Considerations? ←
17:14:05 <sandro> sandro: No, that's IETF (eg Media Types) not W3C
Sandro Hawke: No, that's IETF (eg Media Types) not W3C ←
17:15:19 <sandro> cody: So will we say something like Ashok suggests?
Cody Burleson: 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
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
Steve Speicher: +1 ←
17:16:14 <sandro> +1
+1 ←
17:16:33 <TallTed> +1
Ted Thibodeau: +1 ←
17:16:34 <Ashok> +1
Ashok Malhotra: +1 ←
17:16:36 <nmihindu> +1
Nandana Mihindukulasooriya: +1 ←
17:16:56 <nmihindu> +1 for mesteban
Nandana Mihindukulasooriya: +1 for mesteban ←
17:17:04 <bblfish> +1
Henry Story: +1 ←
17:17:07 <roger> +1
Roger Menday: +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
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?
Arnaud Le Hors: Roger, Nandana? ←
17:19:55 <roger> http://dvcs.w3.org/hg/ldpwg/raw-file/tip/ldp-primer/ldp-primer.html
Roger Menday: http://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
Nandana Mihindukulasooriya: 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.
Roger Menday: 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.
Roger Menday: 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...
Nandana Mihindukulasooriya: 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.
Arnaud Le Hors: 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%
Roger Menday: 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?
John Arwe: Is it done enough to have people review it? ←
17:24:53 <sandro> sandro: The process is (WD)* (WGNote)+
Sandro Hawke: 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.
Nandana Mihindukulasooriya: 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
John Arwe: Point to it as informative reference from LC2 ←
17:26:12 <sandro> sandro: Yeah - so we publish on the same day.
Sandro Hawke: 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?
Arnaud Le Hors: 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.
Nandana Mihindukulasooriya: Henry and Ashok agreed to review it. ←
17:28:08 <bblfish> q+
Henry Story: q+ ←
17:28:19 <Arnaud> ack bblfish
Arnaud Le Hors: ack bblfish ←
17:29:03 <sandro> bblfish: the WebID WG was just about to publish three WebID specs....
Henry Story: the WebID WG was just about to publish three WebID specs.... ←
17:29:07 <sandro> sandro: There is no WebID WG
Sandro Hawke: There is no WebID WG ←
17:29:30 <sandro> Arnaud: Does that relate to the primer?
Arnaud Le Hors: 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
Ted Thibodeau: 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.
Henry Story: Just a bit of advertising here. ←
17:30:56 <sandro> sandro: WebID can ask LDPWG to review its spec.
Sandro Hawke: 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
Nandana Mihindukulasooriya: 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.
Arnaud Le Hors: 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 http://dvcs.w3.org/hg/WebID/raw-file/tip/spec/index.html
Henry Story: yes, I understand. It's just that there is one year to go http://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.
Henry Story: 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.
Roger Menday: We'll be done by the end of September. ←
17:31:56 <sandro> roger: 5-10 minutes feedback NOW would be excellent.
Roger Menday: 5-10 minutes feedback NOW would be excellent. ←
17:32:07 <sandro> q+
q+ ←
17:32:24 <Arnaud> ack sandro
Arnaud Le Hors: ack sandro ←
17:32:46 <sandro> sandro: Why not make the Intro be the Hello World "primer"?
Sandro Hawke: Why not make the Intro be the Hello World "primer"? ←
17:32:48 <bblfish> yes, the primer looks good
Henry Story: yes, the primer looks good ←
17:33:39 <sandro> sandro: the elevator pitch for LDP
Sandro Hawke: the elevator pitch for LDP ←
17:33:48 <sandro> roger: Reasonable idea.
Roger Menday: Reasonable idea. ←
17:34:32 <bblfish> :-) Ah ok. I was going to say the same about it being Replace
Henry Story: :-) 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
Roger Menday: 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.
Roger Menday: The pictures start to get not very useful, eg pagination. ←
17:37:17 <bblfish> q?
Henry Story: q? ←
17:37:19 <bblfish> +q
Henry Story: +q ←
17:37:58 <Arnaud> ack bblfish
Arnaud Le Hors: ack bblfish ←
17:37:59 <sandro> sandro: URLs should either be example.org or someone personally committed to maintaining them or hosted on W3C
Sandro Hawke: 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.
Eric Prud'hommeaux: like in the test harness. ←
17:39:17 <sandro> topic: Last Call Comments & Issues (continues)
17:39:31 <sandro> Arnaud: I tried to split Tim's comments up by topic.
Arnaud Le Hors: I tried to split Tim's comments up by topic. ←
17:40:00 <bblfish> Are you pointing at something?
Henry Story: Are you pointing at something? ←
17:40:05 <bblfish> a URL?
Henry Story: a URL? ←
17:40:09 <sandro> http://www.w3.org/2006/02/lc-comments-tracker/55082/ldp/?status=open&
http://www.w3.org/2006/02/lc-comments-tracker/55082/ldp/?status=open& ←
17:40:30 <sandro> subtopic: Interop level / Vanilla - LC-2833
17:40:32 <sandro> http://www.w3.org/2006/02/lc-comments-tracker/55082/ldp/2833
http://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
Arnaud Le Hors: 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.
Arnaud Le Hors: 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.
.. 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.
.. 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.
.. He understood where we were coming from. ←
17:42:44 <sandro> .. He said maybe two levels of compliance
.. He said maybe two levels of compliance ←
17:43:09 <sandro> SteveS: This bugzilla facada requires no storage.
Steve Speicher: 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.
Steve Speicher: 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.
Ashok Malhotra: 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..... "
Ashok Malhotra: Let's talk about it early in the spec. "You can do both of these things..... " ←
17:44:33 <bblfish> q+
Henry Story: q+ ←
17:44:39 <sandro> john: A lot of the SHOULDS become MUSTS
John Arwe: A lot of the SHOULDS become MUSTS ←
17:45:00 <sandro> SteveS: PUT "may" ...
Steve Speicher: PUT "may" ... ←
17:45:09 <sandro> john: The adulteration stuff wouldn't be allowed
John Arwe: The adulteration stuff wouldn't be allowed ←
17:45:30 <sandro> q+
q+ ←
17:45:47 <Arnaud> ack bblfish
Arnaud Le Hors: ack bblfish ←
17:46:00 <sandro> SteveS: How would you detect if it's a chocolate or vanilla server
Steve Speicher: 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.
Henry Story: 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
Henry Story: Maybe a report on the Validation Workshop ←
17:46:47 <SteveS> q+
Steve Speicher: 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 ....
.. 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.
.. we don't need to wait for RDF Validation to be done. ←
17:47:46 <sandro> .. just define that relation
.. 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
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
Henry Story: Maybe the restriction is a ... something ←
17:49:17 <Arnaud> ack sandro
Arnaud Le Hors: ack sandro ←
17:50:01 <roger> +q
Roger Menday: +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
Sandro Hawke: seems like a simple solution is to build off current restriction, every LDPR is identified as such by type header [ Scribe Assist by Ted Thibodeau ] ←
17:50:44 <TallTed> ... add generic_LDPR and restricted_LDPR subclasses
Ted Thibodeau: ... add generic_LDPR and restricted_LDPR subclasses ←
17:51:07 <sandro> SteveS: What are all the normative statements that would be different?
Steve Speicher: 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
Henry Story: 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
Arnaud Le Hors: ack SteveS ←
17:51:31 <sandro> SteveS: Eg Tim requires Put-Creates, while I forbid Put-Creates.
Steve Speicher: 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.
John Arwe: What are all the ways the client interaction model is different. ←
17:51:47 <Arnaud> ack roger
Arnaud Le Hors: 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.
Roger Menday: 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.
Sandro Hawke: Tim wants something more defined now. ←
17:53:42 <sandro> roger: I'd think what we have now would be prefect for Tim
Roger Menday: I'd think what we have now would be prefect for Tim ←
17:53:52 <sandro> sandro: But he says it's not.
Sandro Hawke: But he says it's not. ←
17:54:10 <sandro> Arnaud: 4.2.10 link header, type ldp:Resource
Arnaud Le Hors: 4.2.10 link header, type ldp:Resource ←
17:55:04 <bblfish> yes, create a subclass of ldp:Resource
Henry Story: yes, create a subclass of ldp:Resource ←
17:55:13 <Ashok> q+
Ashok Malhotra: q+ ←
17:55:20 <bblfish> q+
Henry Story: q+ ←
17:55:29 <sandro> Arnaud: What if I don't know the ldp:Resource subclass?
Arnaud Le Hors: 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
Sandro Hawke: 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
q+ to talk about Steve's Create issue ←
17:57:18 <sandro> roger: the thing advertises what it neads, to be involved
Roger Menday: 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
John Arwe: 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".
Arnaud Le Hors: 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
Arnaud Le Hors: 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.
Ashok Malhotra: 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
Arnaud Le Hors: ack bblfish ←
17:59:11 <sandro> sandro: I think you store metadata on most stuff you pull from the web
Sandro Hawke: I think you store metadata on most stuff you pull from the web ←
17:59:14 <sandro> Ashok: okay
Ashok Malhotra: 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
Henry Story: 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.
Henry Story: 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.
Henry Story: 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)
+1 (except also with server doing the inference) ←
18:00:46 <sandro> q?
q? ←
18:00:58 <Arnaud> ack sandro
Arnaud Le Hors: ack sandro ←
18:00:58 <Zakim> sandro, you wanted to talk about Steve's Create issue
Zakim IRC Bot: sandro, you wanted to talk about Steve's Create issue ←
18:03:10 <roger> +q
Roger Menday: +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)
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
Roger Menday: 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
Roger Menday: 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.
Roger Menday: Second reason -- I think LDP should work without typed resources. ←
18:07:14 <roger> nothing against typed resource too ... :)
Roger Menday: nothing against typed resource too ... :) ←
18:07:22 <roger> I just don't they need to be mandatory
Roger Menday: I just don't they need to be mandatory ←
18:07:26 <sandro> Arnaud: We could invent LDP:UnconstraintedResource
Arnaud Le Hors: We could invent LDP:UnconstraintedResource ←
18:08:38 <Arnaud> ack roger
Arnaud Le Hors: ack roger ←
18:09:48 <bblfish> q+
Henry Story: 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.
Sandro Hawke: 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.
Henry Story: You could have a constraint relation. ←
18:10:48 <sandro> bblfish: And for now write out the constrains in English.
Henry Story: And for now write out the constrains in English. ←
18:10:50 <Arnaud> ack bblfish
Arnaud Le Hors: ack bblfish ←
18:11:07 <sandro> sandro: WHat problem is that solving?
Sandro Hawke: 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.
Henry Story: 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 ...
Roger Menday: 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
Roger Menday: 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.
Henry Story: I want both kinds of clients without having to wait for the WG to define everything. ←
18:12:40 <roger> +q
Roger Menday: +q ←
18:13:13 <sandro> bblfish: The Vanilla thing is too gross. It's not solving the problem, just getting the spec through.
Henry Story: The Vanilla thing is too gross. It's not solving the problem, just getting the spec through. ←
18:13:30 <bblfish> Q+
Henry Story: Q+ ←
18:13:34 <sandro> Arnaud: Maybe in the future we can do something more sophisticated.
Arnaud Le Hors: 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
Roger Menday: 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
Roger Menday: ... 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
Roger Menday: if no.3 doesn't exist, then it's vanillia ←
18:14:25 <roger> i.e. if the property don't exist
Roger Menday: i.e. if the property don't exist ←
18:16:06 <sandro> (scribe gives up for now)
(scribe gives up for now) ←
18:18:45 <roger> +q
Roger Menday: +q ←
18:19:07 <Arnaud> ack roger
Arnaud Le Hors: 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.
John Arwe: 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
Arnaud Le Hors: ack bblfish ←
18:21:55 <sandro> sandro: either constraints or the classes of things which meet that constraint. isomorphic framings.
Sandro Hawke: either constraints or the classes of things which meet that constraint. isomorphic framings. ←
18:22:11 <TallTed> +1 JohnArwe
Ted Thibodeau: +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.
John Arwe: 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
Ted Thibodeau: http://www.iana.org/assignments/link-relations/link-relations.xhtml ←
18:25:28 <JohnArwe> ...seems completely compatible with henry's points
John Arwe: ...seems completely compatible with henry's points ←
18:25:30 <sandro> cody: can we just use RDFS?
Cody Burleson: 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.
Sandro Hawke: 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
Henry Story: -1 ←
18:26:18 <bblfish> -1 on the simple Constrained relation
Henry Story: -1 on the simple Constrained relation ←
18:26:42 <JohnArwe> how is that different from what you were positing henry?
John Arwe: 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
Ted Thibodeau: 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."
Ted Thibodeau: have others." ←
18:27:03 <bblfish> I am for a Link: <http://mozilla.org/bugs/ont#bug>; rel=constraint
Henry Story: I am for a Link: <http://mozilla.org/bugs/ont#bug>; rel=constraint ←
18:27:30 <TallTed> see http://tools.ietf.org/html/rfc6415
Ted Thibodeau: see http://tools.ietf.org/html/rfc6415 ←
18:27:40 <JohnArwe> So you want the absence of the constraint header to imply vanilla/unconstrained?
John Arwe: 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
John Arwe: ...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.
Ted Thibodeau: 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.
Sandro Hawke: 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
Henry Story: ( 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.
Sandro Hawke: 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.
.. 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.
Arnaud Le Hors: 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!
Arnaud Le Hors: 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.
John Arwe: maybe I'm dense, but I still feel like Henry and I violently agreeing henry. ←
18:32:07 <bblfish> yes, agree there are different types of constraints: Data contraints, HTTP contstraints, consequences
Henry Story: 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.
Sandro Hawke: 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
Sandro Hawke: 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
Henry Story: agree: I'd think the HTTP level should be as close together as possible ←
18:37:24 <bblfish> q+
Henry Story: q+ ←
18:38:04 <Arnaud> ack bblfish
Arnaud Le Hors: ack bblfish ←
18:38:52 <bblfish> yes, there is out of band contract which is the big problem, and there is efficiency is important.
Henry Story: 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.
Arnaud Le Hors: 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
John Arwe: Here's the wiki table Sandro: ISSUE-32">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.
Henry Story: 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
Ted Thibodeau: we can identify a potentially inefficient contract that permits a client without an advanced contract to learn about a server [ Scribe Assist by Eric Prud'hommeaux ] ←
18:43:55 <TallTed> SteveS: compliance statements are unclear -- LDPR Server, LDPC Server, LDP Server -- conformance testing seems to start from profile statement
Steve Speicher: compliance statements are unclear -- LDPR Server, LDPC Server, LDP Server -- conformance testing seems to start from profile statement [ Scribe Assist by Ted Thibodeau ] ←
18:44:01 <Arnaud> scribe: TallTed
(Scribe set to Ted Thibodeau)
18:44:44 <TallTed> ... current examples include LDPR, LDPC; we're talking about adding constrained; question about writeable
... 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"
John Arwe: @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?
Eric Prud'hommeaux: 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?
... intend a PUTtable (PATCHable) container? what are all the graph shapes you might get as result? ←
18:47:02 <TallTed> ... may need to constrain containers to have same interactions whether backed by triple store or otherwise...
... may need to constrain containers to have same interactions whether backed by triple store or otherwise... ←
18:49:55 <bblfish> I agree
Henry Story: 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
Henry Story: 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+
Henry Story: q+ ←
18:52:27 <Arnaud> ack bblfish
Arnaud Le Hors: 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
Henry Story: the need is to specify constraints applying on the server side, such that the client can understand them ←
18:53:16 <bblfish> yes
Henry Story: yes ←
18:53:51 <davidwood> "LDP servers capable of storing arbitrary data" vs. "LDP servers capable of storing only pre-specified data elements"
David Wood: "LDP servers capable of storing arbitrary data" vs. "LDP servers capable of storing only pre-specified data elements" ←
18:54:44 <bblfish> which one?
Henry Story: which one? ←
18:55:42 <TallTed> Arnaud: timbl gave several hints about what might work, which we should explore
Arnaud Le Hors: 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
... 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).
... 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
... 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.
Roger Menday: 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)
Roger Menday: 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
Eric Prud'hommeaux: 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.
Roger Menday: 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?
... if a server throws away some of your triples, should you get a 2xx or 4xx result? ←
18:59:16 <bblfish> q+
Henry Story: q+ ←
18:59:51 <bblfish> q-]
Henry Story: q-] ←
18:59:53 <bblfish> q-
Henry Story: 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
David Wood: 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...
... 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)
(20 minute break) ←
19:23:12 <TallTed> (convo resumes)
(No events recorded for 21 minutes)
(convo resumes) ←
19:24:15 <bblfish> hi
Henry Story: hi ←
19:24:31 <bblfish> yes, I am back.
Henry Story: yes, I am back. ←
19:25:15 <bblfish> we can't solve all the problems
Henry Story: we can't solve all the problems ←
19:25:53 <bblfish> q+
Henry Story: q+ ←
19:26:39 <TallTed> rel=type type=ldpServer implies unconstrained;
rel=type type=ldpServer implies unconstrained; ←
19:26:39 <TallTed> + rel=type type=URI dereference leads to constraint definition
+ rel=type type=URI dereference leads to constraint definition ←
19:26:41 <Arnaud> ack bblfish
Arnaud Le Hors: ack bblfish ←
19:27:37 <TallTed> bblfish: constraints on http methods seem different from constraints on content
Henry Story: 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
... 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"
Sandro Hawke: "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
Sandro Hawke: 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.
Henry Story: 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
David Wood: 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.
... 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
... 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
... 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
Arnaud Le Hors: 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
... 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?
... do we need to advertise "I'm a vanilla server"? does silence somewhere imply that? does silence imply something else? ←
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.
Roger Menday: 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 .
Henry Story: 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
Arnaud Le Hors: 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
Henry Story: yes, the link header is rdf ←
19:37:52 <TallTed> SteveS: rel=describedby could be the one to use
Steve Speicher: 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
Sandro Hawke: likes roger's idea of the constraint spec through a header URI ←
19:38:36 <roger> +q
Roger Menday: +q ←
19:38:39 <TallTed> Ashok: what happens for violations?
Ashok Malhotra: what happens for violations? ←
19:38:56 <TallTed> sandro: protocol question. could be silent failure, could be error, etc.
Sandro Hawke: 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.
Arnaud Le Hors: need to do something about transparency of partial success/failure, etc. ←
19:39:56 <davidwood> Ashok, davidwood not happy with silent failures
David Wood: 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
Sandro Hawke: if you're a shape-constraining server, you have to validate immediately, and provide results ←
19:40:09 <bblfish> q+
Henry Story: 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
Ashok Malhotra: 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
Arnaud Le Hors: ack roger ←
19:41:08 <TallTed> ... is this enough?
... 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.
John Arwe: 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
Roger Menday: 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.
Sandro Hawke: +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.
Henry Story: 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
... 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
Henry Story: Agree that we need different relation for an LDPC what needs to be POSTed ←
19:42:41 <bblfish> q-
Henry Story: q- ←
19:42:42 <TallTed> sandro: LDPC needs 2 shapes -- one for PUT, another for POST -- one for exists, one for doesn't exist
Sandro Hawke: 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
Arnaud Le Hors: need to communicate that there are no constraints ←
19:43:26 <bblfish> q+
Henry Story: q+ ←
19:43:37 <TallTed> sandro: absence of any constraints means it's a vanilla graph
Sandro Hawke: 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
... one predicate is graph restraints for LDPR, another predicate is member constraints for LDPC ←
19:44:15 <Arnaud> ack bblfish
Arnaud Le Hors: 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?
Arnaud Le Hors: 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
Henry Story: it's a Link header ←
19:46:49 <bblfish> Arnaud it's a Link header of rel = somethypetobedecidedlater
Henry Story: 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.
Sandro Hawke: 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
Henry Story: 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
Sandro Hawke: 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.
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
Henry Story: IT also constrains the GET ←
19:51:15 <sandro> (this is independent of possible variablity in protocol behaviors, like silent failure of DELETE)
Sandro Hawke: (this is independent of possible variablity in protocol behaviors, like silent failure of DELETE) ←
19:51:33 <bblfish> +1
Henry Story: +1 ←
19:51:47 <TallTed> +1
+1 ←
19:51:55 <JohnArwe> I think we also need to MUST that on 4xx responses that fail due to violation of the constraints.
John Arwe: 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
David Wood: +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.
Roger Menday: +1 and I beleive we need to do this for POST at this stage too. ←
19:52:06 <ericP> +1
Eric Prud'hommeaux: +1 ←
19:52:08 <sandro> the constraint is on the possible graph shapes -- so it affects GET and PUT and PATCH.
Sandro Hawke: 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
Nandana Mihindukulasooriya: +0.5 for the same reasons as davidwood ←
19:52:25 <sandro> +1
Sandro Hawke: +1 ←
19:52:35 <SteveS> +1
Steve Speicher: +1 ←
19:52:36 <sandro> The absense of this header means the absense of such a constraint.
Sandro Hawke: 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
Nandana Mihindukulasooriya: +0.5 - mesteban for the same reasons as davidwood ←
19:52:52 <sandro> +0.5
Sandro Hawke: +0.5 ←
19:52:57 <Ashok> 0.5 also want to see protocol constraints
Ashok Malhotra: 0.5 also want to see protocol constraints ←
19:53:27 <bblfish> +0.5 I think in HTTP one can do things like that.
Henry Story: +0.5 I think in HTTP one can do things like that. ←
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.
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.
PROPOSED: 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
John Arwe: q+ to get consensus on 4xx proposal ←
19:55:36 <bblfish> +1 that we should specify what error messages happen on partial acceptance
Henry Story: +1 that we should specify what error messages happen on partial acceptance ←
19:55:39 <Arnaud> ack john
Arnaud Le Hors: ack john ←
19:55:39 <Zakim> JohnArwe, you wanted to get consensus on 4xx proposal
Zakim IRC Bot: JohnArwe, you wanted to get consensus on 4xx proposal ←
19:56:01 <sandro> +1 so you can see what caused the failure
Sandro Hawke: +1 so you can see what caused the failure ←
19:56:07 <TallTed> +1
+1 ←
19:56:22 <davidwood> +1
David Wood: +1 ←
19:56:33 <nmihindu> +1
Nandana Mihindukulasooriya: +1 ←
19:57:02 <bblfish> +1
Henry Story: +1 ←
19:57:48 <roger> +1
Roger Menday: +1 ←
19:57:55 <SteveS> cody +1
Steve Speicher: cody +1 ←
19:57:59 <ericP> +1
Eric Prud'hommeaux: +1 ←
19:58:01 <SteveS> +1
Steve Speicher: +1 ←
19:58:14 <nmihindu> +1 for mesteban
Nandana Mihindukulasooriya: +1 for mesteban ←
19:58:24 <bblfish> ah I see
Henry Story: ah I see ←
19:59:04 <bblfish> one gets the constraint header on a 40x or 208.5 if there was an error on constraint
Henry Story: 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.
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
Henry Story: +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?
Sandro Hawke: 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
PROPOSED: Same as above for 208.5 ←
20:01:48 <betehess> are authentication and authorization constraints as well?
Alexandre Bertails: are authentication and authorization constraints as well? ←
20:02:11 <bblfish> betehess: we are dealing with content constraints only
Alexandre Bertails: we are dealing with content constraints only [ Scribe Assist by Henry Story ] ←
20:02:22 <TallTed> [...chatter...]
[...chatter...] ←
20:02:37 <bblfish> betehess: graph constraints, or even mime type constraints I suppose
Alexandre Bertails: graph constraints, or even mime type constraints I suppose [ Scribe Assist by Henry Story ] ←
20:03:03 <betehess> well that's important, because the shape constraints could be based on the user
Alexandre Bertails: 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'"
Sandro Hawke: does this new header bifurcate the spec further, along the lines of "if your data is constrained, MUST, else 'not MUST'" [ Scribe Assist by John Arwe ] ←
20:04:10 <TallTed> sandro: do we now need CLDPRs, CLDPCs?
Sandro Hawke: do we now need CLDPRs, CLDPCs? ←
20:04:27 <TallTed> SteveS: and/or WCLDPRs (writeable)?
Steve Speicher: and/or WCLDPRs (writeable)? ←
20:04:43 <bblfish> q+
Henry Story: 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"
John Arwe: 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
Arnaud Le Hors: 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
Henry Story: 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
John Arwe: @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"
Eric Prud'hommeaux: 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.
Henry Story: I agree we may not care now. ←
20:09:26 <bblfish> We should perhaps wait to see if we need it
Henry Story: 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?
Arnaud Le Hors: do we have a use case for this "throw stuff at the wall" scenario? ←
20:09:59 <bblfish> yes, that was a 203.5
Henry Story: 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*
Steve Speicher: 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+
Henry Story: q+ ←
20:12:19 <TallTed> SteveS: the norm is failing when constraints are not met
Steve Speicher: the norm is failing when constraints are not met ←
20:12:25 <Arnaud> ack bblfish
Arnaud Le Hors: ack bblfish ←
20:12:56 <sandro> q?
Sandro Hawke: q? ←
20:13:00 <TallTed> bblfish: if you want to be flexible, don't put constraints...
Henry Story: 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.
Arnaud Le Hors: 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... ?
Ashok Malhotra: what if you send 100 triples, half validate, half do not... ? ←
20:14:46 <TallTed> consensus: you should get an error
consensus: you should get an error ←
20:14:56 <bblfish> agree with Arnaud on the whole for the moment: either make constraints 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
Henry Story: agree with Arnaud on the whole for the moment: either make constraints 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
Sandro Hawke: 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
Henry Story: 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
... 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 ..."
Arnaud Le Hors: points to 4.5.4 "... LDPR server could discard triples ..." ←
20:16:56 <bblfish> yes we can always add a 203.5 later
Henry Story: 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
Sandro Hawke: 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+
Henry Story: q+ ←
20:18:24 <SteveS> q+
Steve Speicher: 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
Cody Burleson: 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
... don't want to have to update all clients to update the server ←
20:19:09 <Arnaud> ack bblfish
Arnaud Le Hors: ack bblfish ←
20:20:27 <Arnaud> ack steve
Arnaud Le Hors: ack steve ←
20:21:36 <bblfish> ok, I agree the use case makes sense
Henry Story: 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"
Steve Speicher: 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 ;-)
John Arwe: 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?
Arnaud Le Hors: 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?
Henry Story: can we write up that use case in detail? ←
20:23:37 <SteveS> bblfish, who are you asking?
Steve Speicher: bblfish, who are you asking? ←
20:23:48 <SteveS> which use case?
Steve Speicher: 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?
John Arwe: 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?
Henry Story: 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.
... two proposals -- can use existing status codes when client intent is known. harder to address when client intent unknown. ←
20:25:57 <bblfish> q+
Henry Story: q+ ←
20:26:08 <bblfish> q-
Henry Story: 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
Steve Speicher: 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+
Henry Story: q+ ←
20:27:22 <Arnaud> ack bblfish
Arnaud Le Hors: ack bblfish ←
20:27:34 <TallTed> [ ... discussion about response codes ... ]
[ ... 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
Henry Story: 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
Sandro Hawke: none of the existing 2xx codes fit what we want ←
20:29:58 <bblfish> http://en.wikipedia.org/wiki/Http_error_codes#2xx_Success
Henry Story: http://en.wikipedia.org/wiki/Http_error_codes#2xx_Success ←
20:30:11 <bblfish> 207 Multi-Status (WebDAV; RFC 4918)
Henry Story: 207 Multi-Status (WebDAV; RFC 4918) ←
20:30:24 <bblfish> 208 Already Reported (WebDAV; RFC 5842)
Henry Story: 208 Already Reported (WebDAV; RFC 5842) ←
20:30:34 <bblfish> 226 IM Used (RFC 3229)
Henry Story: 226 IM Used (RFC 3229) ←
20:31:37 <bblfish> I am not suggesting those, just saying that others have created new 20x codes
Henry Story: 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
Henry Story: here http://en.wikipedia.org/wiki/Http_error_codes#2xx_Success ←
20:31:52 <bblfish> Arnaud:
Arnaud Le Hors: [ Scribe Assist by Henry Story ] ←
20:32:03 <davidwood> http://en.wikipedia.org/wiki/List_of_HTTP_status_codes
David Wood: http://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
Arnaud Le Hors: 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
Henry Story: +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
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
+1 ←
20:37:15 <SteveS> +1
Steve Speicher: +1 ←
20:37:21 <nmihindu> +1
Nandana Mihindukulasooriya: +1 ←
20:37:21 <sandro> +1 yes we can fallback on to a Link Header, in the worst case
Sandro Hawke: +1 yes we can fallback on to a Link Header, in the worst case ←
20:37:27 <roger> +1
Roger Menday: +1 ←
20:37:30 <SteveS> +1 for Cody
Steve Speicher: +1 for Cody ←
20:37:30 <Ashok> +1
Ashok Malhotra: +1 ←
20:37:38 <nmihindu> +1 for mesteban
Nandana Mihindukulasooriya: +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
RESOLVED: Change the spec, somehow, so that in case the server discards some of triples the client sent it informs the client ←
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
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].
Trackbot IRC Bot: 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 ...
Roger Menday: +q to do the same link header we did a while back but for POST instead ... ←
20:40:00 <bblfish> q+
Henry Story: q+ ←
20:41:41 <Arnaud> ack roger
Arnaud Le Hors: ack roger ←
20:41:41 <Zakim> roger, you wanted to do the same link header we did a while back but for POST instead ...
Zakim IRC Bot: 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"?
Arnaud Le Hors: how about this 4.5.6 "MUST allow PUT"? ←
20:43:04 <Arnaud> ack bblfish
Arnaud Le Hors: ack bblfish ←
20:45:59 <TallTed> action: steves to investigate clarified presentation of Client and Server requirements
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].
Trackbot IRC Bot: 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 http://www.w3.org/2006/02/lc-comments-tracker/55082/ldp/2833
Arnaud Le Hors: is there anything else needing discussion in http://www.w3.org/2006/02/lc-comments-tracker/55082/ldp/2833 ←
20:47:13 <TallTed> ... what about the DELETE, in 4.6.2?
... what about the DELETE, in 4.6.2? ←
20:47:53 <bblfish> what are we looking at?
Henry Story: what are we looking at? ←
20:49:00 <bblfish> q+
Henry Story: q+ ←
20:51:14 <bblfish> So there is a waitress with whome a server is intimate...
Henry Story: 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?
... what is the scope of the DELETE method being issued? ←
20:52:01 <TallTed> ... limited to the server being addressed?
... limited to the server being addressed? ←
20:52:07 <Arnaud> ack bblfish
Arnaud Le Hors: 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?
Henry Story: 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?
... 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
... 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.
John Arwe: 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
...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
John Arwe: 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
David Wood: when a resource is added to Callimachus, 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
... 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.
PROPOSED: 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/
21:00:33 <TallTed> +1
+1 ←
21:00:45 <SteveS> +1
Steve Speicher: +1 ←
21:00:56 <davidwood> +1
David Wood: +1 ←
21:01:16 <nmihindu> +1
Nandana Mihindukulasooriya: +1 ←
21:02:39 <nmihindu> +1 for mesteban
Nandana Mihindukulasooriya: +1 for mesteban ←
21:02:44 <roger> ++1
Roger Menday: ++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.
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
John Arwe: arnaud points out that this also hits 5.6.2, second sentence ←
21:05:05 <Zakim> -bblfish
Zakim IRC Bot: -bblfish ←
21:05:08 <bblfish> oops
Henry Story: oops ←
21:06:27 <Zakim> +bblfish
Zakim IRC Bot: +bblfish ←
21:08:03 <bblfish> It's late for me
Henry Story: It's late for me ←
21:09:30 <bblfish> where?
Henry Story: where? ←
21:10:32 <SteveS> 4.10.2.3
Steve Speicher: 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 ..."
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
+1 ←
21:11:07 <sandro> +1
Sandro Hawke: +1 ←
21:11:09 <Ashok> +1
Ashok Malhotra: +1 ←
21:11:21 <roger> +1
Roger Menday: +1 ←
21:11:32 <nmihindu> +1
Nandana Mihindukulasooriya: +1 ←
21:11:34 <davidwood> +1
David Wood: +1 ←
21:11:35 <SteveS> +1
Steve Speicher: +1 ←
21:11:39 <nmihindu> +1 for mesteban
Nandana Mihindukulasooriya: +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 ..."
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
Steve Speicher: +1 for Cody ←
21:14:34 <bblfish> q+
Henry Story: q+ ←
21:15:17 <Arnaud> ack bblfish
Arnaud Le Hors: ack bblfish ←
21:17:36 <davidwood> http://www.ietf.org/rfc/rfc2616.txt in Section 14.30 (Location header)
David Wood: 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.
Henry Story: 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
Steve Speicher: 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
Henry Story: 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.
Henry Story: 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
Henry Story: http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-23#section-7.1.2 ←
21:20:55 <bblfish> 7.1.2. Location
Henry Story: 7.1.2. Location ←
21:20:55 <bblfish> The "Location" header field is used in some responses to refer to a
Henry Story: 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
Henry Story: specific resource in relation to the response. The type of ←
21:20:57 <bblfish> relationship is defined by the combination of request method and
Henry Story: relationship is defined by the combination of request method and ←
21:20:59 <bblfish> status code semantics.
Henry Story: status code semantics. ←
21:21:01 <bblfish> Location = URI-reference
Henry Story: 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
David Wood: 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
Henry Story: http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-23#section-7.1.2 ←
21:30:52 <bblfish> q+
(No events recorded for 7 minutes)
Henry Story: q+ ←
21:31:20 <Arnaud> ack bblfish
Arnaud Le Hors: 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.
(No events recorded for 6 minutes)
John Arwe: 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.
John Arwe: ...have wished for same thing myself. ←
21:38:42 <bblfish> ok, guys its close to midnight here
Henry Story: ok, guys its close to midnight here ←
21:38:46 <bblfish> (wavE)
Henry Story: (wavE) ←
21:38:50 <Zakim> -bblfish
Zakim IRC Bot: -bblfish ←
21:45:01 <Zakim> SW_LDP()8:30AM has ended
(No events recorded for 6 minutes)
Zakim IRC Bot: SW_LDP()8:30AM has ended ←
21:45:01 <Zakim> Attendees were rgarcia, Workshop_room, bblfish
Zakim IRC Bot: Attendees were rgarcia, Workshop_room, bblfish ←
21:46:46 <Arnaud> trackbot, end meeting
Arnaud Le Hors: trackbot, end meeting ←
21:46:46 <trackbot> Zakim, list attendees
Trackbot IRC Bot: Zakim, list attendees ←
21:46:46 <Zakim> sorry, trackbot, I don't know what conference this is
Zakim IRC Bot: sorry, trackbot, I don't know what conference this is ←
21:46:54 <trackbot> RRSAgent, please draft minutes
Trackbot IRC Bot: 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
RRSAgent IRC Bot: I have made the request to generate http://www.w3.org/2013/09/12-ldp-minutes.html trackbot ←
21:46:55 <trackbot> RRSAgent, bye
Trackbot IRC Bot: RRSAgent, bye ←
21:46:55 <RRSAgent> I see 2 open action items saved in http://www.w3.org/2013/09/12-ldp-actions.rdf :
RRSAgent IRC Bot: I see 2 open action items saved in http://www.w3.org/2013/09/12-ldp-actions.rdf : ←
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 [1]
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 [1] ←
21:46:55 <RRSAgent> recorded in http://www.w3.org/2013/09/12-ldp-irc#T20-38-59
RRSAgent IRC Bot: 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 [2]
ACTION: steves to investigate clarified presentation of Client and Server requirements [2] ←
21:46:55 <RRSAgent> recorded in http://www.w3.org/2013/09/12-ldp-irc#T20-45-59
RRSAgent IRC Bot: recorded in http://www.w3.org/2013/09/12-ldp-irc#T20-45-59 ←
Formatted by CommonScribe