Linked Data Platform (LDP) Working Group Teleconference -- 02 Nov 2012

<trackbot> Date: 02 November 2012

<oberger> Arnaud: added the primer to the agenda for this afternoon

Arnaud: yesterday first f2f, ramping up, but feedback to try and speed up discussions
... status quo is the spec as is
... burden is on those who have issue with spec to explain what that is
... discussion centred around: 1. what the problems is (ensuring everyone understands it) 2. how to solve it (proposals)
... make sure we are talking about a specific problem and specific problem rather than debating in the round

<oberger> btw, http://bikeshed.org/ for those who don't know

Arnaud: all exercise some self discipline... don't repeat what others have already say... remove yourself from queue if this happens... then we'll straw poll

oberger: we can only discuss issues where the person who raised it is present?

arnaud: if no one present can defend the position we should just skip it. but e.g. yesterday others managed to represent the view

Access control

<oberger> http://www.w3.org/2012/ldp/charter

<sandro> " The Working Group will not produce a Recommendation specifying solutions for access control and authentication for Linked Data. However the Working Group may identify, based on a set of real world use cases, requirements for authentication and authorization technologies for use with Linked Data. " -- the charter

arnaud: when discussing charter two positions: shouldn't do access control as it's a bigger problem; or that how could we not consider the topic
... compromise in the charter: a note. Need to figure out what will be in it, who will be editors
... we need to define what we want to do

bblfish: identify those interested in distributed access control. I wish to implement this... who else?

betehess: first access control, then distributed access control. Need to split the issues. Identity, authorisation. Don't want to do anything on auth?

<sandro> betehess, I think this is 100% about authorization

stevebattle: is there anything in the spec incompatible with ACLs etc.?

<bblfish> here is an interesting thing: http://www.w3.org/wiki/WebAccessControl

<Zakim> sandro, you wanted to talk about W3C member-access as a user story

<bblfish> that is what betehess means by WebACL

betehess: so far nothing in spec. For WebACL just need to provide ontologies.

<bblfish> +1 there is a requirement for a distributed authentication

sandro: W3C member access control... get to say employees of members to access parts of W3C site... this could be use case for LDP, delegating the access to member orgs

<oberger> sandro, would you add it to the UCR ?

<betehess> sandro, that use-case is definitely what people call "decentralized" here

<SteveS> sandro, good use case should it be added to issue tracker or in minutes enough?

ashok: typically access control is based on underlying storage engine. I can help edit.

bblfish: at the RESTful layer need to expose the metadata... the ACLs for a file... the identity needs to be global for an LDP system that is global and interoperable, automatically distributing

<betehess> http://presbrey.mit.edu/

<bblfish> presbrey built http://data.fm/

betehess: let's be concrete (see link)... first implementation of linked data server... let's start by reviewing this

<Zakim> sandro, you wanted to ask about possible requirement -- do resources have different representations for different-access users?

arnaud: to clarify, we're not going to develop a spec that solves this problem. but want to know what people think. create a wiki page for this to develop the ucr for this.

sandro: do you want to get different triples dependent on who you are identified as? Is there consensus to this approach? Can we clarify when this is reasonable to do?

oberger: are people interested in oauth? is there anything to say about it?
... it can delegate tokens to applications to do things on you behalf

<oberger> oberger: interesting use case : delegating "tokens" to apps to act on your behalf, in oauth

cygri: as someone who would like a ready-made solution that I'd like to take of the shelf... most useful in the note for me would be use case and requirements

<oberger> sandro, I think the point you raised is interesting to the group indeed

cygri: vs. we can't recommend particular tech anyway, so a laundry list of different technologies doesn't seem to be what we're chartered to do

<bblfish> Cygri, is right. 0ne does not need to list all the technologies up. There are parts that remain open.

<oberger> sandro, worth an issue ?

<Zakim> betehess, you wanted to comment on other technologies

arnaud: per the charter, it ought to be ucr. however, if there are those in the group who are interested, don't want to stop that... as long as it doesn't get in the way of the ucr

betehess: if you tell people the note will just be about listing stuff it will be a waste of time... so maybe better not to make a note? what happens if someone comes with a specific proposal, do we turn away?

arnaud: not here to revisit charter
... the question is not whether we should do it (the note)

<betehess> does "Deliverables - Not Recommendation Track" even mean that we need to deliver a NOTE? whyh not just a wiki page?

<oberger> betehess, it's too soon to discuss that IMHO

<oberger> let's see UC and needs of the group more explicited

arnaud: but implementers need to know how to solve this... see this as a starting point to define the problem... leading to solutions and maybe, eventually, a later process for a recommendation

<cygri> betehess, oberger, the charter clearly says "Working Group Note on Use Cases and Requirements for access control and authentication mechanisms needed for this work."

<oberger> cygri, ack

<cygri> betehess, oberger, whether that's a good thing or not, i don't know :-)

<oberger> cygri, we'll see while doing

<betehess> cygri, yeah, just saw that (I wasn't the one who added that in the charter :-)

bblfish: in order to test interop we'll need to have something there. but don't need to fully dive into the "identity pit hole of hell" to do this. but we need to have something there to get acceptance from gov etc.

bart: discussing things that potentially could go wrong with spec. why don't we have implementers trying this to find the problems? does this make it easier to spot the issues rather than discussing all possible issues

steves: not sure what we need to standardise to grant access to individuals, we can do that today in several different ways, do we need to standardise?

<cygri> SteveS++

steves: seems like we should get the wiki page up to start getting input

betehess: for many people the success of ldp will be including some standardisation for problems like access control so that it comes with ldp

steves: not saying isn't useful to standardise

arnaud: whole point of note is to gather this information: what to you need from access control?

<Zakim> timbl_, you wanted to suggest that the art of launching th system is about both having a clean consistent vision and also connecting it to th existing things people are now using.

<bblfish> Arnaud: note is a way to gather information together about what people would like to do

timbl: to get system off the ground needs clear consistent system, but also bringing in those who are tied into existing systems so they will accept future solution. in ideal world finding a clear conversion from existing sys to rdf would be nice.

<SteveS> Think access control is important to success of LDP in long term, just not sure a minimal requirement….impls will impose access restrictions regardless of what we say

<cygri> ACTION: Ashok_Malhotra to set up wiki page on Access Control [recorded in http://www.w3.org/2012/11/02-ldp-minutes.html#action01]

<trackbot> Sorry, couldn't find Ashok_Malhotra. You can review and register nicknames at <http://www.w3.org/2012/ldp/track/users>.

arnaud: ashok to create and structure wiki page to gather use cases and requirements

<cygri> ACTION: Ashok to set up wiki page on Access Control [recorded in http://www.w3.org/2012/11/02-ldp-minutes.html#action02]

<trackbot> Created ACTION-21 - Set up wiki page on Access Control [on Ashok Malhotra - due 2012-11-09].

<bblfish> +1

arnaud: everyone add your ucr, please check whether there's already something there... modify/add rather than duplicate

<cygri> +1

<SteveS> +1

<ericP> Ashok_Malhotra, i already started by dropping an example into http://www.w3.org/2012/ldp/wiki/AccessControl

arnaud: a reasonable approach?

<ericP> i can continue with a couple others

arnaud: I think that's all we need to do on this today

<timbl_> http://www.w3.org/wiki/WebAccessControl

ericP: already have a starting page in place http://www.w3.org/wiki/WebAccessControl

<oberger> ericP, could you explicit the syntax of the example ?

ashok: what does this syntax mean?

arnaud: eric, could you give more explanation of this example?
... call for which issues to discuss and defend

Issue 25

<bblfish> Issue-25?

<trackbot> ISSUE-25 -- Weak aggregation and strong composition in containers -- open

<trackbot> http://www.w3.org/2012/ldp/track/issues/25

<cygri> ISSUE-25?

<trackbot> ISSUE-25 -- Weak aggregation and strong composition in containers -- open

<trackbot> http://www.w3.org/2012/ldp/track/issues/25

stevebattle: ldp spec introduces issue of containers. when you think about these you'd normally consider the strength of these. aggregation is weak with a focus on membership, composition is stronger and considers the lifecycle e.g. deleting resource when container is deleted

oberger: addition of something to container would be a good subject to consider this

arnaud: Steve, do you have a proposal as how to modify spec?

stevebattle: proposal is to use hierarchical URIs to represent containment

arnaud: aggregation vs. composition, but the spec isn't clear? do you want it to do one or the other?

stevebattle: to do both but be clear when it is doing which

ashok: when you add a container to a container is it hierarchical?

stevebattle: yes

steves: not sure how the uri structure is related to containment, not sure the spec should specify uri structure.

<cygri> SteveBattle, please phrase a proposal on IRC

<bblfish> but the solution seems simple to me: why not just have a class of containers that seperates the two cases ?

<bblfish> -1 for adding new verbs, only a last resort

oberger: not entirely clear what a container is in terms of semantics. we need to define what actions we can perform on containers, then map to GET/PUT/POST/DELETE

<sandro> so POST might be CREATE + ADD-TO-CONTAINER ?

<SteveBattle> a single container might support both aggregation and composition so I'm not sure we can do it by container type.

<sandro> krp: I'm a little confused about the proposal. You want the client to understand whether it's containment?

<cygri> PROPOSAL: DELETE on a container deletes the container and any resources with URIs below in a path hierarchy, and nothing else.

<sandro> Arnaud: I'm hearing people want to know what the server is going to do when a container is deleted, as far as deleting the contained resources.

<timbl_> Thius syetm must have rigidly defined and simple semantics. Think unix file syetm.

bblfish: proposal to have two type of containers specified

<sandro> bblfish: I propose two rdf:types of containers. One type deletes its contained resources when it's deleted; the other type does not.

<sandro> +1 I rather like that.

<SteveBattle> I like cygri's wording - very concise.

bblfish: so when client does a GET it knows whether it's an aggregation or container and what the behaviour is when DELETE

<cygri> SteveBattle, note, not intended to be spec text, just a design to be turned into spec text by the editor

oberger: do the different types map to the two examples in the spec

<SteveS> Like what cygri, though instead requiring uri hierarchy structure why not say something like "and any resources managed by the same server as the container"

<ericP> rgarcia, i've typed a proposal like that at 9:59:34

<Zakim> ericP, you wanted to resolve issue-25 adding a Container property called "deletesMembers" which applies regardless of the URI structure

<bblfish> agree I don't think that speaking of URL hierachies is useful

if URL hierarchies are useful, it is only for implementation on the server (where to me it doesn't seem useful, but hey)

it is not a sufficient mechanism to inform the client

stevebattle: don't believe the typing proposal works... can't add same resources to multiple containers but can to aggregations

<ericP> what if we just give up on DELETE delting any members? any use cases which motivate this complexity?

timbl: don't agree that we can make it a general case, sets and lists are different. containment seems like a clear implementation to a filesystem structure and how a service is likely to be implemented
... so group should focus on containers. other forms of aggregation are described by a number of different ontologies.

<cygri> PROPOSAL: DELETE on a container deletes the container and any resources with URIs below in a path hierarchy, and nothing else.

<timbl_> Claification: Does the URI path match the containership at all times?

clarification: can there be any members *not* under the path hierarchy?

<SteveBattle> Ah, cygri, your definition says nothing about the URIs created in POST.

<cygri> SteveBattle, do you want to rephrase it?

<Zakim> rgarcia, you wanted to say why don't we define two membership properties, one for weak and another for strong aggregation

rgarcia: define two membership properties

<timbl_> PROPOSAL: The group drop discussion of the aggregation model as that does not require mutual understanding between client and server, only between client and client.

<SteveBattle> "DELETE on a container deletes the container and any resources with URIs below in a path hierarchy, and nothing else. POST on a container creates a new resource URI hierarchically below the container."

<bblfish> we forgot timbls proposal: the container of the spec is/(should be?) the agregation type of container with the propoerty that if you delete it you delete all sub-resources, managed by that server. Weak agregation could be done using other ontologies by just publishing information in an rdf resource

cygri: spec allows domain specific subclassing and this will quickly get complicated with two properties

<antonis> ldp:compositionPredicate rdfs:subClassOf ldp:memberhiPredicate . ldp:aggregationPredicate rdfs:subPropertyOf ldp:memberhiPredicate .

cygri: do need to support both cases (strong and weak aggregation). container as designed seems to be about strong

<antonis> ?

<SteveBattle> Ughh- that's going to get ugly PRETTY quickly (ld composition predicates)

<bblfish> +1 for how to do weak agregation sounds good.

cygri: but we need to be clear how to do weak aggregation

<betehess> can somebody gives a use-case for weak-aggregation?

<ericP> lastlog propos

oberger: we need to decide which way container is, and whether we need the other

<cygri> oberger++

steves: say that instead of a hierarchy of uris say a resource hierarchy managed by that server

<Zakim> timbl_, you wanted to suggest that the group separate out into separate sections of the document the client-server protocol (includes containers, ACL) and the client-client

timbl: separate client-client protocol from client-server. allow clients to build new kinds of structure and the server doesn't need to be away. server needs to be aware of things like managing the stored resources and backing to (file)storage
... go through spec and consider "does the server need to be aware of this"

<Zakim> rgarcia, you wanted to say that if we don't have both membership properties then we are forcing that domain-specific membership properties are always weak aggregation ones

<cygri> PROPOSAL: We need containers for both composition and aggregation. Container-created resources is composition. It's good practice but not required that URI hierarchy match composition.

stevebattle: Tim is correct, the LDP is primarily about containment. but we do need aggregation.

<SteveS> +1 to cygri 10:22 proposal

stevebattle: other precedents for hierarchical URIs

<SteveBattle> I'd still prefer the use of hierarchical URIs.

<SteveS> oberger, could also look at skos:Collection as the type to indicate aggregation

<Zakim> timbl_, you wanted to point out hierarchical URIs connect with WebDav and also give locality of reference with relative URIs.

<sandro> I have a hard time imagining it's okay to delete /foo and still have /foo/bar exist.

<SteveBattle> TOTALLY agree

<ahaller2> sandro++

<Yves> +1 to sandro

<betehess> agree with tim, we're conflating different problems and solutions here

<sandro> +1 timbl: paging large agregates is something you need with any kind of large RDF Graph

cygri: consider a container with a common relationship to lots of resources, which the container has not control over, but facilities such as paging are still useful

<SteveBattle> paging is currently tied to the aggregation - I think that's right.

<Yves> a POST on a container /foo MAY create multiple resources under /foo, DELETE on a container /foo MUST delete all its underlying resources

timbl: that sounds like an RDF graph. can we not have paging on all RDF graphs?

<bblfish> +1 to follow up on looking at separating paging more clearly

<betehess> Yves: that's an analysis or a proposal?

<Zakim> oberger, you wanted to know why rdfs:Container isn't reuse

<cygri> cygri: we call it "container" even though it's really a controller for a subject-predicate pair

<Yves> betehess, an analysis of what people seems to want

oberger: proposed to use rdfs:member, but I also see rdfs: container

<timbl_> PROPOSAL: the paging functionality be applied to any subject for any property, and that be separated in the spec from containment, and it apply to containment as a example with no further design.

<Yves> and it seems logical too ;)

oberger: so maybe we shouldn't call it container?

<SteveBattle> But we can also use skos:Collection - don't overload refs:Container

<cygri> +1 to timbl's proposal

arnaud: good time to have a break?

<betehess> +1 to timbl

<sandro> +1 timbl's

<rgarcia> +1 to timbl's

<ericP> Proposals:

<ericP> .. hierarchical URIs represent containment (and delelete members) (stevebattle)

<ericP> .. class type specifies whether members are contained (bblfish)

<ericP> .. { <SomeContainer> ldp:deletesMembers true } deletes members regardless of URI (ericP)

<ericP> .. the membership property specifies containment (rgarcia)

<ericP> .. all containers delete members (timbl)

<ericP> .. all created (by POST) resources are contained

<timbl_> PROPOSAL: separate client-client protocol from client-server. allow clients to build new kinds of structure and the server doesn't need to be away. server needs to be aware of things like managing the stored resources and backing to (file)storage. the paging functionality be applied to any subject for any property, and that be separated in the spec from containment, and it apply to containment as a example with no further design.

<SteveBattle> Clarification neede: Does this separation imply that we drop ldp:membershipPredicate or not?

<ahaller2> ISSUE-25

<oberger> JohnArwe, we have wandered a bit far from the issue

ISSUE-25

<sandro> "Weak aggregation and strong composition in containers"

<nmihindu> Arnaud: We are talking about many issues within this issues

<cygri> STRAWPOLL: Do we need weak aggregation in the spec?

<sandro> Arnaud: I take for granted that we need Strong Compisition. Any objection? ... none ...

<nmihindu> Arnaud: do we need to have weak aggregation ?

<cygri> +1 Yes we need it

<BartvanLeeuwen> +1

<ahaller2> +1

<antonis> +1

<rgarcia> +1

<oberger> +1

<SteveS> +1

<betehess> +1

<bblfish> +1 but in other terms

<SteveBattle> would like to hear what Tim had to say before I vote

<nmihindu> Arnaud: do we need aggregation ?

<sandro> +0 apps need it, but I don't think *we* necessarily need to spec anything

<bblfish> +0

<timbl_> -1

<nmihindu> Arnaud: aggregation is weak composition

<oberger> I'm not sure I understand what "need" means

<Yves> +0 we might provision for it, but not define it

<nmihindu> Arnaud: do we need to address weak aggregation in this spec ?

<JohnArwe> what is composition as you're using the term, since I need to understand that in order to parse your definition of aggregation as weak comp

<bblfish> I am not sure

<bblfish> I need to implement it

<nmihindu> oberger: do paging is included in this ?

<antonis> strong composition: when a container is deleted, all contained resources are also deleted

<nmihindu> timbl: why does the server have to know those arcs have to do with aggregation ?

<antonis> weak aggregation: when a container is deleted, resources under it are not

<SteveBattle> +1

<betehess> as a developer, I have no need at all for weak aggregation as I have RDF graphs already, but I see value in paging for any kind of resource

Do we need weak aggregation for *anything other than paging*? (if not, we can split out the paging issue)

<sandro> +1 timbl: general aggregation is something clients to can, without knowledge/support from the server. but LDP servers should provide paging of that data, if necessary.

<bblfish> So one should consider other methods one can use to do the same. Eg. Post an rdf:Collection to a ldp:Collection, then one can use some form of SPARQL update on the collection when making changes

<nmihindu> SteveS: aggregation is important for ordering

<sandro> subtopic: What does the server need to implement about aggregation?

<SteveBattle> I agree the spec doesn't NEED weak aggregation - it's a convenience.

<SteveS> wondering if using RDF collections to specify ordering in the model across pages will impose inserting stuff in graph

<nmihindu> bblfish: if we have use cases for this, we can see how they fit

<timbl_> Hmmm …. SPARQL updates for adding things to a list are something we do not have right now, we have to replace the list.

<nmihindu> Arnaud: we are not sure what are the requirements are and what problems we need to solve

<nmihindu> betehess: I need to have composition for resources I created and rest I can do in my application

<timbl_> ?

<nmihindu> Arnaud: we need to see whether we have a UC for weak aggregation

<bblfish> which issue?

<betehess> the issue may not be describing the UC very well

<Zakim> cygri, you wanted to say we need aggregation to associate two existing resources and to say we need something aggregation-like in the client-server protocol to associate two

<ahaller2> example use case: a web form at /foo, data for this form at /foo/bar1 and /foo/bar2, but I want to keep these instances when I delete /foo, because the instances are independent resources of the web form

<nmihindu> Arnaud: we need to decide whether this a requirement we need address

<SteveBattle> weak aggregation was indirectly raised in issue 7

<nmihindu> cygri: rdf triple by default is weak aggregation

<bblfish> Issue-7?

<trackbot> ISSUE-7 -- What operations are permittered on containers and how do they get invoked? -- open

<trackbot> http://www.w3.org/2012/ldp/track/issues/7

<betehess> I'm not sure if people here agree with cygri's definition of weak aggregation

<SteveBattle> I do

<nmihindu> cygri: I need some mechanism for doing paging and may be we can weak aggregation for this

<betehess> SteveBattle, care to put down in words definitions for weak and strong?

<bblfish> so my question is why can the weakly agregated collection not be just a document that contains links to other resources?

<nmihindu> sandro: whether PATCH will solve this problem ?

<bblfish> mhh. I thought we were going to have patch

<nmihindu> cygri: it might

<bblfish> or something like it - ie sending a SPARQL update type of message to a resource

<betehess> I'm hearing timbl_'s proposal I believe

<sandro> I actually think we should offer basic graph operations -- single triple match, and paging -- standard on all resources.

<nmihindu> cygri: there are two main things related to containers 1) management of properties 2) creating new resources

<nmihindu> krp: concrete use case for weak aggregation

<bblfish> timbl makes a strong case for PATCH

<nmihindu> tmbl_: will PATCH this issue can be handled

<betehess> I thought that some kind of PATCH was a given

<nmihindu> tmbl_: did you make decision to make PATCH optional ?

<nmihindu> Arnaud: We can make patch mandatory how if we define how it will work

<Yves> we need a patch format...

<nmihindu> SteveS: we will not reinvent the wheel but point to existing solutions

<SteveBattle> Composition is a 'part-of' relationship; the lifecycle of the subordinate resource is tied to the container. Aggregation is a 'member-of' relation; and the lifecycle of the subordinate object is not linked to the container.

<nmihindu> SteveS: we didn't include the PATCH as we couldn't agree on a PATCH format etc.

For our application we need weak aggregation, but I believe this can be handled in the domain model. If I wanted to manipulate this membership through LDP, rather than manipulating the wider graph, then the membership triples could be an explicit separate resource that can be manipulated (e.g. DELETE). Strong containers are the distinct case where we would want to be explicit that the server attempt to recursively delete members.

<betehess> krp, +1

<nmihindu> Arnaud: We first make spec address strong aggregation and then take a look at weak aggregation issue

<sandro> PROPOSAL: Make the containers in the spec be about Strong Composition, then accept proposals for how to do weak aggregation. And separate proposals for paging, etc.

<SteveBattle> A given resource may both contain and aggregate mandy objects.

<SteveBattle> +1

<rgarcia> +

<cygri> +

<sandro> +1

<antonis> +1

<rgarcia> +1

<cygri> +1

<betehess> +1

<bblfish> +1

<nmihindu> +1

<timbl_> +1

<Arnaud> +1

<svillata> +1

<Yves> +!

<ahaller2> +1

<Yves> +1

<SteveS> +1

<BartvanLeeuwen> +1

<ericP> +1

<oberger> +1

<sandro> RESOLVED: Make the containers in the spec be about Strong Composition, then accept proposals for how to do weak aggregation. And separate proposals for paging, etc.

<nmihindu> SteveBattle: Do you mean the spec as it is or with changes ?

<nmihindu> SteveBattle: I am against using rdfs:member for composition

<JohnArwe> I thought the resolution was, if you will, at the conceptual level. Agreeing on that concept might imply that spec changes are a consequence.

<bblfish> I understand the issue with rdfs:member being perhaps not precise enough.

<bblfish> ldp:member

<Zakim> cygri, you wanted to say that's a client-client issue

<JohnArwe> ...i.e., if we agree the spec *should* be describing strong composition and we find cases where it is not, well that's what comments are for.

<SteveBattle> I still think that overloads rdfs:member

Though while I think weak composition can/should be done in the domain model, I think this approach will need explanation through example (e.g. in a primer)

<oberger> http://www.w3.org/TR/rdf-schema/#ch_member 5.1.6 rdfs:member

<oberger> rdfs:member is an instance of rdf:Property that is a super-property of all the container membership properties i.e. each container membership property has an rdfs:subPropertyOf relationship to the property rdfs:member.

<nmihindu> cygri: we are not using rdfs:member for composition but the ldp container class

<betehess> please no sub-properties

<oberger> are we done with issue 25 ?

<nmihindu> timbl_: SPARQL update is the clear choice for PATCH

<SteveBattle> I proposed changesets as a PATCH format :(

<nmihindu> Arnaud: I don't think we can close the ISSUE 25

<bblfish> so we need to open a new issue on patch

<bblfish> +1

<cygri> ISSUE-7?

<trackbot> ISSUE-7 -- What operations are permittered on containers and how do they get invoked? -- open

<trackbot> http://www.w3.org/2012/ldp/track/issues/7

<nmihindu> cygri: we need to answer the four points of the ISSUE 25, if PATCH is there is solves the issue. If it is not there we need to address those.

<cygri> ISSUE-17?

<trackbot> ISSUE-17 -- changesets as a recommended PATCH format -- open

<trackbot> http://www.w3.org/2012/ldp/track/issues/17

<nmihindu> sandro: Issue 17 is related to PATCH, may be we should rename it to handle PATCH

<timbl_> Arnaud's division above separates the paging and patch be defined independently of containers is wise, and does require new issues about defining PATCH and generalizing paging.

<sandro> Arnaud: Close issue-25 but make sure we have open ones on Patch and General-Paging

<nmihindu> Arnaud: We need an issue about aggregation, and issue 17 will handle PATCH

<BartvanLeeuwen> Issue-7?

<trackbot> ISSUE-7 -- What operations are permittered on containers and how do they get invoked? -- open

<trackbot> http://www.w3.org/2012/ldp/track/issues/7

<AndyS> FWIW - Changesets can be translated directly to a SPARQL Update (a DELETE DATA and a INSERT DATA) mechanically.

<sandro> cygri: If we define a required patch format, then that solves issue-25, yes.

<nmihindu> Arnaud: we should have an issue on paging

<oberger> issue-17?

<trackbot> ISSUE-17 -- changesets as a recommended PATCH format -- open

<trackbot> http://www.w3.org/2012/ldp/track/issues/17

<cygri> ISSUE-18?

<trackbot> ISSUE-18 -- container membership and robust pagination -- open

<trackbot> http://www.w3.org/2012/ldp/track/issues/18

<nmihindu> oberger: do we need more used cases for aggregation ?

<nmihindu> cygri: we already have one

<SteveS> http://lists.w3.org/Archives/Public/public-ldp-wg/2012Sep/0089.html

<SteveBattle> I believe that all any's scenarios are covered in UC&R

<cygri> ACTION: cygri to open an issue on paging [recorded in http://www.w3.org/2012/11/02-ldp-minutes.html#action03]

<trackbot> Created ACTION-22 - Open an issue on paging [on Richard Cyganiak - due 2012-11-09].

<nmihindu> Arnaud: we need to close some issue and open more granular ones that addresses the raised points

<bblfish> AndyS: hi

<SteveBattle> Are you there Andy?

<AndyS> Hello

+1 to clearly scoped narrower issues

<AndyS> On IRC

<AndyS> (can phone in but need time to move room and dial-in).

<BartvanLeeuwen> AndyS, just read along

<cygri> AndyS, I'm going to create a new issue on managing weak aggregation, to subsume ISSUE-7

<sandro> AndyS, it's not clear what we're about to talk about next.

<AndyS> I am :-) Fascinating.

<cygri> ACTION: cygri to create a new issue on managing weak aggregation, to subsume ISSUE-7; PATCH might be one way to do it [recorded in http://www.w3.org/2012/11/02-ldp-minutes.html#action04]

<trackbot> Created ACTION-23 - Create a new issue on managing weak aggregation, to subsume ISSUE-7; PATCH might be one way to do it [on Richard Cyganiak - due 2012-11-09].

<SteveBattle> Resources under the same authority can be distributed across many servers.

<timbl_> ISSUE: Should the PATCH method be used, as oppose t POST with a given mime type? What systems can support PATCH easily? (tabulator uses POST but could change of course)

<trackbot> Created ISSUE-27 - Should the PATCH method be used, as oppose t POST with a given mime type? What systems can support PATCH easily? (tabulator uses POST but could change of course) ; please complete additional details at http://www.w3.org/2012/ldp/track/issues/27/edit .

<rgarcia> oberger, that is one problem of having strong aggregation using an URI schema. I we don't do it there should not be

<betehess> PROPOSAL: close #25

<nmihindu> Arnaud: can we close ISSUE 25 now ?

<nmihindu> cygri: with the two actions created I think we can close the issue

<bblfish> +1

<betehess> +1

<rgarcia> +1

<SteveS> +1

<svillata> +1

<nmihindu> +1

<oberger> +1

<cygri> +1

<Arnaud> +1

<BartvanLeeuwen> +1

<SteveBattle> +1

<sandro> +1

<antonis> +1

<betehess> APPROVED: close #25

<betehess> RESOLVED: close #25

<betehess> RESOLVED: close ISSUE-25

<betehess> s/APPROVED: close #25//

<betehess> s/RESOLVED: close #25//

<timbl_> Ooops I didn't mean to create an issue in the system. it let me create an issue but not edit it.

<Zakim> oberger, you wanted to know if we need to create an issue on examples only using resources on same server ans subpaths for (strong) composition

<SteveBattle> Isn't this kind of federation an implementation issue?

<nmihindu> oberger: we should make explicit or provide examples that resources can be all over the world even with composition

<bblfish> +1 for cygri: strong composition means you have to go through the container to create the resource.

<nmihindu> cygri: strong composition usually implies it is created by the container on the same server

<nmihindu> oberger: disagree, it could be possible to have something similar to factories in OOP

<webr3> how do you make an LDPC?

<sandro> sandro: When you POST to create a resource in a container, it might be given a URL on a different host, yes. eg posting to api.example.com might make resources show up on {username}.example.com based on who did the post.

<nmihindu> Arnaud: oberger does not want the strong composition to imply the resources are on the same server

<JohnArwe> I think all olivier is asking for it to make at least one EXAMPLE show a container whose "output" member URI has no visible relationship to the container URI

<nmihindu> oberger: The spec does not say that but people might have a misunderstanding without an explicit example

<SteveBattle> A container SHOULD NOT manage resources under a different authority.

<rgarcia> +1 to having an example

<cygri> PROPOSAL: State in the spec that composition doesn't mean that the resources must reside in the same hierarchy or even on the same server

<sandro> +1

<Arnaud> +1

<nmihindu> +1

<rgarcia> +1

<oberger> +1

<svillata> +1

<SteveS> +1

<BartvanLeeuwen> +1

<SteveBattle> -0

<ericP> +1

<cygri> +0.2 sure why not

<JohnArwe> +1

<webr3> +1

<betehess> +1

<nmihindu> SteveBattle: with my early proposal, they should be strictly in the same hierarchy

<sandro> SteveBattle: I like having the contained-item URLs be in the hierarchy under the container URLs

<nmihindu> timbl: at some point we need to have the concept of ownership

<SteveBattle> Yes - I admit it - I do look at URL's - I don't always wear the opaque glasses.

<bblfish> so the point is one of domain name ownership.

<SteveBattle> I also like slugs.

<rgarcia> +q to say that the directory structure can mislead clients when differentiating between paths and resources

<bblfish> PROPOSAL: perhaps the example in the spec should be something close to the livesjournal example

<Zakim> rgarcia, you wanted to say that the directory structure can mislead clients when differentiating between paths and resources

<cygri> sandro++

<nmihindu> rgarcia: in the url, can we assume every part of it is a resource ?

<nmihindu> cygri: no

<cygri> webr3, all containers are resources too. if there are conflicts, it's a bug.

<SteveBattle> Nothing to stop you using a PUT to create a container, or a POST if you have another container.

<nmihindu> Arnaud: where do you stand in this proposal ?

with strong containers when the container is deleted the members should be deleted, but this isn't always possible (not on server, access control). This could be clarified by returning to the client the resources that have actually successfully been deleted (which may not be all members after all)

<Ashok_Malhotra> Tim is asking for transactions!

<webr3> +20 to transactions!

<JohnArwe> ...distributed trxns no less

<sandro> tim: I'm okay with this proposal as long as it's clear the client can't just add something across the web to the "strong Container" and expect it too be deleted when the container is deleted!

<rgarcia> cygri, yes, my only comment was that it can be misleading for clients

<nmihindu> tmbl: I prefer the make sure the delete happens or say it is forbidden to delete

<Zakim> JohnArwe, you wanted to say coming from highly robust implementation background, making the members owned by the container's implementation does *improve your odds* but it is NOT

<melvster> hi all ... just following remotely :) melvster == Melvin Carvalho

<sandro> issue-28?

<trackbot> ISSUE-28 -- transaction/rollback when deleting resources from a LDPC -- raised

<trackbot> http://www.w3.org/2012/ldp/track/issues/28

<Zakim> timbl_, you wanted to say that from client app point ov view, it is important to keep local data in sync with data in the LDP server, so please restrict results to "Your delete of

for the server to guarantee it can fully delete the container and all members, it must restrict the members it accepts to those it would be able to delete?

<Zakim> oberger, you wanted to ask if there's something wrong with 5.6.1

<timbl_> kip, the server never :"accep[ts" members -- it creates them

<timbl_> so it can control them

<nmihindu> oberger: Is there an issue with 5.6.1 ?

<timbl_> s/kip/krp/

<sandro> earlier mostly-resolved: <cygri> PROPOSAL: State in the spec that composition doesn't mean that the resources must reside in the same hierarchy or even on the same server

<timbl_> but point out that the resources will all be under the direct control of the same system.

<nmihindu> Arnaud: should we amend the proposal ?

<timbl_> PROPOSAL: State in the spec that composition doesn't mean that the resources must reside in the same hierarchy or even on the same server but point out that the resources will all be under the direct control of the same system.

<nmihindu> bblfish: we can add an example to the spec with a concrete case

<sandro> PROPOSAL: State in the spec that composition doesn't mean that the resources must reside in the same hierarchy or even have the same "host" part of the URL. Try to have example that motivates it, such as livejournal cross-origin issue

<betehess> can we just decouple creation from deletion for now?

<SteveBattle> My concern is that I'm a fan of human readable URIs - which kind of implies hierarchy <vhttp://www.jenitennison.com/blog/node/114>

<nmihindu> krp: direct control potion of timl is important

<sandro> SteveBattle, I think that's a Best Practice, not something we should mandate.

<SteveBattle> Yeah - I'm happy with that 'MUST' in the proposal.

<sandro> +1 cygri since the server had the power to CREATE the resource, presumably it has the power to DELETE it.

<nmihindu> cygri: if the container has the power to create a resource probably it has the power to delete it

<cygri> How about this: Composition means that resources are created only through the container; however it doesn't mean that the resources must reside in the same hierarchy or even on the same server

<sandro> +1

<BartvanLeeuwen> +1

<rgarcia> +1

<SteveBattle> +1

<JohnArwe> hold on, the server creates it under the access controls of the authenticated user. ditto delete. those are different requests, potentially coming from different principals, and there may be method-level permissions involved.

<ericP> +1

<svillata> +1

<SteveS> +1

the "direct control" part is more important for deletion. I think Tim's point was that we make deleting a (strong) container clear by putting the requirement on the server to control those resources - and it controls that from creation

<nmihindu> Ashok: do you need to follow up it with the information about delete ?

<SteveBattle> Just checking - does that mean 'subordinate resources'. We can still create stand-alone resources some other way - yes?

<timbl_> The server takes on responsibility for being able to efficiently delete the new resource when the container is deleted.

<nmihindu> cygri: The follow up with create a long discussion it is better to stick with this

<cygri> JohnArwe, absolutely anything can fail due to access control

<cygri> PROPOSAL: Composition means that resources are created only through the container; however it doesn't mean that the resources must reside in the same hierarchy or even on the same server

<cygri> +1

<sandro> +1

<rgarcia> +1

<ericP> +1

<svillata> +1

<nmihindu> +1

<Arnaud> +1

<SteveS> +1

<betehess> +1

<BartvanLeeuwen> +1

<bblfish> +1

<oberger> +1

<ahaller2> +1

<SteveBattle> ???

<JohnArwe> +1

<antonis> +1

<timbl_> +1

<Yves> =0

<SteveBattle> +1

<nmihindu> SteveBattle: is this just taking about the resources created by a container ?

<nmihindu> cygri: yes

<SteveBattle> "resources are created ONLY through the container" - what's the scope of that?

<JohnArwe> I do seem to remember existing text saying that containers were allowed to add members through other means outside the spec, so "created only through the container" MIGHT conflict with that.

<nmihindu> RESOLVED: Composition means that resources are created only through the container; however it doesn't mean that the resources must reside in the same hierarchy or even on the same server

<nmihindu> Arnaud: Do we need to change the text in 5.6.1 in the spec ?

<SteveBattle> Can we have minuted clarification of that last point?

<nmihindu> SteveS: yes, it is an editorial change.

<sandro> looks like 5.6.1 turns int o a MUST. Deleting a container means MUST delete containted resources.

<rgarcia> +q to remark JohnArwe 's comment

<bblfish> MUST does not mean it cannot fail

+q to say some of these are errors

<nmihindu> cygri: MUST not be possible for various reasons, we can change it to SHOULD or say the server must notify if something bad happens

<betehess> but these things are already defined in HTTP!

<rgarcia> +1 to indicate that the server must notify the client when something wrong happens

<nmihindu> Arnaud: it is common case for many issues, though it is a MUST, errors can happen

- DRAFT -

Linked Data Platform (LDP) Working Group Teleconference

02 Nov 2012

Attendees

Contents

Access control

Issue 25

ISSUE-25

Summary of Action Items

Scribe.perl diagnostic output