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

Using timezone: Eastern Standard Time
* github-ff joins00:04
[fcrepo-camel-toolbox] birkland pushed 2 new commits to master: https://git.io/v1HZ6
fcrepo-camel-toolbox/master dd1d00e Aaron Coburn: Add provisioning features independent of blueprint-based default configurations...
fcrepo-camel-toolbox/master 1168c50 birkland: Merge pull request #126 from acoburn/fcrepo-2363...
* github-ff leaves
* travis-ci joins00:17
fcrepo4-exts/fcrepo-camel-toolbox#324 (master - 1168c50 : birkland): The build passed.
Change view : https://github.com/fcrepo4-exts/fcrepo-camel-toolbox/compare/8edaaec380dd...1168c5085b0c
Build details : https://travis-ci.org/fcrepo4-exts/fcrepo-camel-toolbox/builds/184447675
* travis-ci leaves
* thomz joins03:47
* coblej joins07:56
<ruebot>escowles: dbernstein pushed another commit on 67 last night08:26
* peichman joins08:36
* peichman leaves08:42
* westgard joins08:54
ruebot ping08:58
<ruebot>westgard: pong
<westgard>ruebot I'm wondering if you could look at, and potentially merge, the outstanding PR on the verification tool.08:59
I have another large PR I would like to make and had some issues getting a clean PR with the otherone still outstanding.
Probably a deficiency in my git fu but in any case I think it would be easier if we could get the outstanding one merged and move forward from there09:00
<ruebot>westgard: sure09:06
<westgard>ruebot++09:07
* whikloj joins09:08
* thomz leaves09:09
<ruebot>whikloj: dbernstein pushed another commit on 67 last night - https://github.com/fcrepo4-labs/fcrepo-import-export/pull/6709:10
<whikloj>ruebot: I saw that, yay for dbernstein. I think if that works just commit it and we look at some utility function for parsing and validating profiles later
<escowles>ruebot: the new commit on #67 looks good — i'm going to give it a closer look now
<whikloj>escowles++09:11
<escowles>whikloj++ # yep, i think we can just ship it if it works
<ruebot>whikloj, escowles: i think there is a problem though if you look at my last comment
<escowles>ruebot: yeah, it would be nice if there was a stacktrace or something, so i might need to debug that if i can't figure out on my own why that's happening
<whikloj>ruebot: ugh, I got that too but I thought it was my messing around.09:12
escowles/ruebot: From my experience this is because you MUST have the APTrust tags in your config yaml file
<ruebot>whikloj, escowles: that should not be the case09:13
<whikloj>escowles/ruebot: this line https://github.com/fcrepo4-labs/fcrepo-import-export/pull/67/files#diff-230835395ae42488584f0706d8828ad4R179
oops not that one
<escowles>whikloj: ok, we should fix that, but it can be in a followup ticket though
<ruebot>i'm cool with that; merging and fixing
<whikloj>escowles/ruebot: This is the line https://github.com/fcrepo4-labs/fcrepo-import-export/blob/master/src/main/java/org/fcrepo/importexport/common/BagConfig.java#L9009:14
<escowles>whikloj/ruebot: yep, i'm going to merge #67, and create tickets for fixing that, and maybe a couple other things09:17
<ruebot>escowles++
<whikloj>escowles++09:18
* github-ff joins
[fcrepo-import-export] escowles pushed 1 new commit to master: https://git.io/v1HAE
fcrepo-import-export/master e860a74 dbernstein: Enforces BagIt profile requirements for user-supplied metadata. (#67)...
* github-ff leaves
* acoburn joins09:23
<escowles>ok, here's a ticket for fixing the aptrust thing: https://jira.duraspace.org/browse/FCREPO-236509:29
* github-ff joins
[fcrepo-import-export] acoburn opened pull request #69: update version to 0.1.0-SNAPSHOT (master...update_version) https://git.io/v1Hxj
* github-ff leaves
<escowles>and here's a ticket for custom tag files: https://jira.duraspace.org/browse/FCREPO-236609:32
<ruebot>escowles++
* github-ff joins09:33
[fcrepo-camel-toolbox] birkland pushed 3 new commits to master: https://git.io/v1HpW
fcrepo-camel-toolbox/master 9b135e9 Aaron Coburn: Fix OPTIONS handling in fcrepo-ldpath...
fcrepo-camel-toolbox/master 8021045 Aaron Coburn: code review
fcrepo-camel-toolbox/master 85f691d birkland: Merge pull request #127 from acoburn/fcrepo-2358...
* github-ff leaves
<escowles>[Import/Export Standup]09:34
* yesterday: meetings, code review, accidentally pushing to master
* today: wrapping up bag functionality
* blockers: the number of hours in the day
<whikloj>[Import/Export Standup]09:35
yesterday: Some verify stuff and a rabbit hole of BagIt profiles
today: Perhaps a better parser for BagIt profiles to allow for finding the required fields, determining validity, etc09:36
stop me if there is better stuff to spend my time on, perhaps verify tooling
blockers: Lunch potluck ;)09:37
<escowles>one more ticket: update the README with Bag examples: https://jira.duraspace.org/browse/FCREPO-2367
<whikloj>ruebot: You want to handle explaining BagIt ^^
<ruebot>whikloj: i grabbed that one09:38
<escowles>whikloj: i've created a few tickets that i think we would ideally close out today: the three received tickets listed in https://jira.duraspace.org/browse/FCREPO-2221
i'm going to rebase #68 (local bagit impl) and then move on to those tickets
<ruebot>escowles: we going for the moon? ripping out LoC?09:39
<escowles>ruebot: i want to have it as an option, and i don't think it'll be hard to get ready to merge if we decide to do it
<whikloj>escowles: FCREPO-2221 doesn't have linked tickets... typo?
<escowles>whikloj: the tickets in that epic — there's a big list right above the comments, right?09:40
<whikloj>escowles++ # I wasn't logged in
<ruebot>escowles++09:41
<whikloj>escowles: So you are adding that local Bag impl you had gist'd yesterday
<escowles>whikloj: yep, it's here and working (but needs to be rebased now that #67 is merged): https://github.com/fcrepo4-labs/fcrepo-import-export/pull/68
<whikloj>escowles: I'll take FCREPO-236509:42
escowles: your PR needs a rebase
<escowles>whikloj: yep, i'm on it
<whikloj>escowles++
* travis-ci joins09:45
fcrepo4-exts/fcrepo-camel-toolbox#326 (master - 85f691d : birkland): The build passed.
Change view : https://github.com/fcrepo4-exts/fcrepo-camel-toolbox/compare/1168c5085b0c...85f691d18199
Build details : https://travis-ci.org/fcrepo4-exts/fcrepo-camel-toolbox/builds/184548372
* travis-ci leaves
* informatician joins10:00
* github-ff joins10:02
[fcrepo-import-export] ruebot created FCREPO-2367 (+1 new commit): https://git.io/v1Qvk
fcrepo-import-export/FCREPO-2367 e2e8578 nruest: Update README with good Bag examples; Resolves FCREPO-2367.
* github-ff leaves
* github-ff joins10:03
[fcrepo-import-export] ruebot opened pull request #70: Update README with good Bag examples; Resolves FCREPO-2367. (master...FCREPO-2367) https://git.io/v1QvZ
* github-ff leaves
* github-ff joins10:09
[fcrepo-import-export] escowles force-pushed local-bagit from bc3890b to 746ff70: https://git.io/v19mr
fcrepo-import-export/local-bagit 746ff70 Esmé Cowles: Local BagIt implementation instead of using LoC bagit-java
* github-ff leaves
<whikloj>escowles/ruebot: So if my reading of bag profiles is correct (that is a question) then Bag profiles don't have a mechanism for specifying required elements that are not inside the bag-info.txt10:11
<escowles>whikloj: this isn't allowed? https://github.com/fcrepo4-labs/fcrepo-import-export/blob/master/src/main/resources/profiles/aptrust.json#L5610:14
* th5 joins10:15
* coblej leaves
<acoburn>dhlamb: fyi, bseeger is going to cut a 4.5.0 release of fcrepo-camel today
<whikloj>escowles: So my reading of (https://github.com/ruebot/bagit-profiles) is that APTrust, etc would be covered by #9 under implementation details. Which is a static file of tags to be included in the bag.10:16
<dhlamb>acoburn, thx. i'll make tickets to stay on top. we need to update to 2.18
<acoburn>dhlamb: and then fcrepo-camel-toolbox will go out early next week10:17
<whikloj>escowles: However it doesn't explicitly say you _can't_ have that tag, but we are rolling our own there. I looked for a copy of APTrust's maybe I'll look again
<escowles>whikloj: oh, when we use the tag file name as a key and inlcude requirements, there's nothing in ruebot's spec that says we can do that
<whikloj>escowles: Right, ruebot10:18
<ruebot>escowles, whikloj; yeah, that looks correct
<whikloj>escowles: ruebot's page says "A list of a tag files that must be included in a conformant Bag. Entries are full path names relative to the Bag base directory."
Sorry that is for "Tag-Files-Required" which is the only entry related to alternate tags10:19
escowles/ruebot: Again it doesn't say we _can't_ have other elements in the JSON.
<westgard>[Import/Export Standup]
Finished yesterday:
PR for FCREPO-2327 (includes some refactoring)
troubleshooting reports of validation errors
Working on today:
Reviewing and closing/commenting on all open tickets
Would like to get FCREPO-2359 and 2361 closed out
Need to troubleshoot FCREPO-2362
Blockers:10:20
We probably need fuller logging and automated tests to solve FCREPO-2362; not sure there'll be time
<ruebot>escowles, whikloj; "it doesn't say we _can't_ have other elements in the JSON" agreed :-)
whikloj++
<whikloj>escowles/ruebot: So perhaps we should put any alternate tags under a standard header like OTHER-INFO then replicate the APTRUST-INFO : { etc10:21
Save on hunting for other tags
<ruebot>that sounds like a sane approach
<escowles>yep, that's a good improvement to make parsing easier10:22
<whikloj>ruebot: the spec says "BagIt-Profile-Identifier is the URI where the profile file is available" does APTrust have a URL for their JSON?
<ruebot>whikloj: nope. we (I) made up the profile based on information the stakeholder provided.10:23
<whikloj>ruebot: not the spec, your group's proposal
ruebot: right, so there is no consensus about a format from the BagIt spec on how to describe alternate implementations or additions10:24
<ruebot>whikloj: hold that! escowles made it :-)
https://jira.duraspace.org/browse/FCREPO-2222
<whikloj>ruebot: escowles made our copy based on your proposal, I'm asking if there is any uptake of the profile idea?10:25
<ruebot>whikloj: oh! well, uhh... kinda. Mark Jordan and I had a call with DPN back in early 2012 or 2013, and awoods was on the call. But, they never followed up.10:26
whikloj: so, no. i don't think anybody is actually publishing the profiles.10:27
<whikloj>hahahahaha
<ruebot>whikloj: it was them, not us :-)
<escowles>i think the perseids one is the only published one: https://w3id.org/ro/bagit/profile10:28
* coblej joins
<whikloj>escowles++10:29
<ruebot>escowles++
<westgard>bseeger ruebot : It looks like FCREPO-2359 and 2361 have been merged. Can someone close out the tickets? They still say "in review".
<ruebot>westgard: on it10:30
<westgard>ruebot++10:31
<whikloj>escowles/ruebot: and this leads to the question, why does our default profile have so many required fields? A BagIt spec bag has none
<escowles>whikloj: the BagIt spec doesn't require any fields, but it recommends using a lot10:32
<westgard>ruebot Also I notice that the branches are still there on the github. What's the procedure for removing the feature branches?
<escowles>maybe we should have a "minimal" profile that doesn't require any user-supplied fields?
westgard: imho, delete the branch when you merge a PR10:33
<ruebot>escowles, whikloj: i was talking with justinsimpson about that last night
<escowles>(or delete your own branches if they are left around)
<whikloj>escowles++ # I agree that using no fields is a bad idea, but a minimal profile is a nice option
<westgard>OK I think I have that power. These have been merged.
<ruebot>that the default profile shouldn't require the bag-tags yaml
since the required tags are created automatically
<escowles>right now it's only Source-Organization that's not auto-generated but required in default10:34
<westgard>it would be "git push upstream --delete <featurebranch>" correct?
* github-ff joins
[fcrepo-camel] bseeger tagged fcrepo-camel-4.5.0 at 0c74049: https://git.io/v1QT6
fcrepo-camel/fcrepo-camel-4.5.0 ec90490 bseeger: [maven-release-plugin] prepare release fcrepo-camel-4.5.0
* github-ff leaves
<escowles>westgard: i usually just go and delete them in github
<whikloj>ruebot/escowles: So perhaps we should not be validating the bag until it is completely created?10:35
<westgard>escowles oh OK makes sense
<escowles>whikloj: i think we can check whether the required fields are provided — it would be nice to return an error message before creating the bag dir, copying files, etc. if it's going to be a problem
so we can say that the three tech md fields we generate can be ignored, but everything else has to be supplied by the user, so we should know at the start10:36
<whikloj>escowles: Simplest solution is to not make application generated fields required
* github-ff joins10:37
[fcrepo-import-export] ruebot pushed 1 new commit to FCREPO-2367: https://git.io/v1QTp
fcrepo-import-export/FCREPO-2367 c86da47 nruest: review
* github-ff leaves
<escowles>whikloj: but some of those fields *are* required by some of the services, so i don't think it's a good idea to change the profile to make our impl eaiser...
* github-ff joins10:38
[fcrepo-import-export] escowles pushed 1 new commit to master: https://git.io/v1Qks
fcrepo-import-export/master 399758d Nick Ruest: Update README with good Bag examples; Resolves FCREPO-2367. (#70)...
* github-ff leaves
<whikloj>escowles: Ok, so is adding an additional value to the profile (like my "generated":true) ok?
* travis-ci joins10:39
fcrepo4-exts/fcrepo-camel#336 (fcrepo-camel-4.5.0 - ec90490 : bseeger): The build passed.
Change view : https://github.com/fcrepo4-exts/fcrepo-camel/commit/ec90490f5122
Build details : https://travis-ci.org/fcrepo4-exts/fcrepo-camel/builds/184565297
* travis-ci leaves
<escowles>whikloj: i don't know... ideally, people would be able to use the profiles with a completely different tool — would the "generated: true" make sense for them?
<informatician>I'm a bit late on this today -10:40
[Import/Export Standup]
Finished yesterday:
- Explored solutions for python debugging.
- Completed tutorials on "PuDB" debugging utility.
- Started exploring solutions to https://jira.duraspace.org/browse/FCREPO-2359
Working on today:
- Will be looking through the committed fix to FCREPO-2359 just for sake of learning.
Blockers:
- None
<escowles>ruebot: whikloj: how are we feeling about merging https://github.com/fcrepo4-labs/fcrepo-import-export/pull/68?10:42
<whikloj>escowles: oops I was watching, I'll test it right now10:43
<escowles>i'm torn myself — i think that bagit-java is working ok and would hate to abandon it, on the other hand, it's not that much code to replace a much larger dependency & they really have been pretty uncooperative
* ajs6f joins10:44
<ruebot>escowles: ...and we're using an out of date version of bagit-java
escowles: ...and the new version breaks everything. so, i say go with it!
<escowles>ruebot: yeah, updating to our own code is easier than updating to their new version...10:45
<ruebot>whikloj: i can test if you want if you're working on other stuff
<ajs6f>ruebot:escowles: I just met Chris Adams the other day. He's grateful for the feedback, because it's letting him shake out edge cases and things from Bagit as they try to move the spec to 1.0.
<ruebot>ajs6f++ Chris is awesome
ajs6f: the other guy however...
<ajs6f>ruebot: what other guy?10:46
* kefo joins
<escowles>ajs6f: John Scancella (the main bagit-java author)
<ajs6f>escowles:ruebot: Oh, dunno him.10:47
<ruebot>ajs6f; yeah, he has made things really difficult10:48
* peichman joins
<ajs6f>ruebot: Chris said something about a release to Maven not having gotten made or something.
<ruebot>ajs6f: yeah, a BETA release was put on maven, and that's what we've been using10:49
ajs6f: https://github.com/LibraryOfCongress/bagit-python/issues/8310:50
ajs6f: which led to this https://github.com/LibraryOfCongress/bagit-java/issues/72
ajs6f: ...and there was this earlier in the week https://github.com/LibraryOfCongress/bagit-java/issues/69
"Bagit is designed to be used by Bagit, not the other way around."10:51
that kinda hurt my soul
<whikloj>escowles: If we load the profile as an external file, we can't enforce requirements without storing a list of tags we generate in the code somewhere. So maybe that is the only solution.
ruebot: That hurt my brain
<escowles>whikloj: that's already in there — that was in the commit dbernstein added last night/this morning
<ajs6f>ruebot: Trying to use or implement Pair (or entry) in Java is a code smell, unless you are writing a Map impl.10:52
<whikloj>escowles: ok, so if there is any other required tags then they have to exist before we start the export or we fail10:53
<escowles>ajs6f: ruebot: yeah, that was the final straw for me — it's completely ridiculous for bagit-java to depend on a GUI library, and i can't believe he was pushing back on that issue
whikloj: yep, i think that's right
<ruebot>https://github.com/LibraryOfCongress/bagit-java/commit/5fa6f85996b9352a7aa4bc1af7e5fdbbffbaee4b10:54
that just came through
<ajs6f>escowles:ruebot: I really, really wish we had worked on https://tools.ietf.org/html/draft-wilper-semantic-content-pkgs-00
escowles:ruebot: I hate when we are hostage to library-world specs.10:55
<escowles>just saw that — it's a step in the right direction (though honestly, the impl should just use Maps and pass Map.Entry for the single-value cases)
<ajs6f>Or maybe he should just f)(&()ing learn to use Map.forEach.10:56
And singlevalue cases should pass two params, key and value. That's idiomatic Java.10:57
<ruebot>escowles: default and no apt-trust in the bag-config.yml shouldn't work on 68, right?
<escowles>ajs6f: the semantic-content-packages spec does look like an improved and simplified version of bagit in many ways
* github-ff joins
[fcrepo-camel] bseeger pushed 1 new commit to gh-pages: https://git.io/v1Qtb
fcrepo-camel/gh-pages fe55928 B. Seeger: Creating site for fcrepo-camel, 4.5.0
* github-ff leaves
<escowles>ruebot: right — whikloj is working on that separately10:58
<ruebot>escowles: cool. i'm good with merging 68 then.
<ajs6f>escowles: Chris W. was well aware of that: https://cwilper.blogspot.com/2012/04/new-internet-draft-semantic-content.html
<ruebot>escowles: merge commit, or squash and merge?
<ajs6f>"I think something a bit more generic that has RDF at its core and, critically, acknowledges that copies of the same content can be made available from multiple locations...could have quite a lot of potential. "
* github-ff joins10:59
[fcrepo-camel] bseeger pushed 2 new commits to master: https://git.io/v1Qqh
fcrepo-camel/master ec90490 bseeger: [maven-release-plugin] prepare release fcrepo-camel-4.5.0
fcrepo-camel/master 1f6b860 bseeger: [maven-release-plugin] prepare for next development iteration
* github-ff leaves
<escowles>ruebot: merge commit please!
* github-ff joins11:00
[fcrepo-import-export] ruebot pushed 1 new commit to master: https://git.io/v1Qmm
fcrepo-import-export/master 626223a Nick Ruest: Merge pull request #68 from fcrepo4-labs/local-bagit...
* github-ff leaves
* th5 leaves11:01
* travis-ci joins11:04
fcrepo4-exts/fcrepo-camel#337 (master - 1f6b860 : bseeger): The build passed.
Change view : https://github.com/fcrepo4-exts/fcrepo-camel/compare/ede2d6ef9197...1f6b8605f57a
Build details : https://travis-ci.org/fcrepo4-exts/fcrepo-camel/builds/184572412
* travis-ci leaves
<whikloj>escowles++ ruebot++ working to remove that APTrust requirement unless you are using APTrust11:08
<ruebot>whikloj++11:09
westgard: how are you doing on the remainder of your objectives for the sprint?11:15
* ajs6f leaves11:17
* github-ff joins
[fcrepo-import-export] escowles created custom-tagfiles (+1 new commit): https://git.io/v1QO8
fcrepo-import-export/custom-tagfiles 47c8ea4 Esmé Cowles: Exporting all custom tags
* github-ff leaves
* github-ff joins11:18
[fcrepo-import-export] escowles force-pushed custom-tagfiles from 47c8ea4 to 3cd44b0: https://git.io/v1QOu
fcrepo-import-export/custom-tagfiles 3cd44b0 Esmé Cowles: Exporting all custom tags
* github-ff leaves
* github-ff joins
[fcrepo-import-export] escowles opened pull request #71: Exporting all custom tags (master...custom-tagfiles) https://git.io/v1QOV
* github-ff leaves
* github-ff joins11:21
[fcrepo-camel-toolbox] acoburn opened pull request #128: Start using released version of fcrepo-camel/4.5.0 (master...update_version) https://git.io/v1QO7
* github-ff leaves
* ajs6f joins11:22
* github-ff joins11:29
[fcrepo-camel] bseeger opened pull request #141: Addes link to 4.5.0 documentation. Fixes typo in 4.4.4 link. (gh-pages...gh-updates-4.5.0) https://git.io/v1Q3X
* github-ff leaves
* github-ff joins11:30
[fcrepo-camel] acoburn closed pull request #141: Adds link to 4.5.0 documentation. Fixes typo in 4.4.4 link. (gh-pages...gh-updates-4.5.0) https://git.io/v1Q3X
* github-ff leaves
<ruebot>whikloj: if i merge https://github.com/fcrepo4-labs/fcrepo-import-export/pull/71 is that going to mess you up?11:35
* github-ff joins11:36
[fcrepo-camel-toolbox] birkland pushed 2 new commits to master: https://git.io/v1QsV
fcrepo-camel-toolbox/master 456d9e3 Aaron Coburn: Start using released version of fcrepo-camel/4.5.0
fcrepo-camel-toolbox/master 0aa1a8a birkland: Merge pull request #128 from acoburn/update_version...
* github-ff leaves
* github-ff joins11:37
[fcrepo-camel-tests] acoburn opened pull request #17: update fcrepo-camel version to latest SNAPSHOT (master...version_update) https://git.io/v1Qs6
* github-ff leaves
* peichman leaves11:40
<ajs6f>ruebot: You (im/ex mob) are working on some kind of feature to convert hostname/repo uri base, is that correct?
<ruebot>ajs6f: not this sprint
<ajs6f>ruebot: But it is planned?11:41
<ruebot>ajs6f: yeah
https://jira.duraspace.org/browse/FCREPO-2335
<ajs6f>ruebot: Why doesn't the repo use relative URIs for in-repo links?
ruebot: I don't mean all the time, just, why can't it, at times when that is useful?
* manez leaves11:42
<ruebot>ajs6f: wouldn't that be an implementation thing? ...like how somebody implements fedora?11:44
ajs6f: oh wait, i think i see what you're saying
<ajs6f>ruebot: CAn you explain it to me? Id like to know.11:45
* github-ff joins
[fcrepo-camel-tests] birkland closed pull request #17: update fcrepo-camel version to latest SNAPSHOT (master...version_update) https://git.io/v1Qs6
* github-ff leaves
<ruebot>ajs6f: maybe this will help? https://github.com/fcrepo4-labs/fcrepo-import-export/pull/48
* github-ff joins11:46
[fcrepo-import-export] ruebot pushed 1 new commit to master: https://git.io/v1QGQ
fcrepo-import-export/master 80f8527 Nick Ruest: Merge pull request #71 from fcrepo4-labs/custom-tagfiles...
* github-ff leaves
<ajs6f>ruebot: I don't know. Does that do some kind of sed-y substitution?
ruebot: I guess my point is that if the ex relative-ises the URIs, the im doesn't have to do very much.11:47
<ruebot>ajs6f: oh, i was thinking the discussion between awoods and escowles on that PR
ajs6f: ...assuming we're talking about the same thing :-)
* travis-ci joins11:49
fcrepo4-exts/fcrepo-camel-toolbox#328 (master - 0aa1a8a : birkland): The build passed.
Change view : https://github.com/fcrepo4-exts/fcrepo-camel-toolbox/compare/85f691d18199...0aa1a8a4b4b1
Build details : https://travis-ci.org/fcrepo4-exts/fcrepo-camel-toolbox/builds/184583241
* travis-ci leaves
<ajs6f>ruebot: I think that is connected. The principle that I am trying to offer is "if a section of a server doesn't make an links outside of the server, it ought to be possible to export and import it using RDF in-between with no absolute URIs".
<ruebot>ajs6f: yeah, that makes sense
<ajs6f>There may be lots of ../../../.. and there may be RDF formats that don't work very well for this, but those are not the point11:50
<ruebot>ajs6f: yeah
<ajs6f>ruebot: And further, if the only absolute URIs in play point outside the repo (like to controlled vocab terms or whatever) then you don't have to do any URI munging in that process. Either to restablish a hostname/port etc, or to push some stuff to a different place in the same repo11:51
* kestlund joins11:52
<ajs6f>ruebot: So I think it follows that rather than work up code that mungs URIs on import, we might want to think about (contra your point about impl above, which I would normally agree with) a Prefer heeader value or something
ruebot: that basically means: "use relative URIs for all intrarepo URIs"11:53
<escowles_lunch>ajs6f: well, we'd still need to munge URIs for the client to know where to POST RDF to, but it would certainly make life easier if the RDF were all realtivized
<ajs6f>escowles: HOLY SH*&*)&*)T YOUR LUNCH CAN TALK
* coblej leaves11:54
<escowles>ajs6f: that was some pretty strong hot sauce...
<ajs6f>http://vignette1.wikia.nocookie.net/candh/images/b/b1/4-6.gif/revision/latest?cb=20120307030040
escowles_lunch: You need to deal with the points on the graphs.
That is true.
I'm just trying to separate what the client has to do (HTTP, like you say) and what the data actually is written down as (RDF, shouldn't care too much about HTTP).11:55
The graph should have the same shape, no matter what color ink you use to write it down.
* github-ff joins11:57
[fcrepo-import-export] escowles deleted custom-tagfiles at 3cd44b0: https://git.io/v1Qnt
* github-ff leaves
<ajs6f>Maybe that kind of Prefer header value is problematic, though. It's not selecting a portion of content for representation, it's changing syntactical stuff.
That kind of more like a miimetype. But mimetype is MUCH too blunt for this.
<escowles>Accept: text/turtle; charset=utf8; relativized=true11:58
<whikloj>sorry ruebot, as a rule always merge I'll do the rebase11:59
<escowles>Accept: text/turtle; charset=utf8; paper-or-plastic: i-brought-my-own-bag
<whikloj>got stuck in an informal chat
escowles++12:00
<ajs6f>You know, http://vignette1.wikia.nocookie.net/candh/images/b/b1/4-6.gif/revision/latest?cb=20120307030040
Whoops, old clipboard.
https://tools.ietf.org/html/rfc7240#section-5.1
makes me think that our Inbound-Links prefer header value is wrongish.
* awead joins
<ajs6f>"requested preferences do not constrain servers, clients, or12:01
any intermediaries to any behavior required for successful
processing; and
"
escowles: Hm, I guess. I don't like the fact that some clients won't know what the heck that means.
escowles: But maybe that okay.12:02
escowles:ruebot: Anyway, my only real point with all this is that if you separate HTTP questions (like as escowles said, "where should I post stuff") from data questions ("is there a relationship between these two resources?") you can solve each a lot more easily.12:03
<escowles>ajs6f: yeah, it's not a great idea — but it's the closest thing i can think of in the HTTP spec that i don't think would break anything else
<ajs6f>escowles: The whole idea of relative-ising is kind of questionable. I admit that up front.
escowles: It's maybe something that a specialized client should do on export as a processing step between retrieval and persistence.12:04
escowles: A flag for the im/ex tool.
Is there a streaming mode for the im/ex tool, so that you can just pipe a repo into another without disk in between?12:05
<escowles>ajs6f: maybe — i do think the export client could relativize stuff before writing to disk (at least writing relative to the exported resource instead of the URI root would address the main set of use cases)
ajs6f: no, but there's a ticket to do that https://jira.duraspace.org/browse/FCREPO-232512:06
<ajs6f>escowles: Yeah, that's what I mean. Let's stay away from server stuff. I think at least being _able_ to relativize on the way through export would be helpful for a lot of this stuff.
<awead>[Import/Export Standup]
Finished yesterday:
Travelled.
Working on today:
Nothing on my place. Ping me if you need something reviewed.
Blockers:
Meetings.
<ajs6f>escowles: Cool. I was just curious.
<escowles>ajs6f: yep — the design of the python verification tool made it possible to do that easily, and it made me think a refactor of the import/export tool to make that possible might be a good idea12:07
<ajs6f>escowles: If you had a mass of relativizedd RDF, and then you add one absoute URI, you could pin it all back up into a server.
escowles: Yeah, people with big binaries will thank you.
I love big binaries and I cannot lie.
<escowles>i hate big binaries and i cannot tell the truth.12:08
<ajs6f>I think that was a ant-Goedel statement.
anti
* kestlund leaves
<ajs6f>escowles: It doesn't even matter which resource gets the absolute URI. The graph is "rigid" like that.12:09
<escowles>awead: i think it would be great if you could test exporting bags again — we just switched to our own impl (instead of the LoC bagit-java), so the more testing we can do today the better
<ajs6f>escowles: And there are RDF formats that can deal with that. I don't know much about BagIt, but I would think there would be some way to do that.12:10
<escowles>ajs6f: as long as there aren't too many ../../../ to go up above the root path of the one fixed URI...
<ajs6f>escowles: It's a machine reading this. There can be fifty .. segments. Computer don't care.
escowles: But I'm just making the point about the minimal data needed.12:11
escowles: One absolute URI is enough, so sprinkling the data with them is overdetermining the solution => future brittleness.
escowles: I'm sure most people would like to see that absolute URI be the "least LDP-contained" resource.12:12
or one of them, if there are more than one
a "minimally-contained" resource, which is what I think a repository actually is.12:13
<escowles>ajs6f: yes, that sounds right to me — and i agree that's what most people would use to fix the graph
<ajs6f>escowles: Yeah, its physically intuitive. You hang a picture from a nail at the top, not the bottom.
<escowles>ruebot: what do you think about https://github.com/fcrepo4-labs/fcrepo-import-export/pull/69 — will it be too much of a hassle to update the docs today?12:14
<ruebot>escowles: i figured we could save it for the call. not a big hassle.12:15
<escowles>ruebot++
<ruebot>maybe awead or informatician want to help out with that?
* th5 joins12:17
* awead leaves
<whikloj>ruebot/escowles: Before I go crazy again, is this a fair way to deal with alternate profiles - https://gist.github.com/whikloj/f65de3d66f1acbecb3374d90e9fbebdf
<escowles>whikloj: i'm not sure what this line is for: https://gist.github.com/whikloj/f65de3d66f1acbecb3374d90e9fbebdf#file-aptrustprofile-json-L5612:18
is it to say "this is the APTrust profile" or "only do this if we're using the APTrust profile"?12:19
<whikloj>escowles: yeah...in hindsight I think it has no use. If we take that the key of any object in that array will became the name of the tag file12:20
<escowles>whikloj++ yes, i think that's simpler and covers our needs12:21
<whikloj>escowles++ # thanks
<escowles>that's also what the bag-config.yml file look like, so those being the same should help people out
<ruebot>escowles++ whikloj++
<escowles>ruebot: working on the premis ontology has taught me to try to remove every wrapper to make sure it is completely necessary12:22
* ruebot snorts12:23
<ajs6f>http://www.incpen.org/pages/data/201207171108Excessive-Packaging.jpg12:24
* ajs6f leaves12:26
* kestlund joins
* coblej joins12:54
* coblej leaves12:59
* peichman joins13:00
* coblej joins
* westgard1 joins13:05
* awead joins13:06
* westgard leaves13:07
* ajs6f joins13:09
* github-ff joins
[fcrepo-import-export] ruebot created update_version_readme (+1 new commit): https://git.io/v1Q0H
fcrepo-import-export/update_version_readme f6425f5 nruest: README updates
* github-ff leaves
<ruebot>acoburn: if i have a commit for the readme updates for the version number change, you want that as a pull against your pull, or you want to cherry-pick that in your pull, or just do two different PRs.13:11
https://github.com/fcrepo4-labs/fcrepo-import-export/commit/f6425f56749d99dd756bf54522e89b47c67def17
<acoburn>ruebot: however you like — my PR is just a two character change, you can easily just incorporate that into your PR and then close mine
* github-ff joins13:15
[fcrepo-import-export] ruebot pushed 1 new commit to update_version_readme: https://git.io/v1QE3
fcrepo-import-export/update_version_readme d3f3fe5 Aaron Coburn: update version to 0.1.0-SNAPSHOT
* github-ff leaves
<ruebot>acoburn: https://github.com/fcrepo4-labs/fcrepo-import-export/pull/72 :-)
* github-ff joins
[fcrepo-import-export] ruebot opened pull request #72: Update version readme (master...update_version_readme) https://git.io/v1QEn
* github-ff leaves
<ruebot>escowles, whikloj: you can merge that once it passes travis
<acoburn>ruebot++13:16
* kestlund1 joins
* kestlund leaves
<whikloj>ruebot++ acoburn++13:17
<ruebot>what's really cool is once #72 gets merged, #69 will automatically close :-)13:18
<whikloj>true dat13:19
* github-ff joins13:20
[fcrepo-import-export] whikloj pushed 1 new commit to master: https://git.io/v1Qug
fcrepo-import-export/master 23e7607 Jared Whiklo: Merge pull request #72 from fcrepo4-labs/update_version_readme...
* github-ff leaves
<whikloj>uhoh ruebot
<ruebot>oh, it didn't work!13:22
:-(
* github-ff joins
[fcrepo-import-export] ruebot closed pull request #69: update version to 0.1.0-SNAPSHOT (master...update_version) https://git.io/v1Hxj
* github-ff leaves
<whikloj>ruebot: quick 30 minute office potluck, be back for wrap up call and finish this ticket13:28
* informatician leaves13:32
* westgard1 leaves13:38
* westgard joins
* informatician joins13:48
* informatician leaves13:58
<ruebot>https://wiki.duraspace.org/display/FF/2016-12+Import+-+Export+Sprint+03+Meetings14:00
<escowles>stupid skype updates...14:01
<ruebot>awead, westgard https://wiki.duraspace.org/display/FF/2016-12+Import+-+Export+Sprint+03+Meetings -- sprint debrief14:02
<awead>on my way
* informatician joins
<ruebot>informatician: you joining us on the debrief?14:05
https://jira.duraspace.org/issues/?jql=project%20%3D%20FCREPO%20AND%20status%20in%20(Open%2C%20%22In%20Progress%22%2C%20Reopened%2C%20%22In%20Review%22%2C%20Received)%20AND%20component%20%3D%20f4-import-export
<awead>he’ll be on in a bit… he’s having some technical difficulties
<informatician>I'm in, apologies for tardiness ;)14:06
Righto
<ruebot>https://jira.duraspace.org/browse/FCREPO-2365
https://jira.duraspace.org/browse/FCREPO-232814:07
https://jira.duraspace.org/browse/FCREPO-232614:14
* peichman leaves14:15
<informatician>https://github.com/fcrepo4-labs/fcrepo-import-export-verify/pull/1714:19
* manez joins14:20
* dwilcox joins14:45
* dwilcox leaves14:58
* dwilcox joins
* dwilcox leaves
* dwilcox joins14:59
* awead leaves
* dwilcox leaves
* dwilcox joins15:00
* informatician leaves
* dwilcox leaves
* dwilcox joins
* dwilcox leaves15:01
* dwilcox joins
* dwilcox leaves15:02
* informatician joins15:04
* escowles leaves15:12
* escowles joins
* escowles_ joins15:21
<ruebot>https://github.com/LibraryOfCongress/bagit-python/issues/83#issuecomment-26768735615:24
* escowles leaves
<ruebot>oh well
<escowles_>ruebot: yeah, that's too bad — maybe we can revisit the next time we do an import/export sprint?15:25
<ruebot>escowles_: yeah. if you're open to it, i am.
<escowles_>all things being equal, i'd rather use their library than not — but getting stuff fixed was more important to me than waiting for them to get their stuff together15:26
* coblej leaves
<ruebot>escowles_: agreed15:27
* ajs6f leaves15:37
* kestlund1 leaves15:38
* kestlund joins15:43
* coblej joins15:47
* informatician leaves15:59
* ajs6f joins16:05
* escowles_ leaves16:07
* escowles joins
* dhlamb leaves16:32
* kestlund leaves16:52
* escowles_ joins16:53
* escowles leaves16:57
* coblej leaves
* acoburn leaves17:06
<whikloj>escowles_/ruebot: Sorry for the slowness here, tests were passing but the behaviour was reversed. I think I have it, but I also think I need to write some more tests to ensure I have caught all possiblities17:44
<ruebot>whikloj: no worries!17:48
* github-ff joins17:52
[fcrepo-import-export] whikloj created FCREPO-2365 (+1 new commit): https://git.io/v17TQ
fcrepo-import-export/FCREPO-2365 d4c8c3e Jared Whiklo: Validate for current profile only
* github-ff leaves
* github-ff joins17:55
[fcrepo-import-export] whikloj pushed 1 new commit to FCREPO-2365: https://git.io/v17kG
fcrepo-import-export/FCREPO-2365 12aadfb Jared Whiklo: Undo logging
* github-ff leaves
* github-ff joins
[fcrepo-import-export] whikloj opened pull request #73: Fcrepo 2365 (master...FCREPO-2365) https://git.io/v17kW
* github-ff leaves
* whikloj leaves17:58
* th5 leaves18:01
* ajs6f leaves18:09
* westgard leaves18:27
* kefo leaves19:11
* ajs6f joins19:18
* ajs6f leaves
* f4jenkins joins23:12

Generated by Sualtam