See also: IRC log
<trackbot> Date: 13 January 2014
<codyburleson> +CodyB
<ericP> i am
<scribe> scribenick: TallTed
Proposed: Approve the minutes of
the January 6 teleconf, http://www.w3.org/2013/meeting/ldp/2013-01-06
... 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
<sandro> regrets from me, holiday
<betehess> can we try to move it exceptionally on Tuesday or another day?
<Arnaud> strawpoll: meeting on 1/20?
<Ashok> regrets, vacation
<betehess> let's set up a Doodle
<ericP> present
<betehess> present
regrets
<JohnArwe> I'll be here
<stevebattle14> present
<SteveS> regrets
<roger> i can make it
<codyburleson> present
<sandro> action-118?
<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> http://www.w3.org/2012/ldp/track/actions/118
Arnaud: question to ericP about status of action-118
ericP: thinks the action has been taken...
Arnaud: TAG discussion seems now to be clearly focused on 20x/30x as combination of 303+200, rather than a paging-specific question
ericP: does anyone have a toolchain that will fail if TAG goes with 30x instead of 20x?
Arnaud: how does TimBL seem to feel about us falling back to 303 until/unless this new code comes?
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
<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
<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
<JohnArwe> +1
<ericP> +1
<stevebattle14> Why [23]XX ?
<sandro> +1
<JohnArwe> TAG is debating 2xx vs 3xx merits
+0.5
<SteveS> +1 (though, we won't prohibit 303..so still an option)
<stevebattle14> +1
<nmihindu> +0 didn't follow the discussion in detail
<deiu> +0 (same as above)
<betehess> +0
<betehess> sounds important: is that possible to get a more detailed proposal by email with the motivations, and then we vote later?
<Arnaud> http://www.w3.org/TR/ldp/#http-get-1
<SteveS> Per John's earlier question, 20130307 draft had 303 as a SHOULD
<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
<JohnArwe> +1 to TallTed
RESOLUTION: 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
Arnaud: so, is action-118 closeable, or do we need it open for tracking TAG?
issue-92?
<trackbot> issue-92 -- Change rel=type to rel=profile for client introspection of interaction model -- open
<trackbot> http://www.w3.org/2012/ldp/track/issues/92
PROPOSED: Close ISSUE-92 by changing rel=type to rel=profile for client introspection of interaction model
<bblfish> ¡hi sorry I am late
<betehess> +1
+1
<bblfish> -1
<ericP> +1
<deiu> +1
<nmihindu> +1
<roger> +1
<SteveS> +1
<JohnArwe> +1
<Ashok> +1
Arnaud: Q to bblfish, what's the basis of objection?
bblfish: @profile is more syntactic, limits the types of documents
<bblfish> profile is better for validation
bblfish: there's no real argument "for", so we should preserve @profile for future use, e.g., validation
<stevebattle14> 0
<betehess> I don't think rel=profile has to be unique
<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?
<JohnArwe> what prevents rel=profile being used for both?
<ericP> sorry http://www.w3.org/2013/ShEx/FancyShExDemo?schemaURL=test/GenX/schema.shex&dataURL=test/Issue-pass-date.ttl&colorize=1
<betehess> exactly
<betehess> http://tools.ietf.org/search/rfc6906
<JohnArwe> http://www.iana.org/assignments/link-relations/link-relations.xml
<betehess> http://tools.ietf.org/search/rfc6906 says precisely "one or more profiles"
JohnArwe: the definition of @type doesn't fit our usage, as seen from the IANA link registry
<JohnArwe> 6. "type"
<JohnArwe> The "type" link relation can be used to indicate that the context
<JohnArwe> resource is an instance of the resource identified by the target
<JohnArwe> Internationalized Resource Identifier (IRI).
<JohnArwe> HTTP/1.1 200 OK
<JohnArwe> Content-Type: text/plain
<JohnArwe> Link: <http://example.org/Person/givenName>; rel="type"
<JohnArwe> Sally
<JohnArwe> When used within the header of an HTTP message, the type specified by
<JohnArwe> the "type" link relation cannot be confused with the content type of
<JohnArwe> the payload as given by the Content-Type header. The "type" link
<JohnArwe> relation references the payload's abstract semantic type, whereas the
<JohnArwe> Content-Type header identifies the specific serialization format of
<JohnArwe> the payload.
<JohnArwe> If the context can be considered to be an instance of multiple
<JohnArwe> semantic types, multiple "type" link relations can be used.
Arnaud: we've shifted from conveying "this is an LDPC/R" to "this is the kind of interaction you can have"
<JohnArwe> http://tools.ietf.org/html/rfc6906 = rel=profile
<betehess> henry, what if we said that the statement was true only and only if you find the rel=profile with a ldpc value?
<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.
TallTed: the RFC says multiple (interaction) @profiles may exist for a single (document/resource) @type
<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
<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.
<SteveS> I agree that interaction can be inferred from the type, though there are cases when it needs to be overwritten.
<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
<Zakim> ericP, you wanted to talk to the above
from RFC 6906 -- [[ ... The objective of profiles is that they allow instances to clearly
identify what kind of mechanism they are using for expressing
additional semantics, should they follow a well-defined framework for
doing so (see Section 5 for examples). While this allows servers and
clients to represent the use of profiles, it does not make the
profile information visible outside of the representation itself, if
the representation is using embedded typed links. For newly defined ...]]
<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'
[[Abstract
This specification defines the 'profile' link relation type that
allows resource representations to indicate that they are following
one or more profiles. A profile is defined not to alter the
semantics of the resource representation itself, but to allow clients
to learn about additional semantics (constraints, conventions,
extensions) that are associated with the resource representation, in
addition to those defined by the media type and possibly other
mechanisms.]]
[...discussion...] Erik Wilde indicated that profile was viable, but we could also choose to define our own relation
Arnaud: summarizing henry's objection -- (1) using profile removes it from later use; (2) don't see any reason for change
<JohnArwe> I don't think (2) was henry's objection; his (2) sounds like "why the need for change"
bblfish: I need to carefully study profile and type; I didn't expect such support for profile
<JohnArwe> defining our own relation was an option arnaud reiterated from my email
<SteveS> That with discussed in http://www.w3.org/2012/ldp/track/issues/91
<betehess> it's duck typing, the other way :-)
<ericP> one can create types for every permutation of properties but they are mostly vapid
<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"
<ericP> sandro, does the file change type when you archive it?
<Zakim> bblfish, you wanted to discuss what Sandro
<betehess> but what if the application data, set by the user, sets rdf:type of ldpc when it is a simple LDPR?
<bblfish> I'll read up it
Arnaud: we'll table it for this week, and aim for closure next time
<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.
issue-89?
<trackbot> issue-89 -- Tie the interaction model with the LDP data model through the notion of Managed Resources -- open
<trackbot> http://www.w3.org/2012/ldp/track/issues/89
<JohnArwe> http://www.w3.org/2012/ldp/wiki/Issue-89 is probably a more useful link ... adding that to issue shortly
<ericP> +1 to using the term "Document" in at least our documentation to refer to info resources
<bblfish> http://lists.w3.org/Archives/Public/public-ldp-wg/2013Dec/0043.html
<betehess> question is more like Simple vs Direct
<betehess> also in my opinion, handling the doubling should only be an optimization
<betehess> please, no inferencing client side........
<bblfish> CONSTRUCT { ?subject ldp:contains ?ldpr }
<bblfish> WHERE{
<bblfish> { ?ldpc a ldp:DirectContainer;
<bblfish> ldp:containerResource ?subject;
<bblfish> ldp:containsRelation ?predicate.
<bblfish> ?subject ?predicate ?ldpr.
<bblfish> }
<bblfish> UNION
<bblfish> {
<bblfish> ?ldpc a ldp:DirectContainer;
<bblfish> ldp:containerResource ?object;
<bblfish> ldp:containedByRelation ?predicate.
<bblfish> ?ldpr ?predicate ?object .
<ericP> re: inferencing, the question is upon whom you place the burden of performing inference
<bblfish> }
<bblfish> }
<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.
<JohnArwe> @TallTed, can you give example(s) of places in LDP today that require client inferencing?
<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
<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
@JohnArwe - membershipPredicate (or whatever we're calling it this week)
<bblfish> 4.2.11 seems to suggest that the current spec requires ldp:contains should be materialised
<bblfish> CONSTRUCT { ?subjet ?predicate ?object }
<bblfish> WHERE {
<bblfish> { ?ldpc a ldp:DirectContainer;
<bblfish> ldp:containerResource ?subject;
<bblfish> ldp:containsRelation ?predicate;
<bblfish> ldp:contains ?ldpr.
<bblfish> BIND (?ldpr AS ?object)
<bblfish> }
<bblfish> UNION
<bblfish> {
<bblfish> ?ldpc a ldp:DirectContainer;
<bblfish> ldp:containerResource ?object;
<bblfish> ldp:containedByRelation ?predicate;
<bblfish> ldp:contains ?ldpr.
<bblfish> BIND (?ldpr AS ?subject)
<bblfish> }
<bblfish> }
ericP: querying will not require client-side inferencing to interact with containers...
<JohnArwe> @TallTed that family of predicates tells a client how to query over what they get back, not how to add new triples... no?
<betehess> @ericP, tabulator not only consumes (read) but also interacts with write/update operations
<JohnArwe> @bblfish: indeed that's why some of us (me at least) talk about doubling the representation size
<ericP> @betehess, sure, but they can be coded in tabulator in 5 or 10 lines of code
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
<ericP> vs. if you had to teach every linked data user to extract and execute the SPARQL constructs that bblfish pasted.
<betehess> @ericP, for something so tied to interaction, I find it very weird to not make it returned by default
<ericP> @betehess, i understand the weird, but it's an optimization which makes the clients slightly more complex
<Arnaud> PROPOSED: ldp:contains MUST be materialized by the server
<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
<bblfish> The advantage of mererialising the ldp:contains is that it makes it consistent with the ldp:SimpleContainer and the ldp:IndirectContainer
<betehess> with these remarks, +1 to MUST
PROPOSED: ldp:contains MUST be materialized by the server in representations delivered to the client, unless client opts out
<betehess> +1
<bblfish> I am fine with that given that one can dedice the membership triples with the query above
<roger> I don't need these ldp:contains in my applications, so, I don't like the MUST here.
<JohnArwe> I can live with the opt out
<ericP> i think this will make that part of LDP to anyone who normally writes web protocols
<ericP> given the choice between reusing LDP and writing their own, they'd see an obvious advantage in writing their own
<betehess> not true, an opt-out mecanism could be send with a header during the GET request
<ericP> true, that certainly mitigates it, but at the cost of more complexity than we are saving
<JohnArwe> http://tools.ietf.org/html/draft-snell-http-prefer-18
<betehess> yeah, why not?
<bblfish> Does this mean you need to send this even before you know that something is an LDPC?
e.g., Prefer=materialized
<betehess> bblfish, if you're an LDP client, then it's totally fine
<bblfish> but well, I suppose if there is alreation <ldpc> a ldp:Container . then you'd know it was an container.
<betehess> the PROPOSAL just says "opt-out", which is fine
<betehess> so we *can* propose a proactive and a reactive mechanism to opt-out from getting all those triples
<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
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)
<bblfish> Agree, downloading the whole thing and parsing it is probably a lot more complicated
<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
<betehess> I prefer to have a complete and correct interaction model
<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?
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)
<betehess> @JohnArwe, how do you see it?
<ericP> -1
<betehess> +1
<stevebattle14> +1
+1
<deiu> +1
<nmihindu> +1
<bblfish> +0.8
<bblfish> I was thinking of this as a statement on an LDPC
<betehess> yes, that's all about opting out from some server-managed triples
<bblfish> I'd imagine this would be in the header of an LDPR to be in the header
<JohnArwe> +1 ... I like @betehess's ideas on reducing the latency hit vs earlier proposals too
<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
<betehess> yeah, I think we also need the other mechanism
<JohnArwe> Thinking of SteveS's comments, I did read the proposal to apply to retrieval requests against an LDPC URI only
<JohnArwe> ...I was assuming we would remain silent about LDPRs, and let implementations deal with inlining-like cases
<SteveS> +0 if we are talking about a GET on a URL for a LDPC, -1 for LDPRs that include/inline LDPCs
<JohnArwe> @ericp, what was the motivation for your -1?
<stevebattle14> ditto
<ericP> -.9
<bblfish> I'd kind of agree that it is adding complexity for something that is probably not going to be that interesting to anyone
<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)
RESOLUTION: 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)
<stevebattle14> The question is if this is opt-in or out
<ericP> happy delegating to editors
<roger> +q
<JohnArwe> ACTION: johnarwe to propose syntax for the resolution [recorded in http://www.w3.org/2014/01/13-ldp-minutes.html#action01]
<trackbot> Error finding 'johnarwe'. You can review and register nicknames at <http://www.w3.org/2012/ldp/track/users>.
<JohnArwe> ACTION: john to propose syntax for the resolution [recorded in http://www.w3.org/2014/01/13-ldp-minutes.html#action02]
<trackbot> Created ACTION-126 - Propose syntax for the resolution [on John Arwe - due 2014-01-20].
<JohnArwe> @roger: when you say you want server preference, can yoyu provide a few words about what that means for you?
<roger> +q
<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)
<bblfish> My question is with the inferencing: it seems like at present the client may have to end up doing inferencing whatever happens
<stevebattle14> Could profile and preferences obviate the need for all these different container types?
<betehess> TallTed++
<bblfish> +1 for TallTed :-)
ADJOURNED
<betehess> great call
<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.
<stevebattle14> bye
<bblfish> bye
<Arnaud> trackbot, end meeting
This is scribe.perl Revision: 1.138 of Date: 2013-04-25 13:59:11 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/ (2) we should define our own relation/ (2) don't see any reason for change/ Succeeded: s/tye/they/ Succeeded: s/comlex/complex/ Found ScribeNick: TallTed Inferring Scribes: TallTed Default Present: Arnaud, Alexandre, Andrei, Ashok_Malhotra, codyburleson, SteveS, Roger, SteveBattle, EricP, JohnArwe, Sandro, TallTed, nmihindu, bblfish Present: Arnaud Alexandre Andrei Ashok_Malhotra codyburleson SteveS Roger SteveBattle EricP JohnArwe Sandro TallTed nmihindu bblfish WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Found Date: 13 Jan 2014 Guessing minutes URL: http://www.w3.org/2014/01/13-ldp-minutes.html People with action items: john johnarwe WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]