IRC log of ldp on 2014-01-06
Timestamps are in UTC.
- 14:59:56 [RRSAgent]
- RRSAgent has joined #ldp
- 14:59:56 [RRSAgent]
- logging to http://www.w3.org/2014/01/06-ldp-irc
- 14:59:58 [trackbot]
- RRSAgent, make logs public
- 14:59:58 [Zakim]
- Zakim has joined #ldp
- 15:00:00 [trackbot]
- Zakim, this will be LDP
- 15:00:00 [Zakim]
- ok, trackbot, I see SW_LDP()10:00AM already started
- 15:00:01 [trackbot]
- Meeting: Linked Data Platform (LDP) Working Group Teleconference
- 15:00:01 [trackbot]
- Date: 06 January 2014
- 15:00:06 [Zakim]
- +??P5
- 15:00:09 [Zakim]
- +Ashok_Malhotra
- 15:00:14 [pchampin]
- zakim, ??P5 is me
- 15:00:15 [Zakim]
- +pchampin; got it
- 15:01:00 [Zakim]
- +Arnaud
- 15:01:18 [Zakim]
- +[IBM]
- 15:01:31 [SteveS]
- Zakim, [IBM] is me
- 15:01:31 [Zakim]
- +SteveS; got it
- 15:02:37 [Zakim]
- +Roger
- 15:02:44 [Zakim]
- +Alexandre
- 15:02:44 [roger]
- roger has joined #ldp
- 15:02:55 [Zakim]
- +JohnArwe
- 15:02:56 [JohnArwe]
- JohnArwe has joined #ldp
- 15:03:05 [Zakim]
- -Alexandre
- 15:03:07 [Zakim]
- +OpenLink_Software
- 15:03:13 [TallTed]
- Zakim, OpenLink_Software is temporarily me
- 15:03:13 [Zakim]
- +TallTed; got it
- 15:03:15 [TallTed]
- Zakim, mute me
- 15:03:15 [Zakim]
- TallTed should now be muted
- 15:03:19 [JohnArwe]
- almighty zakim seems tired today
- 15:03:26 [JohnArwe]
- I hear nothing
- 15:03:35 [JohnArwe]
- now I hear Arnaud
- 15:03:48 [JohnArwe]
- question is, which state is preferred ;-)
- 15:04:15 [Arnaud]
- zakim, who's on the phone?
- 15:04:15 [Zakim]
- On the phone I see +1.214.537.aaaa, Sandro, pchampin, Ashok_Malhotra, Arnaud, SteveS, Roger, JohnArwe, TallTed (muted)
- 15:04:17 [Zakim]
- +Alexandre
- 15:04:27 [codyburleson]
- +Cody
- 15:04:31 [bblfish_]
- bblfish_ has joined #ldp
- 15:04:47 [codyburleson]
- Cody here; dunno how to add to Zakim
- 15:05:41 [Zakim]
- +bblfish
- 15:05:42 [Zakim]
- -Alexandre
- 15:05:56 [bblfish_]
- hi
- 15:07:05 [bblfish_]
- ah yes, Sebastien also had an issue with his little laptop. I think it's a Galaxy S4 too - that's the one that comes with Linux pre-installed right?
- 15:07:09 [Arnaud]
- zakim, who's on the phone?
- 15:07:09 [Zakim]
- On the phone I see +1.214.537.aaaa, Sandro, pchampin, Ashok_Malhotra, Arnaud, SteveS, Roger, JohnArwe, TallTed (muted), bblfish
- 15:07:47 [Arnaud]
- zakim, aaaa is cody
- 15:07:49 [Zakim]
- +cody; got it
- 15:08:35 [JohnArwe]
- Scribe: JohnArwe
- 15:08:43 [betehess]
- also, I'm deeply sorry towards JohnArwe, couldn't/didn't take time to answer http://lists.w3.org/Archives/Public/public-ldp-wg/2013Dec/0076.html ...
- 15:09:07 [JohnArwe]
- Topic: approve Dec 16 minutes
- 15:09:59 [JohnArwe]
- Resolution: Dec 16 minutes approved without objection
- 15:10:09 [Arnaud]
- http://www.w3.org/2013/meeting/ldp/2013-12-16
- 15:10:15 [JohnArwe]
- Topic: Actions
- 15:10:40 [Zakim]
- +Alexandre
- 15:10:45 [JohnArwe]
- Next meeting Mon next week, resuming weekly, 90 minutes until we get to LC 2
- 15:12:41 [JohnArwe]
- http://www.w3.org/2012/ldp/track/actions/122 see note
- 15:13:22 [JohnArwe]
- http://www.w3.org/2012/ldp/track/actions/119 was pretty simple
- 15:14:51 [JohnArwe]
- Resolution: Arnaud will close the 2 actions above
- 15:15:04 [JohnArwe]
- Cody: I closed one on Best Practices
- 15:15:20 [JohnArwe]
- Arnaud: hope to get spec done soon and turn full attn to other docs
- 15:15:24 [JohnArwe]
- Topic: Paging
- 15:16:35 [JohnArwe]
- TimBL responded to our response to his LC comments, he thinks the 200 solution "there be dragons"
- 15:16:48 [JohnArwe]
- TimBL email at http://lists.w3.org/Archives/Public/public-ldp-comments/2013Dec/0000.html
- 15:18:42 [Ashok]
- q+
- 15:19:42 [JohnArwe]
- Arnaud summarizes options/history, convergence issues if we define at w3c now and run it in ietf later.
- 15:19:50 [Arnaud]
- ack Ashok
- 15:20:24 [JohnArwe]
- Ashok: if we defined 209 would help other wgs too. could we work with anyone from those other wgs to move this along?
- 15:20:40 [SteveS]
- FYI, not exactly what we are talking about but found this TAG-57 http://www.w3.org/2001/tag/awwsw/issue57/20120202/#status-code
- 15:22:18 [JohnArwe]
- Arnaud: anyone could use this, that's one reason TimBL thought it a good idea to define (and was hoping we'd finally be the ones to do it, instead of punting to "someone else"). No other natural owner, aside from IETF. TimBL raised it with TAG, initial response before holidays was "why do you need this".
- 15:24:42 [JohnArwe]
- Not asking for a decision today; let TAG discussion proceed for a while. Last we talked in this WG, we seemed mostly ok with reverting to 303 in LDP. Depending on how likely it seems that someone else will take this on, we might choose differently. Obviously we don't want TimBL raising this at LC2.
- 15:24:55 [JohnArwe]
- Topic: issue-92
- 15:25:24 [JohnArwe]
- issue-92?
- 15:25:24 [trackbot]
- issue-92 -- Change rel=type to rel=profile for client introspection of interaction model -- raised
- 15:25:24 [trackbot]
- http://www.w3.org/2012/ldp/track/issues/92
- 15:26:47 [SteveS]
- FYI URLs in Data recommends rel=profile for document properties used within data http://www.w3.org/TR/urls-in-data/#locating-property-documentation
- 15:26:50 [JohnArwe]
- profile is defined in RFC 6906 at http://tools.ietf.org/html/rfc6906#section-3.1
- 15:27:25 [bblfish_]
- q+
- 15:27:33 [SteveS]
- q+
- 15:27:44 [Arnaud]
- ack bblfish
- 15:28:57 [JohnArwe]
- bblfish: disagrees with the argument that type is wrong
- 15:29:18 [JohnArwe]
- ...just now sent email to list
- 15:29:39 [Arnaud]
- ack SteveS
- 15:30:10 [JohnArwe]
- I can tell you Henry that I round-tripped with Erik W (the RFC author) and he thought using profile this way was reasonable.
- 15:30:49 [betehess]
- was rel=profile deployed in other specs/products?
- 15:30:59 [bblfish]
- profile, seems to be very syntactic http://tools.ietf.org/html/rfc6906#section-3.1
- 15:32:18 [Arnaud]
- http://www.w3.org/2013/meeting/ldp/2013-12-16#Issue_91
- 15:32:32 [JohnArwe]
- @betehess, I don't know of any products that it's deployed in. It's Informational RFC in IETF, which Erik explained is usually what they do now for something that sounds mostly-reasonable but is not currently widely deployed.
- 15:33:02 [betehess]
- makes sense
- 15:33:34 [JohnArwe]
- ... the urls-in-data link SS provided has this, since I know you're not hearing the conv well: 4.4 Locating Property Documentation
- 15:33:34 [JohnArwe]
- The previous sections have discussed how important it is to have documentation that includes information about how URLs used within data should be interpreted and specifically whether properties within the data apply to the content found at a URL or to something that content describes. This documentation should be published somewhere such that it's possible for those developers to find it. Possible routes for doing this explicitly include:
- 15:33:34 [JohnArwe]
- if the data is provided through a protocol that supports it, such as through HTTP, by explicitly indicating the media type of the data, and registering that media type such that documentation can be found for it through the IANA media type registry
- 15:33:35 [JohnArwe]
- if the media type is generic (such as application/json), by providing supplementary documentation through a profile link relationship, for example within a HTTP Link header
- 15:33:35 [JohnArwe]
- embedding links to the documentation within the data itself, for example through a resolvable XML namespace or @xsi:schemaLocation attribute in XML or by using resolvable URLs for classes and properties in RDF
- 15:33:58 [JohnArwe]
- ...those last 3 are bullet points; the doc is a FPWD
- 15:34:18 [Arnaud]
- q?
- 15:34:38 [SteveS]
- +1 for opening
- 15:34:42 [Arnaud]
- PROPOSED: Open ISSUE-92
- 15:34:46 [pchampin]
- +1
- 15:34:47 [bblfish]
- +1 for opening
- 15:34:47 [betehess]
- +1
- 15:34:48 [SteveS]
- +1
- 15:35:09 [roger]
- +1
- 15:35:17 [JohnArwe]
- +1
- 15:35:26 [sandro]
- issue-92?
- 15:35:26 [trackbot]
- issue-92 -- Change rel=type to rel=profile for client introspection of interaction model -- raised
- 15:35:26 [trackbot]
- http://www.w3.org/2012/ldp/track/issues/92
- 15:35:33 [TallTed]
- +1
- 15:35:35 [codyburleson]
- +1
- 15:35:39 [Ashok]
- +1
- 15:36:32 [Arnaud]
- RESOLVED: Open ISSUE-92
- 15:36:49 [JohnArwe]
- Arnaud: do not want to re-open whole discussion of how many headers etc, just what syntax we use to express the semantics we've already agreed to
- 15:36:56 [JohnArwe]
- Topic: Issue-89
- 15:36:59 [JohnArwe]
- issue-89?
- 15:36:59 [trackbot]
- issue-89 -- Tie the interaction model with the LDP data model through the notion of Managed Resources -- open
- 15:36:59 [trackbot]
- http://www.w3.org/2012/ldp/track/issues/89
- 15:37:00 [Zakim]
- +Sandro.a
- 15:37:05 [Zakim]
- -Sandro
- 15:37:17 [Zakim]
- +ericP
- 15:37:34 [JohnArwe]
- (from agenda) PROPOSED: define the containment relationship as proposed by Alexandre Issue-89 Proposal 3
- 15:38:07 [sandro]
- betehess, where are you?
- 15:38:16 [bblfish]
- do you have a normal lnadline phone betehess?
- 15:39:28 [bblfish]
- http://www.w3.org/2012/ldp/wiki/Issue-89
- 15:39:33 [JohnArwe]
- Arnaud: summarizes proposal 3 ... formally define a relationship already in spec today: containment, as ldp:contains
- 15:40:01 [JohnArwe]
- ...summarizes proposal 4
- 15:42:55 [JohnArwe]
- ...notes that proposal 3 implies (for a simplecontainer) no change in # triples (membership=contains), for an indirect container also members!=contains, for direct containers members=contains-set so 2x as many triples which people were not crazy about.
- 15:43:51 [JohnArwe]
- ...summarizes proposal 5, which provides a way to filter out the subset of the links you don't want/like (so in the 2x for direct containers case, clients can get only the subset of the triples that they really want)
- 15:44:33 [JohnArwe]
- Alexandre confirms summary, since he cannot speak (bad connection)
- 15:44:45 [JohnArwe]
- EricP: how does proposal 5 differ from what we have now?
- 15:44:48 [bblfish]
- q+
- 15:44:56 [Arnaud]
- ack bblfish
- 15:45:03 [JohnArwe]
- Arnaud: if we reject 3, 5 is irrelevant
- 15:45:26 [SteveS]
- q+
- 15:45:50 [betehess]
- PROPOSAL 5 is about how to opt-in or opt-out and choose from the following types of triples being returned: membership triples, containment triples, other server-managed triples, inlined triples, application specific triples, etc.
- 15:46:02 [betehess]
- should be adapted depending on the use-cases
- 15:46:47 [JohnArwe]
- bblfish: defining containment should be non-controversial, renaming :created ditto, then rest can be "reliably" discussed once you agree on the terms you're using
- 15:47:12 [Arnaud]
- ack SteveS
- 15:47:20 [JohnArwe]
- henry pls make sure I got all of your thoughts correctly, my parser not quite as fast as your speaking
- 15:48:01 [JohnArwe]
- SteveS: some of wiki content is outside proposal but seems to bear on this, like replacing :member with :contains
- 15:48:09 [betehess]
- right, containement and membership are different things, do not remove membership at all
- 15:49:17 [JohnArwe]
- SteveS: so accepting any of these proposals as currently written would not incorporate (from the wiki) the stmt: replaces ldp:member with ldp:contains to align the containment triples and the membership triples in the case of the SimpleContainer.
- 15:50:17 [JohnArwe]
- @betehess, that phrase was simply placed outside the proposal headers so Steve apparently was unsure if the intent was to incorporate it in one of the them (as a simple reading might imply) or not
- 15:50:54 [JohnArwe]
- @betehess, can you state your intent (on IRC since that's all we have for you)?
- 15:51:41 [betehess]
- JohnArwe, yes, we should align the triples
- 15:51:49 [JohnArwe]
- bblfish: if we used rules/sparql, we could do that in either direction. it shows that the concept is important and belongs in the spec.
- 15:52:08 [JohnArwe]
- ...how we deal with inferencing etc is a separate question.
- 15:53:04 [JohnArwe]
- Arnaud: agree value in clarifying spec. maybe accepting proposal 3 is a first step, since that does not talk about how/if to materialize the concept
- 15:53:07 [JohnArwe]
- q+
- 15:53:12 [Arnaud]
- ack JohnArwe
- 15:53:40 [ericP]
- JohnArwe: i asked of the list: what is the intent of proposal 3?
- 15:53:56 [ericP]
- ... is it to say that they MUST be exposed? MAY be exposed?
- 15:54:28 [betehess]
- those triples must be exposed if they resulted from the LDP interactions, or can be enforced eg. something contained can be DELETEd
- 15:54:29 [JohnArwe]
- @betehess, can you speak to your intent? i.e. answer the questions I posed on the list?
- 15:54:49 [JohnArwe]
- ok so "MUST" is the intent?
- 15:54:54 [betehess]
- yes
- 15:55:02 [bblfish]
- I'd say that to start with whether they get exposed always, should not be an issue.
- 15:55:20 [bblfish]
- The ldp:contains, really helps to write down rules.
- 15:55:32 [SteveS]
- and I say it is, ldp:contains can be inferred
- 15:55:32 [JohnArwe]
- Arnaud: we can separate them. as written, proposal 3 does not force materialization.
- 15:55:39 [betehess]
- you don't know if you can DELETE a member in the general case, for example
- 15:56:12 [JohnArwe]
- Arnaud: first step would be to define and talk about "containment" as a concept, and separate off the materialization aspect
- 15:56:30 [JohnArwe]
- EricP: not convinced there is value in having a name for the concept, but not opposed
- 15:57:12 [JohnArwe]
- Arnaud: could use the sparql queries we used for the discussion, even if not normative. could be appendix/whatever.
- 15:57:51 [bblfish]
- Here I show how one goes from one to the other:
- 15:57:52 [bblfish]
- http://lists.w3.org/Archives/Public/public-ldp-wg/2013Dec/0043.html
- 15:57:57 [TallTed]
- Zakim, unmute me
- 15:57:57 [Zakim]
- TallTed should no longer be muted
- 15:58:05 [JohnArwe]
- Arnaud: anyone disagree that we have been talking about 2 distinct relationships? defer for now which are represented explicitly.
- 15:58:09 [bblfish]
- CONSTRUCT { ?subject ldp:contains ?ldpr }
- 15:58:09 [bblfish]
- WHERE{
- 15:58:09 [bblfish]
- { ?ldpc a ldp:DirectContainer;
- 15:58:11 [bblfish]
- ldp:containerResource ?subject;
- 15:58:13 [bblfish]
- ldp:containsRelation ?predicate.
- 15:58:15 [bblfish]
- ?subject ?predicate ?ldpr.
- 15:58:17 [bblfish]
- }
- 15:58:19 [bblfish]
- UNION
- 15:58:21 [bblfish]
- {
- 15:58:23 [bblfish]
- ?ldpc a ldp:DirectContainer;
- 15:58:25 [bblfish]
- ldp:containerResource ?object;
- 15:58:27 [bblfish]
- ldp:containedByRelation ?predicate.
- 15:58:29 [bblfish]
- ?ldpr ?predicate ?object .
- 15:58:31 [bblfish]
- }
- 15:58:33 [bblfish]
- }
- 15:58:34 [betehess]
- both notions are important, just solve different problems
- 15:58:35 [bblfish]
- CONSTRUCT { ?subjet ?predicate ?object }
- 15:58:37 [bblfish]
- WHERE {
- 15:58:39 [bblfish]
- { ?ldpc a ldp:DirectContainer;
- 15:58:41 [bblfish]
- ldp:containerResource ?subject;
- 15:58:43 [bblfish]
- ldp:containsRelation ?predicate;
- 15:58:45 [bblfish]
- ldp:contains ?ldpr.
- 15:58:47 [bblfish]
- BIND (?ldpr AS ?object)
- 15:58:49 [bblfish]
- }
- 15:58:51 [bblfish]
- UNION
- 15:58:53 [bblfish]
- {
- 15:58:55 [bblfish]
- ?ldpc a ldp:DirectContainer;
- 15:58:57 [bblfish]
- ldp:containerResource ?object;
- 15:58:59 [bblfish]
- ldp:containedByRelation ?predicate;
- 15:59:01 [bblfish]
- ldp:contains ?ldpr.
- 15:59:03 [bblfish]
- BIND (?ldpr AS ?subject)
- 15:59:05 [bblfish]
- }
- 15:59:07 [bblfish]
- }
- 15:59:11 [bblfish]
- one rule to go from membership triples to ldp:contains and the other way.
- 16:00:02 [JohnArwe]
- TallTed: which of the 2 is most important is context-specific. I don't think we can say either is primary. If it's equally easy to transition from one to the other, define both and how to transition.
- 16:00:06 [bblfish]
- Tall Ted that's why we're trying to define ldp:contains :-)
- 16:00:18 [bblfish]
- because ldp:conains is not clearly defined yet.
- 16:00:28 [JohnArwe]
- ...within any WG, you'd never get real consensus if the conditions above apply.
- 16:00:35 [TallTed]
- Zakim, mute me
- 16:00:35 [Zakim]
- TallTed should now be muted
- 16:00:49 [JohnArwe]
- ...real consensus on *this one* being primary, that is
- 16:01:34 [Arnaud]
- PROPOSAL 3: define the containment relationship (whether materialized or not)
- 16:01:48 [codyburleson]
- +1
- 16:01:50 [pchampin]
- +1
- 16:01:53 [betehess]
- +1
- 16:01:53 [bblfish]
- +1
- 16:02:06 [TallTed]
- +1
- 16:02:15 [SteveS]
- +0.5
- 16:02:22 [ericP]
- +0
- 16:02:30 [JohnArwe]
- +0.5 (seems useful in some cases, just not those I'm after, but nothing wrong with it for sure)
- 16:02:42 [roger]
- -0.5 i don't really like where this could end up
- 16:03:10 [Zakim]
- -Roger
- 16:04:03 [Arnaud]
- RESOLVED: define the containment relationship (whether materialized or not)
- 16:04:07 [SteveS]
- roger, perhaps you could -1 whatever thing that might come up in the future that rubs you the wrong way
- 16:04:23 [bblfish]
- And add it to the ontology :-)
- 16:04:25 [Zakim]
- +Roger
- 16:06:42 [JohnArwe]
- Roger: wanted to say something but hit wrong button; understand all this for sure, can see doing it piece by piece, so I should be ok with just this much. I didn't -1 it for that reason. I think what's important is what's returned in the hypermedia to clients, the filesys case is a niche. Complicating spec, harder to understand, can't imagine anyone else wanting to implement it.
- 16:07:36 [Arnaud]
- PROPOSED: replace ldp:created/ldp:memberResource with ldp:contains
- 16:07:38 [codyburleson]
- +1
- 16:07:47 [bblfish]
- +1
- 16:07:51 [SteveS]
- +1
- 16:08:03 [Ashok]
- +1
- 16:08:06 [betehess]
- +1
- 16:08:29 [ericP]
- does contains have any implications re: deletion of the container?
- 16:08:35 [JohnArwe]
- Arnaud: agree there is a slight difference (created-only originally, now contained regardless of how created)
- 16:08:39 [bblfish]
- ( It's not quite the same link but, we don't need the subtlety of ldp:created - I iniitially put ldp:created because I was trying to go for something that would be clearly HTTP based, )
- 16:09:30 [JohnArwe]
- Ericp: if I have a system that allows creating members but deleting the container does not result in the container deleting created-members, does this proposal change that?
- 16:09:45 [TallTed]
- Zakim, unmute me
- 16:09:45 [JohnArwe]
- Arnaud: I think it would
- 16:09:47 [Zakim]
- TallTed should no longer be muted
- 16:10:21 [SteveS]
- +1 to ldp:created with ldp:contains, the ldp:memberResource is a different part and only for ldp:SimpleContainer
- 16:10:24 [bblfish]
- q+
- 16:10:31 [Arnaud]
- ack bblfish
- 16:10:31 [JohnArwe]
- TallTed: membership and containment are 2 different things, that we both need
- 16:10:31 [pchampin]
- q+
- 16:11:14 [pchampin]
- q-
- 16:12:22 [JohnArwe]
- bblfish: same as above I put in IRC. :contains is core of the spec. spec already says that delete has side effects, so if you believe a correspondence exists with membership, this is not a new consequence.
- 16:12:53 [betehess]
- the proposals don't say anything about that, but invariants are the answers: containment means that you have the triples *and* the contained resources, so if you remove the containment triples (DELETE on Container), then you should recursively delete the contained resources
- 16:13:05 [Zakim]
- +[IPcaller]
- 16:13:17 [codyburleson]
- Zakim, IPcaller is me
- 16:13:17 [Zakim]
- +codyburleson; got it
- 16:13:23 [Zakim]
- -cody
- 16:13:30 [betehess]
- DELETE on Container, or even a PATCH to delete the triple I guess :-)
- 16:13:53 [JohnArwe]
- bblfish: I don't think this changes anything for the moment. in my sys, you cannot delete a non-empty container.
- 16:14:05 [betehess]
- I'd say that we ignore that for today, and I can write a proposal for next week
- 16:14:33 [JohnArwe]
- SteveS: actually already covered
- 16:14:46 [JohnArwe]
- ...link coming
- 16:15:12 [codyburleson]
- (I'm now in as codyburleson rather than cody because I switched from cell phone to Skype)
- 16:15:21 [JohnArwe]
- SteveS: 5.6.4 has it
- 16:15:27 [SteveS]
- https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp.html#ldpc-HTTP_DELETE
- 16:16:29 [betehess]
- https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp.html#ldpc-5_6_4
- 16:16:56 [JohnArwe]
- SteveS: on your proposal you listed memberResource; I thought that was only for SimpleContainer
- 16:17:20 [JohnArwe]
- Arnaud: nononononono memberResource is something else
- 16:17:47 [JohnArwe]
- ...link to document, and link to member
- 16:18:13 [JohnArwe]
- Ericp roots for "document" here
- 16:18:23 [roger]
- +1 to memberDocument
- 16:18:36 [JohnArwe]
- Arnaud: containment is all about the documents, membership is not (always)
- 16:19:03 [ericP]
- how about this? containment is about the docs, membership is about RDF nodes
- 16:19:36 [bblfish]
- yes, ldp:contains is relationship between HTTP resources. membership extends outside into the real world
- 16:19:38 [JohnArwe]
- @ericp worth you proofing the draft for this ;-)
- 16:19:55 [ericP]
- oops. roger that
- 16:20:06 [bblfish]
- but since our protocol is about HTTP interactions, it is very important to have the ldp:contains relation
- 16:20:48 [betehess]
- eric's question was about deleting in cascade, wasn't it?
- 16:21:30 [betehess]
- right, you can't do that for members, only for contained resources
- 16:22:14 [roger]
- +q
- 16:22:17 [JohnArwe]
- EricP: in our discussions, not in spec, in containment rel when you delete the container you "must" delete any remaining members. if we're changing that, maybe variations on contained get ugly.
- 16:22:25 [Ashok]
- That's my understanding of Eric's point
- 16:23:03 [JohnArwe]
- bblfish: would the proposed replacement result in some new consequence ?
- 16:23:35 [JohnArwe]
- EricP: hard to tell on the fly, since not all of what we discussed was directly reflected in the spec
- 16:23:39 [betehess]
- where does the spec *today* defines what ericP is talking about?
- 16:24:23 [JohnArwe]
- @betehess, EricP said earlier that this is how we've discussed things, differentiating from what spec says.
- 16:24:33 [JohnArwe]
- ...realizing you still have white noise
- 16:25:19 [JohnArwe]
- TallTed: that is where spec is today, leaves things open because when we discussed earlier we realized that specifying this would require lots of new careful definition that we didn't otherwise need
- 16:25:48 [betehess]
- I disagree with ericP: if the server says that { X ldp:contains Y } then DELETEing X, or even deleting { X ldp:contains Y }, then Y must disappear as well, same than DELETEing Y must remove the triple. They are bound together, it's an invariant
- 16:26:20 [betehess]
- not implementation specific
- 16:26:25 [JohnArwe]
- EricP: we were worried about, if we accepted new reqts/refinements on :contains, we'd either rule out certain use cases or need lots of new definitions
- 16:27:04 [betehess]
- Containment is an invariant managed by the server
- 16:27:22 [JohnArwe]
- bblfish: http delete has to operate on resources with uris. created has to be a subset of contains as the spec is today, so why not simplify and remove the overly-precise one.
- 16:27:56 [JohnArwe]
- EricP: historically we've used "containment" to mean: if you delete a non-empty container, those members must be deleted
- 16:28:08 [JohnArwe]
- TallTed: disagree; we've used 'containment' several ways
- 16:28:54 [JohnArwe]
- EricP: as long as we're not committing to specify deletion of non-empty container... ericp help pls... doesn't limit future
- 16:29:23 [JohnArwe]
- Arnaud: need to be sure of the effects before agreeing to this.
- 16:29:25 [JohnArwe]
- q+
- 16:30:01 [JohnArwe]
- Arnaud: people should look at EricP's case
- 16:30:03 [Arnaud]
- ack roger
- 16:30:17 [JohnArwe]
- Roger: will paste
- 16:30:19 [Arnaud]
- ack john
- 16:30:23 [roger]
- I think if we use "containment" a lot less, and "document" (in conjunction with member) a lot more - then it might be a better
- 16:30:28 [ericP]
- s/... ericp help pls.../, for which we historically used the term "containment"/
- 16:31:28 [JohnArwe]
- JohnArwe: was this incorporated as part of proposal 3 approval? as SteveS noted, not really within its scope: replaces ldp:member with ldp:contains to align the containment triples and the membership triples in the case of the SimpleContainer.
- 16:31:59 [JohnArwe]
- Arnaud: no; we're sticking with proposal 3 strictly as written, so it's a pure add at this point
- 16:32:10 [JohnArwe]
- Ericp: why can't we do that?
- 16:32:20 [JohnArwe]
- Arnaud: the document != member in all cases
- 16:32:29 [JohnArwe]
- EricP: ok
- 16:32:32 [roger]
- +q
- 16:32:54 [Arnaud]
- ack roger
- 16:33:21 [JohnArwe]
- so is ericp's rename proposal to be handled as a new issue?
- 16:33:32 [codyburleson]
- What is a "document"? Do you mean an LDPR? Versus some subset of an entire LDPR?
- 16:33:40 [JohnArwe]
- Roger: document instead of member would be useful to clarify spec.
- 16:33:50 [Arnaud]
- PROPOSED: rename ldp:created with ldp:memberDocument
- 16:34:30 [betehess]
- I don't see the point, as PROPOSAL 4 will rename it as ldp:contains
- 16:34:34 [SteveS]
- and also add 'document' to terminology
- 16:34:49 [JohnArwe]
- @cody: in REST-speak, "document" is a less-scary way of saying "information resource". vs "resource" which can be a document OR a cat/person/concept
- 16:36:17 [Zakim]
- -Ashok_Malhotra
- 16:36:23 [bblfish]
- happy new year
- 16:36:31 [Zakim]
- -TallTed
- 16:36:32 [Zakim]
- -SteveS
- 16:36:33 [Zakim]
- -bblfish
- 16:36:34 [Zakim]
- -Sandro.a
- 16:36:35 [Zakim]
- -Roger
- 16:36:35 [Zakim]
- -Alexandre
- 16:36:36 [Zakim]
- -ericP
- 16:36:37 [codyburleson]
- @JohnArwe - Thanks, got it
- 16:36:38 [JohnArwe]
- Arnaud: at some point we need to make decisions on some time-bounded issues like next F2F
- 16:36:38 [Zakim]
- -Arnaud
- 16:36:38 [Zakim]
- -pchampin
- 16:36:43 [Zakim]
- -JohnArwe
- 16:36:45 [Zakim]
- -codyburleson
- 16:36:47 [Zakim]
- SW_LDP()10:00AM has ended
- 16:36:47 [Zakim]
- Attendees were +1.214.537.aaaa, Sandro, Ashok_Malhotra, pchampin, Arnaud, SteveS, Roger, Alexandre, JohnArwe, TallTed, bblfish, cody, ericP, codyburleson
- 16:51:56 [jmv]
- jmv has joined #ldp
- 16:54:21 [codyburleson]
- codyburleson has left #ldp
- 17:07:50 [jmvanel]
- jmvanel has joined #ldp
- 17:13:59 [Arnaud]
- sandro? help! http://www.w3.org/2013/meeting/ldp/2014-01-06?edit=1 Internal Server Error
- 17:43:32 [sandro]
- checking
- 17:44:30 [sandro]
- RRSAgent, pointer?
- 17:44:30 [RRSAgent]
- See http://www.w3.org/2014/01/06-ldp-irc#T17-44-30
- 17:45:08 [sandro]
- ohhhh, I bet 2013 is hardcoded somewhere. heh.
- 17:45:11 [sandro]
- checking.
- 17:46:56 [sandro]
- fixed. sorry about thatr.
- 17:47:00 [sandro]
- Arnaud,
- 17:47:07 [Arnaud]
- I tried with http://www.w3.org/2014/meeting/ldp/2014-01-06?edit=1 but that gave me a 404
- 17:47:24 [sandro]
- refresh?
- 17:47:48 [Arnaud]
- ah!
- 17:47:50 [Arnaud]
- it works
- 17:47:51 [Arnaud]
- thanks
- 17:48:00 [Arnaud]
- https://www.w3.org/2013/meeting/ldp/2014-01-06?edit=1
- 17:48:08 [Arnaud]
- what was it?
- 17:51:24 [sandro]
- I had a regexp in the code for finding relevant files and it hardcoded 2013. (it was supposed to be short lived. :-)
- 17:51:33 [Arnaud]
- :)
- 17:51:45 [Arnaud]
- it's always like that, isn't it?
- 17:52:10 [Arnaud]
- those temporary quick fixes tend to linger around until they bite you
- 17:52:46 [sandro]
- Well, sometimes it's shortlived because the whole project gets abandoned. :-) [ "Half of marriages end in divorce. Which isn't so bad if you consider the other half end in death."]
- 17:54:41 [Arnaud]
- hmm, there seems to be another problem now
- 17:54:54 [Arnaud]
- every time I try to save it claims there is a conflict
- 17:55:07 [sandro]
- looking
- 17:57:12 [sandro]
- try again, pleasre
- 17:57:21 [Arnaud]
- ok
- 17:57:51 [sandro]
- okay, that didnt do it. :-(
- 17:59:45 [Arnaud]
- nope
- 18:01:01 [sandro]
- odd. it did for me. I can edit https://www.w3.org/2013/meeting/ldp/2014-01-06 :(
- 18:01:11 [Arnaud]
- ok, let me try again
- 18:02:05 [Arnaud]
- ok, it worked this time
- 18:02:10 [Arnaud]
- don't know why
- 18:02:20 [Arnaud]
- but I can live with that :)
- 18:02:45 [sandro]
- phew. The error was that the date part of your URL couldn't be split on the '-' char. Strang.
- 18:03:19 [Arnaud]
- oh
- 18:08:52 [Arnaud]
- well, it works now, thanks!
- 18:45:33 [Zakim]
- Zakim has left #ldp
- 19:25:31 [gavinc]
- gavinc has joined #ldp
- 20:38:33 [bblfish]
- bblfish has joined #ldp