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

Using timezone: Eastern Standard Time
* github-ff joins04:24
[fcrepo4-swordserver] claussni pushed 1 new commit to master: https://git.io/vruI0
fcrepo4-swordserver/master 8fc6868 Ralf Claussnitzer: Bump Fedora version to 4.5.1
* github-ff leaves
* travis-ci joins04:31
fcrepo4-labs/fcrepo4-swordserver#61 (master - 8fc6868 : Ralf Claussnitzer): The build passed.
Change view : https://github.com/fcrepo4-labs/fcrepo4-swordserver/compare/9fb15f4b44f5...8fc68687c66f
Build details : https://travis-ci.org/fcrepo4-labs/fcrepo4-swordserver/builds/131634497
* travis-ci leaves
* anarchivist leaves06:25
* anarchivist joins06:26
* arebenji joins07:28
* dwilcox joins08:11
* acoburn joins08:43
* dwilcox leaves08:44
* whikloj joins08:53
* dwilcox joins08:54
* apb18 joins09:01
* jcoyne joins09:07
<ruebot>awoods: is it fine for me to edit this page? https://wiki.duraspace.org/display/FEDORA4x/Configuring+JDBC+Object+Store -- fcrepo.mysql.password/username should fcrepo.ispn.mysql.password/username09:13
<awoods>ruebot: please
<ruebot>awoods: cool. that was my issue with getting fcrepo4 and mysql up the other day. just talked it out with whikloj :-)09:15
awoods: you want me to do test 2 or 3 with apb18's merged PR?
<awoods>ruebot: test 3, please09:18
* dwilcox leaves
<whikloj>ruebot/awoods: I'm guessing that the PostgreSQL JAVA_OPTS will also need to be updated.09:23
<awoods>whikloj/ruebot: I updated the JAVA_OPTS on the bleeding edge page due to changes in the Modeshape5 branch to take out "ispn"... but that was apparently premature.09:26
<ruebot>awoods: oh! that makes sense.09:27
* ajs6f joins09:35
awoods: Do you know who Arnaud represents?09:42
<awoods>ajs6f: no09:43
ajs6f: the short answer is, don't cluster.
<ajs6f>awoods: these people just keep coming out of the woodwork.
<awoods>ajs6f: apparently people use Fedora.09:44
<ajs6f>awoods: I know the answer, too. But I also know (as do you) that we need to have solutions for the needs behind clustering.
awoods: Organizations use Fedora. People put up with Fedora.
* peichman joins09:48
<ajs6f>awoods: Maybe it's time to commit to asynchrony for clustering. We went there for indexing and the sky didn't fall.09:50
<peichman>acoburn: regarding the fcrepo-indexing-solr and ssl issue, I've asked Mohamed to get in touch with you about a patch he has for adding ssl support09:51
<acoburn>peichman++
<awoods>ajs6f: That could be something very interesting to explore: taking clustering into our own hands vs. hoping the underlying system will handle it. On the other side, databases cluster, and filesystems can be shared... what is the use case that drives people to "Fedora Clustering"?09:54
<ruebot>awoods: ./jmeter -Dfedora_4_server=zeta.library.yorku.ca -Dfedora_4_context=fcrepo/rest -Dfilesize_min=10240 -Dfilesize_max=102400 -Dbinary_threads=1 -n -t /home/nruest/git/fcrepo4-jmeter/fedora.jmx
awoods: that look right for test #3? it keeps on exiting right after i start it.
<awoods>ruebot: what is the error?09:55
<ruebot>awoods: don't see anything in catalina.out, or anything locally in the summary log
<ajs6f>awoods: THAT is the question. Some people are trying to buy a sense of security. Some people are trying to buy scale without having to design for it. I think further investigation is warranted.
<acoburn>awoods/ajs6f: the answer depends entirely on the question "what is the use case"
* mikeAtUVa joins09:56
<acoburn>it could be fault tolerance, it could be request speed, it could be data partitioning
each of those suggests a slightly different architecture
<awoods>ruebot: I wish I could help debug
<ajs6f>acoburn:awoods: Right now our answer could be "We thought we could kick the problem off to MODE. MODE kicked it back at us. We are kicking it up the alley to a hypothetical multi-impl future."
<ruebot>awoods: aye. i'll keep on troubleshooting.09:57
<acoburn>ajs6f:awoods: sharding would be easy were it not for ldp containment and membership triples09:58
<ajs6f>acoburn: Easy? Well, easier.
<acoburn>s/easy/somewhat easier/09:59
<ajs6f>Maybe we really should punt. This is, after all, exactly why we decided to publish an API.10:00
* xenthree3 joins
* xenthree3 leaves
<mikeAtUVa>awoods, acoburn: it would be an unacceptable reversion to have fedora4 return modification dates that are earlier than creation dates, right?
<acoburn>mikeAtUVa: I think it would just be weird if last-mod < created10:01
* bseeger joins
<awoods>mikeAtUVa: correct
<mikeAtUVa>awoods: it doesn't look like the method getTimestamp or even GetLastModifiedDate() intermediate all accesses to the last modification date... so I'm not quite sure where else I have to add our little clean-up hack.10:06
awoods, acoburn: I'm happy to keep looking... I'm sure I'll learn something, but tapping your wisdom would save time.10:07
<awoods>mikeAtUVa: I wonder if that argues for option #1
<ajs6f>mikeAtUVa: Are these the methods on FedoraResource you are talking about?10:08
* th5 joins
* dwilcox joins10:09
<mikeAtUVa>ajs6f: yeah.. per this conversation https://github.com/fcrepo4/fcrepo4/pull/1039/files/5ee30e831b5ecb5283ebfc10c8a2a188c98b9987#r63986258
Could we just not store a modification date at all when we first create a resource?
<ajs6f>mikeAtUVa: You do what you go to do for the immediate problem, but if info about resource type X is not being intermediated by our explicit abstraction for resource type X, that's a bug. Period. All of this stuff should be coming through FedoraResource. If you can find examples of it being derived by other means, that's a ticket.10:10
<mikeAtUVa>ajs6f: oh, I think it comes through FedoraResource, just not that one method... I'd probably have to update the code that streams the properties...10:11
ajs6f: ... which uses crazy new java constructs that hurt my poor java2 head...10:12
<ajs6f>mikeAtUVa: Ah, right. Yes, if we have a sophisticamated way of doing dates, the triples methods should use it. It could be annoying, but it's the right thing to do. It will almost certainly pre-fix some future bugs.
mikeAtUVa: Welcome to the future. Here are your cool wraparound sunglasses and mylar clothing.
<awoods>mikeAtUVa: I wonder if we are trying to patch a problem that would be resolved with option #1.10:13
mikeAtUVa/acoburn: this is a blocker... which has the potential of requiring a rollback of: https://github.com/fcrepo4/fcrepo4/commit/04d534da3b446feca644b83e11667a04e011397510:14
<mikeAtUVa>ajs6f: I'd like to explore awoods suggestion... but also, could we just not store a modification date on create. I imagine *someone's* written code to count on modifcation date always being present, but could our spec omit it when it's just a dupe of the creation date anyway?
<awoods>mikeAtUVa: there are two modification dates: jcr and fedora... that is the basis of: https://github.com/fcrepo4/fcrepo4/commit/04d534da3b446feca644b83e11667a04e0113975
<acoburn>awoods: yes, but jcr:lastModified is _really_ problematic10:15
<ajs6f>mikeAtUVa: I'm not sure, but I should think that last mod is not a strange or unusual need.
<ruebot>awoods, acoburn: so, i think i need to do a bit of maintenance on the basebox before i can merge the pr. https://gist.github.com/ruebot/45dbef8ab5bddff44604b10b42f4233c
awoods, acoburn: do you want me to do a new ticket, or a pull against acoburn's pull?
<ajs6f>Just thinking out loud: if we had a guaranteed-available and well-constructed stream of audit events, we wouldn't need last mod to be available independently. Last mod would just be the date of the last audit event.10:16
Maybe people who write code against last mod should just install audit and write against that?
<awoods>ruebot: probably a new ticket, if the base box just needs some cleanup.
<ruebot>awoods: aye. i'll create more work for myself :-)10:17
<awoods>ruebot: small, organized, isolated pieces of work.10:18
* icarus330 joins10:20
* icarus330 leaves
<mikeAtUVa>awoods, ajs6f: alright, I'll see if I can update our FedoraResource implementation to always perform our fancy date illusion whenever the modification date is returned, if it's too hard or I find a confounding problem I'll look into the double-save correction approach.10:25
<awoods>mikeAtUVa++10:26
<ajs6f>mikeAtUVa++
* kefo joins10:41
* mcritchlow joins10:49
* github-ff joins11:00
[fcrepo4] acoburn opened pull request #1040: Fix ETag handling for Binaries and Binary descriptions (master...fcrepo-1983) https://git.io/vrzfz
* github-ff leaves
* github-ff joins11:11
[fcrepo4] awoods closed pull request #991: eTags should be Weak eTags (master...FCREPO-1754) https://git.io/v2GLq
* github-ff leaves
* github-ff joins
[fcrepo4] awoods closed pull request #920: change strong ETags to weak ETags (master...fcrepo-1754) https://git.io/vWKvH
* github-ff leaves
* mikeAtUVa leaves11:24
* bseeger leaves11:48
* jcoyne leaves11:51
* jcoyne joins11:55
* jgpawletko joins12:04
* jgpawletko leaves12:28
* dwilcox leaves12:30
* bseeger joins12:35
* osmandin joins12:39
* jcoyne leaves12:48
* peichman leaves13:01
* peichman joins13:03
* mcritchlow_ joins13:10
* mcritchlow leaves
* mcritchlow_ leaves13:14
* jgpawletko joins13:15
* jcoyne joins13:21
* jgpawletko leaves
* bseeger leaves13:43
* bseeger joins13:49
* peichman leaves14:05
* peichman joins14:09
<awoods>ajs6f: can you take a look and close this ticket: https://jira.duraspace.org/browse/FCREPO-190914:13
* awoods lunchtime14:14
* jcoyne leaves14:15
<ajs6f>Yeah, I'll buy that. closing14:16
<ruebot>awoods, acoburn: building a new base box now, and i'll get it uploaded this afternoon.
<ajs6f>acoburn: seriously, why can't we say that an RDF resource describes itself?14:27
<acoburn>ajs6f: I don't see why it couldn't
<ajs6f>acoburn: we have that bit of code all over: "this thing, if it is an RDF resource, otherwise, cast this thing and get the thing that describes it". That would collapse to just "this thing".14:29
<acoburn>ajs6f: I agree; my only question is whether it should be part of the PR I submitted or part of a separate effort14:30
<ajs6f>acoburn: separate, definitely
<acoburn>ajs6f: that's what I think, too
<ajs6f>acoburn: Also, we could have fun with a new subclass of FedoraResourceImpl: FedoraResourceWithProvenance, which is described by something that isn't itself.14:31
<acoburn>ajs6f: that is an interesting notion of "fun"14:32
<ajs6f>acoburn: Anyway, I'll bring it up at the next tech call
acoburn: This is Fedora. Lower your expectations.
<acoburn>ruebot: this is for you: https://jira.duraspace.org/browse/FCREPO-203314:34
<ruebot>acoburn: aye14:47
* github-ff joins
[fcrepo4-client] ruebot closed pull request #39: Add deprecation notice (master...deprecation) https://git.io/vrEfW
* github-ff leaves
* travis-ci joins14:54
fcrepo4-labs/fcrepo4-client#100 (master - 21eaf27 : Nick Ruest): The build passed.
Change view : https://github.com/fcrepo4-labs/fcrepo4-client/compare/6da86ac9bcb0...21eaf27200c5
Build details : https://travis-ci.org/fcrepo4-labs/fcrepo4-client/builds/131776978
* travis-ci leaves
* ajs6f leaves15:05
* ajs6f joins15:06
* jcoyne joins
<ajs6f>acoburn: You give examples of RDF in various forms for that messaging ontology, which is cool. Have you noticed that a lot of the W3C specs will let you select which RDF serliazliation you want to see with a switch on the page. I wonder if they have a reusable technique for that we could steal.15:07
<acoburn>ajs6f: that would be very cool15:08
<ajs6f>acoburn: I'll make a ticket for awoods.15:09
<ruebot>awoods, acoburn: https://atlas.hashicorp.com/fcrepo/boxes/fcrepo4-base -- done there.15:25
* github-ff joins15:26
[fcrepo4-vagrant] ruebot pushed 1 new commit to master: https://git.io/vrzQx
fcrepo4-vagrant/master a58133d Aaron Coburn: Omit ldp:contains triples from triplestore sync (#46)...
* github-ff leaves
* jcoyne leaves
* jcoyne joins15:27
<ruebot>awoods, acoburn: you'll need to do a `vagrant box update` on vagrant now, and we're good.15:28
<awoods>ruebot: great15:30
* osmandin_afk leaves15:38
* tjohnson joins15:55
<awoods>acoburn: I just started up the updated vagrant (with inferencing) and am not seeing what I would have expected.
acoburn: The fuseki is initially loaded with inferencing triples...15:56
<acoburn>awoods: yes, that is typical
<awoods>acoburn: but when I create a small hierarchy of Fedora resources...
acoburn: I am not seeing auto-created ldp:contains triples.15:57
acoburn: I thought the ldp:contains would come from: https://github.com/fcrepo4-exts/fcrepo4-vagrant-base-box/pull/3/files#diff-6e16a2e39e7246b41c4d73f1a8c89046R38
<acoburn>awoods: that's what I would expect15:58
<awoods>acoburn: should this statement be reversed?
<#fedoraInf> ja:literalContent "<http://fedora.info/definitions/v4/repository#hasParent> owl:inverseOf <http://www.w3.org/ns/ldp#contains>" .
<acoburn>awoods: meaning, I would expect the ldp:contains triples to be there
<awoods>acoburn: i.e. <#fedoraInf> ja:literalContent "<http://www.w3.org/ns/ldp#contains> owl:inverseOf <http://fedora.info/definitions/v4/repository#hasParent>" .15:59
<acoburn>awoods: I have inferencing working properly on fuseki 2.4.0 at Amherst16:01
<ajs6f>acoburn: https://jira.duraspace.org/browse/FCREPO-2034
<acoburn>it uses fedora:hasParent owl:inverseOf ldp:contains16:02
(with the URIs spelled out fully)
ajs6f++
awoods: I can then query '?s a fedora:Resource . ?s ldp:contains ?o'16:03
awoods: and I get back the full set of expected results
awoods: https://gist.github.com/acoburn/0a46788cfac209eb9930d32825127b1816:04
<ajs6f>awoods: I'm pretty sure owl:inverseOf is symmetric. Why would the direction matter?16:05
awoods: Yeah, just checked that. It is symmetric. Which makes sense.16:06
<acoburn>awoods:ajs6f: yes, owl:inverseOf is definitely symmetric16:07
<ajs6f>awoods:acoburn: Although left and right inverses are interesting to think about in this context.
acoburn: You want fun? Now _that's_ fun.
<acoburn>ajs6f: especially on a Friday afternoon16:08
<awoods>acoburn: This line is absent from the vagrant config: https://gist.github.com/acoburn/0a46788cfac209eb9930d32825127b18#file-gistfile1-txt-L30
acoburn: if that makes a difference16:09
<acoburn>awoods: yeah, you shouldn't need it
awoods: this is our configuration at amherst
awoods: you'll notice it assumes the ontologies are located in a certain place on the filesystem, etc, etc
<awoods>acoburn: I need to step out. Is it best to rollback the following commit and address it later? https://github.com/fcrepo4-exts/fcrepo4-vagrant/pull/4616:10
acoburn: I did not get a chance to test this before that ticket was merged.
acoburn: I can look into it this weekend.
<acoburn>awoods: I am going to be in Amherst next week — maybe I can actually download the whole vagrant thing while I'm there16:11
<awoods>acoburn: as you noted, none of the filesystem ontologies are mentioned in: https://github.com/acoburn/fcrepo4-vagrant-base-box/blob/8bd4939e14eddcebf996e8087ad9a7f3a70b341c/config/test.ttl16:12
<acoburn>awoods: right, I was simply giving you a configuration that is currently working for us16:13
awoods: it would need to be adjusted, but it is a good starting point
awoods: but having those additional ontologies sure is nice
<awoods>acoburn: it is probably not a big deal to fix... it just got committed before being tested by anyone.
<acoburn>awoods: I'm sure it's something simple
<awoods>acoburn: I will check on it later.16:15
All: btw, I will be out Mon - Thurs next week at TCDL.16:17
* arebenji leaves16:18
* th5 leaves16:22
* ajs6f leaves16:23
* dwilcox joins
* ajs6f joins16:25
* dwilcox leaves
* ajs6f leaves16:30
* ajs6f joins16:32
<peichman>acoburn: so I tried out the namespace util, and I have managed to get my repo into an unstartable state16:39
<acoburn>peichman: how did that happen?16:40
<peichman>acoburn: "org.modeshape.jcr.value.ValueFormatException: Error converting "acl:Authorization" from String to a Name" on startup, both when I try to start up the webapp and when trying to start the namespace util again
<ajs6f>awoods: is that going to be held at the J.J. Pickle Research Campus of UT Austin?
* jcoyne leaves
<peichman>acoburn: I'm not sure, I changed a handful of prefixes, including the W3C one for WebAC (which was ns006 on my install, I entered acl as the new prefix016:41
acoburn: at the bototm of the stack trace it reports "org.modeshape.jcr.value.NamespaceException: There is no namespace registered for the prefix "acl""
acoburn: any pointers on fixing that?16:42
<acoburn>peichman: acl:Authorization would be a registered type and can't be changed
peichman: I'd change the namespace back to what it had been previously
<peichman>acoburn: the tool let me change it, although it didn't let me change pcdm (which was also registerd as a type)
<acoburn>peichman: that's strange
<ajs6f>peichman: how did you get it to be ns006 to begin with? did you "manually" register that ns prefix before using WebACL16:43
?
<peichman>acoburn: and now I can't even get the util to start; its printing the stack trace and hanging, and not giving me the list of registered prefixes
ajs6f: I think it was due to some hydra experimentation
ajs6f: before we started our WebAC work16:44
<ajs6f>acoburn: this seems like it's about what to do about ns prefixen coming from MODE config docs
<acoburn>peichman: I've only used this on a repo with maybe 100 objects16:47
<ajs6f>acoburn: But are you using the JCR API in your util?
<acoburn>ajs6f: yes, it's all JCR
<peichman>acoburn: I'm also using it on a tiny dev repo, ~90 objects
most of those are just containers
<ajs6f>acoburn: You would think MODE would not let you do something that would blow out like this?
<acoburn>peichman: at least it's not on your production system
<peichman>acoburn: for reals16:48
<acoburn>ajs6f: you would think
<ajs6f>Fedora 4: "At least it's not your production system."
<peichman>ajs6f++
<ajs6f>peichman: Just to try to recover, can you try changing the config-doc prefix for WebACL's ns to ns006?
peichman: Back to ns006, I mean?16:49
<peichman>ajs6f: where would I do that?
<ajs6f>acoburn:peichman: Unless acoburn has other ideas?
<acoburn>ajs6f: you mean the cnd file?
<ajs6f>peichman:acoburn:: Yes, the CND file. Because it's a desperate attempt to get the config files and repo in alignment.
peichman:acoburn: misalignment between them is my guess at why the repo won't start (the repo won't start by itself or with the util for the same reason, I would think).16:50
peichman: What have you got to lose?
peichman: Besides valuable time you could be spending on more profitable activities.16:51
<acoburn>ajs6f: I think the cnd file is embedded inside one of the fcrepo jars
<peichman>acoburn: we explode our jars, so I can try changing the exploded version16:52
<acoburn>peichman: looks like you can define it in the repository.json file16:53
<peichman>acoburn: taking a look at that now
<acoburn>peichman: the question is whether you can specify a filesystem location
<ajs6f>"Exploding jars" is what Fedora is all aout.
<peichman>"node-types" : ["fedora-node-types.cnd"]
<ajs6f>peichman: I believe that that's a classpath, relative location, under most circumstances.16:54
<acoburn>peichman: yes, classpath location
<peichman>ajs6f: looks like, since "find -name fedora-node-types.cnd" returns nothing
<ajs6f>peichman:acoburn: MODE maintains its own custom config-and-wiring system, which has been an annoyance to us for several years now.
peichamn: But if you are using exploded jars, your classpath is "visible" in your filesystem.16:55
<peichman>ajs6f: I misspoke, that should've been exploded *wars*16:56
ajs6f: i.e., the fcrepo-webapp-plus.war; all its jars are still packed up tight
<ajs6f>peichman: That's okay, you could stick something in WEB-INF/classes, I believe, although we are getting dangerously close to touching classloaders.
Basing your application on messing with classloaders is only a few steps away from CROSSING THE STREAMS.16:57
<peichman>ajs6f: since this is not a production system, I'd be fine with a nuclear option of deleting and recreating the repo, if that would fix the problem
<acoburn>peichman: you could also just `rm -rf fcrepo4-data` and start over
<ajs6f>peichman: At this point, yes. The only benefit to recovering would be to file a better bug report for acoburn to work on.
peichman:acoburn: Cause I'm guessing that's what the product of this conversation is going to be.
<peichman>ajs6f: good point; I will attempt a more controlled detonation next week so I can give acoburn better info16:58
<acoburn>peichman: I will look forward to it
<peichman>ajs6f:acoburn: but I would rather leave work Friday afternoon with a functioning repo :-)
<ajs6f>acoburn: Here is your bug report: https://www.youtube.com/watch?v=gwBF23Z52Co16:59
<acoburn>ajs6f++
<peichman>ajs6f++
<bseeger>ajs6f++
<ajs6f>peichman: `rm -rf fcrepo4-data` and restart and there's your functioning repo. I don't know why we don't answer _all_ the bug reports with that.
* bseeger leaves17:04
<peichman>ajs6f:acoburn: I am happy to report the nuclear option worked, and now all I have living on my repo are ants and cockroaches (i.e., my backup data)17:07
<acoburn>peichman: an excellent way to start the weekend
<ajs6f>afk bb on Monday17:08
Have a good weekend all...
* ajs6f leaves
* acoburn leaves17:15
* apb18 leaves
* mcritchlow joins17:31
* whikloj leaves17:45
* apb18 joins17:47
* peichman leaves
* jcoyne joins17:50
* jcoyne leaves
* jcoyne1 joins
* mcritchlow_ joins17:54
* mcritchlow leaves17:57
* apb18 leaves17:59
* mcritchlow_ leaves18:16
* jcoyne1 leaves18:43
* dwilcox joins20:05
* dwilcox_ joins20:09
* dwilcox leaves
* kefo leaves21:13
* dwilcox_ leaves22:05
* jcoyne joins22:09
* dwilcox joins22:14
* jcoyne leaves22:15
* dwilcox_ joins22:17
* dwilcox leaves22:19
* jcoyne joins22:30
* dwilcox_ leaves22:36
* jgpawletko joins23:54
* jgpawletko leaves00:20
* jcoyne leaves01:02