IRC log of ldp on 2014-04-17

Timestamps are in UTC.

12:56:23 [RRSAgent]
RRSAgent has joined #ldp
12:56:23 [RRSAgent]
logging to http://www.w3.org/2014/04/17-ldp-irc
12:56:25 [trackbot]
RRSAgent, make logs public
12:56:25 [Zakim]
Zakim has joined #ldp
12:56:27 [trackbot]
Zakim, this will be LDP
12:56:27 [Zakim]
ok, trackbot; I see DATA_LDPWG()8:30AM scheduled to start 26 minutes ago
12:56:28 [trackbot]
Meeting: Linked Data Platform (LDP) Working Group Teleconference
12:56:28 [trackbot]
Date: 17 April 2014
13:01:51 [Zakim]
DATA_LDPWG()8:30AM has now started
13:01:58 [Zakim]
+MIT-F2F-group
13:03:18 [nmihindu]
Zakim, what's the code?
13:03:18 [Zakim]
the conference code is 53794 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), nmihindu
13:03:33 [Ashok]
Ashok has joined #ldp
13:03:46 [Zakim]
+[IPcaller]
13:03:54 [codyburleson]
Zakim, IPcaller is me.
13:03:54 [Zakim]
+codyburleson; got it
13:04:15 [codyburleson]
Zakim, who is talking?
13:04:15 [Zakim]
+??P17
13:04:22 [Zakim]
+??P16
13:04:24 [BartvanLeeuwen]
Zakim, ??P17 is me
13:04:24 [Zakim]
+BartvanLeeuwen; got it
13:04:26 [Zakim]
codyburleson, listening for 11 seconds I could not identify any sounds
13:04:34 [nmihindu]
Zakim, ??P16 is me
13:04:34 [Zakim]
+nmihindu; got it
13:04:39 [nmihindu]
Zakim, mute me
13:04:39 [Zakim]
nmihindu should now be muted
13:05:45 [Ashok]
scribenick: Ashok
13:05:48 [JohnArwe]
JohnArwe has joined #ldp
13:06:47 [Ashok]
Topic: Agenda
13:06:55 [Zakim]
-BartvanLeeuwen
13:07:14 [Ashok]
Arnaud: Access control and Patch format are on the agenda with testing in the afternoon.
13:07:18 [Zakim]
+??P17
13:07:20 [BartvanLeeuwen]
Zakim, ??P17 is me
13:07:20 [Zakim]
+BartvanLeeuwen; got it
13:07:46 [Ashok]
... I think we need to talk about the spec again. Esp. about JSON-LD.
13:07:58 [Ashok]
... also talk about paging a bit more.
13:07:59 [codyburleson]
*has also the noise
13:08:29 [Ashok]
Arnaud: We can delay testing
13:09:04 [deiu]
deiu has joined #ldp
13:09:13 [Ashok]
... start with Access Control Note now. Then spec and paging
13:09:23 [Ashok]
... and patch
13:09:24 [deiu]
Zakim, who is on the call?
13:09:24 [Zakim]
On the phone I see MIT-F2F-group, codyburleson, nmihindu (muted), BartvanLeeuwen
13:09:52 [Ashok]
Arnaud: I don't see a quick solution to PATCH.
13:10:01 [Ashok]
Topic: Access Control
13:10:18 [TallTed]
TallTed has joined #ldp
13:10:25 [deiu]
Zakim, MIT-F2F-group has Arnaud, Ashok, betehess, JohnArwe, roger, sandro, SteveS, TallTed, deiu
13:10:25 [Zakim]
+Arnaud, Ashok, betehess, JohnArwe, roger, sandro, SteveS, TallTed, deiu; got it
13:10:30 [Ashok]
Arnaud: This was a compromise we came to when we wrote the charter
13:11:12 [Ashok]
... did not want to put on charter because it's a hard issue. So we decided on a separate note.
13:11:48 [codyburleson]
Annoying noise just stopped
13:11:56 [Ashok]
... on yesterday's wish list discussion Access Control was high priority
13:12:10 [Ashok]
... we need agreement on usescases
13:13:01 [deiu]
Ashok: we started on this and we have 2 requirements
13:13:09 [deiu]
... one: you need some form of authentication
13:13:29 [deiu]
... however, we don't want to specify the authentication protocol
13:13:58 [MiguelAraCo]
MiguelAraCo has joined #ldp
13:14:14 [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
13:15:10 [deiu]
... the question is: where do we specify that? In LDP, in HTTP? How do we specify what the ACL privileges are?
13:15:41 [deiu]
... our wiki page has example we can build on
13:16:01 [deiu]
... we haven't gotten further on this because there wasn't a lot of enthusiasm in the group
13:16:07 [deiu]
Arnaud: I agree with that part
13:16:40 [deiu]
... but we should not get sidetracked into discussing the solutions, but instead try to figure out the questions we need to ask ourselves
13:17:12 [deiu]
Ashok: does fine-grained ACL means access to one attribute?
13:17:15 [deiu]
Arnaud: yes
13:17:31 [deiu]
Ashok: people also want access to a group of resources, and to specify that group is hard
13:17:45 [deiu]
Arnaud: that's not what we're trying to decide now
13:17:50 [deiu]
... now we want to know what the requirements are
13:17:55 [betehess]
betehess has joined #ldp
13:18:09 [deiu]
... let's look at the doc together and decide how we can improve it
13:18:50 [deiu]
... why don't we go through the use-cases first?
13:20:59 [deiu]
Arnaud: do people agree that the use-case involving ACL for group is important?
13:22:02 [roger]
roger has joined #ldp
13:22:25 [TallTed]
Use Case: granting access to a (group of) resources to attendees of a particular session at a conference
13:24:24 [TallTed]
Requirements: group entitites; grant permissions to the group; set permissions on a (group of) resources
13:26:17 [Ashok]
Ted: Granularity of access control is important
13:33:50 [TallTed]
Requirement: Grant permissions for (set restrictions on) individual (enumeration) entity/resource.
13:34:32 [TallTed]
Requirement: Group entities/resources by enumeration (closed ended.)
13:34:32 [TallTed]
Requirement: Group entities/resources by attribute (open ended.)
13:35:59 [Ashok]
Arnaud: Do we need 3.3?
13:36:40 [Ashok]
Ted: Disagrees
13:37:36 [Ashok]
... that is should be removed
13:38:02 [Ashok]
s/is/it/
13:40:31 [TallTed]
s/Use Case: granting/generic requirement: granting/
13:43:26 [Ashok]
Usecase: Ted wants to access/update some resource ... he wants his friends to get acess ... he wants to acess related resources
13:44:08 [Ashok]
Ted: Change title of 3.4
13:46:01 [Ashok]
Andre: Do we need access control in LDP?
13:46:16 [Ashok]
... underlying store will have policies
13:46:29 [Ashok]
... how to expose these policies to client
13:47:49 [Ashok]
Ted: Talks about distinction between usecases and requirements
13:49:14 [Ashok]
Alexandre: Is there anyting special about access control for LDP?
13:49:32 [Ashok]
Ted: Is there a system that satisfies these requirements?
13:49:46 [Ashok]
... there is no W3C spec that tells us
13:49:58 [TallTed]
Question: Granularity. LDPC? LDPR? attribute within LDPR ("triple level")?
13:51:43 [Zakim]
+ericP
13:53:43 [Ashok]
Steve: We have application-specific access control
13:54:12 [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
13:54:59 [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.
13:55:08 [Ashok]
Andre: We use Wen Acess Control to specify policies ... LDP just uses them
13:55:25 [TallTed]
Access Control == Identification (e.g., WebID, Username, OpenID) + Authentication (e.g., WebID+TLS, Password, Password+Token) + Authorization (permissions, policies)
13:57:57 [Ashok]
s/Wen/Web/
13:59:20 [ericP]
q+ to ask whether an LDP Resource can have different triples (or Container have different members) depending on the authentication
13:59:25 [Ashok]
Ashok: The question is -- Is Access Control our problem
13:59:47 [Ashok]
Steve: If we don't do it, who will do it?
14:00:43 [ericP]
if resources can look different, you enable fine-grained access control.
14:01:15 [Ashok]
Ashok: Should we write this as a charter for a WG?
14:01:32 [Ashok]
Andre: There is a lot of work to be done here
14:01:32 [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)
14:04:59 [Ashok]
Ashok: #.5 follows from 3.4 ... part of 3.4 actually
14:06:03 [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".
14:06:11 [Arnaud]
ack ericP
14:06:11 [Zakim]
ericP, you wanted to ask whether an LDP Resource can have different triples (or Container have different members) depending on the authentication
14:07:10 [Ashok]
Eric: Is there something in LDP that depends on auathentication?
14:07:39 [Ashok]
Ted: Nothing says two user have to see the same thing
14:09:22 [Ashok]
Andre: Let's ask folks who have implemented access control to send usecases
14:09:36 [Ashok]
\Sandro: I like very specific usecases
14:10:40 [Ashok]
Sandro: 3 paras that would define scope of work in a charter would be good
14:10:56 [Ashok]
s/\sandro/sandro/
14:11:31 [Ashok]
s/\Sandro/Sandro/
14:12:23 [codyburleson]
+q
14:12:51 [codyburleson]
-q
14:15:39 [Ashok]
Move last usecase to intro section
14:16:02 [Ashok]
Move 4.2 to section 5
14:17:57 [Ashok]
Arnaud: Do we need section 5?
14:20:15 [Ashok]
... move to other document?
14:21:28 [Ashok]
Sandro: Start another wiki page with the 3 paras that could go into a charter
14:21:41 [Ashok]
Ted: make that the conclusion of this document
14:21:47 [Ashok]
Arnaud: Yes
14:23:03 [Ashok]
Nandana, do you have a comment?
14:23:28 [nmihindu]
Ashok, no I've just put my mind completely to the primer :)
14:24:03 [Ashok]
Great!
14:24:54 [BartvanLeeuwen]
break now ?
14:25:05 [TallTed]
break until 10:35 local
14:26:18 [Zakim]
-BartvanLeeuwen
14:35:45 [sandro]
topic; json
14:35:53 [Ashok]
Topic: ISSUE-97 Should we use JSON in addition to Turtle?
14:36:07 [sandro]
issue-97
14:36:07 [sandro]
topic: JSON
14:36:07 [trackbot]
issue-97 -- Json instead of (in addition to?) turtle -- raised
14:36:07 [trackbot]
http://www.w3.org/2012/ldp/track/issues/97
14:36:25 [Ashok]
Arnaud: We could put in Best Practices doc.
14:36:41 [Ashok]
... don't want to go to another Last Call.
14:37:34 [Ashok]
... We could put a SHOULD in the spec. We can do this w/o going to another Last Call
14:37:39 [codyburleson]
+1 "SHOULD" support JSON-LD
14:37:58 [ericP]
imo, that's n'th last call
14:38:13 [betehess]
q+
14:38:16 [Ashok]
PROPOSAL: Add SHOULd support JSON-LD in spec
14:38:39 [bblfish_]
bblfish_ has joined #ldp
14:38:57 [Ashok]
... we can also add "who supports JSON-LD" when we go to CR
14:39:19 [Ashok]
Sandro: Are we saying need to convert formats?
14:39:37 [Arnaud]
ack betehess
14:39:41 [Ashok]
... need translation on output or store both formats
14:41:12 [Ashok]
Steve: Or say you match the format of request
14:41:52 [betehess]
my take: MUST Turtle / SHOULD JSON-LD does not sound like a so great idea. not sure that it solves exactly
14:41:58 [Zakim]
+??P4
14:42:04 [BartvanLeeuwen]
Zakim, ??P4 is me
14:42:04 [Zakim]
+BartvanLeeuwen; got it
14:42:18 [Ashok]
Sandro: We should gather data to go into Director meeting
14:42:59 [betehess]
q+
14:43:05 [Ashok]
Sandro: We will put in spec ... if Director obejcts move to BP
14:43:27 [Ashok]
Eric: Can we put into separate doc that put to REC
14:43:38 [Ashok]
Sandro: One line ... too much hassle
14:45:16 [Ashok]
Eric: There is mapping from JSON-LD to Turtle .... 1 to m mapping ...
14:45:29 [Ashok]
... need context
14:45:32 [Arnaud]
ack betehess
14:45:35 [SteveS]
q+
14:45:51 [Ashok]
Sandro: We only support JSON-LD which has context embedded in ti
14:46:00 [Ashok]
s/ti/it/
14:46:40 [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
14:46:46 [Ashok]
Alexandre: Discussion about where SHOULD goes
14:47:03 [ericP]
(Sandro)
14:47:56 [Arnaud]
ack Steves
14:47:57 [Ashok]
... also SHOULD vs. MUST
14:48:10 [sandro]
ericP, no, the servers and the clients get to figure out the @context to use
14:48:46 [Ashok]
Steve: We may have to go to another call if we get significant comments in CR.
14:49:03 [Ashok]
... so we can put in BP and then add to spec later
14:49:28 [Ashok]
Sandro: Let's ask director. If he says NO we move to BP.
14:49:39 [ericP]
sandro, ahh, so we don't ahve a standard serialization in json
14:49:54 [Ashok]
Arnaud: can we add to AT RISK
14:50:11 [Ashok]
Sandro: Maybe
14:51:18 [betehess]
betehess: if there was no LC issue, I would like to see MUST implement JSON-LD (no Turtle mandatory)
14:51:26 [roger]
+1
14:51:44 [deiu]
+1
14:52:57 [Ashok]
Ashok: You are making a marketing asessment
14:53:33 [Ashok]
Sandro: Clear that JSON has market ... not clear if JSON-LD has market
14:54:45 [Ashok]
Arnaud: We are not forcing servers to convert ... it's a SHOULD
14:55:09 [Zakim]
-nmihindu
14:55:50 [Ashok]
Ted: MUST for both format is best
14:56:51 [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.
14:56:55 [Ashok]
Arnaud: We can put a SHOULD for JSON-LD in spec or put in BP
14:57:03 [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.
14:57:19 [TallTed]
+1
14:57:24 [BartvanLeeuwen]
+1
14:57:33 [codyburleson]
+1
14:57:35 [MiguelAraCo]
+1
14:57:37 [SteveS]
+1
14:57:37 [Ashok]
+1
14:57:42 [roger_]
roger_ has joined #ldp
14:57:44 [sandro]
+1
14:57:44 [deiu]
+1 (just to help with adoption, but I would rather see a MUST instead)
14:57:58 [roger_]
+1
14:58:03 [JohnArwe]
+1
14:58:15 [MiguelAraCo]
(I agree with deiu)
14:58:16 [ericP]
-.1 # i'm uncomfortable engouth with sneaking this in after LC to whine about it, but not uncomfortable do something else
14:58:21 [betehess]
+0
14:58:23 [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.
14:58:28 [Ashok]
Some leaning towards MUST
14:58:49 [Ashok]
Topic: PATCH
14:59:40 [Ashok]
Arnaud: There are different solutions but have no agreement on requirements
14:59:47 [Ashok]
... and usecases
15:00:48 [Ashok]
Sandro: Need to be able to patch from any graph to any graph and you need every patch to be tractable
15:01:06 [sandro]
(those are my constraints, other people have others)
15:01:07 [SteveS]
Some prior discussion: Use Cases http://lists.w3.org/Archives/Public/public-ldp-patch/2013Sep/0000.html
15:01:24 [Arnaud]
https://docs.google.com/presentation/d/1snLP7U97q7wgtsHznnP-RRuAndZNwFytU6q-lrO8U6A/
15:01:37 [SteveS]
Requirements: http://lists.w3.org/Archives/Public/public-ldp-patch/2013Sep/0016.html
15:01:48 [Ashok]
Alexandre presents slides
15:02:09 [sandro]
https://www.w3.org/2012/ldp/wiki/LDP_PATCH_Proposals
15:04:34 [Ashok]
SPARQL patch+skolemization, SPARQL patch w/o skolemization, RDF Patch
15:06:03 [Ashok]
q+
15:09:10 [SteveS]
JSON Merge Patch http://tools.ietf.org/html/draft-ietf-appsawg-json-merge-patch-02
15:09:21 [Ashok]
Ashok: Issue with patching large arrays
15:12:55 [Ashok]
q-
15:13:48 [sandro]
q+
15:15:12 [Ashok]
Web Payments using JSON-LD and JSON patch
15:21:51 [Ashok]
Arnaud: Are you agruing for RDF Patch?
15:21:59 [Ashok]
Alexandre: Yes
15:22:46 [Arnaud]
ack sandro
15:24:15 [Ashok]
Sandro: Easy if you don't have blank nodes. So I said use Skolemization.
15:24:32 [Ashok]
... Eric argues that Skolemization is expensive
15:25:36 [Ashok]
Sandro: You could serialize triples to add and triples to delete in Turtle
15:25:42 [SteveS]
q+ to ask if there really is a single universal solution for patch
15:27:42 [Arnaud]
ack steves
15:27:42 [Zakim]
SteveS, you wanted to ask if there really is a single universal solution for patch
15:27:43 [Ashok]
Discussion about blank nodes can be identified
15:28:52 [Ashok]
Arnaud: Either we agree to something that's not perfect or we have no solution at all.
15:29:00 [Ashok]
q+
15:29:35 [sandro]
Pick your poison: blank-node-identifiers or worst-case-fails
15:30:08 [sandro]
q+
15:30:30 [sandro]
q+ to say where LDP *needs* patch (huge containers)
15:30:33 [Ashok]
Steve: My usecase is more towards a lightweight RDF Patch. Limited requirements.
15:31:00 [Arnaud]
ack ashok
15:32:33 [Ashok]
Ashok: Alexandre, is there a document we can point to?
15:33:06 [Arnaud]
ack sandro
15:33:06 [Zakim]
sandro, you wanted to say where LDP *needs* patch (huge containers)
15:33:50 [Ashok]
Sandro: What do LDP users really need?
15:34:23 [Ashok]
... add/delete triple from huge graph ... no blank nodes
15:34:42 [Ashok]
... cannot use PUT
15:37:29 [betehess]
Arnaud, define "big" :-)
15:39:46 [Ashok]
Discussion about Skolemization and how expensive it is
15:43:39 [sandro]
sandro: One could also do a nice, efficient streaming protocol for maintaining sync
15:43:50 [Ashok]
Arnaud: This seems to be brainstorming. How to we make progress? Can we reach a compromise?
15:45:11 [Ashok]
Sandro: Requirement: There is a big graph in a triple store and you want to change a few triples in it
15:45:52 [Ashok]
... must be able to patch any graph
15:46:19 [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?
15:48:42 [betehess]
question: do we want to be able to patch _any_ graph? or do we think "realistic" (define realistic) graphs are just ok
15:48:50 [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
15:49:18 [betehess]
strong a)
15:49:29 [Ashok]
q+
15:50:35 [Arnaud]
ack ashok
15:50:46 [ericP]
this puts universality and tractibility at odds
15:50:58 [TallTed]
require universality; require tractability; require both; require neither...
15:52:58 [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
15:54:19 [betehess]
sandro, that's not a strawpoll, that's a fact
15:54:30 [sandro]
:-)
15:54:52 [betehess]
my answer: yes :-)
15:55:06 [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;
15:55:38 [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.
15:56:21 [nmihindu]
nmihindu has joined #ldp
15:58:23 [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
15:58:47 [betehess]
strong (a)
15:58:48 [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
15:58:49 [ericP]
a
15:58:55 [sandro]
-1 go to lunch :-)
15:59:17 [SteveS]
a +1, b -0 [we do a) first and can do b) later if needed]
15:59:21 [ericP]
OBJECT
15:59:40 [deiu]
a) +1, b) +0
15:59:43 [sandro]
a -0, b +0
15:59:47 [ericP]
a +1, b -.5
15:59:48 [MiguelAraCo]
a) +1
15:59:49 [betehess]
(a) +1 (b) -.9
16:00:32 [BartvanLeeuwen]
a) +1
16:00:45 [JohnArwe]
a +1, b (if needed as fallback) +0.5 ... I would prefer a better understanding of which graphs are considered pathological
16:01:03 [roger]
(a) +1, (b) -0.5, but, mostly plan on using domain specific ways to do PATCH like things
16:01:37 [Ashok]
a
16:01:41 [TallTed]
general solution for all but pathological case; once that's recognized, fall back to Skolemnize
16:02:07 [codyburleson]
a) +1
16:02:36 [Ashok]
Sandro: Still question on expressiveness
16:03:08 [Ashok]
Alexandre: Do we want to handle blank nodes or not
16:04:26 [Ashok]
Eric: Question is whether you have variables and xxx
16:06:39 [Ashok]
Eric: Not hard to produce a spec on SPARQL patch
16:07:58 [Zakim]
-codyburleson
16:08:03 [Arnaud]
lunch break until 12:45 local
16:08:06 [BartvanLeeuwen]
enjoy lunch
16:08:11 [Zakim]
-BartvanLeeuwen
16:08:12 [Arnaud]
zakim, mute ericp
16:08:13 [Zakim]
ericP should now be muted
16:08:41 [ericP]
i'll see your mutation and raise you a departure
16:08:47 [Zakim]
-ericP
16:09:00 [Ashok]
BREAK UNTIL 1PM EASTERN
16:09:12 [JohnArwe]
i.e. for ~51 mins
16:11:49 [BartvanLeeuwen]
thats gone be a quick dinner for me ;)
16:24:05 [jmvanel]
jmvanel has joined #ldp
16:39:25 [Arnaud]
Arnaud has joined #ldp
16:50:50 [deiu]
scribenick: deiu
16:51:10 [deiu]
Arnaud: resuming meeting
16:51:26 [deiu]
... we can spend 1h on PATCH and maybe another hour on paging
16:52:35 [deiu]
... the poll was a useful exercise, so now we know what are the problems we need to solve
16:52:45 [deiu]
... the question is: is there a solution?
16:53:01 [deiu]
... what can we agree on to make progress?
16:53:23 [deiu]
betehess: we have two solutions: ericP's (with BGP) and Pierre-Antoine's solution
16:53:41 [deiu]
sandro: what about RDF patch?
16:53:47 [deiu]
betehess: it needs skolemization
16:54:05 [Zakim]
+[IPcaller]
16:54:12 [deiu]
sandro: Tim's is not expressed in concrete terms...
16:54:41 [deiu]
betehess: that's basically ericP's solution, with additional constraints
16:54:55 [deiu]
Arnaud: let's have a straw poll on these two options
16:55:15 [deiu]
sandro: the big difference is that one feels like SPARQL and the other one doesn't
16:55:31 [deiu]
... "feeling" like SPARQL is a negative point for LDP adoption
16:56:08 [betehess]
solutions are: ericP's SPARQL Update with constrained BGP vs Pierre-Antoine's RDF Patch + property path
16:56:15 [Arnaud]
STRAWPOLL: pursue a) ericP's (with BGP) or b) Pierre-Antoine's solution
16:56:59 [deiu]
a) 0 b) +1
16:57:02 [roger]
a) -0.5, b) 0.5
16:57:04 [betehess]
a) +0 (not disagreeing with ericP's view) b) +1
16:57:19 [sandro]
a -0.5 b 0.5
16:57:30 [TallTed]
a +0.5 b +0.25
16:58:02 [SteveS]
a) +.1 b) +.9
16:58:10 [Ashok]
0, 1
17:00:03 [MiguelAraCo]
a) +0.5 b) -.5
17:00:56 [Zakim]
+??P1
17:01:05 [nmihindu]
Zakim, ??P1 is me
17:01:05 [Zakim]
+nmihindu; got it
17:01:12 [nmihindu]
Zakim, mute me
17:01:12 [Zakim]
nmihindu should now be muted
17:01:53 [Zakim]
+[IBM]
17:02:20 [betehess]
q+ to comment on syntax
17:02:35 [Arnaud]
ack betehess
17:02:35 [Zakim]
betehess, you wanted to comment on syntax
17:03:07 [Zakim]
-[IBM]
17:03:29 [betehess]
Arnaud: we are not married to this syntax, could be JSON
17:03:58 [deiu]
Arnaud: what do we take from this?
17:04:10 [deiu]
... the majority seems to prefer b)
17:04:49 [deiu]
... what's the status of PA's proposal? is it written somewhere?
17:05:00 [deiu]
betehess: no, it isn't, but I plan to do it
17:05:44 [deiu]
... I can also provide a test suite and implementation
17:06:10 [deiu]
Arnaud: do we agree this is the next step? (start drafting the PATCH spec)
17:06:31 [deiu]
... then we have consensus
17:06:53 [deiu]
sandro: we can make it a REC track
17:07:42 [deiu]
Arnaud: there's a big difference, not just in the outcome but in what we do towards it
17:07:42 [Zakim]
+??P12
17:07:47 [BartvanLeeuwen]
Zakim, ??P12 is me
17:07:47 [Zakim]
+BartvanLeeuwen; got it
17:08:11 [betehess]
LD Patch
17:08:21 [deiu]
Arnaud: how do we name it?
17:09:11 [deiu]
betehess: the full name can be "LD patch format" and the short name can be "LD patch"
17:09:31 [betehess]
LD Patch Format, would live at http://www.w3.org/TR/ld-patch/
17:09:42 [sandro]
Linked Data Patch Format
17:09:45 [betehess]
Linked Data Patch Format, would live at http://www.w3.org/TR/ld-patch/
17:09:48 [sandro]
ldpatch
17:09:59 [sandro]
ld-patch
17:09:59 [deiu]
s/LD Patch Format/Linked Data Patch Format/g
17:11:10 [sandro]
PROPOSED: We encourage Alexandre to draft a Linked Data Patch Format, along the lines of Pierre-Antoine's proposal
17:12:10 [SteveS]
+1 (encourage yes, require/mandate is even better ;)
17:12:42 [deiu]
+1
17:12:43 [nmihindu]
+1
17:12:45 [sandro]
+1
17:12:45 [TallTed]
+1
17:12:46 [betehess]
+1
17:12:54 [Ashok]
+1
17:12:57 [roger]
+1
17:13:15 [codyburleson]
+0
17:13:19 [betehess]
/me feels encouraged
17:13:31 [sandro]
RESOLVED: We encourage Alexandre to draft a Linked Data Patch Format, along the lines of Pierre-Antoine's proposal
17:14:17 [deiu]
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
17:15:11 [Arnaud]
s/We encourage Alexandre/We agree/
17:15:32 [deiu]
Arnaud: now betehess can take an action to do it
17:16:29 [deiu]
... then we're done with PATCH for today!
17:16:33 [betehess]
ACTION: betehess to draft a Linked Data Patch Format, along the lines of Pierre-Antoine's proposal
17:16:33 [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].
17:16:47 [deiu]
... I think everyone's happy with this
17:17:08 [deiu]
Topic: paging
17:17:19 [deiu]
Arnaud: Ashok has a proposal for us
17:17:34 [deiu]
Ashok: it looks we're not agreeing on one solution right now
17:17:49 [deiu]
... most solutions have caveats
17:18:18 [deiu]
... so we could add a warning, saying that if you do paging, the collection may change
17:18:29 [deiu]
Arnaud: I think we have agreed that we can do better
17:18:49 [deiu]
... today we're not providing any mechanisms in that regard
17:19:21 [deiu]
... 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
17:19:43 [deiu]
TallTed: adding this editorially to the existing spec makes it clear what you get
17:19:49 [deiu]
sandro: it's clear in the spec that it is lossy
17:20:08 [deiu]
... the spec has the word "lossy"
17:21:10 [deiu]
Arnaud: so basically sandro wants to veto this
17:22:00 [deiu]
... 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
17:22:07 [deiu]
sandro: ok, I can live with that
17:23:06 [sandro]
WARNING: YOU MIGHT NOT SEE INSERTIONS OR DELETTIONS THAT MIGHT HAPPEN DURING PAGING.
17:23:13 [SteveS]
SteveS has joined #ldp
17:23:14 [sandro]
+1 that's all I've ever asked for.
17:23:58 [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].
17:24:03 [sandro]
(because it implies you WILL see triples that are there the whole time)
17:24:12 [deiu]
Arnaud: triples that were there when you started and are still there when you end, are definitely seen by the client
17:26:47 [deiu]
... this is a clarification of how lossy paging is
17:27:10 [deiu]
sandro: is everyone ok with the wording?
17:27:18 [deiu]
TallTed: I'm not ok with any wording so far
17:27:35 [Arnaud]
Arnaud has joined #ldp
17:27:41 [deiu]
sandro: are you ok with having test cases that cover the lossy behavior?
17:29:20 [SteveS]
Anyone have a reference to a source code copyright/license header for W3C test suites?
17:29:28 [deiu]
TallTed: if I'm on the page with items 11-20, and someone deletes 19, what is the first item on the next page?
17:30:10 [deiu]
sandro: I would like to have a test case for those cases
17:30:59 [deiu]
Ashok: if the server remembers the first and last triples it displays, then if you do a delete, then it's ok
17:31:17 [deiu]
... so the triples won't move around between pages
17:31:35 [deiu]
TallTed: things will appear to shift if you scroll back and forth (or if you reload the same page)
17:32:02 [deiu]
... if you reload the same page you may not see the same data (same for scrolling) -> these are the warnings
17:32:33 [deiu]
Arnaud: people are starting to see the value in sandro's proposal
17:32:43 [deiu]
... we still need to agree on how to word it
17:33:57 [deiu]
Arnaud: I think the lossly aspect is especially important in the case where the client doesn't choose when things get paged
17:35:14 [deiu]
Ashok: when the client starts to page, it caches the collection and then pages over the cache, but it may not have enough space
17:35:26 [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
17:35:26 [TallTed]
such. All pages should be tagged NoCache.
17:37:31 [deiu]
[people don't like the NoCache bit]
17:37:37 [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
17:37:38 [TallTed]
such. Caching flags TBD.
17:38:07 [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.
17:41:01 [SteveS]
+1
17:41:13 [sandro]
+1 as long as we're clear this is really an implementation technique, and the key point is the underlying invariant
17:41:16 [betehess]
+0
17:41:26 [Ashok]
+1
17:41:28 [deiu]
+0.9(9999)
17:41:31 [TallTed]
+1
17:41:43 [roger]
+0.8
17:41:43 [SteveS]
+next
17:41:50 [nmihindu]
+1
17:41:53 [BartvanLeeuwen]
+1
17:42:15 [MiguelAraCo]
+.5
17:42:20 [MiguelAraCo]
+0.5
17:42:28 [sandro]
sandro: for eample, you could have pages that are determined by the content
17:42:33 [deiu]
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?
17:42:37 [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.
17:43:32 [Arnaud]
STRAWPOLL: I prefer paging to be controlled by a) the client b) the server
17:44:13 [sandro]
sandro: If the server wants to implement by doing a snapshot, it's welcome to. That meets the invariant.
17:44:43 [deiu]
sandro: the client sends a "preferred page size header" to initiate paging
17:49:38 [sandro]
sandro: it's not aboiut the client being resource limited, so much as the client wanting to focus on a particular bit.
17:49:55 [Arnaud]
STRAWPOLL: I prefer paging to be initiated by a) the client b) the server
17:50:43 [Ashok]
a)
17:50:56 [TallTed]
c - either
17:51:08 [deiu]
a)
17:52:44 [Arnaud]
q?
17:53:06 [sandro]
a
17:53:09 [betehess]
c - potentially both
17:54:04 [sandro]
How about: Prefer: Page-Size-KB=100
17:54:51 [sandro]
How about: Prefer: Page-Size-KB=unlim
17:56:15 [deiu]
=*
17:57:35 [sandro]
sandro: Is it the case that the client MUST understand paging?
17:58:50 [sandro]
STRAWPOLL: The server MAY do paging even if the client hasn't asked for it
17:59:07 [sandro]
(today in the spec, means the client MUST understand paging.)
17:59:29 [sandro]
(as in the spec today)
17:59:43 [TallTed]
+1
17:59:46 [SteveS]
+1
17:59:46 [Ashok]
+1
17:59:47 [sandro]
+0
17:59:48 [deiu]
-0.9
17:59:53 [MiguelAraCo]
+1
18:00:02 [BartvanLeeuwen]
+1
18:00:12 [betehess]
+1
18:00:28 [codyburleson]
+0
18:01:23 [deiu]
Arnaud: so we have consensus
18:01:37 [sandro]
STRAWPOLL: We'll allow for clients to ask for paging, ask for no paging, and ask for page size
18:01:52 [deiu]
... we can talk about page sizes or no page, or what are the preferences the clients can convey to servers
18:02:53 [TallTed]
+1
18:04:42 [SteveS]
+0 (could defer until a LDP.next)
18:05:00 [deiu]
+0 (same as SteveS)
18:05:28 [betehess]
+0
18:05:44 [nmihindu]
+0.5 (would nice to have if possible)
18:05:53 [Ashok]
+1
18:06:17 [roger]
+0.5
18:08:55 [deiu]
deiu: paging can be replaced by sorting+filtering+limit
18:10:05 [TallTed]
s/+limit/+limit+offset/
18:13:30 [deiu]
Arnaud: filtering is pretty complicated
18:13:40 [deiu]
betehess: what about the scope of bnodes between pages
18:15:03 [deiu]
Arnaud: the client should have a say regarding the paging preference
18:16:25 [TallTed]
HTTP code 413 Payload Too Large -- as a result of the client asking for max-result=10KB + whatever request
18:17:23 [deiu]
roger: you could SPARQL to page over the results
18:19:00 [deiu]
... we can use subsets of SPARQL for paging and/or patch
18:21:00 [deiu]
sandro: if a clients says "I want the top 10 items", it also know more about the shape of the graphs than the server
18:21:12 [deiu]
s/know/knows
18:21:35 [deiu]
... there could be a "group by subject" clause to define the items that will be returned
18:23:33 [deiu]
Arnaud: I still think the best way is to allow the client to say "I want paging" or "I don't want paging"
18:28:32 [deiu]
[sandro propses a way to do paging over periods of time - i.e. sending data over 100 ms ]
18:29:53 [deiu]
SteveS: we couldn't come up with something that made sense in OSLC
18:30:12 [deiu]
... small/medium/large are very relative
18:31:09 [deiu]
sandro: then what about time? (if size in kb is not good)
18:31:49 [deiu]
betehess: if you're the client, then you do paging based on a rough idea of the ration between the triple and the size
18:31:55 [deiu]
... so I guess the triple is fine
18:38:51 [deiu]
Arnaud: people are now saying that maybe we can give a page size in triples
18:41:31 [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
18:42:06 [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.
18:42:23 [deiu]
+1
18:42:35 [TallTed]
+1
18:42:38 [betehess]
+1
18:42:41 [SteveS]
+1
18:42:44 [Ashok]
+1
18:42:47 [BartvanLeeuwen]
+1
18:42:50 [nmihindu]
+1
18:42:51 [sandro]
+0.5 (only because number-of-triples isn't the right metric)
18:43:27 [bblfish]
bblfish has joined #ldp
18:43:28 [Ashok]
Roger: +1
18:43:54 [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.
18:43:56 [roger]
roger has joined #ldp
18:44:05 [sandro]
+1 :-)
18:44:17 [betehess]
-0.1
18:44:20 [deiu]
0
18:44:23 [SteveS]
0
18:44:25 [TallTed]
+1
18:44:27 [Ashok]
-1
18:44:30 [roger]
0
18:44:33 [BartvanLeeuwen]
0
18:44:43 [codyburleson]
0
18:45:12 [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.
18:45:29 [deiu]
Arnaud: we can discuss the details later
18:46:55 [deiu]
... are there more issues re. paging?
18:47:10 [deiu]
... we have tackled the most important ones
18:47:19 [sandro]
how about: Prefer: Page-Size=100
18:47:19 [sandro]
and Prefer: Page-Size=* (for no paging) or Page-Size=No-Paging
18:49:13 [deiu]
Ashok: do you want to add membership triples to the top of the page?
18:49:33 [deiu]
sandro: I think there are one per item (one membership and one containment)
18:49:51 [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.
18:54:21 [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.
18:54:51 [sandro]
arnaud: No one is going to have the triples on the same page.
18:55:09 [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.
18:55:25 [sandro]
arnaud: No one is going to have the membership and containment triples on the same page.
18:56:24 [TallTed]
+1
18:56:39 [deiu]
0
18:56:48 [sandro]
+1
18:56:53 [SteveS]
-0.1 (let impls do what makes sense for triples they have)
18:57:34 [betehess]
+0 (not sure how useful it is)
18:58:16 [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.
18:58:44 [roger]
+0.5
18:58:51 [Ashok]
+1
18:59:14 [deiu]
Arnaud: I think we have achieved a lot!
19:00:03 [deiu]
... people are welcome to stick around for interop testing
19:00:25 [BartvanLeeuwen]
:)
19:00:51 [deiu]
Arnaud: let's adjourn the meeting
19:01:04 [deiu]
... on Monday I will host an informative call
19:01:40 [deiu]
... next formal meeting is on the 28th, when I expect all drafts to be ready
19:01:41 [Zakim]
-BartvanLeeuwen
19:02:12 [Arnaud]
adjourned
19:02:18 [Zakim]
-nmihindu
19:02:18 [sandro]
woo hoo!
19:02:22 [deiu]
+1
19:02:28 [Zakim]
-[IPcaller]
19:02:34 [codyburleson]
codyburleson has left #ldp
19:06:49 [Arnaud]
trackbot, end meeting
19:06:49 [trackbot]
Zakim, list attendees
19:06:49 [Zakim]
As of this point the attendees have been codyburleson, BartvanLeeuwen, nmihindu, Arnaud, Ashok, betehess, JohnArwe, roger, sandro, SteveS, TallTed, deiu, ericP, [IPcaller], [IBM]
19:06:57 [trackbot]
RRSAgent, please draft minutes
19:06:57 [RRSAgent]
I have made the request to generate http://www.w3.org/2014/04/17-ldp-minutes.html trackbot
19:06:58 [trackbot]
RRSAgent, bye
19:06:58 [RRSAgent]
I see 1 open action item saved in http://www.w3.org/2014/04/17-ldp-actions.rdf :
19:06:58 [RRSAgent]
ACTION: betehess to draft a Linked Data Patch Format, along the lines of Pierre-Antoine's proposal [1]
19:06:58 [RRSAgent]
recorded in http://www.w3.org/2014/04/17-ldp-irc#T17-16-33