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

Using timezone: Eastern Standard Time
* Iome leaves00:55
* Iome joins01:06
* mikeAtUVa leaves05:55
* acoburn joins08:44
* kefo joins09:00
* bseeger joins09:01
* osmandin joins09:07
* whikloj joins09:14
* kefo leaves
* awoods joins09:26
Good morning, team.09:27
<acoburn>awoods: I have an indirect container question
<awoods>acoburn: good morning.09:28
<acoburn>awoods: can you use ldp:insertedContentRelation with properties on a binary?
awoods: or is that only for use with containers? (I've only seen it with containers)09:29
<awoods>acoburn: are you asking if a binary can be an indirect container?
<acoburn>awoods: no, say the binary's parent is an indirect container09:30
awoods: and the parent's ldp:insertedContentRelation property points to, say, dc:extent
* apb18 joins
<awoods>acoburn: I would expect so... and I do not believe the LDP spec says otherwise.
<acoburn>awoods: ok, thanks
<awoods>acoburn: have you tried it?
<acoburn>awoods: it's not about what currently works — it's about how it _should_ work09:31
awoods: fcrepo-1742
<awoods>acoburn: I believe it should work
acoburn/whikloj/ruebot/barmintor/osmandin: Is there anything that is more pressing than other things that have happened over the last two weeks that you would like to me to look into as soon as possible?09:33
<whikloj>awoods: nope
<awoods>whikloj: is it true that the 4.5.1 docs.fcrepo.org is still needing attention?09:34
<barmintor>although I think we still don't have the 4.5.1 docs pushed to GHP
<awoods>thanks, barmintor.
<acoburn>awoods: other than this question about indirect containers, nope
<whikloj>oh right that
<awoods>barmintor: I plan on giving that a look today
<barmintor>sorry, I hit the wall with it. Not sure what else to do
* mcritchlow joins09:35
<whikloj>awoods: would you like me to try and push those up? I'm the only one who hasn't yet
<awoods>whikloj: we should first look to see if an updated version of that plugin is available.
<whikloj>awoods: not according to maven09:36
http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22com.github.github%22%20AND%20a%3A%22site-maven-plugin%2209:37
https://github.com/fcrepo4/fcrepo4/blob/84a885a561727f9c60c9341c9efed2bfae9f65b3/fcrepo-parent/pom.xml#L52
* mcritchlow leaves09:39
* bseeger leaves09:42
<whikloj>awoods: so is the problem is we are pushing to much data at once?09:44
* bseeger joins09:46
<awoods>whikloj: That is likely the problem, given that the other projects work.09:49
<whikloj>awoods: Is this because we hit a hard limit or a time based limit or you're not sure.09:50
<awoods>whikloj: not sure09:52
* dwilcox joins10:05
* mcritchlow joins10:17
<acoburn>whikloj: do you realize what sort of gymnastics I'm having to perform in order to make the eventing system work properly with indirect containers?10:34
<whikloj>acoburn: no not really, some sort of magic. But I always figure that is your speciality.10:35
<acoburn>whikloj: so much for thinking I was almost done with that ticket…
<whikloj>acoburn: sorry, anything I can do?
<awoods>acoburn: the other approach could be to rethink how direct/indirect containers are handled.
acoburn: i.e. to persist those relationships instead of generating them dynamically.10:36
<acoburn>awoods: it would be a great opportunity to start using Akka
awoods: direct containers are really easy, it's the ICs that are challenging10:37
awoods: I do have an approach that will work, though
awoods: it's just a question of whether I will have time to finish today before being pulled in other directions
awoods: I would need to be convinced of the need to persist those triples10:39
<awoods>acoburn: the argument would be around simplicity of design and maintenance... which may not be true.10:40
<acoburn>awoods: there's a certain complexity w/r/t indirect containers; I don't think that persisting them would help all that much10:41
<whikloj>acoburn/awoods: I guess I don't understand how a property is added to a resource and that doesn't create an event. That seems like it should be in the code already.
<acoburn>whikloj: membership triples are dynamically generated
whikloj: it gets complicated if, say you have an indirect container
<awoods>whikloj: indirect containers create properties indirectly... that are not persisted10:42
<acoburn>whikloj: and the child resource changes the property which is the object of its parent's ldp:insertedContentRelation
whikloj: that means that the parent's target of ldp:membershipResource has a new representation and so its lastModified date must change10:43
whikloj: this is why I try to steer clear of indirect containers10:44
<whikloj>acoburn: so I guess I don't understand the whole membership triples are generate dynamically. If my indirect container adds a property to the membershipResource, then how is that triple generated when I GET that membershipResource10:45
<acoburn>whikloj: https://git.io/vrO84 (as if that explains it)10:46
whikloj: which gets called from here: https://git.io/vrO8z10:47
<whikloj>acoburn: ok, I'll have to try and watch those functions when adding my containers, but it should help me understand. Thanks10:50
<acoburn>whikloj: in a word, there are different "contexts" in which triples are generated: https://git.io/vwRth10:51
whikloj: and depending on the prefer headers supplied, some combination of these contexts are retrieved
<whikloj>acoburn: ok so what you are saying is that when in indirect container adds a property to another resource, it really isn't adding it there at all. Which is why no event is created.10:52
*an indirect....
<acoburn>whikloj: the issue is that if you change the property of a resource that is the child of an indirect container, you should see two events10:53
whikloj: one for changing that resource directly, and one for changing the ldp:membershipRelation resource (indirectly)
* kefo joins10:54
<whikloj>acoburn: yes, same for adding a new child of the indirect container. But I would have assumed that the triple added to the ldp:membershipRelation would be persisted on it and send an event
<acoburn>whikloj: adding the child would cause two or three events10:55
whikloj: certainly an event for the new resource and its parent (that's two)
<whikloj>acoburn: yes10:56
<acoburn>whikloj: and a third if that resource contains a property that is identified by the parent indirect container in the ldp:insertedContentRelation triple
whikloj: but not if that triple isn't present
<whikloj>acoburn: right but that one isn't generated.10:57
<acoburn>whikloj: exactly; that's what I'm trying to fix
<whikloj>acoburn: right, totally. I just am still grappling with how the property is indirectly added to the ldp:membershipRelation but without a JMS event emitted for PROPERY_ADDED or PROPERTY_CHANGED.10:58
<acoburn>whikloj: it's because that triple is added dynamically (it doesn't exist until requested)10:59
<whikloj>acoburn: yeah, and we're back to the start. Sorry my brain works slowly, its why I have to trace code to understand this too often.11:00
<acoburn>whikloj: and I've got a meeting to attend…
<whikloj>acoburn++
* acoburn leaves11:03
* bseeger leaves11:10
* dwilcox leaves11:30
* ajs6f joins11:37
awoods: Everyone seemed cool with the idea of moving the standard documents into the main Duraspace Github account. Do you have rights to make a repo for that?11:38
* dwilcox joins11:42
* acoburn joins11:43
* bseeger joins11:47
* dwilcox leaves11:53
* dwilcox joins11:55
<awoods>ajs6f: We can certainly start by adding the API docs into a DuraSpace Github repo... but does that make more sense than a Fedora-based repo?12:03
<ajs6f>awoods: I don't understand what you are suggesting.
<awoods>ajs6f: I am suggesting that it seems more appropriate for the github organization to be Fedora as opposed to DuraSpace.12:04
<ajs6f>awoods: We don't have a Fedora organization. If you want to make one, that makes a lot of sense to me.
<awoods>ajs6f: we have fcrepo and fcrepo412:05
<ajs6f>awoods: fcrepo4 is right out. That's the ref impl. That will confuse people no end exactly when we are trying to _distinguish_ the APi and ref impl. fcrepo looks like it could work. Is that not where fcrepo3 used to live?12:06
<acoburn>awoods: I agree with ajs6f ^^^
<awoods>acoburn/ajs6f: are we agreeing that fcrepo is the appropriate github organization?12:07
<acoburn>awoods: "fcrepo" would work for me12:08
<awoods>acoburn: It sounds like we need to go back to whichever group ajs6f was referring to when he said, "Everyone seemed cool with the idea of moving the standard documents into the main Duraspace Github account", to make sure they are also cool with fcrepo.12:10
<acoburn>awoods: "duraspace" works for me, too (just not "fcrepo4")12:11
<whikloj>awoods: perhaps adding a note to the meeting minutes, as that should e-mail the participants.
<ajs6f>awoods: That was the tech meeting you missed.12:12
<awoods>ajs6f: ok, we can discuss again on Thurs.12:13
ajs6f/whikloj/acoburn: was an agreeable name for the API repo discussed?12:16
<ajs6f>Repo McRepoFace12:17
<awoods>That is a little surprising
<whikloj>ajs6f/awoods/acoburn: no but I think a simple clear one is best ie. Versioning Specification
<ajs6f>http://www.heraldonline.com/news/nation-world/world/article76705192.html12:18
<awoods>whikloj: interesting, are we thinking that each spec would get its own repo?
<whikloj>awoods: I'm not totally clear on how the ReSpec works, but we could do one repo with various directories if that seems easier
<awoods>whikloj: and is this the home of TCKs?12:19
<ajs6f>awoods: eventaully, they will include TCKs and ontology.
<awoods>ajs6f++
<acoburn>awoods: I don't think we discussed whether all spec apis would be in one repo or in several12:20
* bseeger leaves
<ajs6f>awoods: And any extras. Chips, dip. Maybe a crudite plate.
<whikloj>acoburn: agreed
<acoburn>awoods: but if we think we will version these separately, it might make sense to keep them in separate repos
<awoods>acoburn: that should probably get sorted out... as it relates directly to what the repo is named.
<whikloj>acoburn: or a single github repo with sub-modules
<acoburn>awoods/whikloj: yes, lets discuss next week12:21
<ajs6f>whikloj: Are you talking about git submodules?
<whikloj>ajs6f: yeah, if you want a single repo for all the specs, but to maintain them separately
<awoods>acoburn: I was expecting that "the Fedora API" would be versioned... not its constituent parts.
<ajs6f>whikloj: Mm. That's not a single repo. That a bunch of repos being imported together.
<acoburn>awoods: if that's the case, I'd expect all of them to go into a single repo12:22
<ajs6f>Maybe we should put all this into a Fedora repo.
<whikloj>ajs6f: I think technically its a repo that imports a version of other repos, but it could resolve the single version of the Fedora API made of different versions of each constituent API12:23
or its friday and I've started the slow decline into the weekend
<ajs6f>whikloj: Yes, that is true. But I think we're now talking about using a tool for software development (git versioning) for the use of software _releasing_ (the versioning of the API) and this isn't going to go well.
<awoods>ajs6f/whikloj/acoburn: We have a basis for discussion next Thurs.12:24
<whikloj>ajs6f: fair point, but if we are storing the specification in Github anyways....I'll stop as I think awoods would like this discussion to be next thursday
<ajs6f>We want to keep the git versioning connected with the API version for our own sanity. But they are two different things. For example, the idea of a branch or fork of the API isn't very interesting to me.12:25
* arebenji joins12:30
* arebenji leaves12:32
* dwilcox leaves12:40
<ruebot>ajs6f: http://i.imgur.com/Eo7Jf4o.jpg
<ajs6f>ruebot: Okay, for OR you dress up as the Macho Man and I'll dress up as Rue McClanahan. BEST TAG TEAM EVER!12:42
<ruebot>ajs6f: that is a *very* tempting deal to make
awoods, acoburn: if you two have some time next week, would you mind chatting with me and maybe whikloj about the Islandora CLAW java sub-project. We're working on a first release to just go through the process, and noticed we might have made some mistakes... and could use your expertise :-)12:49
<acoburn>ruebot: I'd be happy to look it over12:50
<ruebot>acoburn++
acoburn: also, whikloj noticed we might have a problem here -- https://issues.sonatype.org/browse/OSSRH-18137 -- the username is acoburn, and the group id is 'ca.islandora'...12:52
<whikloj>but that might be okay
<ruebot>we use 'ca.islandora.camel' in the project https://github.com/Islandora-CLAW/Alpaca/blob/master/pom.xml#L13
<whikloj>we might want to change the project's parent pom to match ca.islandora instead of making all of our stuff sit in a group called "camel"12:53
* whikloj walks back to #islandora
<awoods>ruebot: if setting up a meeting would be helpful, feel free.12:56
<ruebot>awoods: cool. i'll fire up a doodle for y'all12:57
awoods, acoburn: and... thank you!
* dwilcox joins12:58
* dwilcox_ joins13:13
* dwilcox leaves13:17
* acoburn leaves13:28
* bseeger joins14:34
* bseeger leaves14:36
* mikeAtUVa joins14:51
* aawoods_ joins15:10
* aawoods_ leaves15:25
* acoburn joins15:38
* mikeAtUVa leaves
<acoburn>apb18: can I merge this? https://github.com/fcrepo4-labs/fcrepo-api-x/pull/116:02
<apb18>hm, I think Elliot already did - I'm surprised it's still open16:03
acoburn: Yeah, it has been merged but via rebase + ff, so there's no merge commit. I can tell it's been merged by looking at the content of the repp. Hm.o16:09
<acoburn>apb18: ahh, good point. I'll close it with a comment for the commit16:10
<apb18>acoburn: That sounds like the best thing to do. Thanks for noticing!16:11
* osmandin leaves16:28
* dwilcox_ leaves16:30
* kefo leaves
* bseeger joins16:39
* kefo joins16:49
* ajs6f leaves16:53
* apb18 leaves16:55
* bseeger leaves17:04
<acoburn>whikloj: I _think_ I have the indirect container working properly now17:06
<whikloj>acoburn++ # I never doubted it
<acoburn>whikloj: I have to clean up my code a bit and add some more tests before I push those changes to github
<whikloj>acoburn: awesome, I will be glad to try them out
<acoburn>whikloj: cool, you can expect something on Monday17:07
<whikloj>acoburn: thanks again
<acoburn>whikloj: thank you for helping me realize that I implemented it incorrectly in the first place!17:08
<whikloj>acoburn: not sure how I did that...but your welcome
<acoburn>whikloj: it was your 4th comment on this page: https://github.com/fcrepo4/fcrepo4/pull/103317:09
whikloj: and your fifth comment17:10
whikloj: https://github.com/fcrepo4/fcrepo4/pull/1033#issuecomment-218858588
<whikloj>acoburn: see I thought that was explained by the property not actually being applied to the resource, instead there is just the same inbound reference from the indirect container and everything else is dynamic17:11
I'm starting to get it :)
<acoburn>whikloj: it took me a while to really understand ldp containers17:15
whikloj: after about the fifth time awoods explained it, I started to understand17:16
<whikloj>acoburn++ # and with my much more limited knowledge, you hit your fifth explanation long ago :)17:17
<acoburn>whikloj: well, honestly, I think I finally _really_ got the hang of indirect containers this morning
<whikloj>acoburn: they are bizarre creations that is for sure17:18
<acoburn>whikloj: can't disagree there17:19
* acoburn leaves17:32
* whikloj leaves17:39
* kefo leaves19:16
* kefo joins19:28
* apb18 joins
* ajs6f joins19:37
* apb18 leaves19:42
* kefo leaves19:45
* ajs6f leaves19:50
* apb18 joins20:15
* apb18 leaves20:26
* apb18 joins21:17
* apb18 leaves21:27
* mcritchlow_ joins21:36
* mcritchlow leaves
* mcritchlow joins21:42
* mcritchlow_ leaves
* dwilcox joins22:13
* dwilcox leaves22:18
* dwilcox joins22:19
* dwilcox leaves
* apb18 joins22:29
* apb18 leaves22:46
* github-ff joins22:56
[fcrepo4] awoods pushed 1 new commit to gh-pages: https://git.io/vr3Fb
fcrepo4/gh-pages 6b4b508 Andrew Woods: Creating site for fcrepo, 4.5.1
* github-ff leaves
* mcritchlow leaves23:00
* mcritchlow joins
* awoods leaves23:08
* awoods joins23:15
* github-ff joins23:46
[fcrepo4] awoods pushed 1 new commit to gh-pages: https://git.io/vr3N3
fcrepo4/gh-pages 18ef3a8 Andrew Woods: Creating site for fcrepo, 4.5.1
* github-ff leaves
* github-ff joins00:11
[fcrepo4] awoods pushed 1 new commit to gh-pages: https://git.io/vr3Av
fcrepo4/gh-pages 96861bc Andrew Woods: Creating site for fcrepo, 4.5.1
* github-ff leaves
* github-ff joins00:29
[fcrepo4] awoods pushed 1 new commit to gh-pages: https://git.io/vr3A0
fcrepo4/gh-pages 8827fd3 Andrew Woods: Creating site for fcrepo, 4.5.1
* github-ff leaves
* github-ff joins00:32
[fcrepo4] awoods pushed 1 new commit to gh-pages: https://git.io/vr3Ag
fcrepo4/gh-pages 927a8cc Andrew Woods: Creating site for fcrepo4-bom, 4.5.1
* github-ff leaves
* github-ff joins00:34
[fcrepo4] awoods pushed 1 new commit to gh-pages: https://git.io/vr3A1
fcrepo4/gh-pages 76c3176 Andrew Woods: Creating site for fcrepo-jcr-bom, 4.5.1
* github-ff leaves
* github-ff joins00:37
[fcrepo4] awoods pushed 1 new commit to gh-pages: https://git.io/vr3A7
fcrepo4/gh-pages 73fb6bb Andrew Woods: Creating site for fcrepo-boms, 4.5.1
* github-ff leaves
* github-ff joins00:56
[fcrepo4] awoods pushed 1 new commit to gh-pages: https://git.io/vr3xG
fcrepo4/gh-pages d3cf069 Andrew Woods: Creating site for fcrepo-kernel-api, 4.5.1
* github-ff leaves
* github-ff joins01:01
[fcrepo4] awoods pushed 1 new commit to gh-pages: https://git.io/vr3xR
fcrepo4/gh-pages 024eae3 Andrew Woods: Creating site for fcrepo-metrics, 4.5.1
* github-ff leaves
* github-ff joins01:04
[fcrepo4] awoods pushed 1 new commit to gh-pages: https://git.io/vr3xu
fcrepo4/gh-pages a4f2396 Andrew Woods: Creating site for fcrepo-configs, 4.5.1
* github-ff leaves
* github-ff joins01:28
[fcrepo4] awoods pushed 1 new commit to gh-pages: https://git.io/vr3pU
fcrepo4/gh-pages d9b1943 Andrew Woods: Creating site for fcrepo-kernel-modeshape, 4.5.1
* github-ff leaves
* github-ff joins01:34
[fcrepo4] awoods pushed 1 new commit to gh-pages: https://git.io/vr3p3
fcrepo4/gh-pages 0511ac0 Andrew Woods: Creating site for fcrepo-jms, 4.5.1
* github-ff leaves
* github-ff joins01:39
[fcrepo4] awoods pushed 1 new commit to gh-pages: https://git.io/vr3p8
fcrepo4/gh-pages aff7f00 Andrew Woods: Creating site for fcrepo-serialization, 4.5.1
* github-ff leaves
* github-ff joins01:59
[fcrepo4] awoods pushed 1 new commit to gh-pages: https://git.io/vr3p9
fcrepo4/gh-pages a7a1c21 Andrew Woods: Creating site for fcrepo-http-commons, 4.5.1
* github-ff leaves
* github-ff joins02:03
[fcrepo4] awoods pushed 1 new commit to gh-pages: https://git.io/vr3pN
fcrepo4/gh-pages bc6cf11 Andrew Woods: Creating site for fcrepo-connector-file, 4.5.1
* github-ff leaves
* github-ff joins02:10
[fcrepo4] awoods pushed 1 new commit to gh-pages: https://git.io/vr3hk
fcrepo4/gh-pages 2d53750 Andrew Woods: Creating site for fcrepo-auth-common, 4.5.1
* github-ff leaves
* github-ff joins02:19
[fcrepo4] awoods pushed 1 new commit to gh-pages: https://git.io/vr3hn
fcrepo4/gh-pages adcc965 Andrew Woods: Creating site for fcrepo-http-api, 4.5.1
* github-ff leaves
* github-ff joins02:23
[fcrepo4] awoods pushed 1 new commit to gh-pages: https://git.io/vr3hl
fcrepo4/gh-pages ebb795c Andrew Woods: Creating site for fcrepo-webapp, 4.5.1
* github-ff leaves
* github-ff joins02:25
[fcrepo4] awoods pushed 1 new commit to gh-pages: https://git.io/vr3h4
fcrepo4/gh-pages ea47b0a Andrew Woods: Creating site for fcrepo-integration-ldp, 4.5.1
* github-ff leaves
* github-ff joins02:28
[fcrepo4] awoods pushed 1 new commit to gh-pages: https://git.io/vr3hz
fcrepo4/gh-pages 4666a65 Andrew Woods: Creating site for fcrepo-integration-rdf, 4.5.1
* github-ff leaves

Generated by Sualtam