Log of the #fcrepo channel on chat.freenode.net

Using timezone: Eastern Standard Time
* thomz joins02:57
* youn joins09:00
* whikloj joins09:08
* bseeger joins09:10
* acoburn joins09:15
* mikeAtUVa joins
<whikloj>acoburn: ping09:18
<acoburn>whikloj: pong09:19
whikloj: are you wondering about https://github.com/fcrepo4-exts/fcrepo4-vagrant/pull/66
<whikloj>acoburn: no, about isMemberOfRelation09:20
<acoburn>whikloj: have you discovered anything?
<whikloj>acoburn: I think the code awoods put in LdpIsMemberOfRdfContext should be a part of LdpContainerRdfContext
<acoburn>whikloj: I haven't actually looked at the code09:21
whikloj: though, I thought LdpContainerRdfContext was more about just adding the rdf:type values
<whikloj>acoburn: I wondered if I copied his work and amended here
https://github.com/fcrepo4/fcrepo4/blob/master/fcrepo-kernel-modeshape/src/main/java/org/fcrepo/kernel/modeshape/rdf/impl/LdpContainerRdfContext.java#L102
* dwilcox joins09:22
<acoburn>whikloj: it looks like that is the correct class to be working on…09:23
<whikloj>acoburn: ok, I'm gonna play with it and see what I can discover or break
<acoburn>whikloj: I think the challenge is that you have to look up the inbound ref, b/c the relation is reversed
<whikloj>acoburn: Right, I think awoods has done that in his PR. But I'm still deciphering09:24
<acoburn>whikloj: ok
whikloj: question about your PR ^^^
<whikloj>acoburn: yes
<acoburn>whikloj: that's pointing to a draft RC, not a "pre-release" RC. Will that cause trouble?09:25
whikloj: https://github.com/fcrepo4/fcrepo4/releases
whikloj: I see RC-2 as a "draft"
<whikloj>acoburn: ha, oops. I should fix that but it actually grabs the war files from https://github.com/fcrepo4-exts/fcrepo-webapp-plus/releases09:26
acoburn: I'll upload the one-click for fcrepo4 and set it to pre-release too
<acoburn>whikloj: ok, great09:27
* peichman joins09:28
* osmandin joins
* ajs6f joins09:36
<acoburn>ajs6f: so, before that last commit, awoods didn't like the way things worked09:37
ajs6f: it took an entire day to change that
<ajs6f>acoburn: Okay, but I'm not saying go back to that, particuarly.
acoburn: Honestly, you don't have to worry too much about me.
acoburn: My desire to reuse the HTTP layers over a new kernel is now pretty much dead.
<acoburn>ajs6f: well, if that's the case, then what's the point of this effort?09:38
<ajs6f>acoburn: I know. And I'm sorry about this confusion. But after the introduction of a locking regime (!) in the HTTP layers, I don't really think they're fit for reuse any more.09:39
acoburn: IOW, when you started, I was into it, but things have changed while you've been working on it. But I'm not the only person getting ready to reimpl.09:40
acoburn: And the effort has merit of its own, making the code easier to understand and maintain.
<acoburn>ajs6f: sure, but I have no interest in maintaining a piece of software backed by modeshape09:41
<ajs6f>acoburn: So treat my comments on that PR as basically advisory. It's not necessary to adress them if it will cost too much and I'm not vetoing.
acoburn: Well, do _you_ want to reuse th HTTP layers?
acoburn: Because if you do, that's a good reason there tio todo this work.
<acoburn>ajs6f: not at present, but I was hoping to be able to
<ajs6f>acoburn: So there you go. It's not in vain or wasted.
acoburn: And just think of me as an interested, friendly bystander.09:42
<acoburn>ajs6f: fair enough; but this still has bearing on the core types, which we need to get right
<ajs6f>acoburn: Okay, yes, but right in what particular way?09:43
<acoburn>ajs6f: right in that it is understandable
ajs6f: e.g. changing `commit` to `finalize` would be significantly more understandable09:44
<ajs6f>acoburn:Okay. Well, my vote would be (as I said on the PR) to eliminate the whole "batching" notion at the kernel layer. That's an HTTP problem.
acoburn: Let it be managed by HTTP.
<acoburn>ajs6f: that's how I had it earlier, but awoods didn't like that09:45
ajs6f: he called it "brittle"
<ajs6f>acoburn ;Well, then we are at an impasse.
<acoburn>ajs6f: honestly, I don't care either way — I just want the jcr notion out of the kernel
<ajs6f>acoburn: In fact, it is the having those notions spooged all over the kernel which is inappropriate, not the eliminating them.
acoburn: If you don't care, then don't worry about me. awoods is going to have to worry about this long after either of us.09:46
<acoburn>ajs6f: ok, I'm going to make some minor changes to the naming of methods, but otherwise, I see this as one possible implementation and rolling back to the earlier commit as another possibility09:47
<ajs6f>acoburn++
* osmandin leaves10:05
* th5 joins10:36
* dwilcox leaves10:37
* dwilcox joins10:52
* thomz leaves10:54
* ajs6f leaves11:10
* ajs6f joins11:25
* ajs6f leaves
* apb18 joins11:28
<anarchivist>howdy folks. can someone clarify whether the existing Fedora WebAccessControl documentation is up to date based on the Hydra/Fedora WebAC harmonization work from this summer?11:34
<acoburn>anarchivist: is there something about the documentation that seems out of date?11:35
<anarchivist>acoburn: yes - i'm curious about the "Fedora Implementation Notes" on this page: https://wiki.duraspace.org/display/FEDORA4x/WebAC+Authorizations11:36
<acoburn>anarchivist: the webac module supports both strings and URIs, but the documentation may be inaccurate there11:37
<anarchivist>yeah, that was one of the subquestions i had. thanks
<acoburn>anarchivist: yes, that should be updated
<anarchivist>the context is I'm trying to document some of the expectations based on the modeling work we're doing for hybox11:38
<acoburn>anarchivist: IIRC you can pass in a system property with a URI prefix, that is used together with the username (principal) used when authenticating to the container (tomcat/jetty)11:40
anarchivist: also, if you are passing in a header-based delegate, the header value can also be a URI
<anarchivist>great, thank you
the other thing i'm trying to suss out is what actually changed as a result of the harmonization - as best as i can tell, most of the changes were on the Hydra side other than FCREPO-189511:41
<acoburn>anarchivist: that way, if I authenticate to Tomcat as "pat", and set up Fedora to use "http://example.org/users/" as a namespace, then the ACL agent becomes: http://example.org/users/pat11:42
<anarchivist>excellent. got it!
thanks acoburn
* bseeger leaves11:46
<anarchivist>i made a change to update that page - any suggestions are welcome if i could make further improvements: https://wiki.duraspace.org/pages/diffpagesbyversion.action?pageId=70588384&selectedPageVersions=6&selectedPageVersions=511:49
* ajs6f joins11:50
* ajs6f leaves11:51
* dwilcox leaves11:56
<acoburn>anarchivist: those changes are great, thanks! I also made a change, describing how one would configure Fedora to support URIs: https://wiki.duraspace.org/pages/diffpagesbyversion.action?pageId=70588384&selectedPageVersions=6&selectedPageVersions=711:59
anarchivist: and https://wiki.duraspace.org/pages/diffpagesbyversion.action?pageId=69833984&selectedPageVersions=31&selectedPageVersions=32
* bseeger joins12:10
* can-of-bees joins12:15
* th5 leaves12:26
* mjgiarlo joins13:20
* mjgiarlo leaves
* mjgiarlo joins13:21
* mjgiarlo leaves
* mjgiarlo joins13:22
* mjgiarlo leaves13:23
* mjgiarlo joins
* mjgiarlo leaves13:24
* mjgiarlo joins
* mjgiarlo leaves13:25
* mjgiarlo joins13:26
* mjgiarlo leaves
* dwilcox joins13:31
* jackhill leaves13:33
* cbeer leaves
* cbeer joins
* jackhill joins
* github-ff joins13:34
[fcrepo4-vagrant] acoburn closed pull request #66: Move vagrant to point at RC-2 artifacts (4.7.0-RC...increment-rc-2) https://git.io/vP1yz
* github-ff leaves
<whikloj>acoburn: logic check if you have a moment13:35
<acoburn>whikloj: sure
<whikloj>acoburn: So based on this (https://github.com/fcrepo4/fcrepo4/blob/master/fcrepo-kernel-modeshape/src/main/java/org/fcrepo/kernel/modeshape/rdf/impl/LdpIsMemberOfRdfContext.java#L73-L74)
acoburn: It appears that the isMemberOfRelation is only checked if the container of the current resource has a isMemberOfRelation property13:36
<acoburn>whikloj: I need to re-read the relevant portion of the spec13:37
<whikloj>acoburn: not the spec, I'm just looking at that code. We only execute the concatIsMemberOfRelation() if the container is a direct or indirect and has a isMemberOfRelation on it.
acoburn: But I'm wondering where the other triple, the one created by the proxy should appear...like in what context.13:38
<acoburn>whikloj: ok, but I'm going to read the spec anyway, b/c I am not confident that I understand the semantics of isMemberOfRelation off the top of my head13:39
<whikloj>acoburn: I re-read what awoods said in FCREPO-2092 and it seems that his is making the triple, but he never finished updating the response to display the triple
acoburn: yeah ok
* osmandin joins13:40
* osmandin leaves
* dwilcox leaves13:49
* github-ff joins
[ontology] whikloj pushed 1 new commit to master: https://git.io/vPDKe
ontology/master c2eeed4 Aaron Coburn: Remove JCR-sourced and other unused properties from ontology (#41)...
* github-ff leaves
* dwilcox joins
* dwilcox leaves13:51
* dwilcox_ joins
* bseeger leaves13:52
<acoburn>whikloj: ok, I understand the ldp:isMemberOfRelation now
whikloj: those membership triples are added if the parent resource is a direct/indirect container with a ldp:isMemberOfRelation property13:53
<whikloj>acoburn: right, this is where I am getting confused.13:55
acoburn: If I create a RdfSource, and add an indirect Container inside with...
<acoburn>whikloj: do you understand what was wrong with the current impl? does it not work with in indirect container?13:56
<whikloj>acoburn: See I'm wondering if it is working to set the triple, but presenting them is not working?
acoburn: which is why I was looking in the RdfContexts13:57
<acoburn>whikloj: it seems to work fine with direct containers (which is all I ever use)
whikloj: I'll try it with indirect containers
* github-ff joins14:00
[ontology] acoburn deleted fcrepo-1936 at e836472: https://git.io/vPD6i
* github-ff leaves
<anarchivist>hm. more questions about WebAccessControl, namely regarding groups: https://wiki.duraspace.org/display/FEDORA4x/How+to+Use+WebAC+agentClass+Groups14:01
* bseeger joins
<whikloj>acoburn: I don't understand what the spec means by "Create requests to LDP Direct Containers can only add information resources [WEBARCH] - the documents they create - as members."
<anarchivist>this points to an ambiguity to between the (W3C) WebAccessControl wikipage and the ontology14:03
looking at https://wiki.duraspace.org/display/FEDORA4x/How+to+Use+WebAC+agentClass+Groups - it seems to follow examples from https://www.w3.org/wiki/WebAccessControl#Examples_2
<acoburn>whikloj: what they mean is that, in contrast to indirect containers, direct containers can only add triples whose object is a URI (i.e. an information resource; i.e. the resource that was just added)14:04
<whikloj>acoburn: ahhhh, thanks14:05
<acoburn>whikloj: with indirect containers, you can insert triples that are literals or any URIs for that matter
<anarchivist>however, the ontology indicates the range of acl:agentClass is rdfs:Class ...
<acoburn>anarchivist: what is the conflict you see?14:06
<whikloj>anarchivist: is the ambiguity between the WebAC ontology and the WebAC wiki page?14:08
<anarchivist>whikloj: i think it might be.
<whikloj>anarchivist: that is entirely possible
<anarchivist>acoburn: it feels strange that to say that `</fcrepo/rest/group> a rdfs:Class` given the example here: https://wiki.duraspace.org/display/FEDORA4x/How+to+Use+WebAC+agentClass+Groups14:09
<acoburn>anarchivist: are you familiar with RDFS entailment?
<anarchivist>acoburn: rusty.
<acoburn>anarchivist: it is not necessary to materialize all triples
<anarchivist>yes, i've got that much - i'm just not sure that you'd want to infer that `</fcrepo/rest/group> a rdfs:Class .`14:10
it seems messy
<acoburn>anarchivist: the fact that the ontology states that acl:agentClass has a range of rdfs:Class means that an inference engine can add the triple
anarchivist: yes, but rdfs:Class is an instance of rdfs:Class
<anarchivist>ah ha14:11
<acoburn>https://www.w3.org/TR/rdf-schema/#ch_class
<anarchivist>thanks. i guess i'm still struggling with that though, because my brain has focused on `</fcrepo/rest/group>` being an instance of `foaf:Group`14:13
<acoburn>and foaf:Group a rdfs:Class, no?
<anarchivist>yes, but am i wrong in distinguishing instances and classes here?14:14
<acoburn>the rdfs:Range triple isn't for _restricting_ what can and cannot be asserted, it's for determining what triples can be inferred14:16
* dwilcox_ leaves14:17
<acoburn>simply by stating: <foo> acl:agentClass <bar>, I'm implying that <bar> a rdfs:Class, whether or not that triple is materialized
<anarchivist>acoburn: got it now. thanks - no wonder why i was so lost.14:18
<acoburn>rdf will do that :-)
<anarchivist>i knew that much :D14:19
<whikloj>acoburn: So you are using isMemberOfRelation with DirectContainers and are able to GET the resource referred to by the ldp:hasMemberRelation and see the triple?14:20
or am I totally not understanding isMemberOfRelation...
<acoburn>whikloj: no, you see the triple on the child of the direct container
whikloj: w/ a hasMemberRelation, you take three URIs14:21
1. the ldp:membershipResource
2. the ldp:hasMemberRelation
3. the URI of the resource contained by the direct container
<whikloj>acoburn: right sorry staring at the spec and getting muddled
<acoburn>they go in that order: 1. 2. 3
<whikloj>acoburn: I meant the ldp:isMemberOfRelation14:22
<acoburn>if you use isMemberOfRelation, the order is 3. 2 .1
so the triple shows up on the resource at 3 (rather than the resource at 1)
<whikloj>acoburn: So using DirectContainers they don't use the ldp:insertedContentRelation for the predicate?14:23
<acoburn>whikloj: no, direct containers don't use that
<whikloj>acoburn: ahhh okay
<acoburn>whikloj: I still haven't tried it with indirect containers, but judging from awoods' PR, it seems that they don't work
<whikloj>acoburn: it seems like whatever magic is done to show the triple on the membershipResource when using IndirectContainers, needs to be mimicked on resources that have an inbound reference from a resource contained in an IndirectContainer with a ldp:isMemberOfRelation property14:25
<acoburn>whikloj: yes, exactly
<whikloj>acoburn: ok, so which context should that triple appear in? I'm trying to understand how the currently working part does it14:26
* ajs6f joins14:27
<whikloj>acoburn: IIRC those triple are generated on the fly and not persisted on the resource, correct?14:29
<acoburn>whikloj: correct
<whikloj>acoburn: ok, stop me if I go off the rails. But perhaps the new LdpIsMemberOfRdfContext also needs to be called in the ReferencesRdfContext, here:14:31
https://github.com/fcrepo4/fcrepo4/blob/master/fcrepo-kernel-modeshape/src/main/java/org/fcrepo/kernel/modeshape/rdf/impl/ReferencesRdfContext.java#L91
acoburn: and if I am correct, is there a way to use the property values stream against both of those Contexts?14:33
acoburn: Or should it use a new context that tests for the type of IndirectContainer properties and calls the appropriate RdfContext
<acoburn>whikloj: it doesn't really matter if it's part of an existing context or in a new class14:34
<ajs6f>Man, I wish that cbeer and I never set up that whole mess of *Contexts.14:36
<acoburn>it is a bit of a mess
<ajs6f>That stuff should be completely ripped out and redone. And I am not going to do it.
"You got your Context in my RDFStream! No, you got your triples in my HTTP!" A big mess.14:37
* dwilcox joins15:04
* github-ff joins15:13
[fcrepo4-vagrant] whikloj tagged fcrepo4-vagrant-4.7.0-RC-2 at 384d89a: https://git.io/vPD7c
* github-ff leaves
* youn leaves15:24
* dwilcox leaves15:36
* dwilcox joins15:37
* dwilcox leaves
* dwilcox joins15:38
* dwilcox leaves
* dwilcox joins
* dwilcox leaves15:39
* dwilcox joins
* dwilcox leaves15:40
* dwilcox joins
* dwilcox leaves
<whikloj>acoburn/ajs6f: So am I crazy if I modify the LdpIsMemberOfRdfContext to check for any inbound weak references from a resource15:43
then check the referring resource to see if it is contained in an IndirectContainer and has a isMemberOfRelation?
<acoburn>whikloj: makes sense to me15:44
<ajs6f>whikloj:acoburn: I have literally no idea. I'm not even sure if I am in the right IRC room.
* apb18 leaves
<ajs6f>This sounds like LDP jibber-jabber.15:45
And you know my feelings about j-j.
<whikloj>acoburn: It seems like that could impact performance as there is no way to tell until you test all the inbound references if the resource is being referred to in a isMemberOfRelation
<acoburn>my eyes glaze over whenever anyone talks about indirect containers
<ajs6f>indirect container are those foldy things you get takeout Chinese in, right?
<whikloj>Consider it my gift of a good nights sleep
<acoburn>whikloj: there are performance implications for indirect containers period.15:46
<ajs6f>whikloj: Seriously, you don't want to test inbound rels if you can avoid it.
whikloj: That's the graph database motto: Think local.
<whikloj>But isMemberOfRelation doesn't work for indirectContainers is that okay...if we are "LDP"errific?15:47
<ajs6f>whikloj: What do you mean "doesn't work"?15:48
<whikloj>ajs6f: I can't get it to create the triple, or if it is creating the triple I can't get the triple back
* dwilcox joins15:49
<ajs6f>whikloj: That seems like we're not dong the spec. Have you check the LDP tests that we run int he build?
Also we are not "LDP"errific and I put a committer's veto on any further use of the "errific" suffix in this conversation.15:50
<whikloj>ajs6f: I normally take a nap while that runs, but I'll take a look at how it looks in master.
"LDP"tastic?
<ajs6f>whikloj: It is there for a reason.
Yes, things being tastic are acceptable to me.
<acoburn>there are some test failures in the ldp test suite (I think there always have been)
<whikloj>ajs6f: I was having trouble getting one to work and acoburn pointed to this https://github.com/fcrepo4/fcrepo4/pull/108015:51
<ajs6f>acoburn: Right, I'm asking if this is one of them.
whikloj: That is some old cheese.
https://jira.duraspace.org/browse/FCREPO-2092
<whikloj>ajs6f: yes it is
<ajs6f>whikloj: are you working that?15:52
whikloj: Do we know why #1080 did not get merged?
<whikloj>ajs6f: Cause it wasn't complete
<ajs6f>whikloj: Not tastic enough, eh?
whikloj: Are you starting from that?
<whikloj>ajs6f: from PR-1080 "adds an integration test ensuring dynamically added property on indirect resource ** the above integration test failing in this commit"
ajs6f: maybe, I'm still not sure I am setting up an indirect with isMemberOfRelation correctly.15:53
<ajs6f>whikloj: I would check the LDP test suite, find that section, and look at what they are doing there. If nothing else, it should shed light on your procedure for setup.
<whikloj>ajs6f: I guess we would like to use it for the reverse of adding pcdm:hasMember to a Resource, and instead add pcdm:memberOf to the proxied resource.
<ajs6f>whikloj: But still automating the membership action?15:54
<whikloj>ajs6f: right
ajs6f: which might just be a bad idea in the end
<ajs6f>whikloj: No, that's the essence of that tool. That's a good use for it.
whikloj: Guessing this was diegopino's idea?15:55
<whikloj>ajs6f: he suggested we could use it, I was adding the test to my fcrepo4-tests and it failed.
<ajs6f>whikloj: Right. It sounds like him. It's a good idea. That doesn't mean Fedora does it, or if it does, that it works properly.15:56
whikloj: I would start with the test suite to see what _should_ work, use awoods itest maybe as a starting point for code, and looks at ReferencesRdfContext or whatever that has evolved into. the performance questions are real, but we can't know how damaging until you can show some code that we can work with.15:57
whikloj: that's what I would do. if I were going to work on this. Instead, I am going to work on the specs to move me closer to not caring.15:58
<whikloj>ajs6f: test-suite seems to have 3 Spec tests for indirect containers and none reference isMemberOfRelation15:59
ajs6f: the DirectContainer test does, but only to throw an Exception
<ajs6f>whikloj: That's because IndirectContainer < DirectContainer, which is where that jazz gets played.
whikloj: So the test in DirectContainer may be enough. But you say it doesn't work?16:00
<whikloj>ajs6f: the test is for hasMemberRelation not isMemberOfRelation.
https://github.com/w3c/ldp-testsuite/blob/master/src/main/java/org/w3/ldp/testsuite/test/DirectContainerTest.java#L99-L110
It just uses the constant in it.16:01
<ajs6f>"This test does not apply to containers using the ldp:isMemberOfRelation membership pattern."
And you don't see anything else?
<whikloj>not yet, still looking
<ajs6f>testMemberRelationOrIsMemberOfRelationTripleExists
Below "LDP DirectContainer must have either ldp:hasMemberRelation or ldp:isMemberOfRelation"16:02
"LDP DirectContainer cannot have both ldp:hasMemberRelation and ldp:isMemberOfRelation"
<whikloj>Yeah that just cares of the triple exists on the indirect container, which it does. The problem is that it isn't creating new triples
<ajs6f>When you add new member resources?
<whikloj>Right
<ajs6f>In the member resources?16:03
<whikloj>That is what I am seeing, unless I need a different representation
<ajs6f>That is not what the spec says. The spec doesn't tell you that you are going to get new triples in the member resources.16:04
<whikloj>hahah, so we're good
<ajs6f>https://www.w3.org/TR/ldp/#h-ldpdc-containtriple-byrelation
"https://www.w3.org/TR/ldp/#dfn-linked-data-platform-direct-container… MUST contain exactly one triple …"
the member resources don't get the membership triples, the container does.16:05
That's normal for LDP.
whikloj: is this basically about not having fifty jillion triples in a container because you have that many children? Instead having one triple in each child?16:06
<whikloj>ajs6f: yes, so I think I get that. I saw a script escowles had included in that FCREPO-2092 ticket to create the indirectContainer under the added resource16:07
It just seemed crazy
ajs6f: I think in this case telling LDP to bugger off and tracking our relationships using some other way is better.16:08
dhlamb: ^^16:09
<ajs6f>whikloj: Hm. I don't think it was crazy to try this. And I'm not totally sure you count LDP out. It may not work. BUt there might be something in it.
whikloj: It may still be tastic, but in a different way.
* youn joins16:10
<whikloj>ajs6f: ha I like how it works in my head, but not sure it is feasible
Because I need to trace all inbound references to see if they might generate a triple on that resource16:11
<ajs6f>whikloj: I like how it works in my head: http://www.lifehacker.co.in/photo/31610979.cms but I'm not confident that Fedora can do that.
<whikloj>ajs6f++
ajs6f: So I guess the end result is 1) I don't understand LDP all that well and 2) Is how I want the indirectContainers and isMemberOfRelation a bad idea?16:12
<ajs6f>whikloj: We cannot enshrine that kind of behavior in the spec, because acoburn will kill us. It will make it impossible for him to write the glorious Ultradistributed Google-scale World Wide Repository of his vision.
<whikloj>ajs6f: true16:13
<ajs6f>whikloj: It's not a bad idea, it just raises performance questions that the LDP guys clearly and sensibly did not want to raise.
<whikloj>ajs6f: maybe I'll just add a note to that ticket and see why awoods let it wither on the vine16:14
<ajs6f>whikloj: Here's another question about your use case. Where do you expect to _retrieve_ the membership info? From the members?
<acoburn>if you're using ldp:isMemberOfRelation, you _have to_ retrieve the membership triples from the members16:15
<whikloj>ajs6f: Yes, otherwise we end up with a bunch of references on a different resource and the (possible) performance implications.
* apb18 joins
<whikloj>acoburn: Do you have an example? I'm still now sure I get what the LDP people were thinking16:16
s/now/not/
<ajs6f>whikloj:acoburn: Yeah, my point is that you can just include the triple when you create the member, right? What exactly are you gaining with the container thing? Are you trying to avoid including the triple yourself, and instead letting the fact that you are POSTing to a particular location trigger that for you?
<acoburn>whikloj: I try to stay away from indirect containers
whikloj: what ajs6f said ^^^
<ajs6f>whikloj: You presumably know when you create the member that "this thing is a member of that container". Right?16:17
<acoburn>whikloj: and this is why I plan to manage collection membership manually (independent of LDP containers)16:18
<whikloj>ajs6f/acoburn: Yes I think the idea was to avoid managing all memberships on the resource, to use the benefits of proxies.
acoburn: yeah, I think I'm starting to see why
<ajs6f>CONTAINERS != COLLECTION
This is something that has confused a lot of people.
"Collection" is a vague, wooly, not-well-defined notion that comes from the library world and means a lot of different things to a lot of different people.16:19
It has flavors of administration, intellectual arrangment, provenance, lots of other stuff.
"Container" is a precise and much simpler notion.
It has to do with HTTP interactions and triples that connect resources with URIs and that is it.16:20
If you are trying to manage "collections", you might be able to use container to implement some of the stuff you need to do. But I can pretty much guarantee that you will need several different containers to get at the different facets of "collection".16:21
whikloj: and the punch line is that pcdm:hasMember ihas domain and range of ore:Aggregation.16:24
whikloj: So you are almost definitely not dealing with something that can be managed by one container setup.
That's how it is on the street.16:25
<whikloj>ajs6f: Yeah, I understand the problems with pcdm. I thought this setup might work for anything though. Say I make a Resource and then use the IC to add isPartOf to the proxied children16:26
<ajs6f>whikloj: Yeah, and? We need to know what the semantics of isPartOf are.16:28
whikloj: Does it have lifecycle implications? For example, if you delete the "parent" should all of the things that have isPartOf theParent automatically get deleted?16:30
whikloj: If you can't guarantee that, you can't use a single container or a union of containers.
whikloj: well, okay, that's not really true. But if you can't guarantee that, you are going to get into some pretty confusing situations.16:31
<whikloj>ajs6f: Sorry got lost for a second. I would say yes, but perhaps I don't understand. I'm thinking about a RdfSource as the representation of a Collection. Then if the proxies are children, and the Collection is deleted I think it is okay if the isPartOf disappears from the proxied resources16:32
<acoburn>whikloj: I think what ajs6f is saying is that if <resource> :isPartOf <collection>, but then you delete <collection>, does <resource> also get deleted?16:33
<ajs6f>whikloj: Right, as I understand LDP, you don't get that. You will still have to go about manually deleteing all those triples on the kids.
whikloj: Your LDP impl might do some of that work for you, but it's not LDP.
<whikloj>acoburn: No I would say it doesn't
<ajs6f>acoburn:whikloj: yes, that is what I was pointing to, but we can leave that alone.
<whikloj>ajs6f: Right, but clearly my understanding of the isMemberOfRelation was incorrect16:34
<ajs6f>acoburn:whikloj: well, let's say you aren't magically going to get non-local action.
whikloj: I mean, we could talk about other ways to do that, but LDP alone doesn't do that. It's not going to make triples spring up anywhere but right where you are actually sending requests,
or get rid of them16:35
<whikloj>ajs6f: and yet that seems to be exactly what it does with hasMemberRelation
<ajs6f>except for one case: if you delete a contained resource, then the triple representing containement for that resource _will_ go away from the container.
* acoburn leaves
<ajs6f>whikloj: No, I don't think it does. Show me one place in the spec where it says anything about putting triples _in the member resource representation_.16:36
whikloj: (Meaning that the LDP impl is putting triples in there— obviously the client can put triples there with an ordnary request.)16:37
<whikloj>ajs6f: Oh see I can't read specs, they are meant for smart people. I'm going by what is happening, which is why we will need to find another way.
<ajs6f>whikloj: Specs are made for near-sighted people.
<whikloj>ajs6f: with a large bound OED
<ajs6f>whikloj: Think of it this way— LDP is good at helping you bring triples together. It's trying to help you move them apart (to different resources).16:39
SOrry, it's _NOT_ trying to do that latter thign.
<whikloj>ajs6f: right, yeah I got it. I'm just still not clear on how you would actually use an indirectContainer with ldp:isMemberOfRelation. I can't find any examples on the interweb16:40
ajs6f: rather I can't see any reason TO use it
<ajs6f>whikloj: The crucial point is in https://www.w3.org/TR/ldp/#dfn-membership-triples16:42
whikloj: That is the difference between ldp:isMemberOfRelation and ldp:hasMemberRelation
<whikloj>ajs6f: right16:43
<ajs6f>whikloj: "The difference between the two is simply which position member-derived-URI occupies"
whikloj: You would like that to read "The difference between the two is simply which position member-derived-URI occupies _and where the membership triple appears_"16:44
whikloj: But it don't.
whikloj: That doesn't mean that Fedora can't do what you want it to do. It just means that it won't do that on the basis of LDP alone.16:45
<whikloj>ajs6f: Right, but you can't currently get both of those created using an IndirectContainer in Fedora 4. Not that I can figure out at least
<ajs6f>whikloj: No, and you shouldn't be able to.
<whikloj>ajs6f: Because they relate to containment, yes?16:46
<ajs6f>whikloj: The good thing that an IC does is let you choose a predicate to use for membership. It doesn't magically make your predicate symmetrical.
whikloj: Right. Containment is inherently antisymmetrical.
whikloj: And you can choose only _one_ predicate for an IC.16:47
whikloj: we could imagine a more complicated container that lets you choose two predicates that represent the two directions in which containment can be recorded.
whickloj: But LDP isn't offering that.
whikloj: got to go. just remember, http://www.lifehacker.co.in/photo/31610979.cms is the only container that really matters in this discussion.16:48
* ajs6f leaves
* mikeAtUVa has yet to hear of any problem that is uniquely solved with indirect containers, so avoid headaches by never thinking about them.16:52
I'm lucky though, to have ajs6f around to tell me about new technologies in the event that they actually solve relevant problems.16:53
<whikloj>mikeAtUVa++ # I'm considering that for all of the LDP stuff
* bseeger leaves16:59
* dwilcox leaves17:01
* whikloj leaves
* dwilcox joins17:04
* youn leaves
* dwilcox leaves17:07
* apb18 leaves17:08
* mikeAtUVa leaves17:11
* peichman leaves17:14
* apb18 joins19:11
* dwilcox joins20:04
* dwilcox leaves20:22
* apb18 leaves23:29

Generated by Sualtam