Timestamps are in GMT/BST.
[6:55] -orwell.freenode.net- *** Looking up your hostname...
[6:55] -orwell.freenode.net- *** Checking Ident
[6:55] -orwell.freenode.net- *** Found your hostname
[6:55] -orwell.freenode.net- *** No Ident response
[6:55] * DuraLogBot (~PircBot@webster.duraspace.org) has joined #duraspace
[6:55] * Topic is 'Welcome to DuraSpace IRC. This channel is used for formal meetings and is logged - http://irclogs.duraspace.org/'
[6:55] * Set by tdonohue on Thu Sep 15 17:49:38 UTC 2016
[12:20] * helix84 (~ctenar@unaffiliated/helix84) Quit (Ping timeout: 269 seconds)
[12:21] * helix84 (~ctenar@unaffiliated/helix84) has joined #duraspace
[12:32] * tdonohue (~tdonohue@dspace/tdonohue) has joined #duraspace
[13:05] * mhwood (~mhwood@mhw.ulib.iupui.edu) has joined #duraspace
[13:55] * misilot_ (~misilot@p-body.lib.fit.edu) Quit (Quit: Leaving)
[14:44] <DSpaceSlackBot> <tdonohue> <here> Reminder that our DevMtg starts here in ~15mins (top of the hour). Agenda is at: https://wiki.duraspace.org/display/DSPACE/DevMtg+2018-03-07
[14:44] <kompewter> [ DevMtg 2018-03-07 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2018-03-07
[15:00] <DSpaceSlackBot> <tdonohue> <here>: It's DSpace DevMtg time! Let's do our usual roll call to see who is able to join us today
[15:01] <DSpaceSlackBot> <sulfrian> Hi
[15:01] <DSpaceSlackBot> <mwood> Hi
[15:01] <DSpaceSlackBot> <jcreel256> Hi
[15:01] <DSpaceSlackBot> <tdonohue> Hi all...good to have you. I'll go ahead and kick things off here a bit, while we wait for others to show
[15:02] <DSpaceSlackBot> <tdonohue> The Agenda has the usual reminders about upcoming meetings (DSpace 7, DSpace Dev Show & Tell)...to save time, I'm not going to copy those here. Take a look at the agenda though more info
[15:03] <DSpaceSlackBot> <tdonohue> On the DSpace 7 side of things, I don't have any major updates to share today. Efforts are moving along, but they are moving more slowly than we'd like. We could really use more "hands on deck", if anyone has an interest/desire...and if so, get in touch, and I'll help you get looped in / up to speed
[15:05] <DSpaceSlackBot> <tdonohue> We could use more folks helping either with the REST API (Java and/or Spring knowledge recommended), as well as Angular UI (no knowledge required, but need a willingness to learn Angular 5)
[15:05] <DSpaceSlackBot> <tdonohue> That's it for DSpace 7 updates, unless anyone has questions / comments?
[15:05] <DSpaceSlackBot> <tdonohue> Not seeing any typing, so I'm going to speed along here....as I'd like to get to Entities Discussions quickly
[15:06] <DSpaceSlackBot> <tdonohue> On the DSpace 6.x / 6.3 side of things, we are at the same status. Nothing to report, and no major movement towards release yet. If anyone wants to see the next 6.x release out sooner, then we'll need help organizing the release (and again, get in touch if interested)
[15:07] <DSpaceSlackBot> <tdonohue> Moving right along then...
[15:07] <DSpaceSlackBot> <tdonohue> What I'd really like to get to is feedback / discussion / questions / comments on the "DSpace Entities Overview" document I shared recently on dspace-devel and Slack dev:
[15:08] <DSpaceSlackBot> <tdonohue> https://docs.google.com/document/d/1exm_xLToxUMszOvX5itSMFTn5eiGCdggL0Mf522GjHU/edit
[15:08] <kompewter> [ DSpace Entities Overview / Discussion - Google Docs ] - https://docs.google.com/document/d/1exm_xLToxUMszOvX5itSMFTn5eiGCdggL0Mf522GjHU/edit
[15:08] <DSpaceSlackBot> <tdonohue> As noted, this is a general summary of the discussions / analysis of the DSpace Entities Working Group efforts. This will also be discussed by the DSpace Steering Group later today.
[15:09] <DSpaceSlackBot> <tdonohue> The goal is to try and approach a decision in the near future. But, I really would like to hear your thoughts / options / questions about these discussions...are there things you like / don't like? Things you are confused about? General comments / suggestions?
[15:10] <DSpaceSlackBot> <tdonohue> I'm going to pause now, to see if anyone <here> would like to ask questions, etc.
[15:12] <DSpaceSlackBot> <mwood> I think Kim Shepherd raised a question on a ML about whether we understand our requirements enough to make a decision.
[15:12] <DSpaceSlackBot> <sulfrian> While reading this, I try to understand the relation between Entities and hierarchical metadata.
[15:14] <DSpaceSlackBot> <tdonohue> @mwood: I tried to describe some of the user requirements (use cases) in the document under the "Background Information / Why new Entities?" header. Did I misunderstand Kim's question?
[15:14] <DSpaceSlackBot> <sulfrian> Would it be possible to have hierarchical metadata, but without extra pages for the entities or the need to manage the entities?
[15:16] <DSpaceSlackBot> <tdonohue> @sulfrian: There's not really a direct relationship between Entities and hierarchical metadata. When we talk "hierarchical metadata", we are usually reference enhanced metadata on Items (i.e. Documents). When we talk Entities, we are talking about entirely new objects to represent People (so that people can have a "Author Profile" or "Researcher Page"), etc
[15:16] <DSpaceSlackBot> <tdonohue> @sulfrian: The end goal is we'd likely have both in DSpace at some point... but this discussion is more about adding new *Entities* to DSpace (like People), and not about hierarchical metadata.
[15:16] <DSpaceSlackBot> <mwood> Well, roles. people, organizations, and the like.
[15:17] <DSpaceSlackBot> <tdonohue> Does that make sense, or did I misunderstand the question here?
[15:19] <DSpaceSlackBot> <sulfrian> @tdonohue Ok, I understand. I actually would be more interested into hierarchical metadata support.
[15:19] <DSpaceSlackBot> <mwood> I understood Kim to be suggesting that we need to look harder at the entities before looking too closely at the applications thereof.
[15:20] <DSpaceSlackBot> <tdonohue> @sulfrian: good to know. Yes, I think there's still plenty of interest in hierarchical metadata support...but that's not directly part of this discussion. I think it's a separate discussion of how to achieve that
[15:20] <DSpaceSlackBot> <mwood> As soon as we start talking Entities, the discussion quickly turns to what we want to use them for.
[15:21] <DSpaceSlackBot> <mwood> Nobody wants person entities per se; we want things that we can build on them. But we need to get the entities right first lest we paint ourselves into a corner.
[15:22] <DSpaceSlackBot> <tdonohue> @mwood: I can see that, to a point. But, I guess my response is still....sure, we could do that. It'll take time to do that analysis of what we want in an entity. But, part of that analysis would likely start at looking at what others have done here...and that's where DSpace-CRIS has been doing this for ~10 years now
[15:22] <DSpaceSlackBot> <mwood> It's difficult to say whether we should adopt the entity support from DSpace-CRIS or build afresh, until we understand what we are making.
[15:23] <DSpaceSlackBot> <tdonohue> So the balance becomes, do we look towards DSpace-CRIS's 10 years of experience, or do we dig in for a deep analysis and build up our own experience (which will take significant time / effort) and potentially end up in a similar place
[15:23] <DSpaceSlackBot> <mwood> A concrete suggestion was to compare DSpace-CRIS entities with Vivo entities.
[15:25] <DSpaceSlackBot> <tdonohue> I'm fine with that, conceptually. But, with the understanding that we shouldn't be building a VIVO competitor.... rather we'd be striving more for something that could integrate with VIVO
[15:25] <DSpaceSlackBot> <mwood> Sensible. They'd just need to have concepts that map into each other.
[15:26] <DSpaceSlackBot> <tdonohue> And we should all be aware that a big part of what DSpace-CRIS has built is the idea of *configurable* Entities. Their data model is built in a way that you can add new Entities and add new fields/metadata/properties to existing Entities. So, if this question is about "do we have the right metadata", then that's an easy answer...we can reconfigure it to have the right metadata.
[15:27] <DSpaceSlackBot> <tdonohue> So, a comparison with VIVO is warranted...but what DSpace-CRIS has here is not static
[15:29] <DSpaceSlackBot> <mwood> I think the question is "do we have the right concepts?" Probably, yes. It would be nice if we can say definitely, yes. But we go wandering off to talk about Author Pages (on the one hand) or representation in the database (on the other).
[15:30] <DSpaceSlackBot> <tdonohue> I can say with certainty that VIVO Entities include People, Organization hierarchies, and Projects. They also include things like specific Publication types (Article, Book, etc) as separate entity types.
[15:31] <DSpaceSlackBot> <tdonohue> Much of this info is on the VIVO Wiki...here's some of it (their docs are a bit lacking though): https://wiki.duraspace.org/pages/viewpage.action?pageId=71501016
[15:31] <kompewter> [ Managing Data in Your VIVO (*) - VIVO 1.9.x Documentation - DuraSpace Wiki ] - https://wiki.duraspace.org/pages/viewpage.action?pageId=71501016
[15:31] <DSpaceSlackBot> <mwood> I think Kim is getting at the question of how these objects become *knowledge*, not just metadata.
[15:32] <DSpaceSlackBot> <tdonohue> I guess I don't understand what is meant by that (I'm not trying to be difficult, I honestly think these are good questions...I just need to understand the area of doubt better)
[15:33] <DSpaceSlackBot> <tdonohue> VIVO represents entities & relationships between them as RDF triples...so, it's more of a semantic web app. We definitely wouldn't be building that level of complexity into DSpace. But, I *do* think we'd want to be able to export DSpace Entities into VIVO (or visa versa, import from VIVO) at some future point (once we have Entities)
[15:35] <DSpaceSlackBot> <tdonohue> I'm trying to find a better way to respond here...maybe this is simply hard to talk through in a text chat. I agree with the general concept here that we should be analyzing if these are the "right entities". At a basic glance, I think they are... and we have folks like OpenAIRE / COAR Next Gen Repositories report saying they feel Repositories need to represent People & Projects (at a minimum) to better tr
[15:36] <DSpaceSlackBot> <tdonohue> But, maybe I'm missing a key point of the question here?
[15:38] <DSpaceSlackBot> <mwood> Yes. We have different categories of people. Right now, DSpace has one kind of Person: person-who-has-credentials. Authors won't necessarily have credentials. Editors may not be authors. How do we capture the differences? (Clearly I'm struggling too.)
[15:39] <DSpaceSlackBot> <tdonohue> In that scenario, I think the difference is that Authors would actually be *objects*. When we talk about adding Entities, these aren't new *roles*, they are new *objects* that DSpace can represent.
[15:39] <DSpaceSlackBot> <tdonohue> So, an Author is an object, and an EPerson has rights on that object.
[15:39] <DSpaceSlackBot> <tdonohue> If that particular *real person* has an account, then they'd be an EPerson with rights to their Author object (and Author Profile)
[15:39] <DSpaceSlackBot> <mwood> But an author may also be a subscriber or a submitter. They're the same object.
[15:40] <DSpaceSlackBot> <tdonohue> But, in some situations, the Author / Author Profile might be simply managed by the Repo Mgr.
[15:40] <DSpaceSlackBot> <tdonohue> @mwood: no, they are not. We have Authors and we have EPersons. An *EPerson* may be a subscriber or submitter... and Author is not. An Author is simply an object with metadata (like an Item), but in this situation the metadata is about a real person
[15:41] <DSpaceSlackBot> <mwood> I don't see why they are separate entities.
[15:41] <DSpaceSlackBot> <tdonohue> So, when we talk about adding Entities... we are talking about adding *Objects* with metadata...things that are like an Item, but that represent different real-life things
[15:42] <DSpaceSlackBot> <tdonohue> We are *not* talking about changing EPerson / Group authorization schemes... those will remain the same, with the only difference being that Eperson / Groups may now have specific rights on these new Objects (Entities)
[15:42] <DSpaceSlackBot> <tdonohue> And that is exactly how DSpace-CRIS functions / works. They use the out-of-the-box DSpace authN/AuthZ on these new Objects
[15:43] <DSpaceSlackBot> <mwood> That seems like mostly just a way to bolt new roles onto DSpace without altering the existing DSOs.
[15:43] <DSpaceSlackBot> <tdonohue> Does this make more sense? I can definitely understand the confusion of terminology here
[15:44] <DSpaceSlackBot> <tdonohue> @mwood: it might depend on what you mean by "roles". I tend to think of "roles" as having to do with AuthZ... and I don't think adding new Entities has anything to do with AuthZ changes
[15:45] <DSpaceSlackBot> <tdonohue> @mwood: And the key reason I think that is that I believe *most/many* Author Entities will *not* have a corresponding EPerson. Most authors won't login to the system to manage their profile...they will expect the university to do that for them, and they may only login to correct information that is wrong
[15:46] <DSpaceSlackBot> <jcreel256> I agree that it would be inappropriate to conflate the EPerson class with a new java class for Entities.
[15:46] <DSpaceSlackBot> <tdonohue> So, in that situation, you may have thousands of Author Entities...managed by a much smaller subset of EPersons... it's not a 1-to-1 relationship
[15:46] <DSpaceSlackBot> <jcreel256> Especially if they're dynamically configurable, there could be many Entity instances that don't correspond with a user.
[15:48] <DSpaceSlackBot> <mwood> Exactly. I have been thinking for some time that credentials ought to be peeled out of EPerson. A credentials record is something that one person has and another does not.
[15:48] <DSpaceSlackBot> <tdonohue> @jcreel256: so, not to put you on the spot...but is this an area of interest to you & your team? Do you all see a need for adding these Entities and/or have feedback on this write-up (Feel free to add feedback later into the doc itself)
[15:48] <DSpaceSlackBot> <jcreel256> There's a big feature set here that lots of people want. DSpace-CRIS fits the bill, as does VIVO.
[15:48] <DSpaceSlackBot> <mwood> IOW person-hood is central; credentials are optional.
[15:49] <DSpaceSlackBot> <tdonohue> @mwood: I agree, though I think there's two ways of thinking on that. Either peel credentials from EPerson...or "streamline" EPerson into an account that is basically *all about credentials*. Currently, EPerson is a bit "in the middle" at times
[15:49] <DSpaceSlackBot> <jcreel256> We're running a VIVO instance. Librarians have a lot of grief about an inability to use VIVO records as authoritative, disambiguating entities for the authors cited in our DSpace metadata.
[15:50] <DSpaceSlackBot> <jcreel256> Integration makes a lot of sense.
[15:50] <DSpaceSlackBot> <tdonohue> @mwood: and if we had a new Author Entity...that might be a more appropriate place to represent "person-hood"...which could allow us to streamline EPerson into a "user account / credentials" object
[15:51] <DSpaceSlackBot> <tdonohue> @jcreel256: thanks for that feedback! Good to know where you all sit here, and what you are doing currently
[15:51] <DSpaceSlackBot> <mwood> Then what do Editor, Project Manager, etc. do? They are not persons?
[15:51] <DSpaceSlackBot> <sulfrian> @jcreel256 That may be already possible with the Authority-Framework.
[15:52] <DSpaceSlackBot> <jcreel256> Yes, @sulfrian we have experimented with putting VIVO URIs in the authority fields. It's a workable solution. Doing the initial disambiguation is the roadblock.
[15:52] <DSpaceSlackBot> <tdonohue> @mwood: An Admin / Community Admin / Collection Admin are account types. If those individuals also need represented as Authors, then they'd have a corresponding Author Entity
[15:53] <DSpaceSlackBot> <jcreel256> Interestingly, we were doing this for the dc.contributor field (for thesis advisors) and not the dc.creator or dc.contributor.author field.
[15:53] <DSpaceSlackBot> <mwood> So Author, Admin. etc. (and submitter) are roles. The Person is an opaque internal identifier with a number of attributes, most optional.
[15:55] <DSpaceSlackBot> <tdonohue> @mwood: my key points here are (1) not every real-person at a university needs to be represented as an Author Entity, (2) not every real-person who *is* represented as an Author Entity needs to have a user account / credentials on the repository. (3) not every real-person who has a user account/credentials needs to be represented as an Author Entity
[15:55] <DSpaceSlackBot> <tdonohue> So, Author Entities are really about representing "someone who wrote / created / edited something that is stored in the repository".
[15:56] <DSpaceSlackBot> <tdonohue> And that's a different concept from our current EPerson...which is more about "someone who has certain rights to login & possibly change objects in the repository"
[15:56] <DSpaceSlackBot> <mwood> Notice that real-person is at the center of all of these. That's a very abstract concept. Some real-persons are authors. Some real-persons have credentials. Some real-persons have both roles.
[15:58] <DSpaceSlackBot> <tdonohue> @mwood: right, agreed. That's why there are two representations of "real-persons" here... An real-person with credentials. And a real-person who is an author. Some real-persons may have *both* representations in a repo. But, some may only have one.
[15:58] <DSpaceSlackBot> <mwood> But there's only one person, not two (or six).
[16:00] <DSpaceSlackBot> <tdonohue> Of course, but they are two specific facets of a "real-person". A credential object (Eperson) would only have information (metadata) necessary for login / permissions granting. While an author object (Author Entity) would have metadata related to that person's department, ORCID, links to works, etc
[16:00] <DSpaceSlackBot> <jcreel256> Gotta run to another meeting.
[16:01] <DSpaceSlackBot> <tdonohue> Thanks for joining / providing feedback, @jcreel256!
[16:01] <DSpaceSlackBot> <jcreel256> my pleasure
[16:01] <DSpaceSlackBot> <mwood> What does it buy us, that we have two separate entities as parts of one identity?
[16:01] <DSpaceSlackBot> <jcreel256> seeing @mdiggory’s point a bit more, will have to think on it
[16:02] <DSpaceSlackBot> <jcreel256> sorry, wrong mention, @mwood
[16:04] <DSpaceSlackBot> <tdonohue> @mwood: perhaps that's the key point here... In this scenario, I wouldn't consider "EPerson" to be an Entity, as it's merely a "user account" to authenticate you with the system (and integrate with external LDAP or Shib or whatever). The Entity, which your user account may or may not be "linked to", is the Author object.
[16:04] <DSpaceSlackBot> <tdonohue> In the end though, if we found these two Classes (Eperson and Author) could be collapsed into one...that's perfectly OK by me. I'm just not sure I'm convinced that's plausible, as I think they perform different functions
[16:06] <DSpaceSlackBot> <mwood> Yes. The way I'm looking at it, the EPerson loses *all* of its fields except the UUID. If that person is an author, the EPerson has metadata appropriate to an author. If that person can log in, the EPerson has metadata suitable for authN.
[16:08] <DSpaceSlackBot> <tdonohue> @mwood: If we found that simplification could work better, I'm perfectly OK with it. I just don't want us to spend years attempting to redesign a "perfect system", when we could potentially just adopt working aspects of DSpace-CRIS and look to refactor/simplify later (similar to how we recently refactored / simplified objects in the metadata-for-all work in 5.x)
[16:09] <DSpaceSlackBot> <mwood> Yes, that is the trade-off.
[16:09] <DSpaceSlackBot> <tdonohue> So, I guess I just am saying I'm not sure that we need to design perfection right now..but we definitely *could* & should look at areas we feel need more cleanup/refactoring, and "flag those" (in a ticket or wherever)
[16:10] <DSpaceSlackBot> <mwood> I suppose I just have an uneasy feeling that we're trying to convince ourselves that the easy way is right.
[16:10] <DSpaceSlackBot> <tdonohue> If we find major flaws in the DSpace-CRIS model, then yes, we can build it ourselves...but I'm starting to suspect that if it's 85%-90% "right", then it seems a bit silly to try and build something "more perfect"
[16:11] <DSpaceSlackBot> <tdonohue> (But keep in mind, that no decision has been made here...that is just my opinion :point_up: )
[16:11] <DSpaceSlackBot> <mwood> How do we know if it's 85-90% right? I'd take 85-90% but right now I can't put *any* number to it.
[16:13] <DSpaceSlackBot> <tdonohue> That's obviously a guesstimate. I'm saying that mostly because DSpace-CRIS seems to meet the initial use cases / needs we laid out. It does so in a way that may not always be ideal (see the document for "Disadvantages" described), but it's used in production for ~10 years, and has ~100 sites.
[16:13] <DSpaceSlackBot> <tdonohue> So, my conclusion from all that is... "it seems mostly right & works". But, obviously there are things that could use cleaning up in the future.
[16:13] <DSpaceSlackBot> <mwood> Those statistics are encouraging.
[16:14] <DSpaceSlackBot> <tdonohue> But that's also why I wrote up this document to begin with... I wanted to see that others *agree* with my analysis here :slightly_smiling_face:
[16:15] <DSpaceSlackBot> <tdonohue> And I wanted to be sure that we aren't starting to jump to a (wrong) conclusion that others would strongly oppose
[16:15] <DSpaceSlackBot> <sulfrian> I think, that it is really strange that there is another table in the database for the metadata of the entities (`jdyna_values`).
[16:15] <DSpaceSlackBot> Action: tdonohue notes that obviously we are well over time. This discussion is important though...so I hate to cut it short. That said, I completely understand if folks have other meetings / tasks to go to
[16:16] <DSpaceSlackBot> <mwood> I want to be more certain that we are modelling the domain accurately. I don't say we are or we aren't; I _don't know_.
[16:16] <DSpaceSlackBot> <tdonohue> @sulfrian: yes, that's one of those things that is not ideal. From talking to 4Science, the `jdyna_values` table duplicates some of the `metadatavalue` table because they didn't want to directly modify/change core DSpace code (around how it stores metadata)
[16:16] <DSpaceSlackBot> <mwood> Yeah, I should quiet down and think some more.
[16:17] <DSpaceSlackBot> <tdonohue> So, they chose to create a `jdyna_values` so that they could make DSpace-CRIS more of an "extension" (not touching core code)
[16:17] <DSpaceSlackBot> <tdonohue> If they had used `metadatavalue`, they would have had to completely fork DSpace, modify core classes and enhance that table
[16:18] <DSpaceSlackBot> <tdonohue> But, that said... I 100% agree that that's an area that could be simplified / improved in the future, if we adopt DSpace-CRIS's model. It's a duplicate that is not ideal
[16:18] <DSpaceSlackBot> <mwood> That table looked to me like an attempt to port a Fortran EQUIVALENCE into SQL. Maybe, since it'll be going into stock DSpace, we can do it differently.
[16:18] <DSpaceSlackBot> <sulfrian> @tdonohue Yes, I understand why they did it. But I think, that it wouldn't be a great idea to "merge" it in this way.
[16:19] <DSpaceSlackBot> <tdonohue> Yes, if this became part of core DSpace...we could immediately flag it for refactoring / improvement. And, yes, that improvement could even occur before the first release of this new model (if we find resources to achieve that).
[16:19] <DSpaceSlackBot> <mwood> I've been thinking that metadatavalues are due for an overhaul.
[16:19] <DSpaceSlackBot> <sulfrian> I would strongly prefer a way, to keep the metadata-for-all approach for the new entities.
[16:20] <DSpaceSlackBot> <tdonohue> But, I think it'd be hard for us to demand 4Science change this immediately (before merging), without some promise that we will immediately adopt the changes. I think we'd need to approach this as a "we'll adopt your model, but we would like to work together to change this in the core code immediately"
[16:21] <DSpaceSlackBot> <mwood> That sounds well.
[16:21] <DSpaceSlackBot> <tdonohue> @sulfrian: I agree with that. I'd rather this duplication wasn't there. I would rather that change immediately...I'd just need the resources to put towards changing that immediately.
[16:22] <DSpaceSlackBot> <tdonohue> And in all honestly, I'm not entirely sure which model we'd want to merge into... would "metadatavalues" really fit the bill here? Or would we merge everything over into something more like `jdyna_values` (but under a new name, obviously)? That's an analysis we'd have to do.
[16:22] <DSpaceSlackBot> <tdonohue> (Or is it something in between both... not sure)
[16:22] <DSpaceSlackBot> <mwood> Metadatavalue becomes {id, type, blob}.
[16:23] <DSpaceSlackBot> <sulfrian> If the entities stuff would lead to something that I can configure the input forms for collections/communities without changing java code, that would be great.
[16:25] <DSpaceSlackBot> <tdonohue> @sulfrian: I don't recall if that's a feature of DSpace-CRIS or not...but I know most of this stuff (Entities, metadata on Entities, how they are represented on public pages) is 100% configurable from the DSpace-CRIS Admin UI.
[16:25] <DSpaceSlackBot> <tdonohue> So, at the very least, it'd move further in the direction of making stuff configurable from the Admin UI...and we could move other things in that direction too.
[16:26] <DSpaceSlackBot> <mwood> I think that's desirable but it is something that is built atop entities. Certainly we need to be careful not to make it difficult to do such things, as entities work progresses.
[16:27] <DSpaceSlackBot> <tdonohue> I think that's a feature lots of folks would want to see... more configurability from the Admin UI. DSpace-CRIS has moved a lot in that direction, but it does result in extra complexity on the backend -- as DSpace-CRIS stores these configurations in the database.
[16:27] <DSpaceSlackBot> <sulfrian> I would prefer a config file, but a way to import the settings from a file would be fine, too.
[16:28] <DSpaceSlackBot> <mwood> Ah, the eternal struggle: A wants to do things visually, B wants to do them syntactically.
[16:29] <DSpaceSlackBot> <tdonohue> Yes, this is often just differences of opinion :slightly_smiling_face:
[16:29] <DSpaceSlackBot> <tdonohue> I get that, I do...I don't mind configurations in config files...but if you want to manage them from a UI, then you need to build a way to easily modify those config files via the UI.
[16:30] <DSpaceSlackBot> <tdonohue> In the case of DSpace-CRIS, they chose the other route... storing configs (that are modifiable from the UI) in the database
[16:30] <DSpaceSlackBot> <ntorres> in my opinion 100% ui-configurability could be done by a plugin, avoiding to add complexity on core code
[16:30] <DSpaceSlackBot> <tdonohue> So, this *does* make the DSpace-CRIS database much more complex (lots of tables to store configurations). But, it is meant to simplify the user experience...so that they can manage these things from the UI
[16:31] <DSpaceSlackBot> <mwood> One bit of complexity remains: getting the UI to notice changes without restarting.
[16:33] <DSpaceSlackBot> <tdonohue> @ntorres: I totally get that too. There's lots of ways to do this & will always be lots of opinions. That sounds like a perfectly reasonable suggestion to me too... But, again, I worry if we are always looking for the "perfect way" before we move forward, we'll move much much slower.
[16:34] <DSpaceSlackBot> <tdonohue> So, the big balance here is... do we want it perfect? Or do we want it now? We cannot have both immediately.
[16:35] <DSpaceSlackBot> <tdonohue> Thanks all for the discussion. This has been wonderful to talk through. It sounds like it's starting to wrap up (only 35mins late!)
[16:35] <DSpaceSlackBot> <mwood> Put the search for perfection into a time box. When time's up, we go with the best we have.
[16:35] <DSpaceSlackBot> <mwood> OK, I'll quiet down now.
[16:37] <DSpaceSlackBot> <tdonohue> I really do appreciate your thoughts / ideas / feedback. I sincerely mean that. I'd encourage you to continue providing it in the Google Doc, or on mailing list or Slack (however you prefer). I'm listening..and I really enjoy being challenged on what I'm saying/thinking, as I feel it'll result in a better final decision (and no, I'm not always "right" in the end).
[16:37] <DSpaceSlackBot> <tdonohue> Let's wrap this up for today. I will be around on Slack most of the day... so feel free to ping me on dev or similar, if you want to talk more or have more thoughts/comments
[20:17] * dyelar (~dyelar@dyelar.mrb.ku.edu) Quit (Ping timeout: 248 seconds)
[20:21] * dyelar (~dyelar@dyelar.mrb.ku.edu) has joined #duraspace
[22:01] * mhwood (~mhwood@mhw.ulib.iupui.edu) Quit (Remote host closed the connection)
[22:48] * tdonohue (~tdonohue@dspace/tdonohue) Quit (Read error: Connection reset by peer)
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.