edit

Linked Data Platform (LDP) Working Group Teleconference

Minutes of 12 September 2013

Agenda
http://www.w3.org/2012/ldp/wiki/F2F4
Seen
Alexandre Bertails, Arnaud Le Hors, Ashok Malhotra, Cody Burleson, David Wood, Eric Prud'hommeaux, Henry Story, John Arwe, Miguel Esteban Gutiérrez, Nandana Mihindukulasooriya, Raúl García Castro, Roger Menday, Sandro Hawke, Steve Speicher, Ted Thibodeau
Chair
Arnaud Le Hors
Scribe
Steve Speicher, David Wood, Sandro Hawke, Ted Thibodeau
IRC Log
Original
Resolutions
  1. 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). link
  2. Drop inlining from the spec, put it on the wish list for LDPnext link
  3. Open ISSUE-81 link
  4. Dispose of second part of LC-2815 by clarifying the intent in the spec: LDPCs are LDPRs and sorted the same way link
  5. 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 link
  6. 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. link
  7. Servers MUST also have that header on 4xx responses to any verb (PUT, POST, etc.) that fail due to violation of the constraints. link
  8. Change the spec, somehow, so that in case the server discards some of triples the client sent it informs the client link
  9. Make 4.6.2 informative, clarify that it re-states what http allows, and in fact it applies to all methods not just delete. link
  10. Change SHOULD to MUST in 4.10.2.3 "LDPR servers that initiate paging SHOULD respond to request ..." link
Topics
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

1. 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

2. 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

2.1. 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

2.2. 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

2.3. ISSUE-81 - Confusing predicate names

15:26:51 <TallTed> issue-81?

Ted Thibodeau: 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?

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

CLOSE ISSUE-83

15:27:05 <trackbot> Closed ISSUE-83.

Trackbot IRC Bot: Closed ISSUE-83.

15:27:20 <davidwood> ISSUE-81

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

OPEN ISSUE-81

15:28:41 <TallTed> +1 open it

Ted Thibodeau: +1 open it

15:28:53 <Arnaud> PROPOSAL: Open ISSUE-81

PROPOSED: 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

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

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)

2.4. 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

2.5. 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

2.6. 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

3. 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)

4. 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

4.1. 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

John Arwe: +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

John Arwe: +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