Log of the #duraspace-ff channel on chat.freenode.net

Using timezone: Eastern Standard Time
* Guest40520 leaves01:47
* dhlamb joins06:34
* dhlamb leaves06:43
* fcrepo-bot joins07:28
* fcrepo-bot leaves08:38
* Nianli joins09:01
* ajs6f joins09:03
* ajs6f leaves09:10
* whikloj joins09:17
* acoburn joins09:19
* acoburn1 joins09:25
* acoburn leaves09:26
* ksclarke joins09:29
* dwilcox joins09:31
* MohamedAR joins09:48
* MohamedAR leaves
* MohamedAR joins10:13
* MohamedAR leaves10:19
* Nianli leaves10:21
* ajs6f joins10:42
acoburn!1: See my comment to FCREPO-1385. I'm done with that, and not in the good way. {grin}10:43
<acoburn1>ajs6f: I saw your comments, and I think you're right about the kinds of headaches bnodes will continue to cause if fcrepo supports them10:44
ajs6f: there's an agenda item on the tech call related to bnodes10:45
but I think awoods was thinking this was more of an update on the issues
<ajs6f>acoburn1: Maybe we need to come back to that. There is, to my knowledge, exactly one use case. People who want to do "XML-style" RDF with bnodes. I was against accepting the case, but awoods decided to.10:46
acoburn1: escowles, I think, can speak to it a bit, because his institution does use that mis-pattern.
<acoburn1>awoods is out this week, and I'm leading the call
<ajs6f>acoburn1: Okay. Then we should talk about immedaite steps, which I think mostly involve reverting, at this point.10:47
<acoburn1>I don't know if this is the best week to get into the details of this, but it would certainly be worth raising the issues
yes, reverting may be the best path10:48
<ajs6f>acoburn1: it's basically a simple choice: do bnodes, in which case there is a subsidiary question of what color and texture of shit we end up smearing on our code, or don't do bnodes, in which case we have a big job in front of us communicating and working with the institutions who will complain.
acoburn1: At this point, I honestly don't care. I'm not willing to spend any more time with it.10:49
<acoburn1>ajs6f: I've communicated to my colleagues at Amherst that we will not be using bnodes in our implementation as long as I have a say in the matter
ajs6f: so it's hard for me to legitimize spending time on it either10:50
<ajs6f>acoburn1: Indeed. I wouldn't let that happen here, either, but it's more about the shoddy kind of metadata constructions jcoynes discusses as being important to Hydra. They seem already to have invested in mistakes.
<acoburn1>ajs6f: my only real opinion here is that our implementation makes sense. I felt that the previous impl fell short of that10:52
<ajs6f>acoburn1: Yes. The problem is that an impl that _does_ make sense is a huge investment.
<acoburn1>ajs6f: exactly, but there are also gradations of being consistent10:53
<ajs6f>acoburn1: Not sure what you mean?10:54
<acoburn1>ajs6f: nevermind, that doesn't make any sense
Fedora will make you feel that way.10:55
<ajs6f>Not it.11:01
* doylejo joins11:07
<whikloj>tech call: on/off?
If you join (or have joined) please make sure you are listed as an attendee at that page.11:08
<ruebot>what's the ticket? i can add it in the notes.11:11
* yinlin joins11:17
<terrellt>ajs6f: What are the bad metadata concerns jcoyne apparently brings up?11:21
"Don't do bnodes" sounds ominous.11:24
Especially for things like https://github.com/europeana/corelib/wiki/EDMObjectTemplatesProviders#edmTimespan, which the DPLA Application profile uses: http://dp.la/info/wp-content/uploads/2013/04/DPLA-MAP-V3.1-2.pdf11:26
<ajs6f>Sorry, just catching up on IRC. "Don't do bnodes" shouldn't sound too ominous in a Linked Data world. The real issue is: don't do _mutable_ bnodes, and that's what jcoyne was asking for.11:31
If your thing is mutable, it should be named.11:32
<terrellt>Is there documentation on what jcoyne's problem is?11:34
Because again, edm:TimeSpan as a requirement of the DPLA profile for describing dates seems like a big use case for blank nodes, ones whose metadata should be editable.11:35
<ajs6f>terrekllt: I have no idea whether jcoyne has documented what he requested. I completely disagree that edm:TimeSpan is a use case for mutable bnodes. It is, at most, a use case for immutable bnodes.11:36
terrellt: edm:TimeSpan is tiny. If you want to change a property of something else that is an edm:TimeSpan-valued property, delete the property and readd it.11:38
terellt: That is an immutable bnode.
<terrellt>So the proposal is pushing the complexity of changing bnode contents from the server to the client? That's not the end of the world, but yeah, it'll take some communication.11:40
<ruebot>notes have been deployed
<ajs6f>terrellt: At this point, there is no proposal. I have other things to do, and I have spent too much time with Fedora in the past few weeks.11:41
* jgpawletko joins11:42
* ksclarke leaves11:47
* ksclarke joins
* dwilcox leaves12:02
* doylejo leaves12:13
* dwilcox joins12:18
* gregjansen joins12:20
acoburn1: I am using your vagrant environment for workshop, are you around?12:21
<acoburn1>gregjansen: I'm around
<ajs6f>gregjansen: Is this going to be with your new training materials?12:22
<gregjansen>acoburn1: want to demo the solr and fuseki indexing in this workshop. Am I correct that the vagrant environment currently does indexing via message consumer? (I do see audit trail triple store over camel I guess)12:23
ajs6f: yup
<ajs6f>gregjansen: Rocktacular!
<gregjansen>ajs6f: thx man, trying to pull it together. impressed with camel.12:24
<acoburn1>gregjansen: I didn't actually set up the vagrant env
<ajs6f>Camel is a fine beast of burden.
<acoburn1>gregjansen: I think it's still using message-consumer, but I might be wrong
<gregjansen>acoburn1: aha, oops. Saw your name in github
<acoburn1>gregjansen: there are two projects (one is still an open PR) in the fcrepo-camel-toolbox for doing those kinds on indexing tasks with camel
* dwilcox_ joins12:25
<gregjansen>acoburn1: I think so too, but andrew may have added the one camel app (for triple audit)
<acoburn1>gregjansen: yes, the audit workflow is part of vagrant, and it uses camel
gregjansen: it's the other two pieces (fcrepo -> solr) and (fcrepo -> external triplestore) that isn't yet part of the vagrant vm12:26
<gregjansen>Right, so these camel routing apps are to be deployed as separate WARs in tomcat (at least for current purposes)
<acoburn1>gregjansen: there are several deployment options: OSGi and WAR
<gregjansen>acoburn1: aha, okay. I see the indexes are installed, but there is no wiring to them yet? Or is the message consumer deployed?12:27
<ajs6f>gregjansen:acoburn1: acoburn1 has pointed out that the multiply-wars effect isn't necessary, but we have not yet got to the point where either:
* dwilcox_ leaves
<ajs6f>1) We could deploy an OSGi container inside a repo or
2) We can reasonaby expect people to take up Karaf or the like automatically.
* dwilcox leaves
<acoburn1>ajs6f: we can also create pre-configured karaf containers that someone just downloads and starts12:28
<gregjansen>ajs6f: seems reasonable, I was thinking to point at Karaf as a recommendation, but not demo it. too much to learn in one session is bad.
<ajs6f>acoburn1: That might indeed be the best place to start.
gregjansen: Yes, indeed. And Karaf is a big thing to learn.
<acoburn1>and OSGi is a big thing to learn12:29
<gregjansen>okay, separate WARs is fine for now.. Just one container in this workshop so far (I think)
<acoburn1>gregjansen: as for the separate WARs, while it's possible to create a single war that contains all of this routing logic, in my experience, it is vastly preferable to keep these services separate12:30
* dwilcox joins
<acoburn1>that way, you have a solr indexing service that is entirely separate from an audit trail service, etc, etc12:31
gregjansen: but please feel free to ping me with questions about this12:32
* dwilcox leaves12:33
<gregjansen>acoburn1: thanks very much. you will likely hear from me soonish. I will be trying to use the fcrepo/fcrepo-camel examples12:34
<acoburn1>gregjansen: the better examples are in https://github.com/fcrepo4-labs/fcrepo-camel-toolbox12:35
<gregjansen>acoburn1: okay, will look there as well. Those are better examples, but still depend upon the fcrepo-camel implementation, correct?
<acoburn1>and: https://github.com/acoburn/fcrepo-camel-toolbox/tree/fcrepo-1466b/indexing-triplestore12:36
gregjansen: yes, they depend on fcrepo-camel
the routing logic is pretty concise. For example: https://github.com/acoburn/fcrepo-camel-toolbox/blob/fcrepo-1466b/indexing-triplestore/src/main/java/org/fcrepo/camel/indexing/triplestore/TriplestoreRouter.java
for indexing objects in an external triplestore12:37
<ajs6f>Concision is the great advantage of a dsl.
<acoburn1>and for solr indexing: https://github.com/fcrepo4-labs/fcrepo-camel-toolbox/blob/master/indexing-solr/src/main/java/org/fcrepo/camel/indexing/solr/EventRouter.java#L6612:38
* dwilcox joins12:58
* github-ff joins13:20
[migration-utils] mikedurbin pushed 1 new commit to master: http://git.io/vJY6n
migration-utils/master f110262 Nianli Ma: https://jira.duraspace.org/browse/FCREPO-1413: apply and pass the checkstyle rule.
* github-ff leaves
* dwilcox leaves13:30
* awead_ joins13:39
* acoburn2 joins
* acoburn2 leaves