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

Using timezone: Eastern Standard Time
* jonathangee joins08:58
* edInCo joins09:46
* jonathangee leaves09:50
* ksclarke leaves09:52
* ksclarke joins
* jonathangee joins09:53
* ajs6f joins10:05
* gregjansen joins10:15
* github-ff joins10:47
[fcrepo4] ajs6f created KernelAPI (+1 new commit): http://git.io/XXV95A
fcrepo4/KernelAPI 3b4e548 ajs6f: New kernel API module with RDF lexicon
* github-ff leaves
* travis-ci joins10:54
[travis-ci] futures/fcrepo4#1478 (KernelAPI - 3b4e548 : ajs6f): The build has errored.
[travis-ci] Change view : https://github.com/futures/fcrepo4/commit/3b4e548c0159
[travis-ci] Build details : http://travis-ci.org/futures/fcrepo4/builds/16730211
* travis-ci leaves
* ajs6f1 joins10:57
* ajs6f leaves10:58
* edInCo leaves10:59
* github-ff joins11:04
[fcrepo4] ajs6f pushed 1 new commit to KernelAPI: http://git.io/WBegHw
fcrepo4/KernelAPI d95a59c ajs6f: Moving EventType to kernel API
* github-ff leaves
* travis-ci joins11:12
[travis-ci] futures/fcrepo4#1479 (KernelAPI - d95a59c : ajs6f): The build has errored.
[travis-ci] Change view : https://github.com/futures/fcrepo4/compare/3b4e548c0159...d95a59cefc35
[travis-ci] Build details : http://travis-ci.org/futures/fcrepo4/builds/16731394
* travis-ci leaves
* github-ff joins11:14
[fcrepo4] ajs6f pushed 1 new commit to KernelAPI: http://git.io/GByG5A
fcrepo4/KernelAPI 70537ff ajs6f: Renaming API module
* github-ff leaves
<bljenkins>Project fcrepo4 build #1598: FAILURE in 29 min: http://ci.fcrepo.org/jenkins/job/fcrepo4/1598/11:16
* github-ff joins11:26
[fcrepo-jms-indexer-pluggable] ajs6f pushed 2 new commits to osgi: http://git.io/XIJo0g
fcrepo-jms-indexer-pluggable/osgi 6ed19d6 ajs6f: Changing this branch to use forthcoming kernel API module
fcrepo-jms-indexer-pluggable/osgi e662471 ajs6f: Removing temp file
* github-ff leaves
<ajs6f1>Best docs ever: http://jena.apache.org/download/osgi.html11:32
* travis-ci joins11:36
[travis-ci] futures/fcrepo4#1480 (KernelAPI - 70537ff : ajs6f): The build passed.
[travis-ci] Change view : https://github.com/futures/fcrepo4/compare/d95a59cefc35...70537ff3702f
[travis-ci] Build details : http://travis-ci.org/futures/fcrepo4/builds/16732084
* travis-ci leaves
* ajs6f joins11:38
* ajs6f1 leaves11:42
* ajs6f leaves11:43
* edInCo joins11:58
<bljenkins>Yippee, build fixed!11:59
Project fcrepo4 build #1599: FIXED in 41 min: http://ci.fcrepo.org/jenkins/job/fcrepo4/1599/
* edInCo_ joins12:15
* edInCo leaves
* ajs6f joins12:22
<barmintor>ajs6f: is it wrong that part of my rxn to primaryType convo is to think we should just create nt:hierarchyNodes and make everything mixins?12:37
<ajs6f>barmintor: No, I get that. If we really can satisfy all use cases via pure mixins, then let's do just that. I'm not sure that's true, tho'. Stefano seemed to be able to recite some cases where it's not (where he really needed to be able to control the p-type to get the validation he wanted).12:39
Maybe we need to get a simple catalog of reasonable validation cases to check against?
<barmintor>ajs6f: I don't think that validation requires pType, except that we mixin to nt:folder
<ajs6f>barmintor: I'm not sure, honestly. I understood from that conversation that it's not possible to decide that all children of a given node will have some given type without controlling the p-type.12:40
But I could easily have misundestood.
<barmintor>I think it's just that the definitions are additive, so a mixin can't say (no folders)12:41
which suggests to me that surfacing JCR modeling as the source of validation might be flawed
<ajs6f>barmintor: 1) Right, but it's not crazy for someone to want to say, "No folders". 2) I agree. I'm kind of scared to build a whole new validation architecture on top, but maybe that is genuinely what we should do. It would be a shame to be unable to take advantage of at least some of the built-in JCR functionality.12:43
(Finally a chance to use OWL!)
<barmintor>ajs6f: as a middlware developer, I am not enthusiastic about distinguishing these12:44
especially since the JCR spec allows multiple inheritance of pTypes
<ajs6f>these what?
the kinds of node types?
<barmintor>these types- primary from mixin
<ajs6f>Right. I'm not ecstatic either. But I do want people to get the validation functionality they need.12:45
And I really want to augur this plane into the mountainside of OWL.12:47
<barmintor>actually, pursuant: pTypes are also additive, so FCR4 decorating objects with mixins could inadvertently break them.12:48
if the intent was to rely on excluding undefined props/children as an alternative to negative specs
<ajs6f>Wait, meaning adding a mixin to a node could make it impossible to fulfill its p-type?
p-ttypes
<barmintor>No, because pType doesn't exclude12:49
<ajs6f>Yeah, I think we really have to have negative specs.
<barmintor>it's that the state scossu describes is really not that a node *can't* have folder children, it's that it can't have them without a mixin
(for example)
at least, that's how I understand the spec12:50
<ajs6f>You're saying mixin additivity "overrides" p-type negativity?
<barmintor>what pType negativity?
<ajs6f>Exclusion.
<barmintor>what exclusion?
<ajs6f>I understand p-types to be able to exclude children or properties of spec'd types.12:51
<barmintor>I was looking for that in the spec, couldn't find it yet
<ajs6f>Hopefully stefano gave an actual example somewhere, because his whole request rests on that idea.
<barmintor>No, no: His request relies on inheriting from the superType of nt:folder, which doesn't define any child nodes12:53
<ajs6f>If a node has that type, and therefore can't have child nodes, then that's (implicitly) exclusion, no?12:54
You still get to say "No children"
<barmintor>If you get a mixin that defines a child type, it's not a conflict
Maybe I should say it's not exclusion, it's omission
<ajs6f>Right, that's what I was asking about above. So if Stefano does what he wants, but then I come along and add a mixin with child type to the node, can I add a child? Does the primary type win, or the mixin?12:55
<barmintor>afaik, there's no "win"
<ajs6f>WHO IS THE STRONGER!
<barmintor>that's not what "primary" means
it's not even a conflict12:56
a conflict would be "the mixin defines a property with the same name but a different type"
<ajs6f>So, still no children for that node. Then no problem and the tech does what Stefano wants it to do.
<barmintor>NO12:57
<ajs6f>So you _can_ add a child to the node?
<barmintor>your pType doesn't say "no children"
your pType says "no children are defined in the scope of being my type"
<ajs6f>If we don't have exclusion from the p-type, then I think we're going to have to supply it some other way.12:58
Whether that means validation from scratch or something else… dunno.
Got to get to a meeting… bbs
<barmintor>"The mixin type adds additional child node or property definitions to a node (i.e., either permitting or requiring additional child nodes or properties)."
* ajs6f leaves
* jonathangee leaves13:02
* jonathangee joins13:04
* ajs6f joins13:58
barmintor: Are you thinking that we need to step away from relying on JCRs types for validation? That we need to introduce an independent type system (perhaps based on W3C stuff, perhaps not)...14:05
?
<barmintor>I don't know how realistic that is, but I think that is ideal.14:06
At least inasmuch as our validation requirements don't actually correspond, thus far, to JCR type validations
<ajs6f>Fedora (not just 4, any version): Refusing to understand the difference between ideal and real. For over a decade.
I think people really do want exclusion.14:07
<barmintor>agreed- and JCR does not offer that14:08
<ajs6f>Many people find that deep down, their own sense of inclusion as a person is often predicated on their ability to exclude other people. In-groups vs. out-groups, that sort of thing.
<barmintor>...
<ajs6f>I think we have to meet people where they are… psychologically.
Well, what _would_ we do, ideally. In all seriousness, a lightweight OWL profile, like QL?14:09
<barmintor>Are you suggesting that my sense of self-worth is evidence that I have, minimally, a validation subsystem independent of the JCR repo that I may or may not be built on?
<ajs6f>I think your sense of self-worth is evidence of a certain maturity and wisdom.14:10
But hopefully your JCR repo is also valid.
* jonathangee leaves14:21
* scossu joins14:34
* ermadmix joins15:08
* ajs6f leaves15:20
* ajs6f joins15:35
barmintor: I'm now trying to think about what a new validation/typing (really, typing, because structural validation usually appears as a consequent of typing) framework would entail.15:46
Would we go whole-heatedly into the W3C description logic arena?
Would we be willing to go out on our own with a DSL?15:47
Would we, could we, find something to the purpose in the ecosystem of open source around jCR?
* ermadmix leaves
<ajs6f>Asger, for ECM, went to OWL. Would we follow that line?15:48
Is that the kind of clever gamble that Fedora made when it went to RDF for the resource graph several years ago?
Or is it a fool's errand?
Do we want to engage data validation and structural validation in the same battle?15:49
(In the same language.)15:50
* ermadmix joins15:52
<barmintor>These are good questions.15:53
<ajs6f>Good. I'm glad we got some clarity on that.15:54
Should I make a ticket with all these questions for awoods?15:59
<awoods>ajs6f: I am just back online... and getting caught up on the conversations.
<ajs6f>Well, you already know that feeling.16:00
<awoods>All: Thanks for updating the sprint schedule.16:01
<pivotal-bot_>Andrew Woods edited "Transactions across connections not working" https://www.pivotaltracker.com/story/show/6302985216:06
* ermadmix leaves16:13
<awoods>barmintor/ajs6f: As a first step in allowing scossu to at least create the nodes in a structure that he wants, does it make sense (as barmintor mentioned above) to have a more general nodetype as the default for objects, instead of the current nt:folder?16:24
<ajs6f>As long as it doesn't reduce the current functionality...16:25
<awoods>barmintor/ajs6f: This obviously does not address the content validation question, but at least it would offer a more flexible content modeling option.
<ajs6f>awoods is always worried about the users. I'm always worried about the elegance of our ontology.16:26
<barmintor>I'm worried about maintaining the code going forward
<awoods>ajs6f: I do not believe it would reduce the current functionality. We would, however, need to modify our default mixin.
can you elaborate, barmintor?
<ajs6f>barmintor: eh? Pulling up from nt:folder to nt:resource?
<barmintor>awoods: In general. Not specific to this.16:27
Just chiming in with my bit compared to ontological elegance and user happiness :)
<ajs6f>barmintor: That's why I'm furiously beating the dead modularity horse.
Nothing spells happy devs like "I don't have to worry about stuff about which I don't care."16:28
<scossu>@awoods: it would be good to at least have nt:hierarchyNode instead of nt:folder.16:29
<awoods>barmintor: Ongoing maintenance is an import concern. Do you smell something nasty around the corner with a more general default nodetype for objects?
<ajs6f>If you can smell JCR nodetypes, JBoss has a job open for you.
<barmintor>Well, one immediate concern will be this: nt:hierarchyNode has no children defined
<awoods>barmintor: yes, so a mixin would be required that defines children.16:30
<barmintor>yes
<awoods>yes
<ajs6f>So we can add "can have chldren" to fedora:object.
<barmintor>And those children would be...
<scossu>Although as I mentioned in the message board, the very permissive lines in the default fedora:resource type void any possible property restriction.
<ajs6f>That's up to the repo manager.16:31
scossu: Would you suggest restricting that to "any property"?
<barmintor>ajs6f: so you would not add child node defs to the fedora:object CND?
<ajs6f>I would. But I wouldn't be hysterical if a repo manager created a mixin to add other kinds of children.16:32
<barmintor>i feel like we're miscommunicating
<ajs6f>How about a mixin "fedora:fertile" that allows arbitrary children?16:33
<cbeer>what impact does this have on e.g. generic JCR projection machinery, CMIS/WebDAV we get for free with modeshape, sequencers, etc, etc?
<awoods>barmintor/ajs6f/scossu: Does it make more sense to hash this out with voices, on a call? Today or next week?
<ajs6f>cbeer: Stop asking pertinent, pragmatic questions!
<barmintor>awoodsL I can talk Monday16:34
awoods ^^
<ajs6f>Ditto.
<awoods>ditto
* awoods minus the awoods part
<ajs6f>awoods is recursive.
<scossu>I'm available Monday in the morning or after 3pm Central time.16:35
<awoods>4pm ET?
Monday 1/13?
GoogleHangout?
* awoods a nod to ajs6f
<scossu>1/13 at 4pm ET sounds fine.
<ajs6f>Can we push it to 4:30?
<awoods>barmintor?16:36
cbeer?
<barmintor>I have a meeting Monday at 4pm
<ajs6f>Monday at 11AM ET?
<scossu>My hangout contact is stefano dot cossu dot lii at that big email provider
<barmintor>AOL?
(I kid)
<cbeer>awoods: nope. my monday is full. just make good decisious.
<scossu>What's AOL?
<cbeer>decisions16:37
<scossu>(I kid too, I'm not that yong)
<ajs6f>cbeer: I guarantee they'll be good decisions.
cbeer: For now.
<awoods>cbeer: Do you think a less restrictive default object nodetype would break any of the JCR features you mentioned above?16:38
<scossu>I'm busy all day Tue and Wed.
<cbeer>awoods: i don't know. it seems likely. or, at least, it seems likely the results could be confusing.
<ajs6f>So… this Monday at 11AM ET?
<cbeer>it seems VERY likely to me that it'd break any sort of JCR-land interoperability we might have right now
<awoods>11am works for me.16:39
<ajs6f>General JCR interop is something we've occasionally enjoyed the thought of.
<scossu>Ok.
<ajs6f>But never actually thought much about
<awoods>cbeer: What is the difference of having nt:folder and nt:something-else in terms of interoperability?
barmintor? Monday @11am ET?
<cbeer>awoods: if something is an nt:folder, something else in JCR-land can make assumptions about the object (like, for webdav, that it should be presented as a UNIX folder)16:40
i don't know what happens if it isn't an nt:folder
<barmintor>awoods: calendar updated
<ajs6f>So we might lose MODE's WebDAV connector.
<cbeer>and CMIS. and the modeshape REST API. or whatever
<ajs6f>Which eddies got working somewhere back in the dawn of time.16:41
No, not the MODE HTTP API. That is ready to work over _any_ repo.
<awoods>barmintor/ajs6f/scossu and awoods will be on the Monday call?
<ajs6f>Why not?
<scossu>Yes.
<awoods>It would be great to have your wrenches thrown into the Monday call, cbeer. But, alas, we will have to do without.16:43
<scossu>What are your hangout contacts?16:44
<cbeer>awoods: you forget that i don't actually know anything, i just worry about lots of things.
<ajs6f>out for the day, hear y'all on Monday
* ajs6f leaves
* mikeAtUVa leaves17:01
* gregjansen leaves17:10
* scossu leaves17:57
* ksclarke leaves18:10
* ksclarke joins18:13
* edInCo_ leaves18:59
* ksclarke leaves19:28
* ksclarke joins20:27