19:02:53 <RRSAgent> RRSAgent has joined #ldp
19:02:53 <RRSAgent> logging to http://www.w3.org/2013/03/14-ldp-irc
19:03:03 <davidwood> Arnaud and roger discuss the opportunity to reopen this issue if roger remains unhappy with it after the editors update the draft.
19:03:41 <JohnArwe> FWIW, wrt pagesize and the existing link headers I don't see anything promising in the link relations registry http://www.iana.org/assignments/link-relations/link-relations.xml ... I see first, last, next, prev all of which appear to have come from RFC 5005 and those are now registered via RFC 5988.
19:04:47 <sandro> roger: My concern is that Container pagination might not actually work for Resource Pagination, despite SteveS claiming it does.
19:05:42 <SteveS> This proposal was originally discussed on Feb 11th btw http://www.w3.org/2012/ldp/meeting/2013-02-11#Issue__2d_33_Pagination_for_non__2d_container_resources
19:06:11 <sandro> davidwood: summarize objection process
19:07:17 <davidwood> Arnaud: We can spend some time after hours and also tomorrow to see if we need to reopen ISSUE-33.
19:07:43 <davidwood> WG breaks for 25 minutes
19:33:50 <cygri> scribe: cygri
19:33:54 <SteveS> SteveS has joined #ldp
19:34:16 <rgarcia> rgarcia has joined #ldp
19:34:35 <Arnaud> "must-haves": 15, 17, 32, 37, 38
19:34:50 <cygri> Arnaud: Let's get back to our list of high-priority issues.
19:35:16 <cygri> ISSUE-32?
19:35:16 <trackbot> ISSUE-32 -- How can clients discover that a resource is an LDPR or LDPC, and what features are supported? -- open
19:35:16 <trackbot> http://www.w3.org/2012/ldp/track/issues/32
19:35:25 <cygri> ISSUE-37?
19:35:25 <trackbot> ISSUE-37 -- What is the LDP data model and the LDP interaction model? -- open
19:35:25 <trackbot> http://www.w3.org/2012/ldp/track/issues/37
19:35:29 <cygri> ISSUE-38?
19:35:29 <trackbot> ISSUE-38 -- filtered representations and inlining -- open
19:35:29 <trackbot> http://www.w3.org/2012/ldp/track/issues/38
19:36:02 <cygri> topic: ISSUE-32: Discovering LDPRs, LDPCs, and their supported features
19:36:33 <JohnArwe> http://www.w3.org/2012/ldp/wiki/ISSUE-32
19:37:37 <cygri> John's wiki page: http://www.w3.org/2012/ldp/wiki/ISSUE-32#Affordances
19:38:11 <SteveBattle> If you try a GET, and get back RDF that says it's an LDPR or LDPC doesn't that solve the first part of the issue?
19:38:22 <cygri> q+
19:38:38 <Arnaud> ack cygri
19:38:47 <SteveS> q+
19:39:52 <Arnaud> cygri: restates the need for discovery in REST
19:40:43 <Arnaud> cygri: one possibility is to add triples to express what can be done
19:41:01 <Arnaud> cygri: another is to use the option method
19:41:25 <Arnaud> cygri: erik said you should use mediatypes
19:41:49 <Arnaud> cygri: there are different ways but it's good to have a way to find out before trying
19:41:52 <cygri> sandro: I like putting this information into the RDF
19:42:01 <cygri> Ashok: what if it's an image?
19:42:06 <cygri> sandro: Put it into the metadata.
19:42:30 <cygri> JohnArwe: What if different members have different interaction capabilities?
19:42:47 <cygri> sandro: You learn by GETting each resource.
19:43:34 <cygri> davidwood: What we do [in Callimachus], you can start at the top, discover containers, then members, and discover everything on the server.
19:43:42 <cygri> ... We don't quite have that in LDP at the moment.
19:43:47 <SteveBattle> q+
19:43:48 <cygri> ... Discoverability is a good thing.
19:44:00 <Arnaud> ack steves
19:44:28 <bblfish> bblfish has joined #ldp
19:44:40 <cygri> SteveS: Putting this in RDF, HEAD, headers, etc seem all fine.
19:44:47 <cygri> ... Should use HTTP-level options where possible
19:44:52 <JohnArwe> q+
19:45:04 <Arnaud> ack steveb
19:45:29 <cygri> SteveBattle: If this info is in RDF, then we need to define it in the LDP ontology.
19:45:42 <cygri> Arnaud: Does the LDP ontology become part of the spec?
19:45:46 <cygri> JohnArwe: Yes.
19:45:54 <Arnaud> ack john
19:46:00 <cygri> Arnaud: Can we go back to John's wiki page?
19:46:01 <cygri> http://www.w3.org/2012/ldp/wiki/ISSUE-32#Affordances
19:46:48 <cygri> JohnArwe: I went through the spec, trying to find everything that a client might possibly want to introspect.
19:47:09 <cygri> ... If the spec says how to discover optional features, then I put it in.
19:47:47 <cygri> ... There's also POWDER as another way of discovering things.
19:47:54 <nmihindu_> nmihindu_ has joined #ldp
19:48:13 <cygri> ... The more resources your app is dealing with, the more resources it would need to introspect.
19:48:43 <cygri> ... POWDER allows making assertions about sets of resources. Scalable
19:49:19 <cygri> davidwood: The driving use case for PICS (?), POWDER's preprocessor, was porn
19:49:39 <cygri> ... State whether a resource is NSFW
19:50:01 <cygri> ... The porn guys liked it, but the browser guys wouldn't implement it
19:50:44 <cygri> ... POWDER a successor. Lacks a strong use case. The POWDER guys would be happy if you find one!
19:52:33 <cygri> SteveS: Someone should take an action to make another pass over John's wiki page, propose terms etc
19:52:55 <cygri> Arnaud: Is this the direction the group needs to go in?
19:53:04 <cygri> sandro: Do clients benefit from all of these things?
19:53:05 <cygri> q+
19:53:19 <Arnaud> s/needs/wants/
19:53:42 <cygri> ... In my mind, you have general-purpose and domain-specific LDP servers
19:53:58 <cygri> ... Will they implement everything, or the minimum they can get away with?
19:54:08 <krp> krp has joined #ldp
19:54:11 <cygri> JohnArwe: Not just *one* class of domain-specific LDP servers
19:54:12 <Arnaud> ack cygri
19:55:49 <Arnaud> cygri: discoverability is especially important for write operations
19:56:43 <JohnArwe> q+
19:57:34 <Arnaud> ack john
19:57:39 <JohnArwe> q-
19:57:47 <cygri> SteveS: Capabilities and permissions can be dynamic. PUT doesn't show up as allowed method if you don't have the permission
19:58:32 <cygri> sandro: POWDER says, "all resources with this URI template have this property"
19:58:57 <cygri> JohnArwe: So we'd have the same ontology, but a different way of saying it
19:58:58 <cygri> q+
19:59:43 <SteveS> q+
20:00:07 <cygri> JohnArwe: We may not have to do anything different about POWDER. Just define the ontology and mention that POWDER exists as an option
20:00:15 <cygri> q-
20:00:36 <cygri> sandro: The hard part is clustering of features into labelled profiles
20:00:45 <Arnaud> ack steves
20:01:13 <cygri> JohnArwe: I could take an action to define the ontology
20:01:37 <cygri> SteveS: me too
20:02:51 <Arnaud> action: johnarwe to come up with an ontology proposal for discovery
20:02:51 <trackbot> Error finding 'johnarwe'. You can review and register nicknames at <http://www.w3.org/2012/ldp/track/users>.
20:03:35 <cygri> JohnArwe: I assume we could put a version of this table into one of the extra documents
20:03:47 <Arnaud> action: john to come up with an ontology proposal for discovery
20:03:47 <trackbot> Created ACTION-51 - Come up with an ontology proposal for discovery [on John Arwe - due 2013-03-21].
20:05:28 <cygri> JohnArwe: So we leave the issue open.
20:05:36 <cygri> ACTION-51?
20:05:36 <trackbot> ACTION-51 -- John Arwe to come up with an ontology proposal for discovery -- due 2013-03-21 -- OPEN
20:05:36 <trackbot> http://www.w3.org/2012/ldp/track/actions/51
20:05:39 <nmihindu> JohnArwe, this might be interesting to look for binary resources link header too http://www.w3.org/TR/powder-dr/#httplink
20:05:52 <bblfish> Its late here. I'll join back tomorrow I think.
20:05:59 <Arnaud> "must-haves": 15, 17, 32, 37, 38
20:06:05 <cygri> ISSUE-37?
20:06:05 <trackbot> ISSUE-37 -- What is the LDP data model and the LDP interaction model? -- open
20:06:05 <trackbot> http://www.w3.org/2012/ldp/track/issues/37
20:06:07 <cygri> ISSUE-38?
20:06:08 <trackbot> ISSUE-38 -- filtered representations and inlining -- open
20:06:08 <trackbot> http://www.w3.org/2012/ldp/track/issues/38
20:06:24 <cygri> Arnaud: I don't want to talk about ISSUE-37.
20:06:51 <cygri> topic: ISSUE-38: Filtered representations and inlining
20:07:14 <Zakim> -bblfish
20:07:45 <cygri> Arnaud: The spec provides a mechanism to specify non-member properties on a container.
20:08:05 <cygri> ... From what I remember, Roger felt this is limiting
20:08:22 <cygri> roger: The number of non-member properties could be massive.
20:08:40 <cygri> q+
20:09:01 <Arnaud> ack cygri
20:09:53 <SteveBattle> The corresponding use-case: http://www.w3.org/TR/2013/WD-ldp-ucr-20130131/#use-case-filter-resource-description
20:11:04 <JohnArwe> q+
20:13:20 <SteveS> q+
20:13:51 <cygri> cygri: (1) why do we call out the possibility of including extra triples for LDPC members but not for other resources? (2) would be nice if we could flag that the included extra triples are in fact all the triples the server knows about the member
20:13:59 <Arnaud> ack john
20:14:38 <cygri> JohnArwe: This feature is mentioned for containers because that's where we saw it coming up in our products. No intention to be limiting. The server can always include extra triples.
20:16:07 <cygri> ... Such a flag might not give you complete information anyway; etag headers etc.
20:16:13 <Arnaud> ack steves
20:16:44 <cygri> SteveS: Other resolved issues may already answer some of this.
20:17:17 <cygri> ... For example, next page being rdf:nil could indicate there's no more triples
20:18:19 <cygri> ... We support filtering and inlining in some of our implementations and other specs. We see the need, and it works. But speccing this is difficult.
20:18:44 <cygri> ... Given the timeline, I fear we might not be able to get there in such a short period of time
20:18:52 <cygri> Arnaud: We'd need a proposal.
20:19:18 <cygri> ... On the mailing list it was asked: How powerful do you want this system to be?
20:19:37 <cygri> ... You could go all the way to an all-powerful query system.
20:19:55 <SteveS> For references, here's how I've don't "inline" of resources http://open-services.net/bin/view/Main/OslcCoreSpecification#Selective_Property_Values
20:19:56 <cygri> ... Without a specific use case and proposal, it will be difficult to make progress
20:20:32 <cygri> ... Roger, Richard, do you want to come up with a specific proposal?
20:20:39 <SteveS> Here's the "filter" language (build up query URL) http://open-services.net/bin/view/Main/OslcCoreSpecification#Query_Capabilities
20:21:05 <rgarcia> q+
20:21:11 <cygri> ... Can we agree to postpone the issue?
20:21:17 <Arnaud> ack rgarcia
20:21:56 <cygri> rgarcia: Flag this as something that's useful, out of scope now, but can be done later
20:22:12 <cygri> Arnaud: I'd like to talk about possible future working group
20:22:29 <cygri> ... Good first step for LDP2-WG would be a draft charter with a feature list
20:23:16 <cygri> ... Perhaps we should have a wiki page with 2.0 features
20:23:29 <cygri> davidwood: Mark issues as postponed
20:23:42 <mesteban> +1 to Arnaud
20:24:31 <cygri> [discussion of new WG vs. rechartering]
20:27:32 <Arnaud> Proposed: Close Issue-38, putting this on the wish list (to be created) for LDP++
20:28:07 <cody> +1
20:28:09 <JohnArwe> +1
20:28:10 <TallTed> +1
20:28:11 <krp> +1
20:28:13 <SteveBattle> 0
20:28:15 <davidwood> 0
20:28:16 <rgarcia> +1
20:28:16 <mesteban> +1
20:28:18 <SteveS> +1
20:28:19 <nmihindu> +1
20:28:30 <roger> +1 (I still don't like non-member-properties )
20:28:34 <cygri> +1 but I will raise a new issue for the "are members completely inlined?" flag
20:29:19 <Arnaud> Resolved: Close Issue-38, putting this on the wish list (to be created) for LDP++
20:29:21 <sandro> +1
20:30:36 <Arnaud> action: roger to create a wish list wiki page with issue-38
20:30:36 <trackbot> Created ACTION-52 - Create a wish list wiki page with issue-38 [on Roger Menday - due 2013-03-21].
20:31:37 <cygri> ISSUE-37?
20:31:37 <trackbot> ISSUE-37 -- What is the LDP data model and the LDP interaction model? -- open
20:31:37 <trackbot> http://www.w3.org/2012/ldp/track/issues/37
20:31:52 <cygri> topic: ISSUE-37: What is the LDP data model and the LDP interaction model?
20:31:57 <Arnaud> "must-haves": 15, 17, 32, 37
20:31:59 <cygri> Arnaud: Do we really want to talk about this?
20:32:57 <davidwood> q+ to discuss the spec intro section
20:33:26 <cygri> ... Erik and I felt that nailing down the model would clarify lots of things, expose unspoken assumptions regarding what the spec is about, and so on
20:33:50 <cygri> ... There was lots of effort poured into this, and it didn't seem like we were converging
20:34:27 <cygri> ... So maybe we need to keep working on the details of the specification, create a test suite, and identify holes and misinterpretations that way
20:34:35 <SteveS> q+
20:35:15 <Arnaud> ack david
20:35:15 <Zakim> davidwood, you wanted to discuss the spec intro section
20:35:29 <cygri> davidwood: I have an action to review the UC&R document. I've begun that process.
20:35:45 <cygri> ... The core spec does not have a good introduction.
20:36:29 <cygri> ... The UC&R intro is pretty good language, pretty clear.
20:37:17 <cygri> ... I propose that the UC&R intro should be lifted into the core spec.
20:37:53 <cygri> SteveBattle: My intro was largely taken from the original use case submission.
20:38:24 <roger> roger has joined #ldp
20:38:36 <SteveBattle> q+
20:38:41 <Arnaud> ack steves
20:38:53 <cygri> davidwood: People will start with the REC spec, therefore it should have a good introduction.
20:39:13 <SteveBattle> q-
20:39:21 <cygri> SteveS: I recommend against reading the ISSUE-37 wiki page. It's confusing.
20:40:27 <cygri> ... I'm not sure what the proposal is. What part is intended to be replaced?
20:40:58 <cygri> Arnaud: I think we all agree that a new introduction/motivation for the spc would be good.
20:41:03 <cygri> s/spc/spec/
20:41:38 <cygri> davidwood: Explain the model concisely in the introduction.
20:42:17 <cygri> Ashok: I thought we had pretty good agreement regarding the model.
20:43:05 <cygri> ... You should talk about it to see if we have agreement.
20:43:41 <cygri> SteveS: People are not disagreeing with the model. They are disagreeing with my way of describing the model.
20:43:48 <cygri> Ashok: I'm not sure that it's just editorial.
20:44:24 <roger> i  disagree with some aspects of the model :)
20:45:51 <cygri> [discussion on how to make progress]
20:49:09 <Arnaud> action: steves to draft an introduction describing the LDP model for the WG to review
20:49:09 <trackbot> Created ACTION-53 - Draft an introduction describing the LDP model for the WG to review [on Steve Speicher - due 2013-03-21].
20:49:59 <cygri> roger: I think that core LDP should be doing manipulation of linked data. We can layer the container thing on top of that.
20:50:11 <cygri> ... It's weird that we introduce the notion of containers at the use case level.
20:50:16 <SteveBattle> q+
20:50:36 <cygri> ... It's like we decided the architecture before the use cases.
20:51:05 <cygri> ... I don't think containers really should be core.
20:51:29 <SteveS> q+
20:52:03 <cygri> ... The nested-container use case might be interesting to some here, but LDP has potentially a much bigger audience, around services
20:52:31 <cygri> q+
20:53:08 <cygri> Arnaud: The genesis of this group was to define common usage patterns for linked data.
20:53:22 <cygri> ... So that people don't reinvent these things again and again.
20:53:45 <krp> krp has joined #ldp
20:53:52 <cygri> davidwood: We have a number of different implementations that need a container-like thing.
20:54:32 <cygri> roger: In our work we came up with containers as well. We called them progenitors and progeny.
20:54:58 <cygri> ... Besides this strong ancestry notion, we also want to have links across.
20:55:09 <Arnaud> ack steveb
20:55:17 <cygri> ... In LDP we only handle that via PATCH.
20:55:43 <cygri> SteveBattle: Containers came up in many use cases. It's how people want to use this.
20:55:45 <Arnaud> ack steves
20:55:59 <SteveBattle> s/use cases/user stories/
20:56:08 <cygri> SteveS: Roger, you use the word "service" a lot. Not sure if you mean the "shopping cart" sort of service.
20:56:22 <cygri> ... I see that as a very different architecture from what linked data is
20:56:42 <cygri> ... In linked data you'd have a shopping cart resource that can be manipulated via LDP
20:57:25 <cygri> roger: You can do a brilliant shopping cart with linked data and REST
20:57:43 <Arnaud> ack cygri
20:58:44 <JohnArwe> cygri: would like to see output be what spec promises = how to update linked data
20:59:15 <roger> cygri: wants LDP to add something to the 4 axioms of Linked Data
20:59:36 <JohnArwe> ...container design, nested containers, posting to create new resources is all kind of orthogonal to "how to update linked data"
21:00:19 <roger> cygri: thinks we can tweak the container concept a bit more to more towards this objective
21:00:26 <JohnArwe> ...we've tweaked it to allow more of the cross-resource linking, but I don't like the whole choice of terminology; aggr, composition, etc never existed in LD before, and they don't help me to do updates on LD
21:02:01 <JohnArwe> arnaud plays back cygri's remarks to verify understanding
21:02:37 <cody> q+
21:02:40 <roger> q+
21:03:51 <Arnaud> ack cody
21:04:29 <cygri> cody: Is a container thought of as an LDP-specific object, or can it also be a domain object?
21:05:01 <Zakim> disconnecting the lone participant, WG-meeting, in SW_LDP(F2F)8:30AM
21:05:02 <Zakim> SW_LDP(F2F)8:30AM has ended
21:05:02 <Zakim> Attendees were WG-meeting, bblfish
21:05:13 <Arnaud> ack roger
21:05:16 <cygri> JohnArwe: As long as it has the right interface, it can act as both
21:05:55 <cygri> roger: I appreciate that there's the container pattern.
21:06:31 <cygri> ... But if what we're doing is adding the fifth principle of linked data, then it should work for all properties.
21:06:40 <davidwood> q+
21:06:48 <cygri> ... not just container membmership property
21:07:38 <cygri> Arnaud: There's a tradeoff between something very minimalist and widely applicable, and something more specific
21:07:54 <cygri> ... You could argue that some container stuff should be removed to a separate spec
21:08:07 <cygri> ... You could also argue that the discovery bit should be a separate package
21:08:16 <cygri> ... Specs can define conformance levels
21:08:26 <cygri> ... Just throwing this out as food for thought
21:08:31 <Arnaud> ack david
21:08:52 <cygri> davidwood: To me a container is just some RDF that the server knows how to act upon
21:09:13 <cygri> topic: Planning for tomorrow
21:10:16 <cygri> Arnaud: Next F2F ... More pending issues ... pagination ... patch
21:10:32 <cygri> ... We'll close at 4pm tomorrow
21:10:57 <TallTed> +1 davidwood (which is why I disagree with so much special-case-handling for composition vs aggregation -- this is just how the server acts upon that RDF)
21:10:58 <cygri> ... If you care about specific issues, you have to make proposals.
21:11:22 <cygri> ... There'll be a time when we'll just close issues because we don't have any proposals for them
21:11:29 <cygri> q+
21:12:06 <cody> I'm leaving at about 3:00 tomorrow (flight)
21:12:14 <davidwood> TallTed, right!
21:12:35 <Arnaud> ack cygri
21:12:42 <roger> to me, LDP is just some RDF that a client knows how to act upon
21:13:56 <davidwood> roger, that may be the most succinct description of our disagreements I have yet heard. Maybe we should discuss this in more detail.
21:14:29 <JohnArwe> I'm quite willing to continue this discussion over dinner tonight
21:14:42 <JohnArwe> (yes, I enjoy pain)
21:20:03 <Arnaud> meeting adjourned
22:00:21 <roger> roger has joined #ldp
22:06:33 <SteveBattle> SteveBattle has left #ldp
22:46:13 <cygri> cygri has joined #ldp
23:30:59 <bhyland> bhyland has joined #ldp
23:36:17 <Zakim> Zakim has left #ldp