IRC log of ldp on 2013-06-19

Timestamps are in UTC.

07:03:39 [RRSAgent]
RRSAgent has joined #ldp
07:03:39 [RRSAgent]
logging to
07:03:41 [trackbot]
RRSAgent, make logs public
07:03:41 [Zakim]
Zakim has joined #ldp
07:03:43 [trackbot]
Zakim, this will be LDP
07:03:43 [Zakim]
ok, trackbot; I see SW_LDP(F2F)2:30AM scheduled to start 33 minutes ago
07:03:44 [trackbot]
Meeting: Linked Data Platform (LDP) Working Group Teleconference
07:03:44 [trackbot]
Date: 19 June 2013
07:04:30 [SteveS]
SteveS has joined #ldp
07:08:59 [nmihindu]
nmihindu has joined #ldp
07:10:43 [Arnaud]
07:11:01 [nmihindu]
scribe: nmihindu
07:11:13 [Arnaud]
chair: Arnaud
07:14:59 [nmihindu]
Arnaud: we will start discussing the issues later so that people connecting from the US can also participate
07:15:10 [nmihindu]
Topic: Access Control WG Note - steps towards FWD
07:15:22 [nmihindu]
Arnaud: what is the status ?
07:15:24 [bblfish]
where is the note?
07:15:46 [nmihindu]
07:16:52 [nmihindu]
asok: we have the note, we need to get it reviewed by the WG
07:17:53 [nmihindu]
Arnaud: we can give an action item for getting this note reviewed
07:18:11 [nmihindu]
ashok: Ted was interested in reviewing the note
07:18:55 [nmihindu]
mesteban__: what is the deadline for reviewing the note ?
07:19:24 [nmihindu]
ashok: normally it is two weeks, but it can take more
07:19:52 [JohnArwe]
JohnArwe has joined #ldp
07:20:12 [nmihindu]
Arnaud: our priority is the spec, other things come second
07:20:35 [nmihindu]
Arnaud: Ted and mesteban__ can review the document
07:20:35 [Arnaud]
action: mesteban to review and comment the WG Access Control draft
07:20:35 [trackbot]
Created ACTION-76 - Review and comment the WG Access Control draft [on Miguel Esteban Gutiérrez - due 2013-06-26].
07:21:05 [Arnaud]
action: Ted to review and comment the WG Access Control draft
07:21:05 [trackbot]
Created ACTION-77 - Review and comment the WG Access Control draft [on Ted Thibodeau - due 2013-06-26].
07:23:08 [nmihindu]
Arnaud: deadline for reviewing these document will be 1 month
07:23:18 [nmihindu]
... anything more to discuss on this ?
07:23:24 [AndyS]
AndyS has joined #ldp
07:23:48 [mielvds]
mielvds has joined #ldp
07:23:52 [nmihindu]
Topic: Deployment Guide - steps towards FWD
07:23:58 [bblfish]
where is the deployment guide?
07:24:15 [Arnaud]
07:25:21 [krp]
krp has joined #ldp
07:26:06 [nmihindu]
bblfish: what is the difference between the deployment guide and best practices ?
07:26:39 [nmihindu]
Arnaud: we need to find an editor for the deployment guide ?
07:27:11 [nmihindu]
Ashok: what is the difference between the primer and the deployment guide ?
07:28:05 [nmihindu]
Arnaud: Primer is the primarily for users and the deployment guide is mainly for implimenters
07:28:13 [Zakim]
SW_LDP(F2F)2:30AM has now started
07:28:20 [Zakim]
07:28:33 [nmihindu]
... the goals and the audience are different
07:29:29 [nmihindu]
... we moved some stuff from the spec to the deployment guide
07:29:54 [nmihindu]
Ashok: why did we move datatypes from the spec to deployment guide ?
07:30:04 [nmihindu]
07:30:43 [Arnaud]
ack nmihindu
07:30:45 [bblfish]
07:33:46 [cody]
cody has joined #ldp
07:34:28 [nmihindu]
Arnaud: there were things in the spec that would better fit into the deployment guide, so we moved them from the spec to the deployment guide
07:35:17 [nmihindu]
... spec defines the conformance and and the deployment guide shows best practices
07:36:35 [nmihindu]
cody: I can help to do the editorial stuff and organizing it better
07:37:45 [nmihindu]
cody: is there a deadline for this ?
07:37:59 [Ashok]
Ashok has joined #ldp
07:38:12 [nmihindu]
Arnaud: we don't have a specific deadline as per now
07:38:23 [Ashok]
Re. RDF datatypes, here is a useful document:
07:38:28 [rgarcia]
rgarcia has joined #ldp
07:39:07 [nmihindu]
Arnaud: we can make cody the primary editor and nmihindu to help
07:39:14 [cody]
Confirmed: I will be the primary editor for Deployment Guide with Nandana as assist.
07:40:13 [nmihindu]
Arnaud: any more issues discuss on this topic ?
07:40:35 [nmihindu]
SteveS: the name deployment guide is confusing
07:40:54 [nmihindu]
Arnaud: we can change the name now, there are few proposals in the wiki
07:41:28 [nmihindu]
cody: deployment in software is very different from what we have in the document
07:41:58 [nmihindu]
cody: LDP best practise and guidelines ?
07:41:58 [bblfish]
suggested title: LDP Best Practices
07:42:12 [bblfish]
suggested title: LDP Best Practices and guidelines
07:42:43 [SteveS]
I'm good with: LDP Best Practices and Guidelines
07:43:27 [nmihindu]
bblfish: deployment is more about publishing your data
07:44:24 [nmihindu]
Arnaud: LDP best practices is generic enough to cover everything we have in the document
07:45:56 [bblfish]
Proposal: A: LDP Best Practices B: LDP Best Practices and Guidelines
07:46:05 [Arnaud]
PROPOSED: Change title of deployment guide to "LDP Best Practices and Guidelines"
07:46:07 [rgarcia]
07:46:11 [bblfish]
07:46:23 [krp]
07:46:29 [cody]
07:46:40 [cody]
No B
07:46:45 [rgarcia]
I can perfectly live with A
07:46:46 [cody]
Its B!
07:46:57 [mielvds]
07:47:08 [SteveS]
07:47:11 [nmihindu]
B, can live with A
07:47:23 [mesteban__]
07:47:48 [Ashok_]
Ashok_ has joined #ldp
07:47:51 [SteveS]
I can live with A, say +0.51 B, +0.49 A
07:48:48 [nmihindu]
rgarcia: let's let cody decide
07:49:05 [Arnaud]
Resolved: Change title of deployment guide to "LDP Best Practices and Guidelines"
07:50:08 [nmihindu]
Topic: Test Suite & Validator - steps to completion
07:50:46 [nmihindu]
Arnaud: it would have been better if ericP was here
07:50:50 [SteveS]
ericP you awake?
07:51:17 [nmihindu]
rgarcia: I will give an overview and the next steps
07:52:26 [rgarcia]
07:53:42 [nmihindu]
rgarcia: we have defined test cases for core LDP features - all the MUSTs in the spec
07:54:07 [nmihindu]
rgarcia: explaining the current status of the document
07:55:34 [nmihindu]
... the document defines the test cases and result and they are linked for traceability
07:56:47 [nmihindu]
... the tests can be run by a software automatically or manually and the results can be submitted
07:57:29 [nmihindu]
... In the spec, we have both testable requirements and non-testable requirements
07:57:49 [nmihindu]
... it is better to have testable requirements
07:59:24 [nmihindu]
... there are some ambiguities in the spec, we need to remove them to make all the requirements are testable
08:00:45 [nmihindu]
Arnaud: this for implementaters to test their implementations
08:01:03 [nmihindu]
... not a test harness
08:02:16 [nmihindu]
mesteban__: we already discussed this, there are a lot issues testing application specific LDP implementations
08:05:17 [nmihindu]
bblfish: test cases can help to find the problematic areas of the spec
08:05:53 [nmihindu]
rgarcia: at the moment, we cover all the MUSTs but not different compliance levels etc.
08:06:24 [nmihindu]
Arnaud: how much are we missing ? Paging, Sorting ?
08:07:03 [nmihindu]
rgarcia: we are missing the SHOULDs
08:07:28 [nmihindu]
Arnaud: Is anybody using the test suite already ?
08:08:03 [nmihindu]
... it would be interesting to use it and provide feedback
08:08:41 [mielvds]
mielvds has joined #ldp
08:08:53 [cody_]
cody_ has joined #ldp
08:09:09 [nmihindu]
mesteban__: we can not have a test harness for application specific LDP implementations
08:09:30 [nmihindu]
Arnaud: we have at least have one test harness for vanilla implementations
08:10:07 [nmihindu]
mesteban__: if the developers can provide their data, we can provide a SPI for executing the tests
08:10:57 [nmihindu]
Arnaud: we need at least two implementations compliant with the spec
08:13:06 [nmihindu]
Arnaud: we need to find people responsible for coming up with a harness and generate the report
08:13:17 [bblfish]
Alex Bertails had promised to work on the implementation for the test harness ( using Banana RDF possibly )
08:14:41 [nmihindu]
rgarcia: the current tests can be run manually and provide the results to us
08:16:03 [nmihindu]
cody: we need to define a standard format for reporting the results
08:16:31 [nmihindu]
rgarcia: it is already defined in the document
08:17:06 [nmihindu]
bblfish: I can volunteer to provide a test harness
08:17:16 [bblfish]
with the help of alex bertails.
08:17:18 [bblfish]
08:17:22 [bblfish]
( but will do it )
08:17:24 [roger]
roger has joined #ldp
08:17:30 [roger]
08:17:51 [Arnaud]
ack roger
08:18:15 [mielvds]
I can contribute on @bblfish his github repo
08:18:20 [nmihindu]
Arnaud: we can provide a harness for vanilla implementations and the application specific LDP servers can start from there and define their own
08:18:47 [bblfish]
I'll post this to the group. Will use banana-ref
08:18:53 [nmihindu]
roger: other standards do interop fests, can we do something like that ?
08:19:45 [nmihindu]
Arnaud: we can do that, it is always helpful to improve interoperability and also find ambiguities in the spec
08:20:53 [nmihindu]
Arnaud: how we can improve the test suite to include conformance, affordances etc ?
08:21:48 [nmihindu]
... we define the different conformance levels with names, we can make set of tests to cover specific conformance
08:22:54 [nmihindu]
rgarcia: it makes more sense to have separate them as modules, so they are not built on top each other but rather can be orthogonal
08:23:55 [SteveS]
08:23:59 [nmihindu]
bblfish: can you provide an example of specific spec sections which are not testable ?
08:25:51 [nmihindu]
rgarcia: we have you MAY implement feature X, and then SHOULD. It is better to say if you implement feature X, then you MUST DO these
08:25:51 [jmvanel]
jmvanel has joined #ldp
08:26:21 [bblfish]
08:26:22 [bblfish]
08:27:32 [Arnaud]
ack bblfish
08:27:40 [nmihindu]
... it is hard to check the pre-conditions at the moment, for example whether we can do PUT on a resource
08:29:15 [nmihindu]
Arnaud: do you think some of the SHOULDs must be changed to MUSTs ?
08:31:04 [nmihindu]
... in a way, if you implement some feature (or a module), then you MUST and MUST NOT do several things
08:31:20 [nmihindu]
... we can reduce the number of SHOULDs
08:34:28 [nmihindu]
JohnArwe: if we organize the spec like modules, it could be helpful to the implementors to only focus on specific modules they would like to implement
08:37:09 [nmihindu]
Coffee break !!
08:54:02 [stevebattle3]
stevebattle3 has joined #ldp
08:54:35 [rgarcia]
rgarcia has joined #ldp
08:55:35 [roger]
back from coffee
08:57:21 [Arnaud]
Zakim, who's on the phone?
08:57:21 [Zakim]
On the phone I see m
08:57:44 [ericP]
i thought m died at the end of the last movie
08:58:42 [Zakim]
08:58:48 [ericP]
Zakim, [GVoice] is me
08:58:48 [Zakim]
+ericP; got it
08:59:12 [SteveS]
SteveS has joined #ldp
09:00:25 [rgarcia]
scribe: rgarcia
09:00:30 [mielvds]
mielvds has joined #ldp
09:00:55 [rgarcia]
topic: Test Suite
09:01:25 [rgarcia]
ericP: I may implement a test harness, but maybe not in time
09:01:49 [rgarcia]
ashok: Eric, did you implement something for RDB2RDF?
09:02:04 [rgarcia]
ericP: That case was much simpler
09:04:49 [rgarcia]
Arnaud: The point is that if someone writes the test harness for a generic LDP server other people can reuse it, even for the domain-specific LDP servers
09:04:53 [mesteban___]
mesteban___ has joined #ldp
09:05:03 [nandana]
nandana has joined #ldp
09:05:29 [rgarcia]
bblfish: I plan to implement a test harness
09:06:02 [mesteban___]
mesteban___ has joined #ldp
09:06:18 [rgarcia]
ericP: Alexandre said that he was going to implement something but would be quite specific, maybe not of value for others
09:06:56 [rgarcia]
Arnaud: Right now there is no one in charge of developing and maintaining a test harness
09:08:34 [rgarcia]
Arnaud: Back to discussing issues
09:08:52 [rgarcia]
topic: Modules / profiles / affordances
09:09:02 [rgarcia]
Arnaud: What do we need to have?
09:09:22 [ericP]
-> generic triple store LDP test
09:09:28 [rgarcia]
JohnArwe: Why should we do that?
09:09:33 [SteveS]
ericP I see the test harness for RDB2RDF at
09:10:19 [rgarcia]
JohnArwe: … one benefit is to make the specification more consumable: by users, test suite, etc.
09:11:04 [ericP]
SteveS, indeed. i wonder what purpose those links fill there. perhaps inspiration?
09:11:58 [SteveS]
ericP yes, just "hey, look at some other stuff" and maybe someone could factor out something reusable (HTTP commands/response)
09:12:21 [rgarcia]
roger: so, there will be different types of servers; for example with and without pagination
09:12:36 [rgarcia]
JohnArwe: and the clients may also want to use certain features or not
09:12:37 [ericP]
SteveS, true, that's the concrete vision that i think we'd need.
09:13:44 [rgarcia]
Arnaud: Is the read-only profile covered by OPTIONS?
09:13:53 [Zakim]
09:13:56 [rgarcia]
JohnArwe: Yes
09:14:14 [rgarcia]
Arnaud: what else are we not addressing?
09:14:20 [bblfish]
09:14:20 [trackbot]
ISSUE-32 -- How can clients discover that a resource is an LDPR or LDPC, and what features are supported? -- open
09:14:20 [trackbot]
09:15:08 [bblfish]
09:15:08 [trackbot]
ISSUE-80 -- How does a client know which POST requests create new resources -- open
09:15:08 [trackbot]
09:15:49 [JohnArwe]
09:16:10 [cody]
cody has joined #ldp
09:16:43 [Ashok]
Ashok has joined #ldp
09:17:05 [rgarcia]
JohnArwe: Does a server support membership triples whose object is not an LDPR?
09:17:25 [rgarcia]
bblfish: That is related to how do you know what can be posted to a container
09:17:33 [rgarcia]
JohnArwe: That is related to ISSUE-80
09:18:56 [stevebattle4]
stevebattle4 has joined #ldp
09:19:32 [rgarcia]
JohnArwe: 4.1.3 is more related to create that to other things such as PATCH
09:21:08 [rgarcia]
JohnArwe: There are not so many affordances without a discovery mechanism
09:23:27 [Zakim]
09:23:32 [rgarcia]
Ashok: How can it be detected that the data sent to the server is not valid?
09:23:49 [rgarcia]
SteveS: According to the datatype
09:24:20 [rgarcia]
JohnArwe: 5.4.3 is again about ISSUE-80
09:24:46 [rgarcia]
… and 5.6.x is about recursive delete which is already closed
09:25:05 [rgarcia]
… so we are covering everything except those things related to ISSUE-80
09:25:14 [rgarcia]
topic: ISSUE 80
09:25:25 [SteveS]
09:25:25 [trackbot]
ISSUE-80 -- How does a client know which POST requests create new resources -- open
09:25:25 [trackbot]
09:26:01 [rgarcia]
JohnArwe: There is already a proposal for solving the issue
09:26:45 [bblfish]
09:26:52 [rgarcia]
… replicating the way it is used in PATCH for POST would be nice from the HTTP perspective
09:27:10 [rgarcia]
… but the semantics of POST are completely open
09:27:49 [bblfish]
suggest something like a link header that says { <> memberType :someType . } e.g. { <> memberType :Bug
09:27:55 [bblfish]
09:28:32 [rgarcia]
… for example, POST is frequently used for querying
09:28:37 [SteveS]
bblfish -1, that is overkill for what we are talking about and different issue
09:29:36 [rgarcia]
… we can leave things open (as everyone else in the web) or include service documents that specify them
09:30:10 [bblfish]
09:31:00 [Arnaud]
ack bblfish
09:31:14 [rgarcia]
bblfish: this doesn't solve the problem deep enough
09:31:23 [SteveS]
09:32:02 [rgarcia]
… in our case everything is turtle and we want to distinguish what can I post to a container
09:32:24 [rgarcia]
… the mime type is the wrong approach, we should make it declaratively
09:32:30 [bblfish]
suggest something like a link header that says { <> memberType :someType . } e.g. { <> memberType :Bug }
09:33:24 [JohnArwe]
09:33:26 [Ashok]
09:33:40 [SteveS]
thinks that should just be non-member-properties, not link headers…but this is beyond this issue
09:34:09 [Arnaud]
ack sandro
09:34:46 [roger]
roger has joined #ldp
09:34:47 [roger]
09:35:14 [Arnaud]
ack steves
09:35:25 [rgarcia]
sandro: outside of LDPCs, it would be also for resources to know what can be posted
09:35:52 [rgarcia]
SteveS: Part of the data is RDF and other part is not (e.g., binaries)
09:36:36 [rgarcia]
… we don't need to put that information in the link header, since it is part of the resource
09:36:36 [bblfish]
SteveS: we need mime types and member types.
09:37:11 [rgarcia]
… but this leads us maybe beyond LDP 1.0 (constraints, etc.)
09:37:11 [ericP]
q+ to say that re-using RDF types is not the right granularity for what a server will accept
09:37:46 [Arnaud]
ack john
09:38:16 [rgarcia]
JohnArwe: bblfish, how does your proposal define the semantics of the operation?
09:39:00 [rgarcia]
.. is that a constraint of a hint?
09:39:09 [SteveS]
My suggested layering is: what content-types are accepted on POST, does POST support create, then (beyond LDP 1.0 I believe) IF it is RDF content, what Classes are allowed/expected
09:39:28 [rgarcia]
bblfish: You may have more that one link
09:39:46 [stevebattle4]
09:40:16 [rgarcia]
… what John is proposing would be a closed world assumptiom
09:40:18 [ericP]
09:40:24 [Arnaud]
ack ashok
09:40:30 [rgarcia]
ericP: more than that, a closed protocol assumption
09:40:54 [ericP]
q+ to ask what prob we need to solve in 1.0
09:40:59 [rgarcia]
Ashok: You specify the type, but what about the schema?
09:41:19 [rgarcia]
… you also want to specify the structure
09:41:22 [SteveS]
yes ericP, see my previous post
09:41:52 [Zakim]
09:42:13 [rgarcia]
bblfish: you can add multiple relations
09:42:19 [rgarcia]
JohnArwe: but it gets complicated soon
09:43:58 [rgarcia]
Ashok: it is only useful if you can specify the properties of a type
09:44:45 [rgarcia]
Arnaud: the point is at what level do we specify those restrictions
09:44:57 [Arnaud]
ack roger
09:45:10 [JohnArwe]
Orthogonal background question for Sandro or EricP... in the process of drafting the sorting stuff I noticed that ReSpec's SPARQL-QUERY reference (normative to LDP) points to a document which says at the top "go see 1.1" ... should we be changing that ref now?
09:46:03 [rgarcia]
roger: there will be properties on containers beyond the type of what the container contains
09:46:48 [JohnArwe]
...well need to be careful with "contains" word. to some, means "created by container", to others "in the container's membership"
09:47:31 [JohnArwe]
I think what Roger did was say that implementations might distinguish between the types of members that exist, and the types of new members that create would accept.
09:47:37 [rgarcia]
bblfish: at the end OWL is about sets and this is our case
09:48:47 [rgarcia]
… my proposal allows adding later more specific things so clients can be later more advanced
09:49:01 [Arnaud]
ack steveb
09:49:26 [rgarcia]
stevebattle4: I like in principle bblfish's proposal and I don't think we should go beyond that
09:49:37 [JohnArwe]
your volume is highly variable steveb
09:49:47 [roger]
so 'things inside container' and 'ability to create new ones of those things inside container'.
09:49:55 [ericP]
JohnArwe, ReSpec stuff is handled by a secret band of maintainers who, when prodded, update the table associating short name to a spec name. then we have to do a pull to use that updated ReSpec.
09:49:56 [roger]
... just to summarise a bit John
09:49:57 [rgarcia]
… I don't know a general way that can be useful for validation
09:50:39 [rgarcia]
Arnaud: In September there will be a workshop on RDF validation
09:50:43 [ericP]
-> example of OSLC's language for describing valid input
09:50:58 [JohnArwe]
rdf validation workshop =
09:51:29 [Arnaud]
ack eric
09:51:29 [Zakim]
ericP, you wanted to ask what prob we need to solve in 1.0
09:51:56 [rgarcia]
ericP: is it worth to talk about validation approaches?
09:52:10 [rgarcia]
… but for 1.0 we should not cover this
09:52:47 [rgarcia]
Arnaud: resource shapes is a vocabulary to describe the resources you manage
09:53:14 [mielvds]
I also think this causes deep semantic conflicts. This implies OWL reasoning to accept subclasses with every post, which can be a fraction of RDF validation, which would be able to cover all semantics
09:53:32 [rgarcia]
… in an RDF document
09:54:32 [rgarcia]
Arnaud: Right now we don't have a complete solution for validation, right now we have media types but beyond that we don't have nothing stable
09:55:46 [Zakim]
09:56:12 [rgarcia]
bblfish: at the end anything will be something that defines a set of documents
09:56:31 [rgarcia]
… so we can link to that something
09:56:52 [SteveS]
09:57:30 [rgarcia]
s/anything will be something/the solution will be a language/
09:57:33 [Arnaud]
ack steves
09:58:09 [stevebattle4]
Henry, It may only directly constrain the set of RDF models, and only indirectly the set of documents.
09:58:30 [rgarcia]
SteveS: we can specify the media type, but we cannot force now the specification of types
09:58:32 [JohnArwe]
seems to come down to a small number of questions: (1) do we have consensus to add something about this (at any level) to the existing corpus (if n, done, else) (2) do we have consensus to add something telling clients which media types are accepted for create (regardless of how specified)
09:59:14 [rgarcia]
Arnaud: Can we leave the type declaration for later?
09:59:35 [rgarcia]
… E.g., LDP 1.1
09:59:39 [ericP]
+1 to later
09:59:41 [JohnArwe]
...(if no, done, else) (3) do we have consensus to add that at the HTTP and/or RDF levels (if no, done, else which and then) (4) do we have consensus to add anything more?
10:00:15 [rgarcia]
SteveS: Types and constraints may conflic
10:00:22 [rgarcia]
10:00:48 [JohnArwe]
10:00:56 [rgarcia]
bblfish: But we would be promoting bad behaviour
10:01:01 [JohnArwe]
10:01:16 [rgarcia]
Arnaud: But that's the reason we have the Best Practices document
10:01:35 [krp]
+1 to discouraging misuse of media type in the best practice and guidelines
10:02:39 [Arnaud]
ack john
10:03:18 [ericP]
q+ to say that no tool is going to be able to do anything with an english definition of the type
10:03:29 [SteveS]
I don't see how this encourages abuse of media type, people can do POST today and create media types….how does this encourage it?
10:03:43 [rgarcia]
JohnArwe: Reads aloud the questions written above
10:03:50 [bblfish]
10:05:25 [ericP]
10:06:34 [rgarcia]
sandro: are the use cases for ISSUE-80 compelling?
10:07:09 [stevebattle4]
There is no current use-case in UC&R that covers this.
10:07:10 [rgarcia]
bblfish: it helps the test suite
10:07:56 [rgarcia]
Arnaud: is someone against dealing with the media type question?
10:08:31 [Arnaud]
ack bblfish
10:08:51 [rgarcia]
bblfish: beyond media types we would like to define sets of documents
10:09:24 [rgarcia]
Arnaud: we seem to have a consensus on media types but not on the RDF typing
10:11:28 [JohnArwe]
Revised Proposal: define a new HTTP header Accept-Post whose value is a media type list to communicate which media types the server accepts when creating resources via HTTP POST
10:12:34 [rgarcia]
10:12:35 [SteveS]
10:12:38 [JohnArwe]
...the change vs -80 is removal of -Create suffix
10:12:46 [JohnArwe]
10:12:46 [cody]
10:12:48 [nmihindu]
10:12:51 [stevebattle4]
0 - I'd prefer to define a new RDF property accep-post whose value is....
10:12:59 [krp]
10:13:00 [Ashok]
10:13:04 [ericP]
+1 (though i'm concearned about the loss of -Create)
10:13:10 [stevebattle4]
10:13:14 [bblfish]
10:13:18 [mesteban___]
10:13:31 [nmihindu]
10:14:00 [roger]
10:14:45 [Arnaud]
ack nmihindu
10:16:02 [rgarcia]
nmihindu: going behind this proposal may have risk
10:19:11 [krp]
10:19:25 [rgarcia]
10:19:46 [Arnaud]
ack krp
10:20:14 [ericP]
q+ to ask whether we can drop this requirement and drop the header
10:20:47 [Arnaud]
ack eric
10:20:47 [Zakim]
ericP, you wanted to ask whether we can drop this requirement and drop the header
10:21:21 [rgarcia]
krp: There are different levels of constraints and bblfish proposal could also be implemented with the media type approach
10:21:35 [stevebattle4]
+1 to drop this altogether
10:22:22 [Ashok]
-1 to dropping this
10:23:02 [ericP]
Ashok, what can we do with this header?
10:23:56 [Ashok]
Eric, I worry that the server will get fiilled up with bad data unless we constrain what you can add where
10:24:14 [Arnaud]
ack sandro
10:24:20 [roger]
10:24:45 [rgarcia]
sandro: How are we going to define this header?
10:24:55 [rgarcia]
JohnArwe: We can just put it in our specification
10:25:06 [ericP]
Ashok, we still have that issue with the header. all the header does is say that some endpoint accepts post
10:25:27 [rgarcia]
… and requires approval from a domain expert
10:25:31 [roger]
homework for Henry then is there an ontology for the mime types ?
10:25:50 [Ashok]
Eric, I want it to say what type it accepts
10:25:50 [stevebattle4]
10:25:54 [bblfish]
also if there are problems with documents types as thought of this way.
10:26:04 [nmihindu]
ericP, I think it is more like the reverse of Accept header in a GET for client. But this time server letting the clients know what the server will accept.
10:26:43 [rgarcia]
sandro: This is unrelated to LDP
10:26:59 [stevebattle4]
10:27:12 [rgarcia]
… it is an important thing to have and could be addressed elsewhere
10:27:53 [JohnArwe]
do we need a straw poll on whether or not to STOP AT media type? If anyone is going to -1 that, then we know that no matter which way we attempt to go we're looking at a formal objection, so at that point we might as well look for "near consensus"
10:28:03 [Arnaud]
ack roger
10:28:05 [JohnArwe] is the process for adding new link relations
10:28:21 [stevebattle4]
10:28:35 [Zakim]
10:28:38 [Ashok]
10:28:43 [Zakim]
10:28:45 [rgarcia]
Ashok: it seems that we are just postponing difficult topics
10:29:37 [ericP]
q+ to say that losing this header isn't a great loss; that we aren't giving up on any use cases.
10:29:46 [Arnaud]
ack steveb
10:30:28 [roger]
10:30:34 [rgarcia]
ericP: Adding a new header variable should be the last resort
10:30:45 [stevebattle4]
Yes - that's what I said
10:30:57 [stevebattle4]
Sorry for the sound qaulity
10:31:06 [stevebattle4]
10:31:10 [rgarcia]
10:31:16 [Arnaud]
ack ashok
10:31:27 [rgarcia]
10:31:38 [cody]
cody has joined #ldp
10:32:04 [JohnArwe]
10:32:05 [Arnaud]
ack eric
10:32:05 [Zakim]
ericP, you wanted to say that losing this header isn't a great loss; that we aren't giving up on any use cases.
10:32:54 [rgarcia]
ericP: If we do not add the header we would be ruling some use cases
10:32:55 [Arnaud]
ack roger
10:33:09 [ericP]
s/would be/would not be/
10:33:29 [sandro]
ericP, yes we are. We already had consensus this was a requirement, 20 minutes ago -- and if we hadn't, I'd have given some use cases.
10:34:57 [rgarcia]
roger: we need a strategy as a group regarding all these things
10:35:18 [rgarcia]
… and avoid ad-hoc solutions every time we face this kind of decisions
10:36:45 [sandro]
10:37:46 [rgarcia]
10:37:56 [Arnaud]
ack sandro
10:37:58 [JohnArwe]
Roger: how do things function in your view when the request-uri=R and all the triples in the response (i.e. the state of the resource) have a subject URI of S ?
10:38:18 [mielvds]
Document from 2002
10:38:33 [rgarcia]
sandro: Tim thought of URLs for media types but at the end he concluded that shouldn't be done
10:39:02 [Arnaud]
ack rgarcia
10:39:44 [JohnArwe]
sandro: IETF showed no interest in mapping media types to URIs, not W3C's place to do so.
10:41:56 [ericP]
sandro, i agreed to the requirement 'cause i wanted to make progress, but i'd like to see some use case that gets enabled by accept-post
10:42:47 [bblfish]
<> memberType [ mime "image/*" ] .
10:42:52 [cody]
cody has joined #ldp
10:44:28 [bblfish]
<> memberClass [ mime "image/*" ] .
10:45:48 [mielvds]
They are NOT mutual exclusive btw
10:46:13 [roger]
if you want two words here, one is "accepts" and the other one might be "member"
10:46:13 [sandro]
I think it's a terrible design, to conflate media types and classes of things in the application domain.
10:46:22 [ericP]
q+ to say that we keep using the example of RDF types, e.g. Bugs, when it may be more compelling to use some sort of image type to motivate accept-post:
10:46:25 [sandro]
10:46:38 [Arnaud]
ack eric
10:46:38 [Zakim]
ericP, you wanted to say that we keep using the example of RDF types, e.g. Bugs, when it may be more compelling to use some sort of image type to motivate accept-post:
10:46:51 [sandro]
q+ to say we need to this to move away from Turtle someday.
10:47:26 [bblfish]
<> memberClass [ mime "text/*"; owl:IntersectionOf BugReportDocs ] .
10:47:31 [Arnaud]
ack sandro
10:47:31 [Zakim]
sandro, you wanted to say we need to this to move away from Turtle someday.
10:47:40 [JohnArwe]
FWIW *all* of our current in-the-field implementations where we'd look to use this are RDF/XML only, they will begin to support Turtle only with LDP
10:47:55 [JohnArwe]
...some are already jumping on JSON-LD too
10:48:02 [rgarcia]
sandro: everyone will be using JSON-LD in a year from now
10:48:03 [mielvds]
so accept turtle (or whatever rdf format), which allows you to validate the semantics later. But they need to be in sync
10:48:07 [bblfish]
<> memberClass [ mime "appliction/json+ld*"; owl:IntersectionOf BugReportDocs ] .
10:49:03 [sandro]
s/will be/might be/
10:49:54 [rgarcia]
Arnaud: why mixing transport and application layers?
10:51:29 [JohnArwe]
So here's a OOB idea: the proposed header (accept-post) does exactly as my previous proposal; henry's proposal adds the "create" semantic that "REST people" feel intrudes overly much into HTTP space, so the two together actually solve the full issue.
10:51:35 [sandro]
Also, every web app has a use for this information --- so put it where they can use it.
10:52:04 [JohnArwe]
...the set of POST payloads that result in the create semantic is the intersection of the two media type specs.
10:53:06 [rgarcia]
Arnaud: we can vote again after lunch
10:53:09 [stevebattle4]
I'd still like to drop the use of a http header from the proposal.
10:53:33 [rgarcia]
JohnArwe: explains the idea written above
10:54:17 [sandro]
"worst of both worlds"
10:54:53 [sandro]
sandro: doesn't POST to LDC always mean CREATE?
10:55:05 [sandro]
JohnArwe: No, not necessarily
10:55:07 [JohnArwe]
it's a MAY not a MUST
10:55:18 [rgarcia]
Arnaud: break for lunch
10:55:23 [sandro]
10:55:23 [sandro]
very weird.
10:55:24 [ericP]
POST /pics/puppies HTTP/1.1\nContent-type: application/soap+xml .. not likely to work
10:55:44 [sandro]
well, not-working is different from working-differently.
10:56:11 [ericP]
"working-differently" is usually a bug, no?
10:56:12 [Zakim]
10:57:09 [JohnArwe]
sandro: 5.4 ... 5.4.4 does require post = create for rdf media types.
10:59:31 [Zakim]
10:59:32 [Zakim]
12:03:25 [cody]
cody has joined #ldp
12:03:32 [SteveS]
SteveS has joined #ldp
12:04:12 [roger]
roger has joined #ldp
12:04:37 [Zakim]
12:04:46 [rgarcia]
rgarcia has joined #ldp
12:06:22 [Arnaud]
scribe: roger
12:06:45 [JohnArwe]
JohnArwe has joined #ldp
12:06:49 [roger]
Topic: Issue 80
12:06:55 [JohnArwe]
eric, sandro, we're back
12:07:12 [stevebattle4]
Are we still going to the http headers?
12:07:12 [JohnArwe]
Topic: Issue-80
12:07:19 [stevebattle4]
12:07:23 [JohnArwe]
@steveb, that is the proposal
12:07:40 [bblfish]
bblfish has joined #ldp
12:07:43 [bblfish]
+1 to proposal for Accept-Post
12:07:50 [Ashok]
Ashok has joined #ldp
12:07:56 [nmihindu]
Revised Proposal: define a new HTTP header Accept-Post whose value is a media type list to communicate which media types the server accepts when creating resources via HTTP POST
12:08:11 [stevebattle4]
Sounded to me like Sandro was arguing against headers earlier?
12:08:21 [sandro]
No, I like the headers
12:08:34 [stevebattle4]
Oh - OK
12:08:40 [Arnaud]
this was the proposal: define a new HTTP header Accept-Post whose value is a media type list to communicate which media types the server accepts when creating resources via HTTP POST
12:08:48 [JohnArwe]
miel: w/o create it does not solve the issue
12:08:50 [Zakim]
12:09:01 [Zakim]
12:09:39 [stevebattle4]
0 - I still think new header variables should be a last resort.
12:09:46 [SteveS]
+1 to this proposal, including media types and create semantics
12:10:24 [ericP]
stevebattle4, i was arguing to drop the header 'cause i thought we weren't making progress on it. but i'm now more optimistic
12:13:14 [SteveS]
Accept-Post SHOULD return list of media-types supported on an OPTIONS request
12:14:04 [roger]
Arnaud is concerned that there is mismatch between header name and its semantic.
12:14:59 [JohnArwe]
phone folks: = editor's draft, 5.4.1 and the next few cover the post-create space
12:15:33 [Arnaud]
Resolved: Close Issue-80 by defining a new HTTP header Accept-Post whose value is a media type list to communicate which media types the server accepts when creating resources via HTTP POST
12:16:09 [JohnArwe]
...and ericp/sandro, that draft also has the collation stuff in 5.3.7-5.3.10 (.10 specially on collation) if you want to review that
12:16:15 [roger]
Arnaud: can we now close issue 32 as a consequence ?
12:17:05 [roger]
TODO, need to review the spec and check for potential re-introduced inconsistencies
12:17:26 [roger]
Raul: do we need a new header for PUT now ?
12:17:54 [ericP]
12:18:01 [JohnArwe]
phone folks: there was discussion over lunch that resulted in the question of "do we need an Accept-PUT" header ala Accept-Post for the "put to create" cases
12:19:08 [Ashok]
Ashok has joined #ldp
12:20:00 [roger]
EricP: if you GET something, can we assume that the same media type can be PUTted back ?
12:20:29 [SteveS]
12:20:47 [Arnaud]
ack steves
12:22:26 [Yves]
if Accept-Post/Put is generated server side, then the name is not the irght one, Accept-* is usually generated by the client
12:23:19 [bblfish]
(note: You could not do an Accept-PUT on a non existent resource. )
12:23:44 [roger]
SteveS: the PATCH verb uses the same format, i.e. Accept-Patch
12:23:44 [SteveS]
Yves see so we are following their lead
12:26:36 [roger]
We stick with Accept_Post just because the precedent is already set by Accept-Patch
12:26:37 [JohnArwe]
FWIW ericp, I started from the same place; although the first conv I had with someone was "I allow GET html for RDF resources but the POST must be an RDF media type", I did not find that especially convincing. In most cases I deal with, the product uses a framework like Jena to (de)serialize payloads, so the only net cost is testing.
12:27:05 [roger]
We won't do anything with Accept-Put for now
12:27:23 [roger]
Resolved: Close Issue-32.
12:27:26 [Arnaud]
Proposal: close issue-32, addressed by closing related issues (80, etc.)
12:27:31 [stevebattle4]
12:27:33 [bblfish]
12:27:33 [trackbot]
ISSUE-32 -- How can clients discover that a resource is an LDPR or LDPC, and what features are supported? -- open
12:27:33 [trackbot]
12:27:33 [ericP]
JohnArwe, yeah, i'm not leaning towards one version or the other; i just wanted to record that we were willing to use whatever name was acceptable to the IETF HTTP WG
12:27:35 [SteveS]
12:27:40 [ericP]
12:27:41 [roger]
12:27:43 [krp]
12:27:47 [cody]
12:27:47 [bblfish]
12:27:50 [bblfish]
12:27:51 [mesteban___]
12:27:58 [sandro]
12:28:24 [Arnaud]
Resolved: Close issue-32, addressed by closing related issues (80, etc.)
12:28:28 [rgarcia]
12:29:03 [bblfish]
12:29:03 [trackbot]
ISSUE-17 -- changesets as a recommended PATCH format -- pending review
12:29:03 [trackbot]
12:29:03 [sandro]
12:29:03 [trackbot]
ISSUE-17 -- changesets as a recommended PATCH format -- pending review
12:29:04 [trackbot]
12:29:22 [roger]
Topic: Issue-17
12:29:43 [Ashok]
12:29:48 [sandro]
12:30:08 [Arnaud]
ack ashok
12:30:25 [stevebattle4]
12:31:34 [bblfish]
12:31:42 [SteveS]
12:31:45 [Arnaud]
ack sandro
12:32:04 [sandro]
12:33:01 [SteveS]
I started down the road of defining a patch format in RDF and have limited experience with it
12:33:12 [davidwood]
davidwood has joined #ldp
12:33:28 [roger]
Sandro: blank nodes cause trouble, and none of the mainstream PATCH formats have a good answer
12:33:36 [ericP]
q+ to propose that we use Sandro's draft but say it doesn't cover graphs with bnodes now
12:33:43 [Arnaud]
ack steveb
12:34:12 [bblfish]
It's breaking up
12:34:22 [bblfish]
what did he say?
12:34:24 [stevebattle4]
We could rule that blank nodes are off the table.
12:34:41 [stevebattle4]
We need a recommended format for testing
12:34:44 [bblfish]
12:34:55 [Arnaud]
ack steves
12:34:59 [stevebattle4]
A pragmatic alternative is SPARQL update
12:35:34 [sandro]
Yes, for testing, certainly, stevebattle4
12:35:41 [roger]
how to reference Talis changeset ?
12:35:55 [stevebattle4]
No IP issues
12:36:04 [stevebattle4]
I asked Tom Heath
12:36:49 [bblfish]
12:37:11 [Ashok]
Andy, are you there?
12:37:27 [roger]
SteveS: should not rush it, better to wait and mature a PATCH format (or use something else)
12:37:42 [stevebattle4]
So what about SPARQL update?
12:37:54 [Arnaud]
ack eric
12:37:54 [Zakim]
ericP, you wanted to propose that we use Sandro's draft but say it doesn't cover graphs with bnodes now
12:38:46 [SteveS]
I'm ok with not supporting bnodes in first rev of patch format/model
12:39:34 [roger]
12:39:35 [Arnaud]
ack bblfish
12:39:38 [bblfish]
12:40:13 [roger]
EricP: do we have enough use-cases for which blank nodes are not necessary ?
12:41:41 [SteveS]
12:42:14 [Arnaud]
ack roger
12:42:42 [bblfish]
my argument was why not SPARQL1.1 ? e.g.:
12:43:10 [bblfish]
the answer was it is NP Complete. My answer why not have the server just spend a certain time on the problem then return an answer of failure.
12:43:13 [Arnaud]
ack steves
12:44:23 [roger]
Roger: Mostly I want to PATCH the membershipTriples inside a LDPC. In which case blank nodes are not an issue here.
12:45:12 [roger]
SteveS has some blank node requirements ...
12:45:15 [bblfish]
SteveS is speaking about
12:46:43 [Ashok]
12:47:11 [Arnaud]
ack ashok
12:48:29 [Arnaud]
PROPOSAL: Close Issue-17 and put it on the wish list.
12:49:04 [mesteban___]
12:49:09 [sandro]
+1 happy to work on this outside of the LDP Rec Track
12:49:30 [roger]
12:49:56 [Ashok]
12:50:00 [SteveS]
12:50:02 [roger]
Ashok, put a note into the deployment guide, list options, etc ...
12:50:06 [roger]
12:50:26 [ericP]
12:50:28 [stevebattle4]
12:50:49 [Arnaud]
Resolved: Close Issue-17 and put it on the wish list.
12:53:03 [roger]
I added a placeholder on the wishlist ...
12:54:05 [bblfish]
12:54:16 [roger]
Topic: Issue 79
12:54:23 [bblfish]
12:54:23 [trackbot]
ISSUE-79 -- ldp:contains -- open
12:54:23 [trackbot]
12:56:17 [nmihindu]
12:58:21 [mielvds]
This not issue 79 btw, we can make the discussion clearer by first resolving it (i.e. changing rdfs:member by ldp:contains)
13:01:27 [nmihindu]
13:01:30 [Arnaud]
ack nmihindu
13:01:56 [sandro]
13:02:22 [sandro]
Arnaud, which issue are we supposed to be talking about right now?
13:03:27 [sandro]
13:04:51 [bblfish]
13:06:32 [Arnaud]
ack bblfish
13:07:48 [roger]
Arnaud: without a default membershipPredicate, there is a implication for issue-79.
13:14:07 [ericP]
q+ to ask what use cases ldp:contains enables and whether we're compelled by them
13:14:52 [roger]
John: .. to Henry - what does the 'contains' relation really imply ? if it created with POST, or linked with PATCH ... in both cases, does this mean 'contains' ?
13:16:49 [stevebattle4]
(At risk of opening wormcans) ldp:contains _could_ mean LDP Resources that are actually contained regardless of how the containment came about.
13:17:32 [JohnArwe]
Discussion of proposal formulation... what is current, what is still ambiguous, what overlaps with other issues
13:18:05 [JohnArwe]
Henry: ok will remove contains and all the membership issues, of very limited use IMO.
13:18:58 [ericP]
13:18:58 [Arnaud]
ack eric
13:19:15 [cody]
13:19:41 [JohnArwe]
sandro: cannot ever be perfect. can only make a reasonable effort to get a decent solution.
13:21:00 [JohnArwe]
animated discussion of "good enough" vs "perfect" trade-offs
13:21:33 [stevebattle4]
I agree (technically) with Henry. We still confuse Containment and aggregation (sorry).
13:21:58 [Ashok]
13:22:22 [Arnaud]
ack ashok
13:23:05 [ericP]
stevebattle4, i think we fell back to a semantics where we specifically don't make the distinction
13:24:13 [ericP]
that's not the same as confusing them, it's simply that we didn't find sufficient achievable use cases for the additional bookkeeping of separating them
13:24:40 [JohnArwe]
13:25:31 [Arnaud]
ack john
13:27:38 [roger]
13:27:51 [Ashok]
13:28:55 [Arnaud]
ack roger
13:31:38 [Arnaud]
ack ashok
13:32:58 [Zakim]
13:36:51 [ericP]
there are a *huge* number of management issues that come up when we go down this route.
13:37:22 [JohnArwe]
@ericp, which 'route', contains?
13:38:17 [ericP]
discussions of membership and deletability and LDPR references to 1/some/all LDPCs
13:40:27 [ericP]
for instance, i don't think that ldp:created is nearly as useful as ldp:managesN where N is some set of POST/PUT/DELETE operations on the resource that reflect back on the container
13:41:47 [Zakim]
13:47:05 [stevebattle4]
I need to drop out for an hour or so, my current position is +1 on Henry's proposal.
13:47:10 [Zakim]
13:51:59 [rgarcia]
rgarcia has joined #ldp
13:56:38 [TallTed]
TallTed has joined #ldp
13:56:53 [rgarcia]
rgarcia has joined #ldp
13:57:59 [SteveS]
SteveS has joined #ldp
13:58:53 [Arnaud]
13:59:22 [rgarcia]
Offtopic: Here you have the ticket from yesterday's dinner:
14:01:30 [cody]
cody has joined #ldp
14:01:33 [Zakim]
14:01:42 [cody]
Arnaud: We have a resolution on how we close 59.
14:02:55 [cody]
Ashok: Could we agree on option B today? (Arnaud's option B).
14:04:17 [ericP]
q+ to say that i don't think that the extra ldp:created is as useful as a reference to some management profile
14:04:37 [Arnaud]
one possibility: add that on creating a new member resource using POST, LDP servers SHOULD add a triple a la : <> ldp:contains <newly_created_resource>
14:04:59 [Arnaud]
possibly changing ldp:contains to ldp:created
14:05:06 [cody]
Henry: the contains takes into account the deletion semantics
14:05:06 [Arnaud]
ack eric
14:05:06 [Zakim]
ericP, you wanted to say that i don't think that the extra ldp:created is as useful as a reference to some management profile
14:05:47 [Ashok]
14:06:21 [cody]
ericP: I don't think ldl:created or ldl:contains (whatever) is useful, because it will just be used as a proxy. The fact that it was created is a poor proxy for a management profile. You can't say that this is a different delete semantics than we had.
14:06:22 [Arnaud]
ack ashok
14:06:45 [bhyland]
bhyland has joined #ldp
14:07:02 [cody]
Ashok: Can we agree ONLY on adding the extra relation
14:07:15 [cody]
… we can then speak of MAY or SHOULD.
14:07:32 [cody]
ericP: can we at least see a use case?
14:08:28 [cody]
Henry: it's like Atom entry relation.
14:09:34 [SteveS]
14:09:45 [cody]
Henry: One thing - you'd like to have on a container, when you create a resource you want browsers to have at least one relation they can rely on (without necessarily having to wait on the whole stream of relations).
14:09:48 [Arnaud]
ack steves
14:11:54 [roger]
roger has joined #ldp
14:11:59 [cody]
ericP: this is not membership; this is specifically that the resource was created by the container
14:12:04 [cody]
all: yes!
14:13:42 [cody]
ericP: by itself, the fact that you created something is not actionable
14:13:53 [cody]
… you have to add delete semantics.
14:14:17 [cody]
… I think this actually only stands to confuse the issue that people are actually going to want to solve.
14:14:48 [cody]
Henry: This is just naming the relation, declaratively.
14:15:00 [cody]
ericP: so can we name it appropriately?
14:15:28 [cody]
Arnaud: the proposal was ldpCreated
14:15:37 [cody]
ericP: but it has no actionable semantics
14:15:55 [cody]
Henry: Its saying that if you delete it, you remove the relation
14:16:13 [cody]
ericP: the spec already says that, so that doesn't really add anything
14:17:56 [cody]
ericP: My real concern here is that we don't have any real actionable semantics here.
14:18:44 [Ashok]
14:19:01 [cody]
Henry: I say ldpContains (what is created in this container and still not deleted.)
14:19:05 [Arnaud]
ack ashok
14:19:26 [cody]
Ashok: If we were to ask that we agree on this, would you vote against this?
14:19:36 [cody]
ericP: No. I won't stand in the way.
14:20:06 [Arnaud]
PROPOSAL: add that on creating a new member resource using POST, LDP servers SHOULD add a triple a la : <> ldp:created <newly_created_resource>
14:20:47 [cody]
Henry: I prefer ldp:contains
14:21:59 [bblfish]
and you would remove the triple, if it the resource is deleted
14:22:51 [cody]
Ashok: You don't have to have both member and contains; contains implies member.
14:23:25 [SteveS]
I wonder if this can be solved with some existing vocabulary but not finding it in
14:24:11 [cody]
Arnaud: you have 2 triples for every attachment that was created through the container (referring to the scratch work in the PiratePad document)
14:24:53 [JohnArwe]
+1 concept/MAY, hard to swallow a SHOULD (given the 2119 meaning of SHOULD) on this
14:25:24 [rgarcia]
JohnArwe, yes, I was also wondering about the SHOULD
14:25:50 [cody]
… it gives the client a bit more information about how these things came to life. But there is a cost of extra triples.
14:26:22 [cody]
… The spec says that if you delete attachment 3, the membership triple will be removed.
14:26:47 [SteveS]
+0 prefer MAY
14:28:03 [cody]
Arnaud: So there is the possibility to change the proposal from SHOUL to MAY
14:28:15 [ericP]
14:28:16 [cody]
Raul: Why MAY? I would say MUST.
14:28:56 [cody]
Arnaud: I guess there is a nonmonicity issue there that I think ericP was touching on before.
14:29:22 [cody]
JohnArway: In RDF the absence of knowledge is different than saying 'not something'
14:29:55 [cody]
Arnaud: I don't think trying to turn it into a MUST is going to fly (given current opinions across team)
14:30:09 [cody]
… we can make it a proposal...
14:30:16 [Arnaud]
PROPOSAL: A) add that on creating a new member resource using POST, LDP servers SHOULD add a triple a la : <> ldp:created <newly_created_resource> B) s/SHOULD/MAY/
14:30:42 [Ashok]
14:30:48 [SteveS]
A +0 B +0.1
14:30:49 [bblfish]
A: +1 B: +0.5
14:31:06 [mesteban___]
A +0.5 B -0.5
14:31:12 [rgarcia]
A: -0, B: -0.5
14:31:17 [Ashok]
A +1, B+0
14:31:33 [nmihindu]
A: +0.5 B: +0
14:31:42 [JohnArwe]
A: -0, +1
14:31:52 [krp]
A: +1, B: +1
14:32:43 [mielvds]
A: +0 B: +0.5
14:32:51 [roger]
A: -0.5, B: +1
14:32:59 [ericP]
A: -0 B: -0
14:33:55 [cody]
14:34:14 [ericP]
i see B down by 1.9 after cody's vote
14:35:54 [JohnArwe]
I get A=4.5, B=5 ericp. hmmm.
14:36:27 [cody]
Arnaud: The group is clearly divided.
14:36:42 [cody]
JohnArway: It's not clear consensus.
14:37:00 [cody]
Arnaud: I think we should make it a MAY if Henry is satisfied with that.
14:37:09 [cody]
Henry: That's fine with me.
14:37:25 [cody]
Arnaud: Sorry Raul, but...
14:37:29 [Arnaud]
Resolve: add that on creating a new member resource using POST, LDP servers MAY add a triple a la : <> ldp:created <newly_created_resource>
14:37:34 [JohnArwe]
14:37:42 [Arnaud]
Resolved: add that on creating a new member resource using POST, LDP servers MAY add a triple a la : <> ldp:created <newly_created_resource>
14:37:46 [ericP]
JohnArwe, were you counting "<SteveS> A +0 B +0.1" as +1 for B?
14:38:07 [ericP]
'cause i now get 4.5/4.1
14:39:03 [cody]
Arnaud: I think we should close issue 79.
14:39:09 [JohnArwe]
@ericp no I have 0.1. but I guess water under the bridge
14:39:18 [JohnArwe]
close issue-79
14:39:19 [trackbot]
Closed ISSUE-79 ldp:contains.
14:39:41 [JohnArwe]
re-open issue-79
14:40:48 [cody]
Henry: If you look at issue 79, an LDPR that was created by a container could say, "this container created me"
14:41:04 [cody]
Raul: Why not create an inverse property for that?
14:41:09 [Arnaud]
Resolved: Closed Issue-79, by adding that on creating a new member resource using POST, LDP servers MAY add a triple a la : <> ldp:created <newly_created_resource>
14:41:54 [cody]
Arnaud: Is 73 still relevant?
14:42:03 [AndyS]
AndyS has joined #ldp
14:42:31 [cody]
… This renders 73 irrelevant and thereby we close 73. I want to minute that. Is that OK with you, Henry?
14:42:50 [Arnaud]
Resolved: Closed Issue-73, rendered irrelevant by resolution of Issue-79
14:43:24 [bblfish]
[[5.6.1 When a LDPC member resource originally created by the LDPC (for example, one whose representation was HTTP POST'd to the LDPC and then referenced by a membership triple) is deleted, and the LDPC server is aware of the member's deletion (for example, the member is managed by the same server), the LDPC server must also remove it from the LDPC by removing the corresponding membership triple.]]
14:43:56 [cody]
Henry… and removing the corresponding ldl:created
14:44:06 [cody]
… can we add that to that statement?
14:44:08 [bblfish]
add to that [[ remove the ldp:created also ]]
14:44:27 [JohnArwe]
14:44:58 [cody]
Arnaud: Two more issues in the seventies: 71, 72, 78 (all related)
14:45:10 [JohnArwe]
basically editors need to think about ldp:contains implications whereever membership triples are managed today
14:46:13 [Arnaud]
topic: Issue-77
14:46:27 [SteveS]
14:46:51 [bblfish]
14:46:53 [bblfish]
14:46:55 [Arnaud]
ack steves
14:47:11 [JohnArwe]
roger: is this about 4.1.6, vs 4.1.5?
14:47:56 [Arnaud]
ack bblfish
14:48:08 [cody]
SteveS: (Use cases that motivated this)
14:49:43 [cody]
Henry: Inferencing level 0 (a client should be able to follow links without creating any new links and get the minimal function-functionality)
14:49:45 [rgarcia]
14:49:56 [Arnaud]
ack rgarcia
14:50:13 [bblfish]
+1 agree in any case with Issue-77
14:50:31 [cody]
Raul: I think we can remove this part.
14:50:55 [cody]
Arnaud: But we could turn the MUST in to a SHOULD (another option) or move it to the LDP Best Practices and Guidelines
14:51:01 [roger]
14:51:15 [Arnaud]
ack roger
14:51:22 [cody]
Raul: I would prefer to move it outside and deal with the whole problem of type representation and type validation...
14:52:11 [cody]
Roger: LDPC definition is really good. LDPR says go this section. Thought you could be more concise with that definition in LDPR like we've done with LDPC.
14:52:44 [cody]
JohnArwe: A lot of what were talking about in the LDPR is about LDP servers.
14:53:27 [Arnaud]
PROPOSAL: Close Issue-77, remove section 4.1.5 and add the recommendation to the best practices doc
14:53:54 [mesteban___]
14:53:58 [rgarcia]
14:53:59 [nmihindu]
14:54:01 [cody]
Roger: Cody, can you propose a concise definition for LDPR like you did for LDPC?
14:54:18 [roger]
14:54:23 [cody]
14:54:28 [SteveS]
14:54:35 [JohnArwe]
14:54:41 [krp]
14:55:59 [cody]
Henry: Issue with the title of the issue
14:56:50 [Arnaud]
Resolved: Close Issue-77, remove section 4.1.5 and add it as a SHOULD to the best practices doc
14:56:55 [cody]
Arnaud: I had suggested another title here; I think its better to be more assertive about the problem.
14:57:47 [cody]
Raul: Isn't everything in the Best Practices a SHOUL by implication?
14:57:51 [cody]
Arnaud: right
14:58:09 [nmihindu]
14:58:09 [cody]
14:59:20 [cody]
topic: ISSUE-72
14:59:26 [bblfish]
14:59:26 [trackbot]
ISSUE-72 -- The object of a membership triple isn't always the address of the created informational resource -- open
14:59:26 [trackbot]
14:59:55 [AndyS]
AndyS has left #ldp
15:00:44 [cody]
Arnaud: There was an email where you guys were talking about this… I think it puts the finger on it.
15:00:51 [bblfish]
But this is compatible with it being possible for non-reasoning clients ( ISSUE-78 ) to read LDPCs and work out what the ldpc's members are ( ISSUE-73 (rdf:member) and ISSUE-79 (ldp:contains)), without needing to do that reasoning. Ie: it would be better to list the ldp:members in LDPCs clearly, and have the reasoning be there to tell clients what the effect of POSTing a new resource will be: create a new relation ( and if possible do this declaratively ). Curre[CUT]
15:00:51 [bblfish]
is the opposite that is happening: reasoning is required to tell what the members of an ldpc is.
15:00:55 [cody]
SteveS: That email is 6 layers deep and 200 pages long
15:01:00 [bblfish]
~~~~POST /ldpc/ HTTP/1.1 ~~~~~~~~~~
15:01:01 [bblfish]
<otherbug#bug> beatle:relatesTo <> .
15:01:03 [bblfish]
<> a beatle:BugReport;
15:01:04 [bblfish]
dc:title "Another silly bug";
15:01:05 [bblfish]
dc:author </joe#me> ;
15:01:06 [bblfish]
15:01:07 [bblfish]
15:02:45 [JohnArwe]
15:03:38 [cody]
Ignore IRC posted example - move this to the PiratePad link above.
15:05:38 [nmihindu]
this email also might be helpful -
15:05:53 [cody]
15:07:08 [cody]
Henry: You are kind of forcing your users to relate things only to documents (instead of say - just things). You'd be forcing everyone to create a certain type of data structure where objects of relation would only be a certain type of informational resource (unacceptable).
15:07:53 [cody]
Arnaud: The point Roger is making, is that he doesn't want the document to be the member, but to be in the object position of the membership triple
15:08:22 [cody]
Henry: You can logically have this relation, but not by posting to a container.
15:13:51 [cody]
Henry: When we post something, why don't we add the links to the other resources ...
15:14:55 [cody]
Roger: The posted document has this sort of relative URL inside. You're kind of absolutizing the identity of the LDPR.
15:15:13 [cody]
… seems a bit weird.
15:16:23 [cody]
JohnArwe: primaryTopic might be a a particular option for filling gap, but there would certainly be others.
15:16:47 [cody]
Roger: ldp:primaryTopic?
15:17:44 [cody]
nmihindu: foaf:primaryTopic could cause problems with existing data and not having necessaystinction in context of LDP
15:17:56 [SteveS]
15:19:14 [cody]
Arnaud: there is a big difference between membershipObject and primaryTopic, right?
15:20:05 [cody]
s/necessaystinction/necessary distinction
15:20:13 [Arnaud]
ack steves
15:23:17 [rgarcia]
15:25:28 [cody]
Arnaud: I actually don't relying on foaf:primaryTopic is right for the spec
15:26:53 [cody]
Miel: Added:
15:26:54 [cody]
<> a ldp:Container;
15:26:55 [cody]
rdfs:member <pets> .
15:26:56 [cody]
<pets> a ldp:Container;
15:26:57 [cody]
ldp:membershipPredicate foaf:primaryTopic;
15:26:58 [cody]
ldp:membershipSubject </people/roger> .
15:28:05 [cody]
Arnaud: Not sure how that achieves the relation Roger wanted.
15:31:13 [cody]
Henry: You need to put owl:sameAs
15:35:44 [cody]
Team is sorting out (trying to word) proposal on all just discussed on ISSUE-72 in the pad doc.
15:40:33 [Arnaud]
PROPOSAL: Close Issue-72, add ldp:membershipObject to allow overriding the object of the membership triple that gets added when the container creates a new member.
15:40:48 [bblfish]
ldp:membershipObject rdfs:Property;
15:40:49 [bblfish]
rdfs:domain ldp:Container;
15:40:50 [bblfish]
rdfs:range [ a rdf:Property;
15:40:51 [bblfish]
rdfs:domain ldp:Resource ] .
15:42:44 [cody]
JohnArwe amended ¨… creates a new member. LDP constrains the behavior only in the case where the input document contains 0:1 triples whose predicate p is the ldp:membershipObject 's object."
15:42:49 [Arnaud]
PROPOSAL:  Close Issue-72, add ldp:membershipObject to allow overriding the object of the membership triple that gets added when the container creates a new member.  LDP constrains the behavior only in the case where the input document contains 0:1 triples whose predicate p is the  ldp:membershipObject 's object.
15:43:30 [cody]
JohnArwe: Were going to need examples in the primer for this too.
15:46:01 [cody]
Arnaud: The vote, please:
15:46:09 [SteveS]
15:46:15 [Ashok]
15:46:17 [cody]
+0 (ignorance on this)
15:46:19 [mielvds]
15:46:22 [JohnArwe]
15:46:25 [nmihindu]
15:46:31 [roger]
15:46:42 [krp]
15:46:50 [bblfish]
Arnaud said: if people have better ideas please propose them later. Vote if you think this is good enough compared to the current competition.
15:46:52 [bblfish]
15:47:01 [ericP]
15:47:03 [mesteban___]
15:47:12 [rgarcia]
+0.5 (don't like the name of the property)
15:47:42 [Arnaud]
Resolved: Close Issue-72, add ldp:membershipObject to allow overriding the object of the membership triple that gets added when the container creates a new member.  LDP constrains the behavior only in the case where the input document contains 0:1 triples whose predicate p is the  ldp:membershipObject 's object.
15:48:37 [cody]
Arnaud: It is a quarter to 6:00. We've made good progress. Big issues have been addressed. Looking at the list of issues now… We have 78 and 71 (71 being the master)...
15:50:03 [cody]
… (issues remaining, that is)
15:50:21 [cody]
SteveS: I have an easy issue; I submitted a proposal for 66.
15:50:50 [cody]
Arnaud: Also 68. Either one.
15:51:17 [cody]
topic: ISSUE-68
15:51:18 [cody]
15:51:49 [cody]
Ashok: Close it. Because the number of items you want will depend on your client.
15:52:59 [cody]
… the exact number will depend on what the client, user agent is, and what the server thinks that the capabilities of the client is. The point is that the server doesn't know enough.
15:53:29 [cody]
SteveS: You can parse the content and learn the number of resources. So, including it is just possibly going to be duplicate and wrong information.
15:53:46 [cody]
Arnaud: I think Steve Battle raised this question. He's not on.
15:54:09 [cody]
… I already sent an email saying this is at risk. There is no concrete proposal.
15:55:07 [cody]
JohnArwe: too much variability
15:56:33 [Arnaud]
PROPOSAL: Close Issue-68, doing nothing. The page size can change from one page to another based on the application logic.
15:56:37 [SteveS]
15:56:38 [cody]
15:56:50 [rgarcia]
15:56:51 [krp]
15:56:53 [mielvds]
15:56:53 [nmihindu]
15:56:55 [mesteban___]
15:56:55 [mielvds]
15:56:56 [roger]
15:57:07 [Arnaud]
Resolved: Close Issue-68, doing nothing. The page size can change from one page to another based on the application logic.
15:57:21 [cody]
topic: ISSUE-66
15:57:34 [cody]
15:57:59 [cody]
Arnaud: We left this open yesterday with an action item on SteveS to come up with a proposal.
15:58:16 [cody]
SteveS: I posted the proposal on the mailing list.
16:00:55 [bblfish]
sounds reasonable to me
16:01:08 [cody]
… The essence of this robust pagination issue was really about how when you navigate down pages, how do you know when the thing your paging over has changed out from underneath you. One thought was that we stick some header in. So, this optimization is that whenever I am fetching each page, some info will come back about when the resource was last modified. I'm suggesting some non-member property e-tag.
16:02:10 [cody]
Arnaud: Let's wait so that we can respond and debate with eric, who has taken issue to this.
16:02:24 [ericP]
erik, i presume
16:02:33 [JohnArwe]
16:02:44 [JohnArwe]
16:04:15 [rgarcia]
16:04:34 [rgarcia]
this contains the instances
16:04:44 [rgarcia]
and this the classes
16:04:44 [rgarcia]
16:09:04 [cody]
Arnaud: This is again an optimization. Were trying to give the client a shortcut.
16:09:32 [cody]
Kevin: But its several round-trips for the client if we leave it out; not just one.
16:10:15 [cody]
Arnaud: Let's leave it until tomorrow. But let's remember that we can always consider leaving it out of the spec for this round.
16:11:08 [cody]
Arnaud: Adjourning for the day.
16:11:15 [mielvds]
mielvds has left #ldp
16:11:22 [Zakim]
16:12:57 [Zakim]
16:12:58 [Zakim]
SW_LDP(F2F)2:30AM has ended
16:12:58 [Zakim]
Attendees were m, ericP, Sandro, SteveBattle
16:53:36 [betehess]
betehess has joined #ldp
17:02:43 [mesteban___]
mesteban___ has joined #ldp
17:17:30 [gavinc]
gavinc has joined #ldp
17:25:19 [roger]
roger has joined #ldp
17:29:18 [Zakim]
Zakim has left #ldp
17:35:38 [Arnaud]
Arnaud has joined #ldp
17:41:04 [krp]
krp has joined #ldp
18:10:56 [cody]
cody has joined #ldp
18:45:59 [cody]
cody has joined #ldp
20:45:13 [Arnaud1]
Arnaud1 has joined #ldp
21:13:46 [roger]
roger has joined #ldp
21:41:54 [jmvanel]
jmvanel has joined #ldp
23:41:52 [Arnaud]
Arnaud has joined #ldp