IRC log of ldp on 2013-06-18

Timestamps are in UTC.

07:44:11 [RRSAgent]
RRSAgent has joined #ldp
07:44:11 [RRSAgent]
logging to
07:44:13 [trackbot]
RRSAgent, make logs public
07:44:13 [Zakim]
Zakim has joined #ldp
07:44:15 [trackbot]
Zakim, this will be LDP
07:44:15 [Zakim]
ok, trackbot; I see SW_LDP(F2F)2:30AM scheduled to start 74 minutes ago
07:44:16 [trackbot]
Meeting: Linked Data Platform (LDP) Working Group Teleconference
07:44:16 [trackbot]
Date: 18 June 2013
07:44:25 [JohnArwe]
zakim, who's on the phone?
07:44:25 [Zakim]
SW_LDP(F2F)2:30AM has not yet started, JohnArwe
07:44:27 [Zakim]
On IRC I see RRSAgent, JohnArwe, SteveS, rgarcia, Arnaud, mielvds, Ashok, nmihindu, betehess, jmvanel, gavinc, Yves, sandro, trackbot, ericP, thschee
07:44:27 [nmihindu]
zakim, who is on the phone?
07:44:27 [Zakim]
SW_LDP(F2F)2:30AM has not yet started, nmihindu
07:44:29 [Zakim]
On IRC I see RRSAgent, JohnArwe, SteveS, rgarcia, Arnaud, mielvds, Ashok, nmihindu, betehess, jmvanel, gavinc, Yves, sandro, trackbot, ericP, thschee
07:45:28 [mesteban]
mesteban has joined #ldp
07:46:03 [Ashok]
07:51:25 [mielvds1]
mielvds1 has joined #ldp
07:51:59 [roger]
roger has joined #ldp
07:52:02 [BartvanLeeuwen]
BartvanLeeuwen has joined #ldp
07:53:17 [Ashok]
Ashok has joined #ldp
07:53:34 [Zakim]
SW_LDP(F2F)2:30AM has now started
07:53:40 [Zakim]
07:54:05 [BartvanLeeuwen]
Zakim, ??p0 is me
07:54:05 [Zakim]
+BartvanLeeuwen; got it
07:54:11 [Arnaud]
hi Bart
07:54:14 [Arnaud]
we're dialing in
07:54:44 [Zakim]
+ +34.91.336.aaaa
07:54:57 [BartvanLeeuwen]
okay, gives me time for coffee
07:59:23 [Ashok]
Topic: UCR
07:59:56 [Ashok]
Arnaud: There have been comments on UCR
08:00:34 [Ashok]
... we don't have Steve Battle here
08:00:59 [Ashok]
... Great review by Miguel
08:01:39 [roger]
roger has joined #ldp
08:01:58 [Ashok]
... sometimes UCR and spec are not in sync
08:03:36 [Ashok]
Miguel: We should annotate UCR document saying what we cover and what we delay to next version
08:03:51 [nmihindu]
BartvanLeeuwen, we have rgarcia, mesteban, Arnaud, mielvds, Ashok, nmihindu, JohnArwe, SteveS, gavinc, roger, kevin
08:04:15 [Ashok]
... for the use cases we cover we should have pointers in the spec
08:05:00 [Ashok]
08:05:42 [Ashok]
Arnuad: You sent mail on UCR but you did not get a response
08:06:22 [Ashok]
ACTION-42 on MIguel to review UCR can be closed
08:09:19 [Ashok]
Arnaud: Miguel, would you like to be editor for the UCR
08:09:38 [Ashok]
08:11:25 [Ashok]
Discussion about which direction the pointers should go
08:12:01 [Ashok]
08:12:11 [Ashok]
or spec -> UCR
08:13:02 [SteveS]
SteveS has joined #ldp
08:14:07 [AndyS]
AndyS has joined #ldp
08:14:32 [krp]
krp has joined #ldp
08:15:16 [JohnArwe]
zakim, aaaa is the F2F meeting (can't hurt to try)
08:15:16 [Zakim]
I don't understand you, JohnArwe
08:15:21 [JohnArwe]
zakim, aaaa is m
08:15:21 [Zakim]
+m; got it
08:17:29 [Arnaud]
Arnaud has joined #ldp
08:19:35 [Ashok]
Arnaud: Please all look at Miguel's comments
08:20:14 [Ashok]
... Miguel, could you follow up with Steve Battle
08:21:03 [Ashok]
Topic: LDP spec
08:21:56 [Ashok]
Arnaud: We should review the issues and see which ones we need to close
08:23:52 [Ashok]
... we have 2 main isues ... container and membership predicate and there is the one about affordances
08:26:02 [Ashok]
Arnaud bring up list of issues to discuss which ones we address
08:27:12 [mielvds]
mielvds has joined #ldp
08:27:33 [Ashok]
Arnaud: ISSUE-16 has no proposal. Mark as "at risk"?
08:29:03 [Ashok]
John: There is nothing to be done ... spec does not need to change
08:29:50 [Ashok]
Arnaud: ISSUE-32 needs to be addressed
08:30:31 [Ashok]
Arnaud: ISSUE-37 ... Steve was going to add an itroduction to spec
08:30:41 [Ashok]
John: Non-normative text
08:30:56 [Ashok]
Arnaud: ISSUE-50
08:31:46 [Ashok]
Steve: I think we address this .... needs sign-off from Henry
08:32:12 [Ashok]
Arnaud: Duplicate of 54?
08:34:08 [Ashok]
Arnaud: ISSUE-51
08:34:34 [Ashok]
Discussion as to whether this is inverse of the membership predicate
08:35:34 [Ashok]
Roger: We can close issue in order to make progress
08:36:26 [Ashok]
Arnaud: Let's leave open for now ... let's see how discussion on membership predicate work
08:38:12 [Ashok]
Arnaud: ISSUE-56 let's leave open ... related to ISSUE-16?
08:39:50 [Ashok]
Arnaud: ISSUE-57 ... related to ISSUE-32
08:41:54 [Ashok]
Arnaud: ISSUE-58 ... let's look at latest proposal
08:42:13 [Ashok]
John: I suggest leave as "at risk"
08:43:07 [Ashok]
Arnaud: ISSUE-62 ... we need proposal for this
08:43:25 [Ashok]
Roger: There is an issue here. I will create a proposal
08:43:58 [Ashok]
... related to membershipXXX
08:45:11 [Ashok]
Arnaud: ISSUE-66 Robust pagination
08:45:18 [Ashok]
... suggest we close
08:48:47 [Ashok]
Discussion on what the issue creator really wants. If all he wants to find if the pagination has changed we could do it with e-tags/if-match
08:51:18 [Ashok]
Arnaud: ISSUE-68 ... do not have a proposal ... can be closed
08:51:45 [Ashok]
Arnaud: ISSUE-71 needs discussion
08:52:50 [Ashok]
Arnaud: ISSUE-72 needs discussion
08:53:21 [Ashok]
Arnaud: ISSUE-73 needs discussion
08:53:38 [Ashok]
Arnaud: ISSUE-75 needs discussion
08:53:55 [Ashok]
Arnaud: ISSUE-77 needs discussion
08:54:15 [Ashok]
Arnaud: ISSUE-78 may be editorial
08:55:28 [Ashok]
Arnaud: ISSUE-79 needs discussion
08:55:46 [Ashok]
Arnaud: ISSUE-80 needs discussion
08:56:34 [Ashok]
Arnaud: There are 6 issues marked as Pending Review
08:57:26 [Ashok]
Cody: How do you create the first container
08:57:49 [Zakim]
08:58:00 [ericP]
Zakim, [GVoice] is me
08:58:00 [Zakim]
+ericP; got it
09:02:34 [Zakim]
09:08:06 [Zakim]
09:15:13 [sandro]
anyone willing to try a google+ hangout, so remote folks can see you?
09:17:10 [ericP]
if so, i'm
09:18:17 [sandro]
09:19:06 [rgarcia]
rgarcia has joined #ldp
09:20:29 [JohnArwe]
JohnArwe going to scribe temporarily while Ashok makes his points on issue-66 robust pagination
09:21:24 [Arnaud]
topic: ISSUE-66
09:21:34 [nmihindu]
09:21:34 [trackbot]
ISSUE-66 -- Robust pagination -- open
09:21:34 [trackbot]
09:22:06 [ericP]
i think that SQL cursors are good for a single session, and essentially amount to the server copying the entire result set for a query
09:22:13 [JohnArwe]
Ashok: SQL has something called "cursor stability" equivalent
09:22:29 [JohnArwe] robust pagination
09:22:41 [JohnArwe]
Henry arrives in F2F room
09:22:53 [ericP]
the analogy in LDP would have the server holding state for a client which have registered a cursor and promises to release it
09:23:40 [sandro]
basically "nextPageSameState" as a link would do that. or maybe "nextPage" could optionally have those semantics.
09:23:50 [JohnArwe]
... we've said we're not going to do "all this database stuff" like transactions, robust paging, etc. If we're going to do a r/w web we have to do these kinds of things.
09:24:48 [JohnArwe]
@sandro, question would be "same state as what?" the page URL could be from a query made a year ago.
09:25:16 [JohnArwe]
ashok: should at least give client a way to know that page content has changed.
09:25:35 [Ashok]
Topic: ISSUE-65
09:25:45 [Ashok]
The spec does not address this
09:25:46 [ericP]
how i had imagined robust pagination:
09:25:46 [ericP]
<page3> { <C> rdfs:member <R6>, <R7> . <page3> :nextPage <page4> }
09:25:46 [ericP]
after DELETEs of <R6> and <R7>:
09:25:46 [ericP]
<page3> { <page3> :nextPage <page4> } # page<3> is preserved though empty
09:25:52 [sandro]
JohnArwe, same state as the resource was when this content was serialized.
09:26:00 [Ashok]
09:26:48 [Ashok]
Yes, Eric that's one way .... but it will have pages with holes in them
09:26:55 [sandro]
09:26:59 [ericP]
09:27:35 [sandro]
09:27:47 [ericP]
i'm perfectly happy to punt on it
09:27:49 [krp]
09:27:50 [Arnaud]
ack sandro
09:27:50 [JohnArwe]
@sandro, fine if you then add (in the general case) ... for this user. With your version Sandro, does "when it was serialized" have a well-known definition? vs being "since (the last time)..."
09:28:20 [Ashok]
Arnaud: Should we investigate how we could provide robust pagination?
09:28:32 [ericP]
+1 to understanding how an extension could do it making it safe to punt
09:29:30 [Ashok]
Sandro described a design for robust pagination
09:29:32 [ericP]
i suspect that ldp:nextPatch and ldp:longPollPatch are in that category
09:29:46 [Arnaud]
ack krp
09:30:12 [Ashok]
Kevin: Argues we need robust pagination
09:30:36 [ericP]
krp: if you care about consistency in a page, is it specifically NOT a container at that point?
09:30:43 [sandro]
09:30:48 [Arnaud]
ack sandro
09:30:56 [JohnArwe]
the trivial way to support it via an extension is to have the server add information (header or predicate) saying the equivalent of "all paging is stable" i.e. the server always implements stable paging
09:31:09 [SteveS]
SteveS has joined #ldp
09:31:22 [SteveS]
09:31:32 [Ashok]
Sandro, any server can provide robust pagination using version number in the URL
09:32:06 [Ashok]
... you coukd provide two versioin stable and not stable
09:32:36 [JohnArwe]
09:32:41 [Arnaud]
ack steves
09:32:43 [JohnArwe]
09:32:52 [Ashok]
.... discusses StableNextPage predicate
09:32:55 [sandro]
sandro: so have a stableNextPage predicate, defined by us or somebody else
09:34:33 [ericP]
Yves? can weakt ETag validation be applied here?
09:35:10 [Ashok]
Ashok: Without robust pagination you get into trouble when the resource you are working on gets deleted
09:35:35 [Ashok]
Henry: Discusses a timestamp version of the universe
09:36:39 [Ashok]
Arnaud: There should be a mechanism to tell the client that a page has changed
09:37:09 [sandro]
maybe ldp:resourceState ?
09:37:43 [sandro]
http stuff doesn't help, since it's about the page, not about the thing behind all the pages.
09:37:53 [ericP]
q+ to propose that say that we have several choices to make a stability and that we should say nothing to avoid painting people into a corner.
09:38:04 [sandro]
maybe ldp:overallState
09:38:20 [Arnaud]
ack eric
09:38:20 [Zakim]
ericP, you wanted to propose that say that we have several choices to make a stability and that we should say nothing to avoid painting people into a corner.
09:38:24 [Ashok]
Discussion about whether etags can be used
09:38:53 [Zakim]
09:39:03 [BartvanLeeuwen]
Zakim, ??P0 is me
09:39:03 [Zakim]
+BartvanLeeuwen; got it
09:39:04 [Ashok]
Eric: Anything we add to spec would paint us into a corner
09:39:23 [SteveS]
perhaps a pageOfEtag header, to accompany ldp:pageOf
09:39:52 [SteveS]
09:40:00 [sandro]
+1 SteveS pageOfEtag. That's nice.
09:40:18 [krp]
ericP: is that in terms of not stating a solution to stability; or no mechanism for indicating changes to either/or pages or the resource being paged?
09:40:26 [sandro]
09:40:26 [Ashok]
Arnaud: If soemone wants to make a proposal please send soon to the list
09:40:28 [Arnaud]
ack steves
09:40:35 [JohnArwe]
We should at least set client expectations, e.g. "Clients should assume that container membership and page contents can change across successive HTTP requests, unless the server advertises/offers other behavior."
09:41:06 [ericP]
krp, both
09:41:11 [sandro]
+1 JohnArwe
09:41:14 [Ashok]
Steve: Let's wait till next version
09:41:17 [mesteban]
+1 JohnArwe
09:41:28 [mielvds]
a HEAD request for checking the ETag of the container is too much overhead?
09:41:28 [krp]
+1 JohnArwe
09:41:36 [ericP]
+1 JohnArwe
09:42:22 [Ashok]
Meil: Do a HEAD request to container to check if it has changed
09:42:39 [sandro]
You could do a HEAD for LastModified, not ETag, AFTER getting the page. That would work.
09:42:41 [JohnArwe]
09:42:46 [Ashok]
Steve: It get's you someone
09:43:12 [SteveS]
09:43:18 [Ashok]
09:44:03 [Ashok]
Arnaud: I think spec says pagination is not robust
09:45:37 [Ashok]
Arnaud: Editors to check what the spec says
09:47:47 [Ashok]
Arnaud: Let's wait and see if we get a proposal
09:47:50 [sandro]
my googling so far seems to support the 1-second resolution for last-modified. making it useless for HEAD this way.
09:49:25 [Ashok]
Topic: ISSUE-57 How can client tell he is communicating with a LDP server
09:50:01 [bblfish]
bblfish has joined #ldp
09:50:07 [Ashok]
Arnaud: Can you rely on RDF to tell you what the interaction model is
09:50:15 [bblfish]
09:50:38 [Ashok]
... others say conatiner tells you interaction model
09:50:59 [Ashok]
... some suggest changing the media type, that seems like a high cost
09:51:35 [Ashok]
... Coulkd we have a special header?
09:51:40 [sandro]
Arnaud: if you use new media type or a profile, you need new versions of every rdf syntax. so maybe use another header.
09:51:58 [Ashok]
09:52:00 [Yves]
if the issue is for the client to figure out if its' talking to a LDP capable server, then at worst doing an interaction not supported by the server will fail
09:52:21 [Yves]
why knowing a priori that it's an LDP server is better than knowing it a posteriori
09:52:23 [Ashok]
Arnaud: You could use a special header
09:52:50 [sandro]
q+ to say this is a way to do affordances in general
09:53:17 [Arnaud]
ack sandro
09:53:17 [Zakim]
sandro, you wanted to say this is a way to do affordances in general
09:53:53 [Ashok]
Sandro: I like this approach ... profile can be each LDP feature
09:54:21 [Ashok]
... one link header per page
09:55:13 [bblfish]
Sandro is suggesting another option where it is not a relation to one link header, but to a file much more complex that this, with finer details per ldp.
09:55:18 [Ashok]
Arnaud: ISSUE-33 brings up issue of servers with different capabilities
09:55:26 [bblfish]
09:55:26 [trackbot]
ISSUE-33 -- Pagination for non-container resources -- closed
09:55:26 [trackbot]
09:56:23 [sandro]
+1 Arnaud "If you're this kind of server, then you MUST do ...." instead of all our MAY and SHOULDs
09:56:39 [sandro]
header on each ldp RESPONSE
09:56:49 [bblfish]
Did arnaud meant Issue-33?
09:56:49 [bblfish]
what is the page that shows these options?
09:56:51 [mielvds1]
mielvds1 has joined #ldp
09:56:57 [mesteban_]
mesteban_ has joined #ldp
09:56:59 [sandro]
09:56:59 [trackbot]
ISSUE-33 -- Pagination for non-container resources -- closed
09:56:59 [trackbot]
09:57:02 [Arnaud1]
Arnaud1 has joined #ldp
09:57:05 [nmihindu_]
nmihindu_ has joined #ldp
09:57:08 [sandro]
09:57:08 [trackbot]
ISSUE-32 -- How can clients discover that a resource is an LDPR or LDPC, and what features are supported? -- open
09:57:08 [trackbot]
09:57:34 [sandro]
(this was about issue-32)
09:57:42 [Arnaud1]
10:01:19 [SteveS]
And the wiki page
10:03:31 [SteveS]
10:05:14 [Arnaud]
ack steves
10:05:39 [Arnaud]
strawpoll: use profile link headers to advertise ldp capabilities
10:05:49 [JohnArwe]
discussion about when to use link headers vs new RDF types
10:06:28 [SteveS]
10:07:13 [Yves]
+1 link header to identify an ldp-capable server
10:08:30 [krp]
krp has joined #ldp
10:08:53 [bblfish]
bblfish has joined #ldp
10:09:42 [bblfish]
10:10:10 [roger]
roger has joined #ldp
10:10:13 [roger]
hello !!
10:10:25 [SteveS]
We are talking also about, section 6
10:11:11 [Ashok]
Ashok has joined #ldp
10:13:47 [bblfish]
what is the straw poll?
10:14:23 [Arnaud]
strawpoll: use link headers to advertise ldp capabilities
10:14:29 [sandro]
10:14:31 [bblfish]
10:14:33 [ericP]
10:14:34 [rgarcia]
10:14:34 [krp]
10:14:35 [nmihindu_]
10:14:36 [JohnArwe]
10:14:38 [SteveS]
10:14:40 [roger]
10:14:42 [mielvds1]
10:14:49 [mesteban_]
10:15:33 [bblfish]
10:16:10 [Ashok]
Arnaud: You don't want to use 'profile' beacause it is not a recognized term ... you don't want to use RFC 6906?
10:16:51 [JohnArwe]
lots of discussion to clarify that, in the sense that these link headers might be thought of as 'types', that the set of rdf:type triples in the content (RDF resource types) might (and in fact needs to, in cases like a CMS) might differ from the 'types' exposed via link headers since the latter describes the server's interaction capabilities for the resouce not its content.
10:17:08 [Ashok]
Sandro: I have not read RFC 6906
10:18:06 [JohnArwe]
@sandro: what I've heard second hand from ErikW reads differently to me from the words I see in
10:18:29 [Ashok]
Sandro: what's the value of a profile
10:19:29 [Ashok]
John: Profile is defining a particular P
10:19:36 [Ashok]
... o is the URL
10:19:37 [ericP]
:context :linkRelationType :target .
10:20:10 [Ashok]
Sandro: You dereference o and you get the type info
10:20:37 [Arnaud]
this is what I would expect the header to look like: Link: <>; rel=profile
10:21:47 [JohnArwe]
@ericp: right that is the general form of 5988 headers; 6906 defines a particular link relation type (profile, as a short string not a uri/iri)
10:21:53 [sandro]
10:21:53 [trackbot]
ISSUE-57 -- How can a client determine that it is in communication with an LDP server? -- open
10:21:53 [trackbot]
10:22:28 [sandro]
Oh, I guess one can have multiple profiles at once.
10:22:35 [bblfish]
10:22:37 [bblfish]
10:22:39 [JohnArwe]
As Sandro notes, if we use profile, and LDP has 20 optional features, then you need one target IRI for each *combination* which is a lot, and scales badly
10:22:45 [nmihindu_]
10:22:54 [Arnaud]
ack bblfish
10:23:03 [Ashok]
Ashok: We don't need to define profiles in the spec
10:23:37 [Ashok]
10:24:20 [krp]
I heard "read-only" as a shorthand for a named set/profile of features
10:24:49 [Arnaud]
ack nmihindy
10:24:59 [Arnaud]
ack nmihindu
10:25:57 [bblfish]
10:28:39 [Arnaud]
ack ashok
10:29:17 [bblfish]
10:29:17 [trackbot]
ISSUE-32 -- How can clients discover that a resource is an LDPR or LDPC, and what features are supported? -- open
10:29:17 [trackbot]
10:29:25 [JohnArwe]
discussion about how granular the introspection capabilities needs to be from issue-32
10:29:32 [SteveS]
Wiki page:
10:29:33 [bblfish]
what is the URL for the issue-32
10:29:42 [bblfish]
which shows the different types of things?
10:29:51 [Arnaud]
ack bblfish
10:30:44 [SteveS]
10:31:13 [Arnaud]
ack steves
10:32:17 [Ashok]
Ashok has joined #ldp
10:32:33 [JohnArwe]
@henry: email w/ 3 profile strawman is at
10:32:39 [JohnArwe] pdf attachment
10:33:01 [Ashok]
Arnaud: Can we agree that to solve ISSUe-57 is to create a link header
10:33:36 [Ashok]
10:34:20 [sandro]
+1 bblfish using rdf:type relation IN LINK HEADER for ldp:Resource
10:35:32 [Arnaud]
PROPOSAL: close issue-57, adding that LDP servers MUST advertise LDP with a link header: Link: <>; rel=profile
10:36:16 [sandro]
q+ to ask why profile instead of type? (sorry)
10:36:37 [JohnArwe]
@sandro, are you saying that the link relation type = 'rdf:type' or 'type' ? 'type' is in the IANA registry, has the semantics I related before, so has the problem with any existing CMS that I related before.
10:36:43 [Arnaud]
ack sandro
10:36:43 [Zakim]
sandro, you wanted to ask why profile instead of type? (sorry)
10:36:57 [Ashok]
Ashok: And, Sandro type = rdf:type
10:37:04 [roger]
roger has joined #ldp
10:38:06 [SteveS]
10:38:07 [mielvds1]
So I guess bblfish is saying servers that offer rdf:type LDPResource should offer LDP functionality, else it's their problem?
10:38:18 [JohnArwe]
@sandro: an existing CMS; it exposes every rdf:type it finds in RDF-based resources as Link: "type", "rdf:type URI" headers.
10:38:30 [Arnaud]
ack steves
10:38:46 [Ashok]
Arnaud: Sandro, please type in proposal
10:39:07 [Ashok]
Steve: We could add profile types to the spec
10:39:28 [roger]
10:39:32 [Arnaud]
ack roger
10:39:51 [sandro]
PROPOSED: close ISSUE-57, adding that LDP servers MUST advertise LDP with a link header: Link: <>; rel=type (and noting that we consider rel=type to be shorthand for the rdf:type property). And we/others can subclass ldp:Resource as needed later.
10:40:14 [Ashok]
Roger: We need client to be generic ... that should be in the content
10:40:18 [JohnArwe]
...if you plunk a LDPR representation into that, and it has rdf:type=ldp:Resource in the representation, then the CMS would expose that. The CMS has not violated any spec, but it does not treat the resource as anything more than RDF (it's RDF, not LDP). If we re-use Link: 'type',<ldp:Resource> , that CMS is a liar.
10:41:02 [ericP]
10:41:04 [sandro]
10:41:13 [Ashok]
Sandro: You don't want to have to look at header if you don't want to? You can take your chances.
10:41:25 [BartvanLeeuwen]
10:41:47 [roger]
10:42:48 [rgarcia]
+-0 (not sure about what happens with containers)
10:42:48 [Ashok]
10:42:56 [mesteban_]
10:43:04 [SteveS]
+.5 (not sure 'type' matches as closely as 'profile')
10:43:16 [nmihindu_]
10:43:18 [bblfish]
bblfish has joined #ldp
10:43:19 [krp]
10:43:39 [sandro]
(I prefer 'type' to 'profile' because we get clear semantics for the the link target)
10:43:42 [JohnArwe]
-0.15 ... will learn to live with it, but recognize it's not as iron-clad as a link relation type that LDP newly defines
10:43:46 [bblfish]
+1 for the ldp:Resource version ( missing the def cause I got kicked out )
10:44:37 [Ashok]
John: This does not give you an ironclad guarantee
10:44:40 [codyburleson]
codyburleson has joined #ldp
10:46:12 [Ashok]
Arnaud: How would server put a type in automatically?
10:46:40 [sandro]
JohnArwe: I'm concerned that some systems will issue this link header automatically when they don't know anything about LDP, because they learned this information from somewhere (eg the content).
10:47:10 [mielvds1]
+1 (not perfect; can live with it)
10:47:15 [roger]
btw, what is the equivalent of a Link: header which could be used to encode a literal statement in a header element ?
10:47:31 [sandro]
I don't think that can be done, roger.
10:48:11 [codyburleson_]
codyburleson_ has joined #ldp
10:48:28 [roger]
sandro, should it be done ?
10:48:51 [Arnaud]
RESOLVED: close ISSUE-57, adding that LDP servers MUST advertise LDP with a link header: Link: <>; rel=type (and noting that we consider rel=type to be shorthand for the rdf:type property). And we/others can subclass ldp:Resource as needed later.
10:49:05 [Ashok]
Arnaud: Does anyone want to change their vote?
10:49:14 [Ashok]
No response
10:49:28 [Ashok]
Arnaud: ISSUE is resolved
10:51:37 [Ashok]
Arnaud: Raul is asking 'what happens to containers' ... do we need a different type
10:51:53 [Ashok]
Sandro: Containers are a type of LDPR
10:52:47 [bblfish]
where is the definition for the 'type' link relations btw?
10:52:55 [ericP]
Link: <>; rel="rdf:type"; <>; rel="rdf:type"
10:53:17 [krp]
10:53:26 [sandro]
eric, we just decided it was ldp:Resource not ldp:LDPR
10:53:41 [Arnaud]
eric, that would be: Link: <>; rel="rdf:type"; <>; rel="rdf:type"
10:53:50 [ericP]
roger that
10:54:00 [Arnaud]
10:54:02 [sandro]
so it's: and it's rel="type" not rel="rdf:type"
10:54:24 [sandro]
That is: Link: <>; rel="type"; <>; rel="type"
10:55:11 [Arnaud]
oh right
10:56:20 [Ashok]
Arnaud: This solves whether you are in an LDP context or not
10:56:28 [roger]
in my opinion, LDPRs are GETable only, and it's only the LDPC which are special (i.e. potentially support POST, PUT, PATCH), and may require these link headers.
10:56:59 [Ashok]
Arnaud: Do we need separate headers for resources and containers?
10:57:08 [JohnArwe]
note that we have an issue open to 'move' create from containers to ldp:Resource's
10:57:29 [Ashok]
Sandro: We need to look at other affordances
10:57:40 [bblfish]
This is really related to the issue on Inssue-78
10:58:03 [sandro]
sandro: how we handle Containers will need to depend on how we do other affordances.
10:58:03 [Ashok]
Arnaud: Let's leave it as LDPR for now
10:58:21 [Ashok]
10:58:43 [Ashok]
One hour break
10:59:04 [Zakim]
10:59:09 [Zakim]
10:59:18 [Zakim]
11:39:18 [bhyland]
bhyland has joined #ldp
12:04:35 [BartvanLeeuwen]
I knew they 1h wouldn't work in spain :)
12:04:36 [Zakim]
12:04:52 [ericP]
12:05:30 [ericP]
Zakim, [GVoice] is me
12:05:30 [Zakim]
+ericP; got it
12:09:38 [Zakim]
12:09:43 [BartvanLeeuwen]
Zakim, ??P13 is me
12:09:43 [Zakim]
+BartvanLeeuwen; got it
12:12:28 [Zakim]
12:14:54 [Arnaud]
Arnaud has joined #ldp
12:15:19 [mielvds]
mielvds has joined #ldp
12:16:27 [Ashok]
Ashok has joined #ldp
12:16:44 [Ashok]
Resuming after lunch
12:17:49 [codyburleson]
codyburleson has joined #ldp
12:17:53 [bblfish]
bblfish has joined #ldp
12:20:04 [davidwood]
davidwood has joined #ldp
12:20:51 [mesteban]
mesteban has joined #ldp
12:20:53 [rgarcia]
rgarcia has joined #ldp
12:20:59 [mesteban]
12:21:15 [nmihindu]
nmihindu has joined #ldp
12:21:59 [JohnArwe]
is there anyone In There ?
12:22:14 [nmihindu]
12:22:28 [sandro]
what's that, John? I hear the meeting room, and see you on IRC.
12:22:35 [SteveS]
SteveS has joined #ldp
12:22:56 [mesteban]
scribe: me
12:23:07 [mesteban]
scribe: mesteban
12:23:08 [JohnArwe]
JohnArwe has joined #ldp
12:23:15 [mesteban]
Topic: primer
12:23:16 [nmihindu]
wiki -
12:23:38 [mesteban]
nmihindu: reporting on the status of the primer
12:23:57 [mesteban]
... current status available in the posted link.
12:24:34 [mesteban]
... is the structure proposed on the wiki what the project wants?
12:25:08 [mesteban]
... there are issues to be solved, that if address would allows us to deliver the Primer by the end of the month.
12:25:31 [mesteban]
Arnaud: delivering is not a must (as it is not in the charter)
12:25:54 [mesteban]
... would rather prefer to focus effort on the LDP doc.
12:26:16 [krp]
krp has joined #ldp
12:26:44 [mesteban]
... the proposal for the primer should be reviewed
12:27:01 [mesteban]
... Ashok volunteers.
12:27:59 [Arnaud]
action: ashok to review the primer and send feedback
12:27:59 [trackbot]
Created ACTION-70 - Review the primer and send feedback [on Ashok Malhotra - due 2013-06-25].
12:28:04 [Arnaud]
action: henry to review the primer and send feedback
12:28:04 [trackbot]
Created ACTION-71 - Review the primer and send feedback [on Henry Story - due 2013-06-25].
12:28:06 [mesteban]
bblfish: would like to review
12:28:30 [mesteban]
Arnaud: timing is not important
12:29:04 [mesteban]
SteveS: it would be nice to have it when delivering the LDP spec.
12:29:25 [bblfish]
yes. it's important to make sure the best practices are best practices.
12:29:42 [mesteban]
Arnaud: we could this as a goal.
12:29:53 [mesteban]
s/could this/could have this/
12:30:17 [mesteban]
Arnaud: what is the purpose of the primer? Which is the target audience?
12:31:16 [mesteban]
Arnaud: there is tension between documenting what to implement and how it is to be used.
12:31:35 [ericP]
the text that's crafted to be precise and impossible to misinterpret is seldom the easiest read
12:31:54 [mesteban]
... the educational aspect should be focussed on LDP and not RDF.
12:33:01 [mesteban]
nmihindu: the point is that maybe the examples provided are to complex for non-RDF/LD people.
12:33:17 [mesteban]
... and maybe some education to that respect is necessary
12:34:08 [mesteban]
Roger: we should avoid communicating bad practices.
12:34:42 [mesteban]
bblfish: we have a year to see developers which bad practices "learn" and clarify the primer accordingly
12:36:31 [mesteban]
bblfish: we have to focuss on providing examples that do things properly
12:36:47 [Arnaud]
12:37:07 [mesteban]
12:37:21 [SteveS]
12:37:49 [Arnaud]
ack steves
12:38:03 [mesteban]
Ashok: developers usually ask about things related on how to use the LDP spec, and that's what it should be covered on the Primer.
12:38:23 [bblfish]
12:40:26 [Arnaud]
ack bblfish
12:41:45 [mesteban]
bblfish: maybe in the end we end up providing something like "LD-atom".
12:42:28 [mesteban]
Arnaud: we have an agreement that the purpose is not educate the people on general best practices,
12:42:48 [mesteban]
... just provide correct/good/valid examples.
12:43:05 [cody]
cody has joined #ldp
12:43:49 [mesteban]
nmihindu: we have used a patch format based on changesets for the examples
12:44:15 [mesteban]
... is it OK to keep them in the examples regardless nothing is said in the spec regarding PATCH?
12:44:21 [Ashok]
12:45:12 [mesteban]
arnoud: there is a problem if we don't say anything in the spec to that respect
12:45:14 [Arnaud]
ack ashok
12:46:51 [mesteban]
ashok: what happened with work that was done regarding PATCH?
12:47:03 [sandro]
+1 Arnaud's telling of the story
12:47:54 [sandro]
arnaud: Sandro worked on a proposal for Patch, but didn't come up with anything he was happy with enough to propose to the group
12:47:59 [mesteban]
arnaoud: if the LDP doesn't doesn't say anything about PATCH, the Primer shouldn't say a word either.
12:48:19 [sandro]
cf if you're curious.
12:48:25 [mesteban]
12:49:17 [mesteban]
nmihindu: are we switching to Respec?
12:49:22 [mesteban]
... when?
12:49:42 [mesteban]
Arnaud: you should switch as soon as possible.
12:50:02 [mesteban]
Topic: LDP spec again
12:50:28 [bblfish]
12:50:28 [trackbot]
ISSUE-32 -- How can clients discover that a resource is an LDPR or LDPC, and what features are supported? -- open
12:50:28 [trackbot]
12:50:41 [mesteban]
Topic: ISSUE-32
12:52:23 [mesteban]
JohnArwe: it would be better to focus on other issues more relevant to the LDP spec than starting discussion about affordances
12:53:54 [mesteban]
Arnaud: should we wait to dig into affordances until other issues regarding compliance have been solved?
12:54:08 [mesteban]
JohnArwe: definitely.
12:54:49 [SteveS]
SteveS has joined #ldp
12:55:39 [bblfish]
12:55:59 [JohnArwe]
13:01:34 [mesteban]
Arnaud: we have to focus on the broad categories more than on the specific tasks
13:02:57 [mesteban]
... do those tasks reflect the features that we want to expose?
13:03:17 [mesteban]
... then, how are we to advertise them? Profiles?
13:03:17 [sandro]
13:03:57 [Arnaud]
ack sandro
13:04:31 [mesteban]
Sandro: PATCH is a would use case for affordances.
13:04:43 [mesteban]
s/a would/a good/
13:05:05 [mesteban]
... because of the PATCH format semantics
13:05:05 [SteveS]
13:05:28 [nmihindu]
sandro, will that help ?
13:05:47 [Arnaud]
ack steves
13:08:54 [sandro]
sandro: I think it makes sense to use HTTP PATCH with RDF, you just need some affordance signalling, and rel=type works fine for that as far as I can tell.
13:09:24 [nmihindu]
mesteban: does the pdf in the email reflect the features of LDP correctly ?
13:09:24 [sandro]
sandro: like <> a ldp:PatchableViaPatchLanguage3 --- lets clients know they can use HTTP PATCH with that language.
13:11:29 [mesteban]
Arnaud: do we have then the "read-only" scenario?
13:12:13 [mesteban]
rgarcia: is the enumeration of tasks in the "prifle" exhaustive?
13:12:48 [mesteban]
Arnaud: if any other feature is found we would have to change the definition of the profile
13:14:30 [mesteban]
JohnArwe, SteveS: beware the document does not reflect the latest status of the LDP spec.
13:15:12 [betehess]
betehess has joined #ldp
13:16:21 [mesteban]
Arnoud: it will be difficult capture all the business logic reqs. from applications
13:17:05 [SteveS]
13:17:10 [mielvds1]
mielvds1 has joined #ldp
13:17:52 [mesteban]
JohnArwe: we should at least point out the variability points, but not necessesarily making a proposal on the implementation details
13:18:17 [ericP]
don't forget the ever-important CONNECT method
13:20:06 [mesteban]
Arnaud: so it seems there are two big categories: read only and read+write.
13:21:01 [mesteban]
... does it makes sense a write only profile?
13:21:09 [Arnaud]
13:22:53 [mesteban]
Arnaud: can the LDP spec stay without affordances?
13:23:51 [SteveS_]
SteveS_ has joined #ldp
13:24:05 [mesteban]
JohnArwe: I'm fine if for each variability point the LDP spec provides an instrospection mechanism for guessing the details from the implementation
13:24:40 [SteveS_]
13:24:57 [Arnaud]
ack steves
13:25:12 [mesteban]
bblfish: if we manage to identify the gaps (variability points) we could the later see if we can categorize them somehow.
13:25:26 [mesteban]
s/could the later/could later/
13:27:12 [mesteban]
SteveS_: we could just provide profiles for letting users know if only LDP Resources are supported or LDPR+LDPC and then provide introspection mechanisms for the other issues.
13:27:36 [mesteban]
s/for the other issues/for the other variability points/
13:28:21 [roger]
roger has joined #ldp
13:29:02 [JohnArwe]
JohnArwe has joined #ldp
13:29:37 [mesteban]
Arnaud: the only mechanism right now for discovering the capabilities is trial and error, and eventhough the errors might not real reflect the capabilities of the server
13:31:02 [mesteban]
bblfish: we could assume that once we now the type of resource (LDPC or LDPR) it is take for granted that certain operations (HTTP verbs) should be supported
13:32:10 [roger]
13:32:13 [nmihindu]
13:32:25 [Ashok]
Re: OPTIONS, the spec says This method allows the client to determine the options and/or requirements associated with a resource, or the capabilities of a server, without implying a resource action or initiating a resource retrieval.
13:32:30 [Arnaud]
ack nmihindu
13:32:59 [rgarcia]
13:33:06 [Ashok]
13:33:22 [mesteban]
nmihindu: the current draft of the spec reflects the usage of HEAD
13:33:25 [bblfish]
13:33:28 [JohnArwe]
13:33:40 [mesteban]
... but it might be better to support OPTIONS
13:33:58 [Arnaud]
ack roger
13:34:22 [SteveS]
13:34:30 [Arnaud]
ack ashok
13:34:45 [bblfish]
q+ why does Allow not give us all we need:
13:34:48 [mesteban]
SteveS: but this would require defining the structure for the body of the response
13:34:58 [bblfish]
q+ to why does Allow not give us all we need:
13:35:08 [nmihindu]
13:35:17 [mesteban]
Roger: we could just say we support OPTIONS without specifying the format of the response's body
13:35:46 [nmihindu]
"A 200 response SHOULD include any header fields that indicate optional features implemented by the server and applicable to that resource (e.g., Allow), possibly including extensions not defined by this specification. The response body, if any, SHOULD also include information about the communication options."
13:36:14 [mesteban]
JohnArwe: the options may apply to the server of the specific URI.
13:36:18 [bblfish]
13:36:21 [Arnaud]
ack roger
13:36:33 [Arnaud]
ack john
13:37:39 [mesteban]
JohnArwe: as we already enforce GET and HEAD, and can simulate OPTIONS with them it might be better to stick to them to lower possible entry barriers.
13:38:35 [Arnaud]
ack steves
13:38:39 [bblfish]
13:39:35 [TallTed]
TallTed has joined #ldp
13:40:10 [krp]
krp has joined #ldp
13:40:49 [JohnArwe]
13:41:08 [Arnaud]
ack john
13:41:09 [JohnArwe]
13:41:14 [SteveS]
SteveS: OPTIONS has the feature over HEAD in that you do not need to compute various GET-response headers, like: lastModified, etag, content-size, content-type
13:41:25 [bblfish]
Options in HTTP spec
13:41:40 [nmihindu]
q+ to say may be we can mention it in the deployment guide as always :)
13:42:19 [Arnaud]
ack nmihindu
13:42:19 [Zakim]
nmihindu, you wanted to say may be we can mention it in the deployment guide as always :)
13:43:00 [mesteban]
nmihindu: SteveS notice makes sense in the deployment guide, and could be included in there
13:43:34 [mesteban]
... do we don't lose the point
13:44:15 [Arnaud]
break for 15mn
13:52:31 [TallTed]
TallTed has joined #ldp
13:57:42 [JohnArwe]
yes cody
13:59:12 [SteveS]
SteveS has joined #ldp
13:59:49 [cody]
cody has joined #ldp
14:00:05 [rgarcia]
rgarcia has joined #ldp
14:00:53 [Arnaud]
scribe: krp
14:01:31 [krp]
SteveS: If OPTIONS is a more efficient way to do it, perhaps that is what we should have in the spec
14:01:53 [krp]
... rather than HEAD, which requires everything as per GET but without the body
14:02:48 [JohnArwe]
14:02:52 [krp]
roger: asks for an example of how we would do this with OPTIONS rather than HEAD
14:02:54 [Arnaud]
ack john
14:03:35 [bblfish]
14:03:40 [krp]
JohnArwe: if the allow has patch you also need to provide the allow-patch
14:04:04 [SteveS]
14:04:32 [krp]
Arnaud: could we have an example of this and what the change to the spec would be by tomorrow?
14:04:35 [JohnArwe]
14:04:37 [cody]
14:04:48 [Arnaud]
ack cody
14:05:15 [krp]
cody: why does section 4.6.2 exist in the spec?
14:05:52 [krp]
JohnArwe: it's a MUST because otherwise it would be optional by http default
14:06:36 [krp]
Arnaud: Likes the rfc5789 example. it doesn't seem to include any required options document
14:06:42 [JohnArwe]
14:07:01 [krp]
... if we were to do it like this example, it seems it does much of what we want
14:10:23 [krp]
Arnaud: whether to change HEAD in 4.6 to OPTIONS, or add a new OPTIONS section after 4.6
14:10:55 [JohnArwe]
Proposal: ADD: LDP Servers MUST indicate their support for HTTP Methods by responding to a HTTP OPTIONS request on the LDPR's URL. LDP Servers MUST include an 'Allow' header with the supported HTTP Methods. LDP Servers MUST include an 'Allow-Patch' header per RFC 5789, if the server supports PATCH.
14:11:10 [bblfish]
14:11:13 [SteveS]
14:11:15 [rgarcia]
14:11:25 [cody]
14:11:41 [nmihindu]
14:11:48 [krp]
14:11:49 [mesteban]
14:12:06 [BartvanLeeuwen]
14:12:11 [ericP]
14:12:16 [mielvds1]
14:12:37 [JohnArwe]
14:12:43 [JohnArwe]
+1 (for Roger)
14:12:47 [Arnaud]
RESOLVED: ADD: LDP Servers MUST indicate their support for HTTP Methods by responding to a HTTP OPTIONS request on the LDPR's URL. LDP Servers MUST include an 'Allow' header with the supported HTTP Methods. LDP Servers MUST include an 'Allow-Patch' header per RFC 5789, if the server supports PATCH.
14:13:31 [JohnArwe]
trackbot, topic?
14:13:31 [trackbot]
Sorry, JohnArwe, I don't understand 'trackbot, topic?'. Please refer to <> for help.
14:13:38 [krp]
Arnaud: this has only added a section. what should we do with 4.6 (HEAD)?
14:14:32 [krp]
SteveS: doesn't hurt anything to leave it a MUST. maybe say "If you support HEAD..."
14:14:49 [JohnArwe]
part of issue-32
14:15:06 [nmihindu]
14:15:06 [trackbot]
ISSUE-32 -- How can clients discover that a resource is an LDPR or LDPC, and what features are supported? -- open
14:15:06 [trackbot]
14:15:08 [krp]
Arnaud: let's leave as is. SteveS to come back if there's a problem.
14:17:35 [krp]
... Any objections to closing issue-19 as is? This issue is too broad at the moment.
14:17:45 [JohnArwe]
14:18:21 [Arnaud]
topic: issue-19
14:18:34 [krp]
Ashok: if there are specific error cases we need to have them pointed out
14:19:25 [krp]
JohnArwe: in the original email one resolution is that the errors are already covered by existing specs -- this seems to be the case
14:19:43 [krp]
... so can we close with that resolution?
14:21:43 [JohnArwe]
14:21:58 [Arnaud]
PROPOSAL: Close Issue-19 as is, the spec already covers some error cases, if other specific cases need to be addressed they should be pointed out individually
14:22:10 [JohnArwe]
14:22:14 [krp]
14:22:23 [rgarcia]
14:22:27 [roger]
14:22:30 [sandro]
14:22:30 [trackbot]
ISSUE-9 -- Should properties used in BPR representations be BPRs? -- closed
14:22:30 [trackbot]
14:22:38 [SteveS]
14:22:41 [nmihindu]
14:22:45 [mesteban]
14:22:46 [Ashok]
14:22:47 [sandro]
14:22:47 [trackbot]
ISSUE-19 -- Adressing more error cases -- pending review
14:22:47 [trackbot]
14:22:48 [mielvds1]
14:22:50 [sandro]
14:23:33 [bblfish]
14:23:40 [BartvanLeeuwen]
14:23:57 [cody]
14:24:00 [Arnaud]
RESOLVED: Close Issue-19 as is, the spec already covers some error cases, if other specific cases need to be addressed they should be pointed out individually
14:24:29 [krp]
topic: ISSUE-63
14:24:43 [krp]
14:24:43 [trackbot]
ISSUE-63 -- Need to be able to specify collation with container ordering -- pending review
14:24:43 [trackbot]
14:25:01 [ericP]
14:25:17 [bblfish]
14:26:06 [Arnaud]
PROPOSAL: Close Issue-63, per Ashok's proposal (adding ldp:containerSortCollation)
14:26:16 [krp]
Arnaud: propose we close as per Ashok's resolution, does ericP agree?
14:26:38 [Arnaud]
ack bblfish
14:26:59 [krp]
bblfish: this looks like it's using default reasoning again?
14:27:40 [krp]
arnaud: the issue is that it's an optional property
14:28:48 [krp]
JohnArwe: so this should be a mandatory property
14:29:12 [krp]
Ashok: but this adds a cost when it's not always needed
14:29:24 [bblfish]
mu issue is a montonocity issue
14:29:33 [bblfish]
just we need to be a bit careful
14:29:38 [krp]
ericP: agrees. is it still worth having that control? how would we test it? how many people would implement it?
14:29:58 [krp]
Ashok: this is going to be used by lots of people for lots of different applications, why handcuff it?
14:30:17 [krp]
Arnaud: if there is a default value you would have to specify it
14:30:53 [mesteban]
14:31:10 [Arnaud]
ack mesteban
14:31:21 [krp]
mesteban: is this some information property about how the server works?
14:31:44 [ericP]
14:31:52 [krp]
JohnArwe: when the server responds it says how the server ordered the information
14:32:20 [krp]
... doesn't enable the client to change the ordering
14:32:36 [krp]
Arnaud: it gives the client enough information to reproduce the ordering
14:33:25 [krp]
ericP: if the client gets items where the ordering is useful for presentation, the client needs to know how to reproduce that ordering as it can't get it from the rdf
14:34:22 [krp]
bblfish: if the ordering doesn't matter, or it's not important to the client, it doesn't include the ordering. if it does it uses one of these. so there's no default.
14:34:44 [krp]
Arnaud: so it's either unspecified, or specified with this property?
14:36:25 [krp]
... what do these collations look like?
14:36:53 [krp]
JohnArwe: the compare function is defined in xpath.
14:39:39 [krp]
bblfish: we need to make this work at a basic level for agents with low/near-zero reasoning. but we have to consider what happens for a client with reasoning.
14:40:19 [krp]
Arnaud: e.g. you don't see the property as it's not there, you assume it's using a default, but then you find it's using the other compare
14:40:55 [JohnArwe]
Some details on the 2-operand vs 3-operand behavior of fn:compare for strings...
14:41:27 [JohnArwe]
SPARQL Query appears to say that the default collation for the 2-case is codepoint, see ...
14:41:55 [krp]
ericP: you can't do anything with sorting until you've reached a document boundary
14:42:00 [JohnArwe]
XPath allows SPARQL to do that explicitly
14:42:21 [krp]
bblfish: on what property are you sorting? on the uris?
14:42:33 [krp]
Ashok: no, that's another issue. you have specified what you're sorting
14:43:06 [JohnArwe]
This sorting is for strings and untyped literals (which in RDF 1.1 will be treated as strings, and is how most implementations treat them today according to what I heard Sandro say at SemTech)
14:43:20 [Arnaud]
14:43:23 [nmihindu]
14:43:58 [krp]
JohnArwe: we defer the implementation to fn:compare to sparql query
14:44:58 [krp]
Arnaud: what is important is that if it's not stated you don't know which it is
14:47:01 [Arnaud]
PROPOSAL: Close Issue-63, adding a ldp:containerSortCollation, when set to, use compare(A,B), when set to something else, use compare(A, B, C)
14:47:28 [SteveS]
14:47:41 [bblfish]
14:48:50 [JohnArwe]
5.3.10 in editor's draft
14:49:04 [sandro]
+0 sounds reasonable, but I can't see the text on the editor's machine
14:49:16 [krp]
14:50:20 [JohnArwe]
14:51:03 [Arnaud]
PROPOSAL: Close Issue-63, adding a ldp:containerSortCollation, when set to, use compare(A,B), when set to another collation, use compare(A, B, C)
14:51:33 [ericP]
hey, that's my paragraph
14:51:35 [ericP]
write your own!
14:52:04 [ericP]
14:52:13 [ericP]
i actually don't remember if i did or not
14:53:09 [SteveS]
+1 (to proposal not ericP's ramblings)
14:53:22 [ericP]
+1 (ditt)
14:53:24 [krp]
14:53:27 [mielvds1]
14:53:31 [BartvanLeeuwen]
14:53:43 [Ashok]
14:53:45 [ericP]
14:53:46 [cody]
14:53:49 [mesteban]
14:53:57 [sandro]
+0 (sounds okay, but I don't understand it)
14:53:59 [rgarcia]
14:54:03 [nmihindu]
14:54:11 [JohnArwe]
+1 + need to remove "impln dependent" from editor's draft, since that's not what sparql says
14:54:34 [JohnArwe]
roger +1's
14:54:37 [bblfish]
bblfish has joined #ldp
14:54:53 [cody]
Henry +1
14:54:56 [Arnaud]
Resolved: Close Issue-63, adding a ldp:containerSortCollation, when set to, use compare(A,B), when set to another collation, use compare(A, B, C)
14:55:36 [krp]
14:55:36 [trackbot]
ISSUE-67 -- Full container membership without pagination -- pending review
14:55:36 [trackbot]
14:55:52 [bblfish]
14:55:52 [trackbot]
ISSUE-67 -- Full container membership without pagination -- pending review
14:55:52 [trackbot]
14:56:36 [krp]
Arnaud: several people have said that it is impossible to guarantee this, so suggest closing this
14:56:49 [JohnArwe]
14:56:57 [krp]
Ashok: there are valid reasons not to want paging
14:57:00 [nmihindu]
topic: issue-67
14:57:16 [Zakim]
14:57:47 [krp]
mielvds: if the server will not satisfy the request return forbidden?
14:58:16 [krp]
arnaud: surely returning a page (which is indicated) is better
14:59:54 [krp]
bblfish: if you are a server and you would like to give clients that can take it the whole content then you can
15:01:11 [krp]
roger: so the default (without paging) is to send the lot?
15:01:16 [krp]
JohnArwe: yes
15:01:52 [bblfish]
and a redirect ti the first page is a way for the server to say I can't deal with it all so you can only get pages
15:02:20 [krp]
looking at
15:03:33 [bblfish]
15:03:33 [trackbot]
ISSUE-67 -- Full container membership without pagination -- pending review
15:03:33 [trackbot]
15:03:57 [Arnaud]
PROPOSAL: Close ISSUE-67: Full container membership without pagination, saying no.
15:04:13 [rgarcia]
15:04:21 [nmihindu]
15:04:23 [SteveS]
15:04:27 [mesteban]
15:04:28 [ericP]
15:04:31 [Zakim]
15:04:32 [Ashok]
15:04:33 [JohnArwe]
+1 from roger
15:04:34 [krp]
15:04:36 [cody]
15:04:42 [mielvds1]
15:04:45 [sandro]
15:04:55 [bblfish]
+1 the reason was that a GET on the resource will by default return the full resource if there is no paging
15:05:01 [Arnaud]
Resolved: Close ISSUE-67: Full container membership without pagination, saying no.
15:05:30 [Zakim]
15:08:11 [krp]
15:08:11 [trackbot]
ISSUE-69 -- Query syntaxes for accessing the first and subsequent pages -- pending review
15:08:11 [trackbot]
15:08:35 [krp]
ashok: why this is useful: if I'm on a cellphone I only want the first 5
15:09:21 [krp]
... does the server paginate differently based on client request
15:09:38 [krp]
Arnaud: the server *may* -- it is implementation specific
15:09:40 [ericP]
use cookies!
15:10:12 [krp]
SteveS: it seems like there are use cases where this would be valuable -> wish list?
15:12:08 [krp]
Arnaud: this issue is specifically on the difference in syntax between first and other pages. but all of them are opaque and not specified by the spec.
15:13:13 [Arnaud]
PROPOSAL: close ISSUE-69, as is, the syntax is opaque and dependent on the implementation
15:13:43 [krp]
JohnArwe: there is no way to find the 5th page. the right way to do it might be to expose a URI template, but we are too far ahead there to do so at this point
15:13:44 [SteveS]
15:13:48 [krp]
15:13:55 [JohnArwe]
15:13:56 [Ashok]
15:14:01 [roger]
roger has joined #ldp
15:14:03 [roger]
15:14:04 [nmihindu]
15:14:12 [cody]
15:14:13 [rgarcia]
15:14:17 [sandro]
15:14:18 [mesteban]
15:14:26 [mielvds1]
15:14:35 [Arnaud]
RESOLVED: Close ISSUE-69, as is, the syntax is opaque and dependent on the implementation
15:14:46 [bblfish]
15:16:05 [krp]
15:16:05 [trackbot]
ISSUE-71 -- No membershipSubject or membershipPredicate -- open
15:16:05 [trackbot]
15:18:46 [Arnaud]
topic: Issue-75
15:19:20 [krp]
15:19:20 [trackbot]
ISSUE-75 -- non-monotonic ldp:membershipXXX relations -- open
15:19:20 [trackbot]
15:20:08 [krp]
Arnaud: easy fix. you always have to specify membershipPredicate.
15:20:22 [krp]
Ashok: on each container? (yes)
15:20:33 [SteveS]
15:20:54 [krp]
bblfish: I would prefer there is something like ldpmember which we can always rely on (kind of a default)
15:21:21 [krp]
... think of membershipPredicate as a kind of rule, when you post here you're adding a triple and also doing something else
15:21:45 [roger]
15:21:58 [Arnaud]
ack john
15:22:05 [krp]
Arnaud: keeping the spec as is, there is an issue with non-monotinicity. can we scope to that question for the moment.
15:22:28 [krp]
JohnArwe: I feel we conflate containership with creatorship
15:22:33 [krp]
Arnaud: off-topic!
15:22:55 [Arnaud]
ack steves
15:24:00 [JohnArwe]
I continue to object to Henry's POST-centric characterization of how he thinks membership works, which he used in the course of his remarks *on this issue*
15:24:11 [krp]
SteveS: I think this would come up when someone adds a property, then says this is a subclass of rdfs:member. so this problem can come up without a default when triples are added later?
15:24:22 [roger]
+1 to John
15:24:30 [krp]
... so I don't understand how having a default or not in the spec solves this.
15:24:50 [ericP]
what on earth would i do with a container if i didn't know the membership predicate?
15:24:53 [ericP]
15:25:34 [betehess_laptop]
betehess_laptop has joined #ldp
15:25:59 [krp]
bblfish: either: assume you don't know, or thinking of it declaratively and inferentially as a rule that transforms
15:26:13 [Arnaud]
ack roger
15:26:17 [rgarcia]
15:26:45 [krp]
roger: make membershipPredicate a MUST, and do not conflate LDPR and LDPC
15:27:06 [Arnaud]
ack eric
15:27:27 [JohnArwe]
not clear on what roger thinks are being conflated ... might agree with him if I did, cannot be sure
15:27:58 [krp]
ericP: must always state membershipPredicate is reasonable. the reason for including that complexity might be better explained by examples (from IBM?)
15:28:39 [krp]
... any motivations to appeal to non-RDF folks (look how simple in RDF) goes away if we follow Henry's proposal
15:28:54 [roger]
OK, to re-state my opinion in another way. membershipPredicate and membershipSubject MUST be declared. and the membershipSubject cannot refer to self.
15:29:32 [bblfish]
15:29:34 [krp]
... what do I want to do with a container if I don't know the membershipPredicate?
15:29:41 [SteveS]
ericP I tried to summarize why there was some complexity added, see
15:29:43 [krp]
... it should always be expressed
15:29:51 [JohnArwe]
+1 ericP, if we were to require both in many cases of interest to me (re-using existing collections by overlaying LDP onto them) the representation sizes would effectively double; so not only "not as simple", but obviously less scalable
15:29:53 [Arnaud]
ack rgarcia
15:30:24 [Arnaud]
ack bblfish
15:30:45 [krp]
rgarcia: I don't think the resource representation to include the application model (referring to SteveS example of adding later triples)
15:31:01 [JohnArwe]
@ericp: we're not talking about it, we're IRCing
15:31:56 [ericP]
@JohnArwe, and maybe we reach concensus on that issue ready to resolve when we raise it
15:32:11 [krp]
SteveS: we saw this repeating pattern; always posting in the same way, wanted to both support the domain model and keep a common interaction
15:34:32 [krp]
bblfish: if when you post to a container like atom there's a default action. when you post something else, think of it as a rule -- as a consequence it add these other relationships
15:34:46 [ericP]
PROPOSED: if membershipSubject and membershipPredicate remain in LDP, they MUST be expressed in every page of an LDPC
15:36:23 [krp]
... behind membership subject membershipPredicate there's already a simple rule language
15:36:40 [JohnArwe]
s/in every page/in every container/
15:37:23 [Arnaud]
PROPOSED: Close Issue-75, if membershipSubject, membershipPredicate, and membershipPredicateInverse remain in LDP, they MUST be expressed in every page of an LDPC
15:37:52 [Arnaud]
PROPOSED: if membershipSubject and membershipPredicate remain in LDP, they MUST be expressed in every LDPC
15:38:33 [SteveS]
15:39:07 [roger]
15:39:26 [JohnArwe]
15:39:28 [rgarcia]
15:39:33 [mesteban]
15:39:33 [krp]
15:39:42 [nmihindu]
15:39:43 [ericP]
15:39:49 [sandro]
15:40:06 [roger]
15:40:18 [cody]
15:41:21 [mielvds1]
+1 (but it will change anyway ;))
15:42:12 [krp]
bblfish: what is it the client doesn't know when it doesn't have these (membershipSubject, membershipPredicate, and membershipPredicateInverse)?
15:42:22 [bblfish]
15:42:29 [krp]
Arnaud: it doesn't know how to browse the membership of the container
15:42:35 [Arnaud]
RESOLVED: Close Issue-75, if membershipSubject, membershipPredicate, and membershipPredicateInverse remain in LDP, they MUST be expressed in every LDPC
15:42:53 [krp]
15:42:53 [trackbot]
ISSUE-71 -- No membershipSubject or membershipPredicate -- open
15:42:53 [trackbot]
15:43:12 [Arnaud]
ack roger
15:43:22 [JohnArwe]
editor's should factor in inverse member predicates when drafting issue-75 text
15:43:30 [JohnArwe]
15:44:12 [krp]
roger: so you have these rules, so that once you've posted to it, gives you the equivalent to membershipPredicate in domain terms?
15:44:15 [JohnArwe]
I have not been. agnostic on doing them now vs later.
15:44:52 [krp]
... how does it work if I'm interested in person likes/dislikes food. what happens if I post, I'm not asking the server to decide if I like of dislike
15:45:31 [krp]
bblfish: post a resource that's the food, with a relationship going back to a container saying you like
15:45:40 [Arnaud]
15:46:31 [krp]
roger: that's complicated. this needs to be simple for developers.
15:47:33 [krp]
bblfish: when you're posting to a container, what you're not saying is if you don't know what the membershipPredicate there, you don't know what the contains relationship is
15:47:53 [krp]
(see issue-79)
15:50:10 [Arnaud]
15:51:35 [krp]
looking at section of email following "Let's take a look at bug 13 again:"
15:52:27 [ericP]
Arnaud, could you paste your example into ?
15:54:35 [krp]
bblfish: at least define contains, as this means we can say what we're missing what we don't know
15:54:46 [ericP]
it's malformed, throw it away
15:56:20 [krp]
... I can discover via hateoas
15:56:40 [krp]
... it makes it explicit of what the attachments of the children are (if contains is there)
15:57:34 [krp]
... you have a default without having a default
15:57:46 [krp]
arnaud: but you double the triples. is it worth it?
15:58:17 [krp]
roger: don't think it's too bad for my normal usage patterns
15:58:51 [roger]
.... because the LDPR is the one which is GETted
15:59:03 [krp]
bblfish: sometimes I have to go and look at another document to find out what's in my container
15:59:21 [roger]
16:00:05 [krp]
... when you GET a document, it's the final absolute definition of that document, I shouldn't have to go somewhere else to know
16:00:22 [Arnaud]
ack roger
16:00:29 [JohnArwe]
16:01:08 [krp]
roger: appreciated explanation on mailing lists of semanticised atom. but could it be done the other way?
16:01:21 [krp]
bblfish: you're requiring inference much earlier without this
16:04:20 [Arnaud]
ack john
16:06:49 [krp]
arnaud: will there always be two triples for each attachment? (with the ldp:contains)
16:07:14 [Ashok]
16:08:55 [mielvds1]
You'll have inferencing either way
16:08:58 [krp]
johnarwe: if an addition is made (an attachment) by patch, does the contains have to be added?
16:09:58 [mesteban]
16:10:07 [Arnaud]
ack ashok
16:10:39 [krp]
ashok: is how attachments/alh being added that way ok? or does it mean the server must add the corresponding ldp:contains?
16:11:23 [cody]
cody has joined #ldp
16:11:28 [krp]
johnarwe: this redefines the notion of membership as it is in the spec
16:12:02 [krp]
16:12:45 [sandro]
how long are we going today?
16:12:48 [Arnaud]
ack mesteban
16:12:52 [SteveS]
16:13:08 [krp]
mesteban: there are two possible ways for updating the same thing
16:13:08 [JohnArwe]
@sandro notionally, until 15 minutes ago ;-)
16:13:21 [krp]
... do I have to keep everything synchronised?
16:14:27 [Arnaud]
ack krp
16:15:41 [Zakim]
16:15:55 [JohnArwe]
My expectations are that any given resource would only allow one method of updating membership triples. We allowed PATCH primarily due to the scaling issues for large-membership containers (PUT does not scale past some client and/or server limit)
16:16:09 [Arnaud]
sandro, I proposed to extend meeting by 1h
16:16:29 [Arnaud]
we're getting close to that though
16:16:36 [JohnArwe]
...for small-enough cases, PUT is how you add membership "ptrs" to existing resources.
16:17:40 [JohnArwe]
...At some point you hit some limit on client or server, and PUT no longer functions so you're forced to PATCH.
16:18:40 [sandro]
I propose Henry and Steve come to consensus over dinner.
16:18:52 [Arnaud]
16:19:04 [sandro]
Once they do that, I might be able to follow this.
16:19:15 [Arnaud]
I think we are going to stop here for today
16:19:19 [JohnArwe]
I'm thinking that this may be a "profiles do that" answer.
16:19:39 [SteveS]
16:20:15 [Arnaud]
ack steves
16:21:00 [sandro]
I'm going to drop off. Having too much trouble following this. Back in the morning.
16:21:11 [Zakim]
16:28:28 [betehess]
betehess has joined #ldp
16:39:48 [mielvds1]
mielvds1 has left #ldp
16:43:42 [Arnaud]
meeting adjourned
17:02:05 [davidwood]
davidwood has joined #ldp
17:52:59 [Arnaud]
Arnaud has joined #ldp
17:54:49 [davidwood]
davidwood has joined #ldp
17:55:22 [SteveS]
SteveS has joined #ldp
17:56:28 [mesteban]
mesteban has joined #ldp
18:25:56 [betehess_]
betehess_ has joined #ldp
18:31:27 [betehess_laptop]
betehess_laptop has joined #ldp
18:35:00 [Zakim]
disconnecting the lone participant, m, in SW_LDP(F2F)2:30AM
18:35:01 [Zakim]
SW_LDP(F2F)2:30AM has ended
18:35:01 [Zakim]
Attendees were BartvanLeeuwen, +34.91.336.aaaa, m, ericP, Sandro
18:35:02 [bblfish_]
bblfish_ has joined #ldp
18:45:18 [Zakim]
Zakim has left #ldp
19:18:22 [cody]
cody has joined #ldp
20:46:33 [bblfish]
bblfish has joined #ldp
21:38:04 [bblfish]
bblfish has joined #ldp
22:14:34 [bblfish]
bblfish has joined #ldp
22:28:43 [krp]
krp has joined #ldp
22:35:20 [SteveS]
SteveS has joined #ldp
22:56:36 [roger]
roger has joined #ldp
23:17:56 [krp]
krp has joined #ldp
23:48:58 [krp]
krp has joined #ldp