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

Using timezone: Eastern Standard Time
* ksclarke leaves02:51
* fcrepo-bot joins04:28
* fcrepo-bot leaves05:30
* ksclarke joins09:43
* ajs6f joins10:27
* osmandin joins10:36
* edInCo joins10:49
* escowles joins10:59
<ajs6f>Hangout today?
<cbeer>ajs6f: awoods said RT
<ajs6f>The crappy ReadyTalk line? Sure.11:03
* ermadmix joins11:05
<cbeer>ajs6f: RDF doesn't have any notion of "primary type" right?11:13
i've been making that assumption, but realized i should probably validate it11:14
<ajs6f>cbeer: Not to my knowledge. Remember, RDF doesn't understand or contemplate classes, at all.
In OWL, we could discuss the types of a resource with the shortest possible path to owl:Thing, but that's kind of goofy.11:15
<cbeer>ajs6f: right. and if they don't, it still seems weird to try to shoe-horn that concept into our API.. or, we end up introducing two potentially conflicting type-systems
<ajs6f>cbeer: Agreed.
I suppose we could imagine RDF "primary types" to be those types of a resource which have no supertypes?11:16
<cbeer>i'm still not convinced the idea of a primary type is actually useful11:23
<ajs6f>cbeer: I agree, that's why I want to talk only about "types".
<osmandin>AFK. I have to run to a meeting.11:27
<cbeer>ajs6f: what can you express with JCR primary types that you can't with mixins?
<ajs6f>cbeer: I know of nothing.11:28
cbeer: I'm trying to avoid distinguishing them while still allowing people like Stefano to explore them.11:29
<cbeer>ajs6f: ok. i'm scared that people will explore them and end up making some pretty scary applications11:31
<ajs6f>cbeer: I'm looking forward to seeing the horror movie.11:33
<cbeer>awoods: ok. so, here's the use-case that may get broken by allowing primary types..11:34
awoods: you have an islandora app running against fcrepo4 that uses primary types to declare things are islandora:objects or whatever11:35
and islandora:object nodes require a couple different properties
this means you can't drop in a hydra app on top of that fcrepo4 repo
and have it operate against those islandora nodes natively
and that's something you can do in fcrepo3, because no type validation is preventing that11:36
* gregjansen joins
<ajs6f>cbeer: Wouldn't that be true w/ or w/o this change?
The properties would block you.
<cbeer>and without primary types, we're allowing fcrepo4 to support some sort of open world assumptions.. or, the only assumptions there are those we impose at the fcrepo4 level, not the app level
<ajs6f>cbeer: Is that just bad ontology on the part of Islandora and Hydra11:37
<gregjansen>cbeer: if someone can repaste anything important I will put this in notes..
<cbeer>ajs6f: except we said CNDs are a bad place to do required properties for validation
<ajs6f>Shouldn't they both be inheriting from some other primary type?
08:34 ] cbeer> awoods: ok. so, here's the use-case that may get broken by allowing primary types..
08:35 ] cbeer> awoods: you have an islandora app running against fcrepo4 that uses primary types to declare things are islandora:objects or whatever
08:35 ] cbeer> and islandora:object nodes require a couple different properties
08:35 ] cbeer> this means you can't drop in a hydra app on top of that fcrepo4 repo
08:35 ] cbeer> and have it operate against those islandora nodes natively
08:36 ] cbeer> and that's something you can do in fcrepo3, because no type validation is preventing that
<ajs6f>cbeer: We said that? CNDs are a bad place for that?
<cbeer>ajs6f: sure.. but, if they do that.. why use primary types at all?
ajs6f: didn't we? i think we have a whole wiki page about the problems around validation11:38
<ajs6f>cbeer: Because they (Hydra and islandora) may have subtypes of their own with additional semantics.
<cbeer>ajs6f: but they're additive
<ajs6f>cbeer: I bet we do (have a wiki page somewhere).
<cbeer>"Scott Prater wants to create a wiki page documenting how to represent a fedora 3 content model as a fedora 4 CND, figure out how to ingest it and add objects."11:39
not sure where that is
<ajs6f>cbeer: sure. I still don't see the blocker here. Problem, yes, but for the Hydra and Islandora communities, not the Fedora core.
<escowles>cbeer: https://wiki.duraspace.org/display/FF/How+to+Migrate+a+Fedora+3+Content+Model+to+a+Fedora+4+Node+Type
<cbeer>ajs6f: well, sure. but if we don't need to provide that much rope, why do it?11:40
escowles: thanks. it looks like sprater got around whatever problem we uncovered with using mandatory properties11:41
<ajs6f>Well, I want a big juicy steak for lunch, but I'm not going to get it.11:42
Just beans tacos.
cbeer: We do need to — Stefano wants it.
cbeer: Generally, I'm always in favor of letting people play with power tools. I don't feel responsible for their maimed limbs or blood loss.11:43
<cbeer>ajs6f: he says he wants it.
i'm not sure he needs it, or the other tools we provide would do just as good a job
<ajs6f>cbeer: I'm not sure he does, either. I'd rather he try. (Actually, I'm not sure I can think of how he would create the restrictions he discussed without primary types.)11:44
<barmintor>sorry, swooping in: 1) If you're talking about representing FCR3 CModels as JCR types, primary types would never enter into the equation. 2) If all your new pTypes have to inherit from jcr types anyway, what does it give you over mixin types? 3) If you are determined to jeopardize yourown objects FCR4 compatibility, you can always work directly against MODE APIs, no?11:45
<cbeer>i'm dropping off11:48
<ajs6f>1) I'm not sure FCR3 is relevant— Stefano is not migrating. 2) They don't, so that's not an issue. 3) If you can get access to that API. We offer no way to do that now.
<barmintor>ajs6f: Are there not a number of places in the FCR codebase in which we assume jcr core types? If so, why would FCR4 offer an API to break your objects?11:50
<ajs6f>barmintor: I don't know that there are (those places) and if they are there, I'd like to get rid of them11:51
<barmintor>Hmm… I feel like we danced to this song before.11:52
<ajs6f>barmintor: Very possibly.
Special topic call?
* barmintor is firing up Eclipse11:54
* escowles leaves11:59
<awoods>I have to drop
* edInCo leaves12:05
<ajs6f>barmintor/cbeer: It occurs to me that I'm still playing a theme I started about a year and a half ago, near the beginning of this fcrepo4 thing. I want to move from the world of fcrepo<4, in which Fedora objects come into existence via action against the official API, to a world in which Fedora objects are recognized as such by proving to be valid for a certain type (procedure -> prescription). That's why I'm not worried about letting people like Stefano br12:06
<barmintor>ajs6f: Sure- that's why we made the fedora jcr types mixins12:08
<ajs6f>barmintor: Sure, and I think everyone is good with that. The question is whether it goes far enough.
If our code doesn12:09
t depend on particular primary types (and I don't think it should) then there should be no harm at all in allowing people to manipulate them, just as we let them manipulate mixins that aren't fedora mixins.12:10
<barmintor>"letting them do it" and "writing a REST API to do it" are different things, though
<ajs6f>"manipulate them" = manipulate primary types.
barmintor: True that, but in the current absence of any other way to expose functionality…12:11
We have an internal Java API, but no way to expose it.
Not even RMI.
I think again of the idea of offering the MODE HTTP API alongside ours, for the Stefanos of the world...12:12
<barmintor>But we don't have that Java API
exactly, that's MODE's API
<ajs6f>We don't offer MODE's APIs, Java or HTTP, right now.12:13
Theres no way to get at them from outside the repository itself.
Maybe we _should_.
That would answer all of the "power user" needs at once.
And give them enough rope to hang themselves and all their friends.
<barmintor>I would be more comfortable saying" "If you're a 'power user', feel free to expose MODE's APIs in your repo". This feels like pushing more JCR-ness to an API level where (cf the SPARQL updates and what-not) we have tried to be more RDF-y12:15
barmintor: Maybe supplying a "MODE API add-on" is a good place for us, and for Stefano.12:16
And it wouldn't be hard at all.
<gregjansen>why can we just say "rdr:type" in our api, and then figure out if the type is a mixin or not?
<ajs6f>greagjansen: We can.
<gregjansen>right,they are mutually exclusive
<ajs6f>That's what I suggested.
BUt cbeer has some (very valid) misgivings.12:17
<gregjansen>we just cannot express it to consumers of rdf:type
Well, sort of.
We can't express it in a single triple.
We _can_ (and do) express it in a graph.
<gregjansen>but they will happen to have more strongly typed resources
<ajs6f>They are.
my:thing rdf:type my:type
my:type rdf:type jcr:mixin
<gregjansen>right, and we can include that in the default graph if we want to12:18
<ajs6f>And we provide that second triple at the node types ednpoint.12:19
(It may look diffferent, I can't remember how cbeer expressed it.)
We could.
Maybe complete graphs for all the types of the requested resource, even, although that could get long.
I guess the default stuff is pretty long already.
The more triples, the better!12:20
<gregjansen>not advocating for graph inclusion, but we could do it
<ajs6f>Sure. Maybe we should come back at Stefano and ask point-blank, "Would a richer presentation of the resource graphs combined with the MODE API let you try to things you want to try?"12:22
<gregjansen>I wonder if Fedora will end up being just one head on a larger JCR.. kind of already is, with the non-fedora nodes we've added for things like policies and projection of filesystems..
<barmintor>see, ^^ makes me uneasy
<ajs6f>I think the principle to keep in mind is: as much as possible, Fedora code should be about the things that Fedora cares about.
Not things that JCR can do as well or better.12:23
<gregjansen>sounds like a feature to me, but I agree that implementors are often tempted by such paths
<barmintor>ajs6f: exactly, but to me this suggests that fcrepo4 should not traffic in primary types
<gregjansen>barmintor: do we can enough about node validation to write our own code to do it?12:24
<ajs6f>barmintor: I'm actually fine with that— but I want to make sure that Stefano can do the (to my mind, reasonable) thing he wants to do: restrict constructions by type.
Exactly. ^^^
Or is that something jCR does perfectly well already.
<gregjansen>yes, we may in fact care enough about that.. since we've written it in the past.. also our content model projects so far have already found the limitations of CND..12:25
<ajs6f>And if so, how do we make that functionality available.
(Because Stefano just proved that it currently isn't.)
True enough. That's IT! OWL FULL or bust!12:26
We can't rest until all problems in the repo are thoroughly intractable.12:27
Time for lunch. bbl
* ajs6f leaves
<gregjansen>personally, I am fine with letting people hang themselves on JCR a bit. once stefano and others are publishing their linked data, them maybe we implement something in the realm of OWL12:28
* scossu joins12:32
* edInCo joins12:59
* ermadmix leaves13:06
* ermadmix joins13:32
* scossu leaves14:00
* scossu joins14:06
* nbanks joins14:08
* osmandin leaves14:14
* github-ff joins14:58
[fcrepo-jms-indexer-pluggable] ajs6f pushed 1 new commit to osgi: http://git.io/wySfVg
fcrepo-jms-indexer-pluggable/osgi 223b70e ajs6f: Bundle-izing indexer modules
* github-ff leaves
* ajs6f joins15:06
gregjansen: Have you finished that OWL extension module that presents four-color presentation quality output diagrams of the ontology of repo resources?
all: We have a dependency from the kernel through the metrics modules which draws in a bunch of jersey libraries. (via metrics-jersey). I'd like to suggest that it's time to revisit the use of the Metrics library. I'm all in favor of getting performance metrics, but how are we actually using the Metrics stuff? Does it deserve to be an absolute requisite to operate the repository? (Especially since drawing in Jersey libraries implies that it is literally imp15:21
* gregjansen leaves15:27
* gregjansen joins15:33
* gregjansen leaves
<ajs6f>awoods: What I just said ^^^ turns out to be an example of a larger set of problems. The root cause is that external components (like the indexer) have no way to draw in Fedora kernel types without directly depending on fcrepo-kernel (and _all_ of its dependencies). We need an actual API artifact that can be used for these kinds of cases. I think I'm going to pause the "OSGi-ify the indexer" work and pivot to a new task: develop a "Fedora kernel API" artifa15:43
I'll pull out the useful interfaces and contracts from the kernel (and let the kernel pull that API module in as an ultra-lightweight dependency). I don't think we need to carry any JCR types into this module, at least not yet.15:44
* nbanks leaves15:45
<awoods>ajs6f: Sounds like an overdue task.16:02
ajs6f: Please create a pivotal ticket.
ajs6f: What are you planning on calling the maven module that contains the api?16:03
<ajs6f>awoods; Aye. I'll just aim to put up a strawman. This merits some discussion, and at least one fifteen-minute IRC debate between barmintor and myself.
awoods: I've already called it fcrepo-api. Patches welcome.
<awoods>ajs6f: where do you expect the impls of that api to come from?16:04
<ajs6f>awoods: The kernel itself, the JCR API, and the Jena core.
<awoods>ajs6f: In terms of our code, only fcrepo-kernel?
ajs6f: In which case, I would lean towards fcrepo-kernel-api16:05
<ajs6f>awoods: If it needs more than the kernel, we need to refactor or reconsider the functionality of the kernel.
awood: Okay, I'll write a ticket to rename it.
<awoods>ajs6f: Is the initial implementation pushed?16:06
<ajs6f>It was pushed in December. Weren't you watching?
<pivotal-bot_>A. "Horbulaco" Soroka added "Write a ticket to create an API strawman for discussion." https://www.pivotaltracker.com/story/show/63569926
A. "Horbulaco" Soroka started "Write a ticket to create an API strawman for discussion." https://www.pivotaltracker.com/story/show/63569926
A. "Horbulaco" Soroka added "Create a strawman Java API artifact for kernel functionality." https://www.pivotaltracker.com/story/show/6356996416:07
A. "Horbulaco" Soroka accepted "Write a ticket to create an API strawman for discussion." https://www.pivotaltracker.com/story/show/63569926
A. "Horbulaco" Soroka started "Create a strawman Java API artifact for kernel functionality." https://www.pivotaltracker.com/story/show/63569964
<awoods>ajs6f: I do not see any code associated with that ticket.
<ajs6f>Now _that_ was an obscure joke.
<awoods>ajs6f: if the strawman api code has not yet been pushed, I would suggest renaming it now, and not creating an additional ticket for something that does not yet exist.16:10
<ajs6f>awoods: I can't do work for a ticket that doesn't exist. It's a chicken and egg problem.
<awoods>ajs6f: I trust your judgment.16:11
<awoods>ajs6f: That is either very optimistic or very dark.16:12
<ajs6f>I’m a pessimist because of intelligence, but an optimist because of will.16:13
Antonio Gramsci : Letter from Prison (19 December 1929)
<awoods>ajs6f, the quoting machine.16:14
<ajs6f>We may want to factor out some of our utility dependencies (Guava, Apache Commons libraries, etc.) into a Maven BOM artifact.
awoods: I don't need original thoughts: I have Maven to track my dependencies.
<awoods>ajs6f: I like the idea of a Fedora BOM.16:15
<barmintor>what does BOM stand for? I'm used to it meaning 'byte order marker'.16:16
<ajs6f>awoods: I like the idea of several. A utilities BOM for Guava and its ilk, an RDF machinery BOM for Jena, OpenRDF, etc., and a JCR BOM (which might just be the MODE BOM), and then an "everything" BOM.
For simplicity.
barmintor: a Maven artifact with no code, just a list of dependency versions to make sure that artifacts in a ramified software project can stay in step.16:17
barmintor: We use MODE's BOM now, for exactly that reason.
barmintor: Kills a lot of "Wait, I have a chain of dependencies to _five_ different versions of the same lib!?!" problems.16:18
We've been relying on the pom.xml in fcrepo4 parent for that functionality, but a BOM avoids crossing concerns.16:19
The parent artifact of the project is also responsble for setting up plugin configurations, etc.
<awoods>barmintor: It is a maven3 thing.
<ajs6f>Separating that sort of "build process management" concern from actual transitive dependency management can make Maven much more pleasant to use.16:20
<awoods>hard to imagine
<ajs6f>Spoken like a true Fedora tech lead.16:21
Out of three I've known, none have failed to complain about Maven.
awoods: What's more interesting right now: solid machinery for development (BOMs) or developing a coherent sense of the kernel capabilities (API)? I don't have time for both before the 13th.16:25
<awoods>ajs6f: API
<pivotal-bot_>A. "Horbulaco" Soroka added "Create BOMs for fcrepo dependencies" https://www.pivotaltracker.com/story/show/63571456
<ajs6f>Maybe. k and a half.
out for the day. see y'all later16:32
* ajs6f leaves
<pivotal-bot_>A. "Horbulaco" Soroka edited "Create Maven BOMs for fcrepo dependencies" https://www.pivotaltracker.com/story/show/6357145616:33
* nbanks joins17:49
* ermadmix leaves17:58
<cbeer>hm: http://www.w3.org/2001/sw/wiki/TurtlePatch18:01
* ksclarke leaves18:28
* ksclarke joins18:30
* ksclarke leaves
* nbanks leaves18:46
* edInCo leaves19:16
* scossu leaves19:18
* ksclarke joins21:17
* ksclarke leaves
* ksclarke joins21:48