W3C

- DRAFT -

Linked Data Platform (LDP) Working Group Teleconference

17 Apr 2014

See also: IRC log

Attendees

Present
codyburleson, BartvanLeeuwen, nmihindu, Arnaud, Ashok, betehess, JohnArwe, roger, sandro, SteveS, TallTed, deiu, ericP, [IPcaller], [IBM]
Regrets
Chair
SV_MEETING_CHAIR
Scribe
Ashok, deiu

Contents


<trackbot> Date: 17 April 2014

<Ashok> scribenick: Ashok

Agenda

Arnaud: Access control and Patch format are on the agenda with testing in the afternoon.
... I think we need to talk about the spec again. Esp. about JSON-LD.
... also talk about paging a bit more.

<codyburleson> *has also the noise

Arnaud: We can delay testing
... start with Access Control Note now. Then spec and paging
... and patch
... I don't see a quick solution to PATCH.

Access Control

Arnaud: This was a compromise we came to when we wrote the charter
... did not want to put on charter because it's a hard issue. So we decided on a separate note.

<codyburleson> Annoying noise just stopped

Arnaud: on yesterday's wish list discussion Access Control was high priority
... we need agreement on usescases

<deiu> Ashok: we started on this and we have 2 requirements

<deiu> ... one: you need some form of authentication

<deiu> ... however, we don't want to specify the authentication protocol

<deiu> ... second: once you are authenticated (and say you get a token), then you can access various things, update them, etc., so there must be some way to specify what you can do

<deiu> ... the question is: where do we specify that? In LDP, in HTTP? How do we specify what the ACL privileges are?

<deiu> ... our wiki page has example we can build on

<deiu> ... we haven't gotten further on this because there wasn't a lot of enthusiasm in the group

<deiu> Arnaud: I agree with that part

<deiu> ... but we should not get sidetracked into discussing the solutions, but instead try to figure out the questions we need to ask ourselves

<deiu> Ashok: does fine-grained ACL means access to one attribute?

<deiu> Arnaud: yes

<deiu> Ashok: people also want access to a group of resources, and to specify that group is hard

<deiu> Arnaud: that's not what we're trying to decide now

<deiu> ... now we want to know what the requirements are

<deiu> ... let's look at the doc together and decide how we can improve it

<deiu> ... why don't we go through the use-cases first?

<deiu> Arnaud: do people agree that the use-case involving ACL for group is important?

<TallTed> generic requirement: granting access to a (group of) resources to attendees of a particular session at a conference

<TallTed> Requirements: group entitites; grant permissions to the group; set permissions on a (group of) resources

Ted: Granularity of access control is important

<TallTed> Requirement: Grant permissions for (set restrictions on) individual (enumeration) entity/resource.

<TallTed> Requirement: Group entities/resources by enumeration (closed ended.)

<TallTed> Requirement: Group entities/resources by attribute (open ended.)

Arnaud: Do we need 3.3?

Ted: Disagrees
... that it should be removed

Usecase: Ted wants to access/update some resource ... he wants his friends to get acess ... he wants to acess related resources

Ted: Change title of 3.4

Andre: Do we need access control in LDP?
... underlying store will have policies
... how to expose these policies to client

Ted: Talks about distinction between usecases and requirements

Alexandre: Is there anyting special about access control for LDP?

Ted: Is there a system that satisfies these requirements?
... there is no W3C spec that tells us

<TallTed> Question: Granularity. LDPC? LDPR? attribute within LDPR ("triple level")?

Steve: We have application-specific access control

<nmihindu> people who are doing similar things today with Linked Data without LDP (Victor from UPM, Serena from Inria) do it as dataset, graph, triple levels as far as I know

<codyburleson> We should escape Identification and Authentication. We need only a URI to represent ANY Principal. Once we have that, we can focuse specifically on Authorization and make no claim about how the Principal URI is derived.

Andre: We use Web Acess Control to specify policies ... LDP just uses them

<TallTed> Access Control == Identification (e.g., WebID, Username, OpenID) + Authentication (e.g., WebID+TLS, Password, Password+Token) + Authorization (permissions, policies)

Ashok: The question is -- Is Access Control our problem

Steve: If we don't do it, who will do it?

<ericP> if resources can look different, you enable fine-grained access control.

Ashok: Should we write this as a charter for a WG?

Andre: There is a lot of work to be done here

<ericP> (i don't think there's anything that says that can't be different, though HTTP purists may argue that two representations with different triples can't represent the same resource at the same time)

Ashok: #.5 follows from 3.4 ... part of 3.4 actually

<codyburleson> Problem Statement: Any platform for developing web applications would be incomplete without a mechanism for Authentication and Authorization. Without this functionality, the platform could serve only light, utilitarian purposes at best. Without security, it would not even be proper to call the system a "platform".

<Zakim> ericP, you wanted to ask whether an LDP Resource can have different triples (or Container have different members) depending on the authentication

Eric: Is there something in LDP that depends on auathentication?

Ted: Nothing says two user have to see the same thing

Andre: Let's ask folks who have implemented access control to send usecases

Sandro: I like very specific usecases
... 3 paras that would define scope of work in a charter would be good

s/\sandro/sandro/

<codyburleson> +q

<codyburleson> -q

Move last usecase to intro section

Move 4.2 to section 5

Arnaud: Do we need section 5?
... move to other document?

Sandro: Start another wiki page with the 3 paras that could go into a charter

Ted: make that the conclusion of this document

Arnaud: Yes

Nandana, do you have a comment?

<nmihindu> Ashok, no I've just put my mind completely to the primer :)

Great!

<BartvanLeeuwen> break now ?

<TallTed> break until 10:35 local

<sandro> topic; json

ISSUE-97 Should we use JSON in addition to Turtle?

<sandro> issue-97

JSON

<trackbot> issue-97 -- Json instead of (in addition to?) turtle -- raised

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

Arnaud: We could put in Best Practices doc.
... don't want to go to another Last Call.
... We could put a SHOULD in the spec. We can do this w/o going to another Last Call

<codyburleson> +1 "SHOULD" support JSON-LD

<ericP> imo, that's n'th last call

PROPOSAL: Add SHOULd support JSON-LD in spec
... we can also add "who supports JSON-LD" when we go to CR

Sandro: Are we saying need to convert formats?
... need translation on output or store both formats

Steve: Or say you match the format of request

<betehess> my take: MUST Turtle / SHOULD JSON-LD does not sound like a so great idea. not sure that it solves exactly

Sandro: We should gather data to go into Director meeting
... We will put in spec ... if Director obejcts move to BP

Eric: Can we put into separate doc that put to REC

Sandro: One line ... too much hassle

Eric: There is mapping from JSON-LD to Turtle .... 1 to m mapping ...
... need context

Sandro: We only support JSON-LD which has context embedded in it

<ericP> right, but that's a mapping from json to one namespace unless you want to use the very ugly json-ld with no short names

Alexandre: Discussion about where SHOULD goes

<ericP> (Sandro)

Alexandre: also SHOULD vs. MUST

<sandro> ericP, no, the servers and the clients get to figure out the @context to use

Steve: We may have to go to another call if we get significant comments in CR.
... so we can put in BP and then add to spec later

Sandro: Let's ask director. If he says NO we move to BP.

<ericP> sandro, ahh, so we don't ahve a standard serialization in json

Arnaud: can we add to AT RISK

Sandro: Maybe

<betehess> betehess: if there was no LC issue, I would like to see MUST implement JSON-LD (no Turtle mandatory)

<roger> +1

<deiu> +1

Ashok: You are making a marketing asessment

Sandro: Clear that JSON has market ... not clear if JSON-LD has market

Arnaud: We are not forcing servers to convert ... it's a SHOULD

Ted: MUST for both format is best

<sandro> PROPOSED: Close issue-97 with adding JSON-LD as a SHOULD in the spec, if we can in W3C process without another Last Call; if it'll require another LC, then we advocate for it in BP.

Arnaud: We can put a SHOULD for JSON-LD in spec or put in BP

<codyburleson> There is a marketing factor at play here that shouldn't be discounted. Turtle is meaningless to the "average" web developer. JSON-LD provides an option that is meaningful for them. If we want to successful, we need to appeal to the broader audience. So, I agree that is SHOULD be in the spec; not BPs.

<TallTed> +1

<BartvanLeeuwen> +1

<codyburleson> +1

<MiguelAraCo> +1

<SteveS> +1

+1

<sandro> +1

<deiu> +1 (just to help with adoption, but I would rather see a MUST instead)

<roger_> +1

<JohnArwe> +1

<MiguelAraCo> (I agree with deiu)

<ericP> -.1 # i'm uncomfortable engouth with sneaking this in after LC to whine about it, but not uncomfortable do something else

<betehess> +0

<sandro> RESOLVED: Close issue-97 with adding JSON-LD as a SHOULD in the spec, if we can in W3C process without another Last Call; if it'll require another LC, then we advocate for it in BP.

Some leaning towards MUST

PATCH

Arnaud: There are different solutions but have no agreement on requirements
... and usecases

Sandro: Need to be able to patch from any graph to any graph and you need every patch to be tractable

<sandro> (those are my constraints, other people have others)

<SteveS> Some prior discussion: Use Cases http://lists.w3.org/Archives/Public/public-ldp-patch/2013Sep/0000.html

<Arnaud> https://docs.google.com/presentation/d/1snLP7U97q7wgtsHznnP-RRuAndZNwFytU6q-lrO8U6A/

<SteveS> Requirements: http://lists.w3.org/Archives/Public/public-ldp-patch/2013Sep/0016.html

Alexandre presents slides

<sandro> https://www.w3.org/2012/ldp/wiki/LDP_PATCH_Proposals

SPARQL patch+skolemization, SPARQL patch w/o skolemization, RDF Patch

<SteveS> JSON Merge Patch http://tools.ietf.org/html/draft-ietf-appsawg-json-merge-patch-02

Ashok: Issue with patching large arrays

Web Payments using JSON-LD and JSON patch

Arnaud: Are you agruing for RDF Patch?

Alexandre: Yes

Sandro: Easy if you don't have blank nodes. So I said use Skolemization.
... Eric argues that Skolemization is expensive
... You could serialize triples to add and triples to delete in Turtle

<Zakim> SteveS, you wanted to ask if there really is a single universal solution for patch

Discussion about blank nodes can be identified

Arnaud: Either we agree to something that's not perfect or we have no solution at all.

<sandro> Pick your poison: blank-node-identifiers or worst-case-fails

Steve: My usecase is more towards a lightweight RDF Patch. Limited requirements.

Ashok: Alexandre, is there a document we can point to?

<Zakim> sandro, you wanted to say where LDP *needs* patch (huge containers)

Sandro: What do LDP users really need?
... add/delete triple from huge graph ... no blank nodes
... cannot use PUT

<betehess> Arnaud, define "big" :-)

Discussion about Skolemization and how expensive it is

<sandro> sandro: One could also do a nice, efficient streaming protocol for maintaining sync

Arnaud: This seems to be brainstorming. How to we make progress? Can we reach a compromise?

Sandro: Requirement: There is a big graph in a triple store and you want to change a few triples in it
... must be able to patch any graph

<betehess> also, remember that there will be a time to see what is supported in implementations... who is planning to implement one of the solutions?

<betehess> question: do we want to be able to patch _any_ graph? or do we think "realistic" (define realistic) graphs are just ok

<Arnaud> STRAWPOLL: a) I'd rather keep it simple and accept a limited solution, b) I want a general solution and am willing to accept the additional cost

<betehess> strong a)

<ericP> this puts universality and tractibility at odds

<TallTed> require universality; require tractability; require both; require neither...

<sandro> STRAWPOLL: If we suggest one PATCH format, we make it (a) fail on certain pathological graphs, or (b) require the server to maintain Skolemization maps

<betehess> sandro, that's not a strawpoll, that's a fact

<sandro> :-)

<betehess> my answer: yes :-)

<sandro> STRAWPOLL: If we suggest one PATCH format, we make it (a) fail on certain pathological graphs, or (b) require the server to maintain Skolemization maps. Vote for which branch you'd rather live with;

<sandro> STRAWPOLL: (Assuming we suggest one PATCH format) should it (a) fail on certain pathological graphs, or (b) require the server to maintain Skolemization maps.

<Arnaud> STRAWPOLL: I'd rather have a solution that (a) doesn't address certain pathological graphs, or (b) requires the server to maintain Skolemization maps

<betehess> strong (a)

<deiu> a) I don't want to pay a high price every time, regardless of case (while also maintaining skolemized versions), AND because I also want to do the PATCH operation in one request

<ericP> a

<sandro> -1 go to lunch :-)

<SteveS> a +1, b -0 [we do a) first and can do b) later if needed]

<ericP> OBJECT

<deiu> a) +1, b) +0

<sandro> a -0, b +0

<ericP> a +1, b -.5

<MiguelAraCo> a) +1

<betehess> (a) +1 (b) -.9

<BartvanLeeuwen> a) +1

<JohnArwe> a +1, b (if needed as fallback) +0.5 ... I would prefer a better understanding of which graphs are considered pathological

<roger> (a) +1, (b) -0.5, but, mostly plan on using domain specific ways to do PATCH like things

a

<TallTed> general solution for all but pathological case; once that's recognized, fall back to Skolemnize

<codyburleson> a) +1

Sandro: Still question on expressiveness

Alexandre: Do we want to handle blank nodes or not

Eric: Question is whether you have variables and xxx
... Not hard to produce a spec on SPARQL patch

<Arnaud> lunch break until 12:45 local

<BartvanLeeuwen> enjoy lunch

<ericP> i'll see your mutation and raise you a departure

BREAK UNTIL 1PM EASTERN

<JohnArwe> i.e. for ~51 mins

<BartvanLeeuwen> thats gone be a quick dinner for me ;)

<deiu> scribenick: deiu

Arnaud: resuming meeting
... we can spend 1h on PATCH and maybe another hour on paging
... the poll was a useful exercise, so now we know what are the problems we need to solve
... the question is: is there a solution?
... what can we agree on to make progress?

betehess: we have two solutions: ericP's (with BGP) and Pierre-Antoine's solution

sandro: what about RDF patch?

betehess: it needs skolemization

sandro: Tim's is not expressed in concrete terms...

betehess: that's basically ericP's solution, with additional constraints

Arnaud: let's have a straw poll on these two options

sandro: the big difference is that one feels like SPARQL and the other one doesn't
... "feeling" like SPARQL is a negative point for LDP adoption

<betehess> solutions are: ericP's SPARQL Update with constrained BGP vs Pierre-Antoine's RDF Patch + property path

<Arnaud> STRAWPOLL: pursue a) ericP's (with BGP) or b) Pierre-Antoine's solution

a) 0 b) +1

<roger> a) -0.5, b) 0.5

<betehess> a) +0 (not disagreeing with ericP's view) b) +1

<sandro> a -0.5 b 0.5

<TallTed> a +0.5 b +0.25

<SteveS> a) +.1 b) +.9

<Ashok> 0, 1

<MiguelAraCo> a) +0.5 b) -.5

<Zakim> betehess, you wanted to comment on syntax

<betehess> Arnaud: we are not married to this syntax, could be JSON

Arnaud: what do we take from this?
... the majority seems to prefer b)
... what's the status of PA's proposal? is it written somewhere?

betehess: no, it isn't, but I plan to do it
... I can also provide a test suite and implementation

Arnaud: do we agree this is the next step? (start drafting the PATCH spec)
... then we have consensus

sandro: we can make it a REC track

Arnaud: there's a big difference, not just in the outcome but in what we do towards it

<betehess> LD Patch

Arnaud: how do we name it?

betehess: the full name can be "LD patch format" and the short name can be "LD patch"

<betehess> Linked Data Patch Format, would live at http://www.w3.org/TR/ld-patch/

<sandro> Linked Data Patch Format

<betehess> Linked Data Patch Format, would live at http://www.w3.org/TR/ld-patch/

<sandro> ldpatch

<sandro> ld-patch

<sandro> PROPOSED: We encourage Alexandre to draft a Linked Data Patch Format, along the lines of Pierre-Antoine's proposal

<SteveS> +1 (encourage yes, require/mandate is even better ;)

+1

<nmihindu> +1

<sandro> +1

<TallTed> +1

<betehess> +1

<Ashok> +1

<roger> +1

<codyburleson> +0

<betehess> /me feels encouraged

<sandro> RESOLVED: We agree to draft a Linked Data Patch Format, along the lines of Pierre-Antoine's proposal

Arnaud: the resolution is that as a group we will start working on PA's proposal, while betehess will write it down in the document
... now betehess can take an action to do it
... then we're done with PATCH for today!

<betehess> ACTION: betehess to draft a Linked Data Patch Format, along the lines of Pierre-Antoine's proposal [recorded in http://www.w3.org/2014/04/17-ldp-minutes.html#action01]

<trackbot> Created ACTION-139 - Draft a linked data patch format, along the lines of pierre-antoine's proposal [on Alexandre Bertails - due 2014-04-24].

Arnaud: I think everyone's happy with this

paging

Arnaud: Ashok has a proposal for us

Ashok: it looks we're not agreeing on one solution right now
... most solutions have caveats
... so we could add a warning, saying that if you do paging, the collection may change

Arnaud: I think we have agreed that we can do better
... today we're not providing any mechanisms in that regard
... yesterday we were left with 2 options: what we have in the spec + notification (which doesn't stop the client from continuing); the second option was to pursue sandro's proposal

TallTed: adding this editorially to the existing spec makes it clear what you get

sandro: it's clear in the spec that it is lossy
... the spec has the word "lossy"

Arnaud: so basically sandro wants to veto this
... we've agreed that we will do the notification (which is supposed to be mandatory) so the clients know if there was a change during paging

sandro: ok, I can live with that

<sandro> WARNING: YOU MIGHT NOT SEE INSERTIONS OR DELETTIONS THAT MIGHT HAPPEN DURING PAGING.

<sandro> +1 that's all I've ever asked for.

<TallTed> we do also have -- 7.1.1 A LDP client SHOULD NOT present paged resources as coherent or complete, or make assumptions to that effect. [RFC5005].

<sandro> (because it implies you WILL see triples that are there the whole time)

Arnaud: triples that were there when you started and are still there when you end, are definitely seen by the client
... this is a clarification of how lossy paging is

sandro: is everyone ok with the wording?

TallTed: I'm not ok with any wording so far

sandro: are you ok with having test cases that cover the lossy behavior?

<SteveS> Anyone have a reference to a source code copyright/license header for W3C test suites?

TallTed: if I'm on the page with items 11-20, and someone deletes 19, what is the first item on the next page?

sandro: I would like to have a test case for those cases

Ashok: if the server remembers the first and last triples it displays, then if you do a delete, then it's ok
... so the triples won't move around between pages

TallTed: things will appear to shift if you scroll back and forth (or if you reload the same page)
... if you reload the same page you may not see the same data (same for scrolling) -> these are the warnings

Arnaud: people are starting to see the value in sandro's proposal
... we still need to agree on how to word it
... I think the lossly aspect is especially important in the case where the client doesn't choose when things get paged

Ashok: when the client starts to page, it caches the collection and then pages over the cache, but it may not have enough space

<TallTed> PROPOSAL: Spec Sandro's paging proposal (link next based on last record shown on current page; link prev based on first record shown on current page); include warnings that reloading any "page" may not deliver same data as previous load of that "page". Full one-way traversal will show every record that is there at commencement and remains throughout; records added or deleted (even if re-added) during traversal may not be shown as

<TallTed> such. All pages should be tagged NoCache.

[people don't like the NoCache bit]

<TallTed> PROPOSAL: Spec Sandro's paging proposal (link next based on last record shown on current page; link prev based on first record shown on current page); include warnings that reloading any "page" may not deliver same data as previous load of that "page". Full one-way traversal will show every record that is there at commencement and remains throughout; records added or deleted (even if re-added) during traversal may not be shown as

<TallTed> such. Caching flags TBD.

<TallTed> PROPOSAL: Spec Sandro's paging proposal (link next based on last record shown on current page; link prev based on first record shown on current page); include warnings that reloading any "page" may not deliver same data as previous load of that "page". Full one-way traversal will show every record that is there at commencement and remains throughout; records added or deleted (even if re-added) during traversal may not be shown.

<SteveS> +1

<sandro> +1 as long as we're clear this is really an implementation technique, and the key point is the underlying invariant

<betehess> +0

<Ashok> +1

+0.9(9999)

<TallTed> +1

<roger> +0.8

<SteveS> +next

<nmihindu> +1

<BartvanLeeuwen> +1

<MiguelAraCo> +.5

<MiguelAraCo> +0.5

<sandro> sandro: for eample, you could have pages that are determined by the content

Ashok: suppose I don't care about updates and I just want to page, and if the contents change then I'm ok with it, then am I allowed to do that?

<Arnaud> RESOLVED: Spec Sandro's paging proposal (link next based on last record shown on current page; link prev based on first record shown on current page); include warnings that reloading any "page" may not deliver same data as previous load of that "page". Full one-way traversal will show every record that is there at commencement and remains throughout; records added or deleted (even if re-added) during traversal may not be shown.

<Arnaud> STRAWPOLL: I prefer paging to be controlled by a) the client b) the server

<sandro> sandro: If the server wants to implement by doing a snapshot, it's welcome to. That meets the invariant.

sandro: the client sends a "preferred page size header" to initiate paging

<sandro> sandro: it's not aboiut the client being resource limited, so much as the client wanting to focus on a particular bit.

<Arnaud> STRAWPOLL: I prefer paging to be initiated by a) the client b) the server

<Ashok> a)

<TallTed> c - either

a)

<sandro> a

<betehess> c - potentially both

<sandro> How about: Prefer: Page-Size-KB=100

<sandro> How about: Prefer: Page-Size-KB=unlim

=*

<sandro> sandro: Is it the case that the client MUST understand paging?

<sandro> STRAWPOLL: The server MAY do paging even if the client hasn't asked for it

<sandro> (today in the spec, means the client MUST understand paging.)

<sandro> (as in the spec today)

<TallTed> +1

<SteveS> +1

<Ashok> +1

<sandro> +0

-0.9

<MiguelAraCo> +1

<BartvanLeeuwen> +1

<betehess> +1

<codyburleson> +0

Arnaud: so we have consensus

<sandro> STRAWPOLL: We'll allow for clients to ask for paging, ask for no paging, and ask for page size

Arnaud: we can talk about page sizes or no page, or what are the preferences the clients can convey to servers

<TallTed> +1

<SteveS> +0 (could defer until a LDP.next)

+0 (same as SteveS)

<betehess> +0

<nmihindu> +0.5 (would nice to have if possible)

<Ashok> +1

<roger> +0.5

deiu: paging can be replaced by sorting+filtering+limit+offset

Arnaud: filtering is pretty complicated

betehess: what about the scope of bnodes between pages

Arnaud: the client should have a say regarding the paging preference

<TallTed> HTTP code 413 Payload Too Large -- as a result of the client asking for max-result=10KB + whatever request

roger: you could SPARQL to page over the results
... we can use subsets of SPARQL for paging and/or patch

sandro: if a clients says "I want the top 10 items", it also knows more about the shape of the graphs than the server
... there could be a "group by subject" clause to define the items that will be returned

Arnaud: I still think the best way is to allow the client to say "I want paging" or "I don't want paging"

[sandro propses a way to do paging over periods of time - i.e. sending data over 100 ms ]

SteveS: we couldn't come up with something that made sense in OSLC
... small/medium/large are very relative

sandro: then what about time? (if size in kb is not good)

betehess: if you're the client, then you do paging based on a rough idea of the ration between the triple and the size
... so I guess the triple is fine

Arnaud: people are now saying that maybe we can give a page size in triples

<sandro> PROPOSED: We'll provide a way for the client to express a desired page size hint to the server, including whether or not to do paging at all

<sandro> PROPOSED: We'll provide a way for the client to express a desired page size hint to the server, including whether or not to do paging at all. Size in number of triples, but we know the server might be doing associated-chunks of triples, like around a blank node, or the same container item.

+1

<TallTed> +1

<betehess> +1

<SteveS> +1

<Ashok> +1

<BartvanLeeuwen> +1

<nmihindu> +1

<sandro> +0.5 (only because number-of-triples isn't the right metric)

<Ashok> Roger: +1

<sandro> PROPOSED: We'll provide a way for the client to express a desired page size hint to the server, including whether or not to do paging at all. Size in number of KILOBYTES, but we know the server might be doing associated-chunks of triples, like around a blank node, or the same container item.

<sandro> +1 :-)

<betehess> -0.1

0

<SteveS> 0

<TallTed> +1

<Ashok> -1

<roger> 0

<BartvanLeeuwen> 0

<codyburleson> 0

<Arnaud> RESOLVED: We'll provide a way for the client to express a desired page size hint to the server, including whether or not to do paging at all. Size in number of triples, but we know the server might be doing associated-chunks of triples, like around a blank node, or the same container item.

Arnaud: we can discuss the details later
... are there more issues re. paging?
... we have tackled the most important ones

<sandro> how about: Prefer: Page-Size=100

<sandro> and Prefer: Page-Size=* (for no paging) or Page-Size=No-Paging

Ashok: do you want to add membership triples to the top of the page?

sandro: I think there are one per item (one membership and one containment)

<sandro> PROPOSED: If a Container has membership triples and containment triples included, the membership triples and containment triples MUST be on the same page as each other.

<sandro> PROPOSED: If a Container has membership triples and containment triples included, the membership triples and containment triples for a given resource MUST be on the same page as each other.

<sandro> arnaud: No one is going to have the triples on the same page.

<sandro> PROPOSED: If a Container has membership triples and containment triples included, the membership triples and containment triples for a given (contained/member) resource MUST be on the same page as each other.

<sandro> arnaud: No one is going to have the membership and containment triples on the same page.

<TallTed> +1

0

<sandro> +1

<SteveS> -0.1 (let impls do what makes sense for triples they have)

<betehess> +0 (not sure how useful it is)

<sandro> RESOLVED: If a Container has membership triples and containment triples included, the membership triple and containment triple for a given (contained/member) resource MUST be on the same page as each other.

<roger> +0.5

<Ashok> +1

Arnaud: I think we have achieved a lot!
... people are welcome to stick around for interop testing

<BartvanLeeuwen> :)

Arnaud: let's adjourn the meeting
... on Monday I will host an informative call
... next formal meeting is on the 28th, when I expect all drafts to be ready

<Arnaud> adjourned

<sandro> woo hoo!

+1

<Arnaud> trackbot, end meeting

Summary of Action Items

[NEW] ACTION: betehess to draft a Linked Data Patch Format, along the lines of Pierre-Antoine's proposal [recorded in http://www.w3.org/2014/04/17-ldp-minutes.html#action01]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.138 (CVS log)
$Date: 2014/04/17 19:07:02 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
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/is/it/
Succeeded: s/Use Case: granting/generic requirement: granting/
Succeeded: s/Wen/Web/
FAILED: s/\sandro/sandro/
Succeeded: s/\Sandro/Sandro/
Succeeded: s/ti/it/
Succeeded: s/LD Patch Format/Linked Data Patch Format/g
Succeeded: s/We encourage Alexandre/We agree/
Succeeded: s/+limit/+limit+offset/
Succeeded: s/know/knows/
Found ScribeNick: Ashok
Found ScribeNick: deiu
Inferring Scribes: Ashok, deiu
Scribes: Ashok, deiu
ScribeNicks: Ashok, deiu
Default Present: codyburleson, BartvanLeeuwen, nmihindu, Arnaud, Ashok, betehess, JohnArwe, roger, sandro, SteveS, TallTed, deiu, ericP, [IPcaller], [IBM]
Present: codyburleson BartvanLeeuwen nmihindu Arnaud Ashok betehess JohnArwe roger sandro SteveS TallTed deiu ericP [IPcaller] [IBM]

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Found Date: 17 Apr 2014
Guessing minutes URL: http://www.w3.org/2014/04/17-ldp-minutes.html
People with action items: betehess

[End of scribe.perl diagnostic output]