14:59:44 <RRSAgent> RRSAgent has joined #ldp
14:59:44 <RRSAgent> logging to http://www.w3.org/2014/01/13-ldp-irc
14:59:46 <trackbot> RRSAgent, make logs public
14:59:46 <Zakim> Zakim has joined #ldp
14:59:48 <trackbot> Zakim, this will be LDP
14:59:48 <Zakim> 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:25 <Ashok> Ashok has joined #ldp
15:00:29 <Zakim> +Arnaud
15:00:50 <Zakim> +TimBL
15:00:58 <stevebattle14> stevebattle14 has joined #ldp
15:01:00 <betehess> Zakim, TimBL is Alexandre
15:01:00 <Zakim> +Alexandre; got it
15:01:04 <codyburleson> +CodyB
15:01:14 <betehess> Zakim, Alexandre also has Andrei
15:01:14 <Zakim> +Andrei; got it
15:01:55 <Arnaud> zakim, who is on the phone?
15:01:55 <Zakim> On the phone I see [IPcaller], Arnaud, Alexandre
15:01:56 <Zakim> Alexandre has Alexandre, Andrei
15:02:16 <SteveS> SteveS has joined #ldp
15:02:35 <Zakim> +Ashok_Malhotra
15:02:40 <codyburleson> zakim, IPCaller is me
15:02:40 <Zakim> +codyburleson; got it
15:02:52 <roger> roger has joined #ldp
15:02:58 <Zakim> +[IBM]
15:03:07 <SteveS> zakim, ibm is me
15:03:07 <Zakim> +SteveS; got it
15:03:08 <Zakim> +Roger
15:03:53 <Zakim> +SteveBattle
15:04:36 <Zakim> +EricP
15:04:58 <ericP> i am
15:04:58 <Zakim> +JohnArwe
15:05:37 <Zakim> +Sandro
15:06:41 <Zakim> +OpenLink_Software
15:06:49 <TallTed> Zakim, OpenLink_Software is temporarily me
15:06:49 <Zakim> +TallTed; got it
15:08:21 <TallTed> scribenick: TallTed
15:08:40 <TallTed> Proposed: Approve the minutes of the January 6 teleconf, http://www.w3.org/2013/meeting/ldp/2013-01-06
15:09:42 <TallTed> 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
15:11:42 <sandro> regrets from me, holiday
15:12:50 <betehess> can we try to move it exceptionally on Tuesday or another day?
15:13:03 <Arnaud> strawpoll: meeting on 1/20?
15:13:03 <Ashok> regrets, vacation
15:13:04 <betehess> let's set up a Doodle
15:13:14 <ericP> present
15:13:17 <betehess> present
15:13:17 <TallTed> regrets
15:13:17 <JohnArwe> I'll be here
15:13:23 <stevebattle14> present
15:13:23 <SteveS> regrets
15:13:26 <roger> i can make it
15:13:30 <codyburleson> present
15:14:13 <TallTed> TOPIC: action items
15:17:00 <nmihindu> nmihindu has joined #ldp
15:17:11 <sandro> 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
15:17:12 <trackbot> http://www.w3.org/2012/ldp/track/actions/118
15:17:58 <TallTed> Arnaud: question to ericP about status of action-118
15:18:23 <Zakim> +??P21
15:18:31 <TallTed> ericP: thinks the action has been taken...
15:19:17 <nmihindu> Zakim, ??P21 is me
15:19:17 <Zakim> +nmihindu; got it
15:19:24 <nmihindu> Zakim, mute me
15:19:24 <Zakim> nmihindu should now be muted
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
15:20:31 <TallTed> ericP: 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?
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
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
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
15:26:11 <JohnArwe> +1
15:26:32 <ericP> +1
15:26:50 <stevebattle14> Why [23]XX ?
15:27:15 <sandro> +1
15:27:20 <JohnArwe> TAG is debating 2xx vs 3xx merits
15:27:20 <TallTed> +0.5
15:27:40 <SteveS> +1  (though, we won't prohibit 303..so still an option)
15:27:46 <stevebattle14> +1
15:27:52 <nmihindu> +0 didn't follow the discussion in detail
15:28:05 <deiu> +0 (same as above)
15:29:18 <betehess> +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?
15:30:56 <Arnaud> 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
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
15:33:16 <JohnArwe> +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
15:37:27 <TallTed> Arnaud: so, is action-118 closeable, or do we need it open for tracking TAG?
15:38:55 <bblfish> bblfish has joined #ldp
15:39:39 <TallTed> TOPIC: ISSUE-92 - Interaction Model
15:39:42 <TallTed> issue-92?
15:39:42 <trackbot> 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
15:41:35 <Zakim> +bblfish
15:41:42 <TallTed> 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
15:41:50 <betehess> +1
15:41:52 <TallTed> +1
15:41:52 <bblfish> -1
15:41:53 <ericP> +1
15:42:00 <deiu> +1
15:42:07 <nmihindu> +1
15:42:10 <roger> +1
15:42:15 <SteveS> +1
15:42:16 <JohnArwe> +1
15:42:18 <Ashok> +1
15:42:57 <TallTed> Arnaud: Q to bblfish, what's the basis of objection?
15:43:36 <TallTed> bblfish: @profile is more syntactic, limits the types of documents
15:44:23 <bblfish> 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
15:44:59 <stevebattle14> 0
15:45:03 <betehess> 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?
15:45:17 <JohnArwe> 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
15:45:23 <betehess> exactly
15:46:10 <betehess> http://tools.ietf.org/search/rfc6906
15:46:14 <JohnArwe> 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"
15:46:39 <TallTed> JohnArwe: the definition of @type doesn't fit our usage, as seen from the IANA link registry
15:46:49 <JohnArwe> 6. "type"
15:46:49 <JohnArwe>    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
15:46:49 <JohnArwe>    Internationalized Resource Identifier (IRI).
15:46:49 <JohnArwe>      HTTP/1.1 200 OK
15:46:49 <JohnArwe>      Content-Type: text/plain
15:46:49 <JohnArwe>      Link: <http://example.org/Person/givenName>; rel="type"
15:46:49 <JohnArwe>      Sally
15:46:50 <JohnArwe>    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
15:46:50 <JohnArwe>    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
15:46:50 <JohnArwe>    Content-Type header identifies the specific serialization format of
15:46:50 <JohnArwe>    the payload.
15:46:50 <JohnArwe>    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.
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"
15:49:08 <Zakim> +Sandro.a
15:49:14 <Zakim> -Sandro
15:49:32 <JohnArwe> 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?
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.
15:53:11 <TallTed> TallTed: 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
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.
15:54:58 <SteveS> 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
15:56:14 <ericP> q+ to talk to the above
15:56:59 <Arnaud> ack ericP
15:57:00 <Zakim> 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
15:59:40 <TallTed>    identify what kind of mechanism they are using for expressing
15:59:40 <TallTed>    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
15:59:41 <TallTed>    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
15:59:43 <TallTed>    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'
16:00:09 <Ashok> q+
16:00:51 <TallTed> [[Abstract
16:00:51 <TallTed>    This specification defines the 'profile' link relation type that
16:00:51 <TallTed>    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
16:00:52 <TallTed>    semantics of the resource representation itself, but to allow clients
16:00:52 <TallTed>    to learn about additional semantics (constraints, conventions,
16:00:54 <TallTed>    extensions) that are associated with the resource representation, in
16:00:56 <TallTed>    addition to those defined by the media type and possibly other
16:00:58 <TallTed>    mechanisms.]]
16:01:23 <bblfish> q?
16:01:25 <Arnaud> ack ashok
16:03:00 <TallTed> [...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
16:04:44 <JohnArwe> 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
16:05:08 <JohnArwe> 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
16:05:28 <betehess> 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
16:06:50 <ericP> s/tye/they/
16:07:23 <TallTed> q?
16:07:43 <Arnaud> 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"
16:08:22 <bblfish> q+ for what Sandro
16:08:35 <ericP> sandro, does the file change type when you archive it?
16:09:09 <Arnaud> ack bblfish
16:09:09 <Zakim> 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?
16:10:41 <bblfish> I'll read up it
16:11:12 <TallTed> Arnaud: we'll table it for this week, and aim for closure next time
16:11:22 <TallTed> TOPIC: 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.
16:11:26 <TallTed> issue-89?
16:11:26 <trackbot> 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
16:12:35 <JohnArwe> 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
16:16:21 <bblfish> q+
16:17:31 <bblfish> http://lists.w3.org/Archives/Public/public-ldp-wg/2013Dec/0043.html
16:17:47 <betehess> question is more like Simple vs Direct
16:18:00 <betehess> also in my opinion, handling the doubling should only be an optimization
16:18:41 <betehess> please, no inferencing client side........
16:18:42 <bblfish> CONSTRUCT { ?subject ldp:contains ?ldpr }
16:18:42 <bblfish> WHERE{
16:18:42 <bblfish>   { ?ldpc a ldp:DirectContainer;
16:18:44 <bblfish>           ldp:containerResource ?subject;
16:18:46 <bblfish>           ldp:containsRelation ?predicate.
16:18:48 <bblfish>     ?subject ?predicate ?ldpr.
16:18:50 <bblfish>   }
16:18:52 <bblfish>    UNION
16:18:54 <bblfish>  {
16:18:56 <bblfish>      ?ldpc a ldp:DirectContainer;
16:18:58 <bblfish>            ldp:containerResource ?object;
16:19:00 <bblfish>            ldp:containedByRelation ?predicate.
16:19:02 <bblfish>      ?ldpr ?predicate ?object .
16:19:04 <ericP> re: inferencing, the question is upon whom you place the burden of performing inference
16:19:04 <bblfish>   }
16:19:06 <bblfish> }
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.
16:21:32 <JohnArwe> @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
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
16:22:05 <TallTed> @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
16:22:56 <bblfish> CONSTRUCT { ?subjet ?predicate ?object }
16:22:56 <bblfish> WHERE {
16:22:57 <bblfish>  { ?ldpc a ldp:DirectContainer;
16:22:59 <bblfish>           ldp:containerResource ?subject;
16:23:01 <bblfish>           ldp:containsRelation ?predicate;
16:23:03 <bblfish>           ldp:contains ?ldpr.
16:23:05 <bblfish>     BIND (?ldpr AS ?object)
16:23:07 <bblfish>   }
16:23:09 <bblfish>    UNION
16:23:11 <bblfish>   {
16:23:13 <bblfish>      ?ldpc a ldp:DirectContainer;
16:23:15 <bblfish>            ldp:containerResource ?object;
16:23:17 <bblfish>            ldp:containedByRelation ?predicate;
16:23:19 <bblfish>            ldp:contains ?ldpr.
16:23:21 <bblfish>    BIND (?ldpr AS ?subject)
16:23:23 <bblfish>   }
16:23:25 <bblfish> }
16:23:27 <bblfish> q+
16:23:34 <Arnaud> ack bblfish
16:23:47 <TallTed> ericP: 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?
16:24:25 <betehess> @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
16:25:24 <ericP> @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
16:26:07 <ericP> 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
16:27:36 <ericP> @betehess, i understand the weird, but it's an optimization which makes the clients slightly more comlex
16:28:15 <ericP> s/comlex/complex/
16:28:41 <Arnaud> 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
16:29:01 <betehess> q+
16:29:09 <Arnaud> 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
16:30:26 <betehess> 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
16:31:09 <betehess> +1
16:31:35 <bblfish> 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.
16:32:13 <JohnArwe> 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
16:32:51 <ericP> 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
16:33:46 <betehess> q+
16:33:56 <ericP> true, that certainly mitigates it, but at the cost of more complexity than we are saving
16:34:02 <Arnaud> ack betehess
16:34:15 <Zakim> -EricP
16:34:39 <Zakim> +EricP
16:34:48 <JohnArwe> http://tools.ietf.org/html/draft-snell-http-prefer-18
16:35:10 <betehess> yeah, why not?
16:35:23 <bblfish> 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
16:35:54 <betehess> 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.
16:36:53 <betehess> the PROPOSAL just says "opt-out", which is fine
16:37:29 <Ashok> q+
16:37:38 <Arnaud> ack ashok
16:37:43 <betehess> 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
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)
16:42:17 <bblfish> 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
16:43:47 <betehess> 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?
16:44:12 <bblfish> q+
16:44:17 <Arnaud> 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)
16:44:27 <betehess> @JohnArwe, how do you see it?
16:45:06 <ericP> -1
16:45:15 <betehess> +1
16:45:18 <stevebattle14> +1
16:45:28 <TallTed> +1
16:45:32 <deiu> +1
16:45:38 <nmihindu> +1
16:46:01 <bblfish> +0.8
16:46:52 <bblfish> 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
16:47:27 <bblfish> 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
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
16:49:44 <betehess> 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
16:50:49 <JohnArwe> ...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
16:51:57 <bblfish> q+
16:52:06 <JohnArwe> @ericp, what was the motivation for your -1?
16:52:32 <bblfish> q-
16:53:16 <stevebattle14> ditto
16:53:54 <ericP> -.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
16:56:22 <bblfish> q+
16:56:34 <Arnaud> RESOLVED: 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: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)
16:56:45 <Arnaud> ack bblfish
16:57:38 <stevebattle14> The question is if this is opt-in or out
16:57:43 <ericP> happy delegating to editors
16:58:01 <roger> +q
16:58:14 <JohnArwe> action: johnarwe to propose syntax for the resolution
16:58:14 <trackbot> Error finding 'johnarwe'. You can review and register nicknames at <http://www.w3.org/2012/ldp/track/users>.
16:58:21 <Arnaud> ack roger
16:58:38 <JohnArwe> 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].
16:59:06 <JohnArwe> @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
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)
16:59:41 <Arnaud> 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
17:00:53 <stevebattle14> Could profile and preferences obviate the need for all these different container types?
17:01:36 <Zakim> -Ashok_Malhotra
17:01:39 <betehess> TallTed++
17:01:55 <bblfish> +1 for TallTed :-)
17:01:56 <TallTed> ADJOURNED
17:01:59 <betehess> 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.
17:02:20 <Zakim> -Sandro.a
17:02:26 <Zakim> -EricP
17:02:27 <Zakim> -JohnArwe
17:02:27 <Zakim> -Alexandre
17:02:27 <stevebattle14> bye
17:02:28 <Zakim> -TallTed
17:02:28 <Zakim> -SteveS
17:02:30 <Zakim> -Roger
17:02:30 <Zakim> -bblfish
17:02:32 <Zakim> -Arnaud
17:02:33 <Zakim> -SteveBattle
17:02:34 <bblfish> bye
17:02:39 <Arnaud> trackbot, end meeting
17:02:39 <trackbot> 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
17:02:47 <trackbot> 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