edit

Linked Data Platform (LDP) Working Group Teleconference

Minutes of 13 January 2014

Agenda
http://www.w3.org/2012/ldp/wiki/Meetings:Telecon2014.01.13
Seen
Alexandre Bertails, Andrei Sambra, Arnaud Le Hors, Ashok Malhotra, Cody Burleson, Eric Prud'hommeaux, Henry Story, John Arwe, Nandana Mihindukulasooriya, Reza B'Far, Roger Menday, Sandro Hawke, Steve Battle, Steve Speicher, Ted Thibodeau
Chair
Arnaud Le Hors
Scribe
Ted Thibodeau
IRC Log
Original
Resolutions
  1. without objection Approve the minutes of the January 6 teleconf, http://www.w3.org/2013/meeting/ldp/2014-01-06 link
  2. resolve issue around ACTION-118 by adding At-risk text saying we'd use the TAG's new [23]xx code, and, if that code is not sufficiently through IETF process by CR, we will use a 303 link
  3. server MUST be able to materialize ldp:contains in representations delivered to the client, based on client preference (possibly via HTTP Prefer or Accept Request header; possibly another mechanism) link
Topics
14:59:44 <RRSAgent> logging to http://www.w3.org/2014/01/13-ldp-irc

RRSAgent IRC Bot: logging to http://www.w3.org/2014/01/13-ldp-irc

14:59:46 <trackbot> RRSAgent, make logs public

Trackbot IRC Bot: RRSAgent, make logs public

14:59:48 <trackbot> Zakim, this will be LDP

Trackbot IRC Bot: Zakim, this will be LDP

14:59:48 <Zakim> ok, trackbot, I see SW_LDP()10:00AM already started

Zakim IRC Bot: ok, trackbot, I see SW_LDP()10:00AM already started

14:59:49 <trackbot> Meeting: Linked Data Platform (LDP) Working Group Teleconference
14:59:49 <trackbot> Date: 13 January 2014
15:00:29 <Zakim> +Arnaud

Zakim IRC Bot: +Arnaud

15:00:50 <Zakim> +TimBL

Zakim IRC Bot: +TimBL

15:01:00 <betehess> Zakim, TimBL is Alexandre

Alexandre Bertails: Zakim, TimBL is Alexandre

15:01:00 <Zakim> +Alexandre; got it

Zakim IRC Bot: +Alexandre; got it

15:01:04 <codyburleson> +CodyB

Cody Burleson: +CodyB

15:01:14 <betehess> Zakim, Alexandre also has Andrei

Alexandre Bertails: Zakim, Alexandre also has Andrei

15:01:14 <Zakim> +Andrei; got it

Zakim IRC Bot: +Andrei; got it

15:01:55 <Arnaud> zakim, who is on the phone?

Arnaud Le Hors: zakim, who is on the phone?

15:01:55 <Zakim> On the phone I see [IPcaller], Arnaud, Alexandre

Zakim IRC Bot: On the phone I see [IPcaller], Arnaud, Alexandre

15:01:56 <Zakim> Alexandre has Alexandre, Andrei

Zakim IRC Bot: Alexandre has Alexandre, Andrei

15:02:35 <Zakim> +Ashok_Malhotra

Zakim IRC Bot: +Ashok_Malhotra

15:02:40 <codyburleson> zakim, IPCaller is me

Cody Burleson: zakim, IPCaller is me

15:02:40 <Zakim> +codyburleson; got it

Zakim IRC Bot: +codyburleson; got it

15:02:58 <Zakim> +[IBM]

Zakim IRC Bot: +[IBM]

15:03:07 <SteveS> zakim, ibm is me

Steve Speicher: zakim, ibm is me

15:03:07 <Zakim> +SteveS; got it

Zakim IRC Bot: +SteveS; got it

15:03:08 <Zakim> +Roger

Zakim IRC Bot: +Roger

15:03:53 <Zakim> +SteveBattle

Zakim IRC Bot: +SteveBattle

15:04:36 <Zakim> +EricP

Zakim IRC Bot: +EricP

15:04:58 <ericP> i am

Eric Prud'hommeaux: i am

15:04:58 <Zakim> +JohnArwe

Zakim IRC Bot: +JohnArwe

15:05:37 <Zakim> +Sandro

Zakim IRC Bot: +Sandro

15:06:41 <Zakim> +OpenLink_Software

Zakim IRC Bot: +OpenLink_Software

15:06:49 <TallTed> Zakim, OpenLink_Software is temporarily me

Ted Thibodeau: Zakim, OpenLink_Software is temporarily me

15:06:49 <Zakim> +TallTed; got it

Zakim IRC Bot: +TallTed; got it

15:08:21 <TallTed> scribenick: TallTed

(Scribe set to Ted Thibodeau)

<TallTed> chair: Arnaud
<TallTed> agenda: http://www.w3.org/2012/ldp/wiki/Meetings:Telecon2014.01.13
<TallTed> topic: Admin

1. Admin

15:09:42 <TallTed> Proposed: Approve the minutes of the January 6 teleconf, http://www.w3.org/2013/meeting/ldp/2014-01-06

PROPOSED: Approve the minutes of the January 6 teleconf, http://www.w3.org/2013/meeting/ldp/2014-01-06

15:10:52 <TallTed> RESOLVED: without objection Approve the minutes of the January 6 teleconf, http://www.w3.org/2013/meeting/ldp/2014-01-06

RESOLVED: without objection Approve the minutes of the January 6 teleconf, http://www.w3.org/2013/meeting/ldp/2014-01-06

15:11:42 <sandro> regrets from me, holiday

Sandro Hawke: regrets from me, holiday

15:12:50 <betehess> can we try to move it exceptionally on Tuesday or another day?

Alexandre Bertails: can we try to move it exceptionally on Tuesday or another day?

15:13:03 <Arnaud> strawpoll: meeting on 1/20?

STRAWPOLL: meeting on 1/20?

15:13:03 <Ashok> regrets, vacation

Ashok Malhotra: regrets, vacation

15:13:04 <betehess> let's set up a Doodle

Alexandre Bertails: let's set up a Doodle

15:13:14 <ericP> present

Eric Prud'hommeaux: present

15:13:17 <betehess> present

Alexandre Bertails: present

15:13:17 <TallTed> regrets

regrets

15:13:17 <JohnArwe> I'll be here

John Arwe: I'll be here

15:13:23 <stevebattle14> present

Steve Battle: present

15:13:23 <SteveS> regrets

Steve Speicher: regrets

15:13:26 <roger> i can make it

Roger Menday: i can make it

15:13:30 <codyburleson> present

Cody Burleson: present

<TallTed> Arnaud: ok, we'll hold a meeting and see what we can do

Arnaud Le Hors: ok, we'll hold a meeting and see what we can do

15:14:13 <TallTed> TOPIC: Tracking of action items

2. Tracking of action items

15:17:11 <sandro> action-118?

Sandro Hawke: ACTION-118?

15:17:12 <trackbot> action-118 -- Eric Prud'hommeaux to Report to timbl: some pref for reverting to 303, 200+header still on the table, henry considering 200+location -- due 2013-12-23 -- OPEN

Trackbot IRC Bot: ACTION-118 -- Eric Prud'hommeaux to Report to timbl: some pref for reverting to 303, 200+header still on the table, henry considering 200+location -- due 2013-12-23 -- OPEN

15:17:12 <trackbot> http://www.w3.org/2012/ldp/track/actions/118

Trackbot IRC Bot: http://www.w3.org/2012/ldp/track/actions/118

15:17:58 <TallTed> Arnaud: question to ericP about status of action-118

Arnaud Le Hors: question to ericP about status of ACTION-118

15:18:23 <Zakim> +??P21

Zakim IRC Bot: +??P21

15:18:31 <TallTed> ericP: thinks the action has been taken...

Eric Prud'hommeaux: thinks the action has been taken...

15:19:17 <nmihindu> Zakim, ??P21 is me

Nandana Mihindukulasooriya: Zakim, ??P21 is me

15:19:17 <Zakim> +nmihindu; got it

Zakim IRC Bot: +nmihindu; got it

15:19:24 <nmihindu> Zakim, mute me

Nandana Mihindukulasooriya: Zakim, mute me

15:19:24 <Zakim> nmihindu should now be muted

Zakim IRC Bot: nmihindu should now be muted

<TallTed> topic: Paging

3. Paging

15:19:53 <TallTed> Arnaud: TAG discussion seems now to be clearly focused on 20x/30x as combination of 303+200, rather than a paging-specific question

Arnaud Le Hors: TAG discussion seems now to be clearly focused on 20x/30x as combination of 303+200, rather than a paging-specific question

15:20:31 <TallTed> ericP: does anyone have a toolchain that will fail if TAG goes with 30x instead of 20x?

Eric Prud'hommeaux: does anyone have a toolchain that will fail if TAG goes with 30x instead of 20x?

15:22:56 <TallTed> Arnaud: how does TimBL seem to feel about us falling back to 303 until/unless this new code comes?

Arnaud Le Hors: how does TimBL seem to feel about us falling back to 303 until/unless this new code comes?

15:24:17 <TallTed> ericP: last recalled proposition was that we write in that the new code is preferred, but this is at risk, and failing the new code's availability, 303 will be used

Eric Prud'hommeaux: last recalled proposition was that we write in that the new code is preferred, but this is at risk, and failing the new code's availability, 303 will be used

15:25:21 <ericP> PROPOSED: resolve ISSUE-118 by adding At-risk text saying we'd use the TAG's new [23]xx code, and, if that code is not sufficiently through IETF process by CR, we will use a 303

PROPOSED: resolve ISSUE-118 by adding At-risk text saying we'd use the TAG's new [23]xx code, and, if that code is not sufficiently through IETF process by CR, we will use a 303

15:25:41 <ericP> PROPOSED: resolve issue around ACTION-118 by adding At-risk text saying we'd use the TAG's new [23]xx code, and, if that code is not sufficiently through IETF process by CR, we will use a 303

PROPOSED: resolve issue around ACTION-118 by adding At-risk text saying we'd use the TAG's new [23]xx code, and, if that code is not sufficiently through IETF process by CR, we will use a 303

15:26:11 <JohnArwe> +1

John Arwe: +1

15:26:32 <ericP> +1

Eric Prud'hommeaux: +1

15:26:50 <stevebattle14> Why [23]XX ?

Steve Battle: Why [23]XX ?

15:27:15 <sandro> +1

Sandro Hawke: +1

15:27:20 <JohnArwe> TAG is debating 2xx vs 3xx merits

John Arwe: TAG is debating 2xx vs 3xx merits

15:27:20 <TallTed> +0.5

+0.5

15:27:40 <SteveS> +1  (though, we won't prohibit 303..so still an option)

Steve Speicher: +1 (though, we won't prohibit 303..so still an option)

15:27:46 <stevebattle14> +1

Steve Battle: +1

15:27:52 <nmihindu> +0 didn't follow the discussion in detail

Nandana Mihindukulasooriya: +0 didn't follow the discussion in detail

15:28:05 <deiu> +0 (same as above)

Andrei Sambra: +0 (same as above)

15:29:18 <betehess> +0

Alexandre Bertails: +0

15:30:09 <betehess> sounds important: is that possible to get a more detailed proposal by email with the motivations, and then we vote later?

Alexandre Bertails: sounds important: is that possible to get a more detailed proposal by email with the motivations, and then we vote later?

15:30:56 <Arnaud> http://www.w3.org/TR/ldp/#http-get-1

Arnaud Le Hors: http://www.w3.org/TR/ldp/#http-get-1

15:31:13 <SteveS> Per John's earlier question, 20130307 draft had 303 as a SHOULD

Steve Speicher: Per John's earlier question, 20130307 draft had 303 as a SHOULD

15:33:01 <JohnArwe> I neither see nor remember and LDP requirement on clients "handling" any particular status code - we get any reqts there via the "LDP clients are HTTP clients" normative reference

John Arwe: I neither see nor remember and LDP requirement on clients "handling" any particular status code - we get any reqts there via the "LDP clients are HTTP clients" normative reference

15:33:16 <JohnArwe> +1 to TallTed

John Arwe: +1 to TallTed

15:36:27 <TallTed> RESOLVED: resolve issue around ACTION-118 by adding At-risk text saying we'd use the TAG's new [23]xx code, and, if that code is not sufficiently through IETF process by CR, we will use a 303

RESOLVED: resolve issue around ACTION-118 by adding At-risk text saying we'd use the TAG's new [23]xx code, and, if that code is not sufficiently through IETF process by CR, we will use a 303

15:37:27 <TallTed> Arnaud: so, is action-118 closeable, or do we need it open for tracking TAG?

Arnaud Le Hors: so, is ACTION-118 closeable, or do we need it open for tracking TAG?

15:39:39 <TallTed> TOPIC: ISSUE-92 - Interaction Model

4. ISSUE-92 - Interaction Model

15:39:42 <TallTed> issue-92?

ISSUE-92?

15:39:42 <trackbot> issue-92 -- Change rel=type to rel=profile for client introspection of interaction model -- open

Trackbot IRC Bot: ISSUE-92 -- Change rel=type to rel=profile for client introspection of interaction model -- open

15:39:42 <trackbot> http://www.w3.org/2012/ldp/track/issues/92

Trackbot IRC Bot: http://www.w3.org/2012/ldp/track/issues/92

15:41:35 <Zakim> +bblfish

Zakim IRC Bot: +bblfish

15:41:42 <TallTed> PROPOSED: Close ISSUE-92 by changing rel=type to rel=profile for client introspection of interaction model

PROPOSED: Close ISSUE-92 by changing rel=type to rel=profile for client introspection of interaction model

15:41:44 <bblfish> ¡hi sorry I am late

Henry Story: ¡hi sorry I am late

15:41:50 <betehess> +1

Alexandre Bertails: +1

15:41:52 <TallTed> +1

+1

15:41:52 <bblfish> -1

Henry Story: -1

15:41:53 <ericP> +1

Eric Prud'hommeaux: +1

15:42:00 <deiu> +1

Andrei Sambra: +1

15:42:07 <nmihindu> +1

Nandana Mihindukulasooriya: +1

15:42:10 <roger> +1

Roger Menday: +1

15:42:15 <SteveS> +1

Steve Speicher: +1

15:42:16 <JohnArwe> +1

John Arwe: +1

15:42:18 <Ashok> +1

Ashok Malhotra: +1

15:42:57 <TallTed> Arnaud: Q to bblfish, what's the basis of objection?

Arnaud Le Hors: Q to bblfish, what's the basis of objection?

15:43:36 <TallTed> bblfish: @profile is more syntactic, limits the types of documents

Henry Story: @profile is more syntactic, limits the types of documents

15:44:23 <bblfish> profile is better for validation

Henry Story: profile is better for validation

15:44:32 <TallTed> bblfish: there's no real argument "for", so we should preserve @profile for future use, e.g., validation

Henry Story: there's no real argument "for", so we should preserve @profile for future use, e.g., validation

15:44:59 <stevebattle14> 0

Steve Battle: 0

15:45:03 <betehess> I don't think rel=profile has to be unique

Alexandre Bertails: I don't think rel=profile has to be unique

15:45:09 <ericP> bblfish, you mean something like http://localhost/2013/ShEx/FancyShExDemo?schemaURL=test/GenX/schema.shex&dataURL=test/Issue-pass-date.ttl&colorize=1 , right?

Eric Prud'hommeaux: bblfish, you mean something like http://localhost/2013/ShEx/FancyShExDemo?schemaURL=test/GenX/schema.shex&dataURL=test/Issue-pass-date.ttl&colorize=1 , right?

15:45:17 <JohnArwe> what prevents rel=profile being used for both?

John Arwe: what prevents rel=profile being used for both?

15:45:22 <ericP> sorry http://www.w3.org/2013/ShEx/FancyShExDemo?schemaURL=test/GenX/schema.shex&dataURL=test/Issue-pass-date.ttl&colorize=1

Eric Prud'hommeaux: sorry http://www.w3.org/2013/ShEx/FancyShExDemo?schemaURL=test/GenX/schema.shex&dataURL=test/Issue-pass-date.ttl&colorize=1

15:45:23 <betehess> exactly

Alexandre Bertails: exactly

15:46:10 <betehess> http://tools.ietf.org/search/rfc6906

Alexandre Bertails: http://tools.ietf.org/search/rfc6906

15:46:14 <JohnArwe> http://www.iana.org/assignments/link-relations/link-relations.xml

John Arwe: http://www.iana.org/assignments/link-relations/link-relations.xml

15:46:27 <betehess> http://tools.ietf.org/search/rfc6906 says precisely "one or more profiles"

Alexandre Bertails: http://tools.ietf.org/search/rfc6906 says precisely "one or more profiles"

15:46:39 <TallTed> JohnArwe: the definition of @type doesn't fit our usage, as seen from the IANA link registry

John Arwe: the definition of @type doesn't fit our usage, as seen from the IANA link registry

15:46:49 <JohnArwe> 6. "type"

John Arwe: 6. "type"

15:46:49 <JohnArwe>    The "type" link relation can be used to indicate that the context

John Arwe: The "type" link relation can be used to indicate that the context

15:46:49 <JohnArwe>    resource is an instance of the resource identified by the target

John Arwe: resource is an instance of the resource identified by the target

15:46:49 <JohnArwe>    Internationalized Resource Identifier (IRI).

John Arwe: Internationalized Resource Identifier (IRI).

15:46:49 <JohnArwe>      HTTP/1.1 200 OK

John Arwe: HTTP/1.1 200 OK

15:46:49 <JohnArwe>      Content-Type: text/plain

John Arwe: Content-Type: text/plain

15:46:49 <JohnArwe>      Link: <http://example.org/Person/givenName>; rel="type"

John Arwe: Link: <http://example.org/Person/givenName>; rel="type"

15:46:49 <JohnArwe>      Sally

John Arwe: Sally

15:46:50 <JohnArwe>    When used within the header of an HTTP message, the type specified by

John Arwe: When used within the header of an HTTP message, the type specified by

15:46:50 <JohnArwe>    the "type" link relation cannot be confused with the content type of

John Arwe: the "type" link relation cannot be confused with the content type of

15:46:50 <JohnArwe>    the payload as given by the Content-Type header.  The "type" link

John Arwe: the payload as given by the Content-Type header. The "type" link

15:46:50 <JohnArwe>    relation references the payload's abstract semantic type, whereas the

John Arwe: relation references the payload's abstract semantic type, whereas the

15:46:50 <JohnArwe>    Content-Type header identifies the specific serialization format of

John Arwe: Content-Type header identifies the specific serialization format of

15:46:50 <JohnArwe>    the payload.

John Arwe: the payload.

15:46:50 <JohnArwe>    If the context can be considered to be an instance of multiple

John Arwe: If the context can be considered to be an instance of multiple

15:46:50 <JohnArwe>    semantic types, multiple "type" link relations can be used.

John Arwe: semantic types, multiple "type" link relations can be used.

15:48:10 <TallTed> Arnaud: we've shifted from conveying "this is an LDPC/R" to "this is the kind of interaction you can have"

Arnaud Le Hors: we've shifted from conveying "this is an LDPC/R" to "this is the kind of interaction you can have"

15:49:32 <JohnArwe> http://tools.ietf.org/html/rfc6906 = rel=profile

John Arwe: http://tools.ietf.org/html/rfc6906 = rel=profile

15:51:07 <betehess> henry, what if we said that the statement was true only and only if you find the rel=profile with a ldpc value?

Alexandre Bertails: henry, what if we said that the statement was true only and only if you find the rel=profile with a ldpc value?

15:52:30 <JohnArwe> Question about Henry's clay-tablet example (or foaf:Person, another fav).  if you know something is-a clay tablet (person), I don't think you KNOW anything about its interaction model - I cannot write (Henry's example, pen/paper) on a conceptual tablet.

John Arwe: Question about Henry's clay-tablet example (or foaf:Person, another fav). if you know something is-a clay tablet (person), I don't think you KNOW anything about its interaction model - I cannot write (Henry's example, pen/paper) on a conceptual tablet.

15:53:11 <TallTed> TallTed: the RFC says multiple (interaction) @profiles may exist for a single (document/resource) @type

Ted Thibodeau: the RFC says multiple (interaction) @profiles may exist for a single (document/resource) @type

15:53:35 <betehess> well to be fair, RDF Semantics leaves the trueness of the statement up to some Interpretation function I. So it's easy to make the statement false if rel=profile is not given

Alexandre Bertails: well to be fair, RDF Semantics leaves the trueness of the statement up to some Interpretation function I. So it's easy to make the statement false if rel=profile is not given

15:54:26 <JohnArwe> I think a more carefully worded version might be: something whose reprsentation == the representation of an LDPC, but that does not "interact like" a LDPC.

John Arwe: I think a more carefully worded version might be: something whose reprsentation == the representation of an LDPC, but that does not "interact like" a LDPC.

15:54:58 <SteveS> I agree that interaction can be inferred from the type, though there are cases when it needs to be overwritten.

Steve Speicher: I agree that interaction can be inferred from the type, though there are cases when it needs to be overwritten.

15:55:40 <ericP> bblfish, i'd expect that { <x> a :Issue ; :submittedBy <Bob> . <Bob> a :Person ; foaf:name "Bob" . } would be type=IssueDoc, profile=LDP-editable-resource

Eric Prud'hommeaux: bblfish, i'd expect that { <x> a :Issue ; :submittedBy <Bob> . <Bob> a :Person ; foaf:name "Bob" . } would be type=IssueDoc, profile=LDP-editable-resource

15:56:14 <ericP> q+ to talk to the above

Eric Prud'hommeaux: q+ to talk to the above

15:56:59 <Arnaud> ack ericP

Arnaud Le Hors: ack ericP

15:57:00 <Zakim> ericP, you wanted to talk to the above

Zakim IRC Bot: ericP, you wanted to talk to the above

15:59:40 <TallTed> from RFC 6906 -- [[ ...    The objective of profiles is that they allow instances to clearly

from RFC 6906 -- [[ ... The objective of profiles is that they allow instances to clearly

15:59:40 <TallTed>    identify what kind of mechanism they are using for expressing

identify what kind of mechanism they are using for expressing

15:59:40 <TallTed>    additional semantics, should they follow a well-defined framework for

additional semantics, should they follow a well-defined framework for

15:59:40 <TallTed>    doing so (see Section 5 for examples).  While this allows servers and

doing so (see Section 5 for examples). While this allows servers and

15:59:41 <TallTed>    clients to represent the use of profiles, it does not make the

clients to represent the use of profiles, it does not make the

15:59:41 <TallTed>    profile information visible outside of the representation itself, if

profile information visible outside of the representation itself, if

15:59:43 <TallTed>    the representation is using embedded typed links.  For newly defined ...]]

the representation is using embedded typed links. For newly defined ...]]

16:00:04 <SteveS> seems like we are not discussing this issue but trying to reopen/solve another already closed issue, instead the issue at hand is if we should use rel='profile' or create a rel='ldp interaction model'

Steve Speicher: seems like we are not discussing this issue but trying to reopen/solve another already closed issue, instead the issue at hand is if we should use rel='profile' or create a rel='ldp interaction model'

16:00:09 <Ashok> q+

Ashok Malhotra: q+

16:00:51 <TallTed> [[Abstract

[[Abstract

16:00:51 <TallTed>    This specification defines the 'profile' link relation type that

This specification defines the 'profile' link relation type that

16:00:51 <TallTed>    allows resource representations to indicate that they are following

allows resource representations to indicate that they are following

16:00:52 <TallTed>    one or more profiles.  A profile is defined not to alter the

one or more profiles. A profile is defined not to alter the

16:00:52 <TallTed>    semantics of the resource representation itself, but to allow clients

semantics of the resource representation itself, but to allow clients

16:00:52 <TallTed>    to learn about additional semantics (constraints, conventions,

to learn about additional semantics (constraints, conventions,

16:00:54 <TallTed>    extensions) that are associated with the resource representation, in

extensions) that are associated with the resource representation, in

16:00:56 <TallTed>    addition to those defined by the media type and possibly other

addition to those defined by the media type and possibly other

16:00:58 <TallTed>    mechanisms.]]

mechanisms.]]

16:01:23 <bblfish> q?

Henry Story: q?

16:01:25 <Arnaud> ack ashok

Arnaud Le Hors: ack ashok

16:03:00 <TallTed> [...discussion...] Erik Wilde indicated that profile was viable, but we could also choose to define our own relation

[...discussion...] Erik Wilde indicated that profile was viable, but we could also choose to define our own relation

16:03:59 <TallTed> Arnaud: summarizing henry's objection -- (1) using profile removes it from later use; (2) we should define our own relation

Arnaud Le Hors: summarizing henry's objection -- (1) using profile removes it from later use; (2) don't see any reason for change

16:04:44 <JohnArwe> I don't think (2) was henry's objection; his (2) sounds like "why the need for change"

John Arwe: I don't think (2) was henry's objection; his (2) sounds like "why the need for change"

16:05:06 <TallTed> bblfish: I need to carefully study profile and type; I didn't expect such support for profile

Henry Story: I need to carefully study profile and type; I didn't expect such support for profile

16:05:08 <JohnArwe> defining our own relation was an option arnaud reiterated from my email

John Arwe: defining our own relation was an option arnaud reiterated from my email

16:05:11 <SteveS> That with discussed in http://www.w3.org/2012/ldp/track/issues/91

Steve Speicher: That with discussed in http://www.w3.org/2012/ldp/track/issues/91

16:05:28 <betehess> it's duck typing, the other way :-)

Alexandre Bertails: it's duck typing, the other way :-)

16:05:38 <TallTed> s/ (2) we should define our own relation/ (2) don't see any reason for change/
16:06:37 <ericP> one can create types for every permutation of properties but tye are mostly vapid

Eric Prud'hommeaux: one can create types for every permutation of properties but they are mostly vapid

16:06:50 <ericP> s/tye/they/
16:07:23 <TallTed> q?

q?

16:07:43 <Arnaud> ack sandro

Arnaud Le Hors: ack sandro

16:07:44 <ericP> diff files have one media type and multiple interactions. i'd not want to characterize every utterance of the same diff file as a different "type"

Eric Prud'hommeaux: diff files have one media type and multiple interactions. i'd not want to characterize every utterance of the same diff file as a different "type"

16:08:22 <bblfish> q+ for what Sandro

Henry Story: q+ for what Sandro

16:08:35 <ericP> sandro, does the file change type when you archive it?

Eric Prud'hommeaux: sandro, does the file change type when you archive it?

16:09:09 <Arnaud> ack bblfish

Arnaud Le Hors: ack bblfish

16:09:09 <Zakim> bblfish, you wanted to discuss what Sandro

Zakim IRC Bot: bblfish, you wanted to discuss what Sandro

16:09:44 <betehess> but what if the application data, set by the user, sets rdf:type of ldpc when it is a simple LDPR?

Alexandre Bertails: but what if the application data, set by the user, sets rdf:type of ldpc when it is a simple LDPR?

16:10:41 <bblfish> I'll read up it

Henry Story: I'll read up it

16:11:12 <TallTed> Arnaud: we'll table it for this week, and aim for closure next time

Arnaud Le Hors: we'll table it for this week, and aim for closure next time

16:11:22 <TallTed> TOPIC: ISSUE-89 - Managed Resources

5. ISSUE-89 - Managed Resources

16:11:23 <JohnArwe> my observation is simply that (following my nose and reading the spec), rel=type only "references the payload's abstract semantic type" ... nothing in 6903 (defines rel=type) says anything about interaction model.

John Arwe: my observation is simply that (following my nose and reading the spec), rel=type only "references the payload's abstract semantic type" ... nothing in 6903 (defines rel=type) says anything about interaction model.

16:11:26 <TallTed> issue-89?

ISSUE-89?

16:11:26 <trackbot> issue-89 -- Tie the interaction model with the LDP data model through the notion of Managed Resources -- open

Trackbot IRC Bot: ISSUE-89 -- Tie the interaction model with the LDP data model through the notion of Managed Resources -- open

16:11:26 <trackbot> http://www.w3.org/2012/ldp/track/issues/89

Trackbot IRC Bot: http://www.w3.org/2012/ldp/track/issues/89

16:12:35 <JohnArwe> http://www.w3.org/2012/ldp/wiki/Issue-89 is probably a more useful link ... adding that to issue shortly

John Arwe: ISSUE-89">http://www.w3.org/2012/ldp/wiki/ISSUE-89 is probably a more useful link ... adding that to issue shortly

16:15:52 <ericP> +1 to using the term "Document" in at least our documentation to refer to info resources

Eric Prud'hommeaux: +1 to using the term "Document" in at least our documentation to refer to info resources

16:16:21 <bblfish> q+

Henry Story: q+

16:17:31 <bblfish> http://lists.w3.org/Archives/Public/public-ldp-wg/2013Dec/0043.html

Henry Story: http://lists.w3.org/Archives/Public/public-ldp-wg/2013Dec/0043.html

16:17:47 <betehess> question is more like Simple vs Direct

Alexandre Bertails: question is more like Simple vs Direct

16:18:00 <betehess> also in my opinion, handling the doubling should only be an optimization

Alexandre Bertails: also in my opinion, handling the doubling should only be an optimization

16:18:41 <betehess> please, no inferencing client side........

Alexandre Bertails: please, no inferencing client side........

16:18:42 <bblfish> CONSTRUCT { ?subject ldp:contains ?ldpr }

Henry Story: CONSTRUCT { ?subject ldp:contains ?ldpr }

16:18:42 <bblfish> WHERE{

Henry Story: WHERE{

16:18:42 <bblfish>   { ?ldpc a ldp:DirectContainer;

Henry Story: { ?ldpc a ldp:DirectContainer;

16:18:44 <bblfish>           ldp:containerResource ?subject;

Henry Story: ldp:containerResource ?subject;

16:18:46 <bblfish>           ldp:containsRelation ?predicate.

Henry Story: ldp:containsRelation ?predicate.

16:18:48 <bblfish>     ?subject ?predicate ?ldpr.

Henry Story: ?subject ?predicate ?ldpr.

16:18:50 <bblfish>   }

Henry Story: }

16:18:52 <bblfish>    UNION

Henry Story: UNION

16:18:54 <bblfish>  {

Henry Story: {

16:18:56 <bblfish>      ?ldpc a ldp:DirectContainer;

Henry Story: ?ldpc a ldp:DirectContainer;

16:18:58 <bblfish>            ldp:containerResource ?object;

Henry Story: ldp:containerResource ?object;

16:19:00 <bblfish>            ldp:containedByRelation ?predicate.

Henry Story: ldp:containedByRelation ?predicate.

16:19:02 <bblfish>      ?ldpr ?predicate ?object .

Henry Story: ?ldpr ?predicate ?object .

16:19:04 <ericP> re: inferencing, the question is upon whom you place the burden of performing inference

Reza B'Far: inferencing, the question is upon whom you place the burden of performing inference [ Scribe Assist by Eric Prud'hommeaux ]

16:19:04 <bblfish>   }

Henry Story: }

16:19:06 <bblfish> }

Henry Story: }

16:19:18 <JohnArwe> 4.2.11 LDP servers MUST NOT require LDP clients to implement inferencing in order to recognize the subset of content defined by LDP. Other specifications built on top of LDP may require clients to implement inferencing [RDF-CONCEPTS]. The practical implication is that all content defined by LDP must be explicitly represented.

John Arwe: 4.2.11 LDP servers MUST NOT require LDP clients to implement inferencing in order to recognize the subset of content defined by LDP. Other specifications built on top of LDP may require clients to implement inferencing [RDF-CONCEPTS]. The practical implication is that all content defined by LDP must be explicitly represented.

16:21:32 <JohnArwe> @TallTed, can you give example(s) of places in LDP today that require client inferencing?

John Arwe: @TallTed, can you give example(s) of places in LDP today that require client inferencing?

16:21:39 <betehess> the protocol if the containment triples are not there by default, then you can't easily write invariants for the LDP protocol/interaction model

Alexandre Bertails: the protocol if the containment triples are not there by default, then you can't easily write invariants for the LDP protocol/interaction model

16:21:53 <betehess> the *problem if the containment triples are not there by default, then you can't easily write invariants for the LDP protocol/interaction model

Alexandre Bertails: the *problem if the containment triples are not there by default, then you can't easily write invariants for the LDP protocol/interaction model

16:22:05 <TallTed> @JohnArwe - membershipPredicate (or whatever we're calling it this week)

@JohnArwe - membershipPredicate (or whatever we're calling it this week)

16:22:53 <bblfish> 4.2.11 seems to suggest that the current spec requires ldp:contains should be materialised

Henry Story: 4.2.11 seems to suggest that the current spec requires ldp:contains should be materialised

16:22:56 <bblfish> CONSTRUCT { ?subjet ?predicate ?object }

Henry Story: CONSTRUCT { ?subjet ?predicate ?object }

16:22:56 <bblfish> WHERE {

Henry Story: WHERE {

16:22:57 <bblfish>  { ?ldpc a ldp:DirectContainer;

Henry Story: { ?ldpc a ldp:DirectContainer;

16:22:59 <bblfish>           ldp:containerResource ?subject;

Henry Story: ldp:containerResource ?subject;

16:23:01 <bblfish>           ldp:containsRelation ?predicate;

Henry Story: ldp:containsRelation ?predicate;

16:23:03 <bblfish>           ldp:contains ?ldpr.

Henry Story: ldp:contains ?ldpr.

16:23:05 <bblfish>     BIND (?ldpr AS ?object)

Henry Story: BIND (?ldpr AS ?object)

16:23:07 <bblfish>   }

Henry Story: }

16:23:09 <bblfish>    UNION

Henry Story: UNION

16:23:11 <bblfish>   {

Henry Story: {

16:23:13 <bblfish>      ?ldpc a ldp:DirectContainer;

Henry Story: ?ldpc a ldp:DirectContainer;

16:23:15 <bblfish>            ldp:containerResource ?object;

Henry Story: ldp:containerResource ?object;

16:23:17 <bblfish>            ldp:containedByRelation ?predicate;

Henry Story: ldp:containedByRelation ?predicate;

16:23:19 <bblfish>            ldp:contains ?ldpr.

Henry Story: ldp:contains ?ldpr.

16:23:21 <bblfish>    BIND (?ldpr AS ?subject)

Henry Story: BIND (?ldpr AS ?subject)

16:23:23 <bblfish>   }

Henry Story: }

16:23:25 <bblfish> }

Henry Story: }

16:23:27 <bblfish> q+

Henry Story: q+

16:23:34 <Arnaud> ack bblfish

Arnaud Le Hors: ack bblfish

16:23:47 <TallTed> ericP: querying will not require client-side inferencing to interact with containers...

Eric Prud'hommeaux: querying will not require client-side inferencing to interact with containers...

16:23:57 <JohnArwe> @TallTed that family of predicates tells a client how to query over what they get back, not how to add new triples... no?

John Arwe: @TallTed that family of predicates tells a client how to query over what they get back, not how to add new triples... no?

16:24:25 <betehess> @ericP, tabulator not only consumes (read) but also interacts with write/update operations

Alexandre Bertails: @ericP, tabulator not only consumes (read) but also interacts with write/update operations

16:25:05 <JohnArwe> @bblfish: indeed that's why some of us (me at least) talk about doubling the representation size

John Arwe: @bblfish: indeed that's why some of us (me at least) talk about doubling the representation size

16:25:24 <ericP> @betehess, sure, but they can be coded in tabulator in 5 or 10 lines of code

Eric Prud'hommeaux: @betehess, sure, but they can be coded in tabulator in 5 or 10 lines of code

16:25:56 <TallTed> Arnaud: 4.2.11 was there to say "clients won't have to implement OWL-Full (or similar) to handle LDP", not to eliminate all inferencing entirely

Arnaud Le Hors: 4.2.11 was there to say "clients won't have to implement OWL-Full (or similar) to handle LDP", not to eliminate all inferencing entirely

16:26:07 <ericP> vs. if you had to teach every linked data user to extract and execute the SPARQL constructs that bblfish pasted.

Eric Prud'hommeaux: vs. if you had to teach every linked data user to extract and execute the SPARQL constructs that bblfish pasted.

16:26:33 <betehess> @ericP, for something so tied to interaction, I find it very weird to not make it returned by default

Alexandre Bertails: @ericP, for something so tied to interaction, I find it very weird to not make it returned by default

16:27:36 <ericP> @betehess, i understand the weird, but it's an optimization which makes the clients slightly more comlex

Eric Prud'hommeaux: @betehess, i understand the weird, but it's an optimization which makes the clients slightly more complex

16:28:15 <ericP> s/comlex/complex/
16:28:41 <Arnaud> PROPOSED: ldp:contains MUST be materialized by the server

PROPOSED: ldp:contains MUST be materialized by the server

16:28:53 <betehess> Arnaud, it was at the end of a meeting, not really thought, so maybe it's better not to quote me on saying that I was ok with _not_ materialized

Alexandre Bertails: Arnaud, it was at the end of a meeting, not really thought, so maybe it's better not to quote me on saying that I was ok with _not_ materialized

16:29:01 <betehess> q+

Alexandre Bertails: q+

16:29:09 <Arnaud> ack betehess

Arnaud Le Hors: ack betehess

16:29:11 <bblfish> The advantage of mererialising the ldp:contains is that it makes it consistent with the ldp:SimpleContainer and the ldp:IndirectContainer

Henry Story: The advantage of mererialising the ldp:contains is that it makes it consistent with the ldp:SimpleContainer and the ldp:IndirectContainer

16:30:26 <betehess> with these remarks, +1 to MUST

Alexandre Bertails: with these remarks, +1 to MUST

16:30:59 <TallTed> PROPOSED: ldp:contains MUST be materialized by the server in representations delivered to the client, unless client opts out

PROPOSED: ldp:contains MUST be materialized by the server in representations delivered to the client, unless client opts out

16:31:09 <betehess> +1

Alexandre Bertails: +1

16:31:35 <bblfish> I am fine with that given that one can dedice the membership triples with the query above

Henry Story: I am fine with that given that one can dedice the membership triples with the query above

16:31:57 <roger> I don't need these ldp:contains in my applications, so, I don't like the MUST here.

Roger Menday: I don't need these ldp:contains in my applications, so, I don't like the MUST here.

16:32:13 <JohnArwe> I can live with the opt out

John Arwe: I can live with the opt out

16:32:21 <ericP> i think this will make that part of LDP to anyone who normally writes web protocols

Eric Prud'hommeaux: i think this will make that part of LDP to anyone who normally writes web protocols

16:32:51 <ericP> given the choice between reusing LDP and writing their own, they'd see an obvious advantage in writing their own

Eric Prud'hommeaux: given the choice between reusing LDP and writing their own, they'd see an obvious advantage in writing their own

16:33:22 <betehess> not true, an opt-out mecanism could be send with a header during the GET request

Alexandre Bertails: not true, an opt-out mecanism could be send with a header during the GET request

16:33:46 <betehess> q+

Alexandre Bertails: q+

16:33:56 <ericP> true, that certainly mitigates it, but at the cost of more complexity than we are saving

Eric Prud'hommeaux: true, that certainly mitigates it, but at the cost of more complexity than we are saving

16:34:02 <Arnaud> ack betehess

Arnaud Le Hors: ack betehess

16:34:15 <Zakim> -EricP

Zakim IRC Bot: -EricP

16:34:39 <Zakim> +EricP

Zakim IRC Bot: +EricP

16:34:48 <JohnArwe> http://tools.ietf.org/html/draft-snell-http-prefer-18

John Arwe: http://tools.ietf.org/html/draft-snell-http-prefer-18

16:35:10 <betehess> yeah, why not?

Alexandre Bertails: yeah, why not?

16:35:23 <bblfish> Does this mean you need to send this even before you know that something is an LDPC?

Henry Story: Does this mean you need to send this even before you know that something is an LDPC?

16:35:42 <TallTed> e.g., Prefer=materialized

e.g., Prefer=materialized

16:35:54 <betehess> bblfish, if you're an LDP client, then it's totally fine

Alexandre Bertails: bblfish, if you're an LDP client, then it's totally fine

16:36:08 <bblfish> but well, I suppose if there is alreation <ldpc> a ldp:Container . then you'd know it was an container.

Henry Story: but well, I suppose if there is alreation <ldpc> a ldp:Container . then you'd know it was an container.

16:36:53 <betehess> the PROPOSAL just says "opt-out", which is fine

Alexandre Bertails: the PROPOSAL just says "opt-out", which is fine

16:37:29 <Ashok> q+

Ashok Malhotra: q+

16:37:38 <Arnaud> ack ashok

Arnaud Le Hors: ack ashok

16:37:43 <betehess> so we *can* propose a proactive and a reactive mechanism to opt-out from getting all those triples

Alexandre Bertails: so we *can* propose a proactive and a reactive mechanism to opt-out from getting all those triples

16:37:58 <JohnArwe> the IETF draft above allows the server to ignore the client's pref.  if we wanted something stronger, there is the HTTP Expect header http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-21#section-6.1.2

John Arwe: the IETF draft above allows the server to ignore the client's pref. if we wanted something stronger, there is the HTTP Expect header http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-21#section-6.1.2

16:38:27 <TallTed> PROPOSED: server MUST be able to materialize ldp:contains in representations delivered to the client, based on client preference (opt-in possibly via HTTP Prefer Request header, opt-out by some other method)

PROPOSED: server MUST be able to materialize ldp:contains in representations delivered to the client, based on client preference (opt-in possibly via HTTP Prefer Request header, opt-out by some other method)

16:42:17 <bblfish> Agree, downloading the whole thing and parsing it is probably a lot more complicated

Henry Story: Agree, downloading the whole thing and parsing it is probably a lot more complicated

16:43:13 <betehess> I just don't like the idea of the containment triples being part of an _opt-in_ mechanism (eg. with client-side inferencing), because you can't easily speak about the invariants

Alexandre Bertails: I just don't like the idea of the containment triples being part of an _opt-in_ mechanism (eg. with client-side inferencing), because you can't easily speak about the invariants

16:43:47 <betehess> I prefer to have a complete and correct interaction model

Alexandre Bertails: I prefer to have a complete and correct interaction model

16:44:08 <JohnArwe> @betehess, if we require the server to support the opt-in (so clients that care Know they can use it), does that help you?

John Arwe: @betehess, if we require the server to support the opt-in (so clients that care Know they can use it), does that help you?

16:44:12 <bblfish> q+

Henry Story: q+

16:44:17 <Arnaud> ack bblfish

Arnaud Le Hors: ack bblfish

16:44:24 <TallTed> PROPOSED: server MUST be able to materialize ldp:contains in representations delivered to the client, based on client preference (possibly via HTTP Prefer Request header)

PROPOSED: server MUST be able to materialize ldp:contains in representations delivered to the client, based on client preference (possibly via HTTP Prefer Request header)

16:44:27 <betehess> @JohnArwe, how do you see it?

Alexandre Bertails: @JohnArwe, how do you see it?

16:45:06 <ericP> -1

Eric Prud'hommeaux: -1

16:45:15 <betehess> +1

Alexandre Bertails: +1

16:45:18 <stevebattle14> +1

Steve Battle: +1

16:45:28 <TallTed> +1

+1

16:45:32 <deiu> +1

Andrei Sambra: +1

16:45:38 <nmihindu> +1

Nandana Mihindukulasooriya: +1

16:46:01 <bblfish> +0.8

Henry Story: +0.8

16:46:52 <bblfish> I was thinking of this as a statement on an LDPC

Henry Story: I was thinking of this as a statement on an LDPC

16:47:24 <betehess> yes, that's all about opting out from some server-managed triples

Alexandre Bertails: yes, that's all about opting out from some server-managed triples

16:47:27 <bblfish> I'd imagine this would be in the header of an LDPR to be in the header

Henry Story: I'd imagine this would be in the header of an LDPR to be in the header

16:47:39 <JohnArwe> +1 ... I like @betehess's ideas on reducing the latency hit vs earlier proposals too

John Arwe: +1 ... I like @betehess's ideas on reducing the latency hit vs earlier proposals too

16:48:53 <betehess> SteveS, if you want to be proactice, you'd always send the header, on any GET, because you don't know what you could find

Alexandre Bertails: SteveS, if you want to be proactice, you'd always send the header, on any GET, because you don't know what you could find

16:49:44 <betehess> yeah, I think we also need the other mechanism

Alexandre Bertails: yeah, I think we also need the other mechanism

16:49:53 <JohnArwe> Thinking of SteveS's comments, I did read the proposal to apply to retrieval requests against an LDPC URI only

John Arwe: Thinking of SteveS's comments, I did read the proposal to apply to retrieval requests against an LDPC URI only

16:50:49 <JohnArwe> ...I was assuming we would remain silent about LDPRs, and let implementations deal with inlining-like cases

John Arwe: ...I was assuming we would remain silent about LDPRs, and let implementations deal with inlining-like cases

16:51:29 <SteveS> +0 if we are talking about a GET on a URL for a LDPC, -1 for LDPRs that include/inline LDPCs

Steve Speicher: +0 if we are talking about a GET on a URL for a LDPC, -1 for LDPRs that include/inline LDPCs

16:51:57 <bblfish> q+

Henry Story: q+

16:52:06 <JohnArwe> @ericp, what was the motivation for your -1?

John Arwe: @ericp, what was the motivation for your -1?

16:52:32 <bblfish> q-

Henry Story: q-

16:53:16 <stevebattle14> ditto

Steve Battle: ditto

16:53:54 <ericP> -.9

Eric Prud'hommeaux: -.9

16:54:54 <bblfish> I'd kind of agree that it is adding complexity for something that is probably not going to be that interesting to anyone

Henry Story: I'd kind of agree that it is adding complexity for something that is probably not going to be that interesting to anyone

16:56:22 <bblfish> q+

Henry Story: q+

16:56:40 <TallTed> RESOLVED: server MUST be able to materialize ldp:contains in representations delivered to the client, based on client preference (possibly via HTTP Prefer or Accept Request header; possibly another mechanism)

RESOLVED: server MUST be able to materialize ldp:contains in representations delivered to the client, based on client preference (possibly via HTTP Prefer or Accept Request header; possibly another mechanism)

16:56:45 <Arnaud> ack bblfish

Arnaud Le Hors: ack bblfish

16:57:38 <stevebattle14> The question is if this is opt-in or out

Steve Battle: The question is if this is opt-in or out

16:57:43 <ericP> happy delegating to editors

Eric Prud'hommeaux: happy delegating to editors

16:58:01 <roger> +q

Roger Menday: +q

16:58:21 <Arnaud> ack roger

Arnaud Le Hors: ack roger

16:58:38 <JohnArwe> action: john to propose syntax for the resolution

ACTION: john to propose syntax for the resolution

16:58:38 <trackbot> Created ACTION-126 - Propose syntax for the resolution [on John Arwe - due 2014-01-20].

Trackbot IRC Bot: Created ACTION-126 - Propose syntax for the resolution [on John Arwe - due 2014-01-20].

16:59:06 <JohnArwe> @roger: when you say you want server preference, can yoyu provide a few words about what that means for you?

John Arwe: @roger: when you say you want server preference, can yoyu provide a few words about what that means for you?

16:59:31 <roger> +q

Roger Menday: +q

16:59:34 <betehess> JohnArwe, feel free to ping me as soon as you have a draft, I'll be happy to review it (but I have no Internet connection Wed to Friday)

Alexandre Bertails: JohnArwe, feel free to ping me as soon as you have a draft, I'll be happy to review it (but I have no Internet connection Wed to Friday)

16:59:41 <Arnaud> ack roger

Arnaud Le Hors: ack roger

17:00:16 <bblfish> My question is with the inferencing: it seems like at present the client may have to end up doing inferencing whatever happens

Henry Story: My question is with the inferencing: it seems like at present the client may have to end up doing inferencing whatever happens

17:00:53 <stevebattle14> Could profile and preferences obviate the need for all these different container types?

Steve Battle: Could profile and preferences obviate the need for all these different container types?

17:01:36 <Zakim> -Ashok_Malhotra

Zakim IRC Bot: -Ashok_Malhotra

17:01:39 <betehess> TallTed++

Alexandre Bertails: TallTed++

17:01:55 <bblfish> +1 for TallTed :-)

Henry Story: +1 for TallTed :-)

17:01:56 <TallTed> ADJOURNED

ADJOURNED

17:01:59 <betehess> great call

Alexandre Bertails: great call

17:02:07 <JohnArwe> @bblfish as I heard things (and this gets to my q to roger as well), the server Must be able to materialize the containment triples if the client asks (HTTP Expect semantics), and if not asked the server can just pick one.

John Arwe: @bblfish as I heard things (and this gets to my q to roger as well), the server Must be able to materialize the containment triples if the client asks (HTTP Expect semantics), and if not asked the server can just pick one.

17:02:20 <Zakim> -Sandro

Zakim IRC Bot: -Sandro

17:02:26 <Zakim> -EricP

Zakim IRC Bot: -EricP

17:02:27 <Zakim> -JohnArwe

Zakim IRC Bot: -JohnArwe

17:02:27 <Zakim> -Alexandre

Zakim IRC Bot: -Alexandre

17:02:27 <stevebattle14> bye

Steve Battle: bye

17:02:28 <Zakim> -TallTed

Zakim IRC Bot: -TallTed

17:02:28 <Zakim> -SteveS

Zakim IRC Bot: -SteveS

17:02:30 <Zakim> -Roger

Zakim IRC Bot: -Roger

17:02:30 <Zakim> -bblfish

Zakim IRC Bot: -bblfish

17:02:32 <Zakim> -Arnaud

Zakim IRC Bot: -Arnaud

17:02:33 <Zakim> -SteveBattle

Zakim IRC Bot: -SteveBattle

17:02:34 <bblfish> bye

Henry Story: bye

17:02:39 <Arnaud> trackbot, end meeting

Arnaud Le Hors: trackbot, end meeting

17:02:39 <trackbot> Zakim, list attendees

Trackbot IRC Bot: Zakim, list attendees

17:02:39 <Zakim> As of this point the attendees have been Arnaud, Alexandre, Andrei, Ashok_Malhotra, codyburleson, SteveS, Roger, SteveBattle, EricP, JohnArwe, Sandro, TallTed, nmihindu, bblfish

Zakim IRC Bot: As of this point the attendees have been Arnaud, Alexandre, Andrei, Ashok_Malhotra, codyburleson, SteveS, Roger, SteveBattle, EricP, JohnArwe, Sandro, TallTed, nmihindu, bblfish

17:02:47 <trackbot> RRSAgent, please draft minutes

Trackbot IRC Bot: RRSAgent, please draft minutes

17:02:48 <RRSAgent> I have made the request to generate http://www.w3.org/2014/01/13-ldp-minutes.html trackbot

RRSAgent IRC Bot: I have made the request to generate http://www.w3.org/2014/01/13-ldp-minutes.html trackbot

17:02:48 <trackbot> RRSAgent, bye

Trackbot IRC Bot: RRSAgent, bye

17:02:48 <RRSAgent> I see 2 open action items saved in http://www.w3.org/2014/01/13-ldp-actions.rdf :

RRSAgent IRC Bot: I see 2 open action items saved in http://www.w3.org/2014/01/13-ldp-actions.rdf :

17:02:48 <RRSAgent> ACTION: john to propose syntax for the resolution [1]

ACTION: john to propose syntax for the resolution [1]

17:02:48 <RRSAgent>   recorded in http://www.w3.org/2014/01/13-ldp-irc#T16-58-38

RRSAgent IRC Bot: recorded in http://www.w3.org/2014/01/13-ldp-irc#T16-58-38



Formatted by CommonScribe