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

Using timezone: Eastern Standard Time
* dwilcox joins03:16
* dwilcox leaves03:56
* dwilcox joins05:55
* dwilcox leaves06:45
* coblej joins08:03
* github-ff joins08:09
[fcrepo-import-export] ruebot tagged fcrepo-import-export-0.1.0 at 5c722e9: https://github.com/fcrepo4-labs/fcrepo-import-export/commit/8ab0a63b2257
fcrepo-import-export/fcrepo-import-export-0.1.0 8ab0a63 nruest: [maven-release-plugin] prepare release fcrepo-import-export-0.1.0
* github-ff leaves
* github-ff joins08:13
[fcrepo-import-export] ruebot pushed 2 new commits to master: https://github.com/fcrepo4-labs/fcrepo-import-export/compare/a0bcb9d12647...da94dcbc6fed
fcrepo-import-export/master 8ab0a63 nruest: [maven-release-plugin] prepare release fcrepo-import-export-0.1.0
fcrepo-import-export/master da94dcb nruest: [maven-release-plugin] prepare for next development iteration
* github-ff leaves
* github-ff joins08:22
[fcrepo-import-export] ruebot created gh-pages (+1 new commit): https://git.io/v1xbt
fcrepo-import-export/gh-pages 897b0f8 Nick Ruest: Creating site for fcrepo-import-export, 0.1.1-SNAPSHOT
* github-ff leaves
* manez leaves08:32
* coblej leaves
* manez joins08:35
* coblej joins08:41
* github-ff joins08:57
[fcrepo4] acoburn pushed 3 new commits to 4.6-maintenance: https://git.io/v1xAS
fcrepo4/4.6-maintenance bd861d5 Andrew Woods: Recursively remove inbound references to child of deleted containers...
fcrepo4/4.6-maintenance 0e043e3 Andrew Woods: Ignore non-existent referents...
fcrepo4/4.6-maintenance 5c9f8fc Aaron Coburn: Merge pull request #1148 from awoods/fcrepo-2323-4.6...
* github-ff leaves
<f4jenkins>Project fcrepo4 build #3489: FAILURE in 58 sec: http://jenkins.fcrepo.org/job/fcrepo4/3489/08:58
* kestlund joins09:01
* kestlund1 joins
* kestlund leaves
* coblej leaves09:05
* coblej joins09:07
* travis-ci joins09:13
fcrepo4/fcrepo4#4875 (4.6-maintenance - 5c9f8fc : Aaron Coburn): The build passed.
Change view : https://github.com/fcrepo4/fcrepo4/compare/65c806d10e6d...5c9f8fc6c045
Build details : https://travis-ci.org/fcrepo4/fcrepo4/builds/185776287
* travis-ci leaves
* youn joins09:28
* apb18 joins09:30
* mikeAtUVa joins09:39
* youn leaves09:44
* bseeger joins09:59
* kestlund1 leaves10:00
* kestlund joins
* coblej leaves10:17
* acoburn joins10:25
* coblej joins10:32
* kestlund leaves10:36
* kefo joins10:37
* kestlund joins10:42
* whikloj joins10:47
<acoburn>apb18: sure enough, the separation of blueprint from java code in the fcrepo-camel-toolbox is working; I've got an extension to the fcrepo-ldpath code that suits our needs at Amherst10:52
* dhlamb joins11:26
* kestlund leaves11:41
* kestlund joins11:42
* coblej leaves11:53
* bseeger leaves12:11
* bseeger joins13:01
* github-ff joins13:33
[fcrepo-webapp-plus] acoburn closed pull request #52: remove profile for fcrepo-connector-file, which is unmaintained (master...remove_connector) https://github.com/fcrepo4-exts/fcrepo-webapp-plus/pull/52
* github-ff leaves
* travis-ci joins13:35
fcrepo4-exts/fcrepo-webapp-plus#184 (master - d3348f5 : Aaron Coburn): The build passed.
Change view : https://github.com/fcrepo4-exts/fcrepo-webapp-plus/compare/37eabb5e455a...d3348f5dd3f2
Build details : https://travis-ci.org/fcrepo4-exts/fcrepo-webapp-plus/builds/185850989
* travis-ci leaves
<apb18>acoburn: good to hear! By the way - I'm tying up some loose ends with the fork of repository-extension-services used in the API-X demo. So far, I have it rebased against 1.0.8-SNAPSHOT from your gitlab instance, and fixed a few integration tests I didn't have time to look at and @Ignored13:38
<acoburn>apb18: excellent. I looked briefly at your fork and those changes all look really straight-forward13:39
<apb18>acoburn: What would be the best way to do a pull request, so you and bseeger can determine which parts (if any) y'all want to incorporate into your codebase?13:41
i.e. would it be easiest if you updated your github fork, and I did a PR against that, or should I be interacting with your gitlab instance?13:43
<acoburn>apb18: I'll update the github fork
<apb18>Sounds good, thanks!13:44
<acoburn>apb18: you should be able to rebase on the master branch now13:49
<apb18>acoburn: excellent13:50
* kestlund leaves14:00
* kestlund joins14:05
<ruebot>https://wiki.duraspace.org/display/FEDORA4x -- we should probably update that graphic, right? Infinispan is gone.14:22
I assume awoods made it?
<apb18>ruebot: It looks fairly out of date!14:37
<ruebot>apb18: yep!14:38
* kestlund leaves14:43
<apb18>ruebot: it should probably align itself with the major functional areas mentioned in the spec. I mean, it doesn't even mention messaging et al.
<ruebot>apb18++ #agreed14:45
* cmmills leaves15:00
* kestlund joins15:04
<dhlamb>acoburn, something's come up in some discussions about the fedora ontology, looking for guidance15:09
acoburn, is fedora:hasParent explicitly the inverse of ldp:contains?
<acoburn>dhlamb: no it is not
dhlamb: it isn't in terms of the ontology, but it is in a practical, implementation sense15:10
<dhlamb>acoburn, from the looks of it, fedora:hasChild is actually the inverse of fedora:hasParent?
<acoburn>dhlamb: that is correct
<dhlamb>acoburn, so by basing repository structure off of fedora:hasParent, i'm not using ldp at all?15:11
<acoburn>dhlamb: no
dhlamb: as in, what you wrote above is correct
<dhlamb>acoburn, thx. was about to ask for clarification15:12
acoburn, so i'm not using ldp, i'm using fedora?
<acoburn>dhlamb: what it comes down to is this: fedora:hasParent is fedora-specific; ldp:contains is ldp-specific
dhlamb: so a generic LDP client wouldn't understand fedora:hasParent15:13
<dhlamb>acoburn, ok. i'm trying to navigate the semantic quagmire around setting things up in a way that makes more sense for sql
<acoburn>dhlamb: it may also be worth noting that the Fedora spec is silent about the fedora:hasParent triple15:14
<dhlamb>acoburn, i'd prefer for my tree to be directed from leaves to root. makes joins easier.
<acoburn>dhlamb: it's easier for a lot of things, not just sql15:15
<dhlamb>acoburn, oh, so i'm really in some murky waters, then
<acoburn>dhlamb: not necessarily — it depends on the assumptions you're making about the repository
dhlamb: right now there really is only one "Fedora" implementation15:16
dhlamb: as a FYI, I'm making the assumption that fedora:hasParent owl:inverseOf ldp:contains in my external triplestore
<dhlamb>acoburn, and that's PRECISELY what i'm getting at
acoburn, WOW
acoburn, because that's what I want to do15:17
<acoburn>dhlamb: it means I can exclude containment triples from the representation, making everything much, much easier
<dhlamb>acoburn, and you are inferencing this by feeding your 3-store some extra OWL that states it?
<acoburn>dhlamb: yes, I feed it this triple: fedora:hasParent owl:inverseOf ldp:contains15:18
<ruebot>apb18: https://jira.duraspace.org/browse/FCREPO-2372 -- feel free to add more if you want to
<apb18>ruebot: cool, will do15:19
<dhlamb>acoburn, ok, and by doing so i just need to understand that things may be different with a different fedora impl
<acoburn>dhlamb: yes, exactly15:20
dhlamb: so if you can avoid putting that piece of logic deep inside your code, that would be good
dhlamb: for me, I make it into a configuration parameter
dhlamb: which can be turned on or off15:21
<dhlamb>acoburn, i have one relationship that i call whatever i want, and it's config for me to map that to fedora:hasParent or whatever else I want
acoburn, so I think I'm good there
<acoburn>dhlamb: excellent
<dhlamb>acoburn, and i guess if another impl doesn't have a notion of hasParent, that's when I'd have to step in and make my own15:22
acoburn, yes, serendipitously, drupal 8 is basically an sql -> rdf engine
<acoburn>dhlamb: exactly. I'd have to say, though, that fedora:hasParent is incredibly useful15:23
<dhlamb>acoburn, yes. it avoids n+1 for me like nobody's business
<acoburn>dhlamb: I, for one, would like a way to navigate to a repository root location by following links
<dhlamb>acoburn, do you mean you'd prefer for the parent to not be in the representation, but be provided as a link header?15:25
<acoburn>dhlamb: either way, but I'd like some mechanism by which to find a "parent"15:26
<dhlamb>acoburn, oh... i see... if you go from root to leaves, you can't work your way back
<acoburn>dhlamb: ajs6f and I have discussed the possibility of putting all "server managed" properties into headers, and we both really like that idea
dhlamb: LDP mandates certain "server managed" triples to be present in the body of the response, but otherwise, it would make it easier to distinguish between what Fedora produces and what a user provides15:27
<dhlamb>acoburn, would make PUTs cleaner
<acoburn>dhlamb: exactly15:28
<dhlamb>acoburn, there's a hilarious gif somewhere about w3c specs i'll have to hunt down and show you
acoburn, found it: http://devopsreactions.tumblr.com/post/47690154351/trying-to-code-to-w3c-standards15:33
<mikeAtUVa>dhlamb: I wonder how that (putting server managed triples in headers) would be impacted by our need to allow management of traditionally server-managed triples for lossless import?15:36
<dhlamb>mikeAtUVa, good point. they wouldn't be in the representation and you'd lose them15:37
<mikeAtUVa>dhlamb: all the hand-waving required for ruebot's phase III of import/export is going to involve some hard questions when we get down to it...
<acoburn>mikeAtUVa: alternately, you could use a prefer header to make those part of the representation15:38
<mikeAtUVa>acoburn: dhlamb: for GETthing them, sure, but it's my understanding for the new "Import" feature, we're going to have to modify the repository to allow them to be set by fedora API calls.15:40
<acoburn>mikeAtUVa: yes, that's certainly part of it, and I don't have any easy answers for that15:41
<mikeAtUVa>acoburn, dhlamb: perhaps there's an easy solution that will work, but we'll likely have a new category of metadata that overlaps between server managed and user managed.
* kestlund1 joins15:47
* kestlund leaves
* dhlamb leaves15:57
* peichman joins
* peichman1 joins15:58
* peichman1 leaves16:00
* peichman leaves16:02
* mikeAtUVa leaves16:47
* bseeger leaves17:00
* kestlund1 leaves17:03
* acoburn leaves17:06
* whikloj leaves17:53
* apb18 leaves18:11
* kefo leaves18:38
* apb18 joins18:40
* peichman joins18:59
* apb18 leaves19:02
* peichman1 joins19:07
* peichman leaves
* apb18 joins19:21
* manez_ joins19:39
* peichman1 leaves19:43
* manez leaves19:45
* peichman joins19:51
* peichman leaves
* apb18 leaves20:32
* dwilcox joins21:07
* kefo joins21:25
* dwilcox leaves21:29
* kefo leaves21:30
* peichman joins21:40
* dwilcox joins
* peichman leaves21:44
* dwilcox leaves22:14
* apb18 joins22:28
* apb18 leaves22:48
* dhlamb joins23:10

Generated by Sualtam