Re: [Dspace-tech] Development goals
Hi Mark, > I've been saying for some time that, nice as the DSpace user interface > is in many respects, it is not and should not be the only way to plumb > a DSpace archive. If it is (currently) difficult to get a particular > search style put into DSpace, may I suggest trying a different > approach. > > One could harvest metadata via the PMH responder, organize them any > way one wishes, and search them in any desired way. > I can't resist pointing out that this is exactly what "DWell" does -- the faceted browsing and search UI that is layered over DSpace via an OAI-PMH plugin for RDFized metadata. See http://simile.mit.edu/wiki/Dwell or Richard Rodger's presentation on same at http://www.aepic.it/conf/viewpaper.php?id=212&print=1&cf=11 I think this is an excellent approach to building better DSpace UIs, and just leaves us with the problem of the underlying data rigidity, which I hope we can address by relying more on RDF or other rich metadata that is stored in the assetstore alongside the content files. The current DSpace metadata tables are great for managing content, but suboptimal for discovering what's in the repository (assuming we can get better discovery metadata from outside the system, somehow). MacKenzie -- MacKenzie Smith Associate Director for Technology MIT Libraries - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
Re: [Dspace-tech] Development goals
Dorothea, > I think there's an additional issue that may prove even more difficult > to address: the problem of a technical infrastructure widely adopted > by non-technical people. > We should establish that this is actually the norm (as you point out later) and in every industry, not just libraries or archives. Business managers theoretically know what they need, but do not (should not) be expected to write the software to accomplish those goals. > I haven't taken a look at the wiki to be sure, but my gestalt sense is > that a substantial majority of DSpace instances live in academic > libraries and academic-library consortia. As the general run of > academic librarians goes, *I am highly technical*. (Tim Donohue is an > outright anomaly.) > I think you're right that the majority of DSpace adopters right now are in the library or related domains. At least the visible ones. But those institutions are taking various approaches to defining and managing their repository services. Some have one-person-to- do-everything, and some have much more fine-grained support. As one example, at MIT we have a dedicated product manager (not hands-on technical, but quite capable of writing requirements and talking to developers), a dedicated developer, and a sysadmin to look after the production system day-to-day. I wish I had more staff to help out, but this is what we could support for the moment. The one-person-who-does-it-all model is definitely not going to scale for the sorts of DSpace applications that we're seeing. And if you look at the staffing models for other production systems like ILSes or course management systems no one would expect one person to deal with every aspect of them (including writing the software). These are complex problems that we're just beginning to understand, so expect to see plenty of dead ends and throw-away code before it's over. In other words, *more* investment, not less, at this stage of the game. > As I said, though, I'm > atypical *on the technical high end* of librarianship. I don't think > DSpace has ever come to terms with what that means. It's not end-user > cluelessness that's the problem, as it is with many open-source > packages. It's cluelessness *in the managers of the software*, which > is a different and rather nastier problem. > I will argue strenuously that service managers (or product managers, or program managers, or whatever you prefer to call that role) should *not* be trying to hack the system. They should be, and are, asking for changes that they think will improve the service they run. But who to ask? There are two paths: ask local developers (MIT's case) or ask the DSpace developer community at large. Obviously the former has a better chance of actually getting done, but the latter happens sometimes. For example, your request for an easier, less technical way to configure the system that doesn't require programming skills is very reasonable, but it would take a developer a lot of time to implement that, and it would be to the benefit of the whole community rather than a single institutions (especially the ones that have developers who might do this work, but who don't particularly need it themselves). So how to get that done? You could hire a developer of your own to do it. Or talk your institution (or CIC) into pooling its resources to hire a developer at the Foundation to do the work. etc. > - Since discussion of DSpace development is (understandably!) heavily > tilted toward developers and people with developer-level skills, the > developer community has very little access to and therefore > comprehension of rubber-meets-road requirements and procedures in > real-world library contexts. Also a generalization. Many DSpace developers are confronted daily with local service managers that want stuff. The problem as I see it is that those product roadmaps aren't being widely shared by their service managers (at least not on the DSpace lists) so we don't know where they converge or differ. That's what I'd like to see improved, but I wonder how much agreement there really is between institutions about the right way for repository services to evolve... what you perceive as indifference from developers may actually be indifference from the service managers that decide what those developers should work on... so you may be arguing with the wrong people. > - It has historically been extremely difficult for an individual at my > level of technical savvy or below to be heard by DSpace developers. > So (not to belabor the point) but could you ask Ken and Nolan to give you a dedicated developer for a year? If repository services are a priority for your institution, can you make the case that you need more resources to do what you believe it should? > On the other hand, > open-source developers are notorious for disdain of non-technical > input and the people who provide it, and DSpace has unfortunately not > departed from
Re: [Dspace-tech] Development goals
As a developer on other projects but mostly an end-user of DSpace, a few things stand out for me: When considering administrative access to services like DSpace, it's important to remember (and to remind the IT folk :-) that a box is not a platform is not an application. It's easy to set up permissions so that a given user account can do nothing but replace a specific file, like for example dspace.war. I've done it on our test box. The people who run a box don't have to grant free rein to those who run the platforms (e.g. Tomcat), and the people who run a platform don't have to grant full license to the people who run an application on it. It's merely necessary to establish trust and negotiate boundaries. If any party is unwilling to do that, or think there is no time to do it, that party should take a break to think about its purpose and examine its priorities. It's IT's job to make what you need to do doable. One thing that helps developers to work with, rather than against, end-users is for end-users to tell developers *what* they want to do and resist the temptation to tell the developers *how* to do it. (We all have this problem, whether in the doctor's office or the auto repair shop or what have you.) It's the developer's role to analyze requirements and propose means to meet them, because the developer has the information to do that while the end-user has the information on what is valuable to accomplish. Often an approach which seems perfectly reasonable to an end-user is "obviously" wrong from the developer's point of view, and of course developers may see nothing wrong with solutions that are baffling to the user. The developer should detect the underlying problem and guide the conversation back from "how" to "what", but there are times when this does not happen. The end-user should also be sensitive to such issues and help to make it happen. Never tell people how to do things. Tell them what to do and let them surprise you with their ingenuity. -- Gen. George Patton There's an interesting issue of modes of communication associated with the comment on training people to customize DSpace. Presentations necessarily take place at a given point in time, but people in need of tutorial material more often need it when they are taking up the task, not whenever it is available -- there's too big a time gap between the lecture and the lab., so to speak. I think that written material is probably more effective here, and I applaud those who are creating it. -- Mark H. Wood, Lead System Programmer [EMAIL PROTECTED] Typically when a software vendor says that a product is "intuitive" he means the exact opposite. pgp5mANba2hoC.pgp Description: PGP signature - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
Re: [Dspace-tech] Development goals
> It's not hard to argue that plenty of innovation and contribution has > been stillborn -- a quick look at the patch queue is enough for that. > It's tempting and easy to lay the blame solely at the doorstop of the > technology, however there are many other issues: (snipping excellent list) I think there's an additional issue that may prove even more difficult to address: the problem of a technical infrastructure widely adopted by non-technical people. I haven't taken a look at the wiki to be sure, but my gestalt sense is that a substantial majority of DSpace instances live in academic libraries and academic-library consortia. As the general run of academic librarians goes, *I am highly technical*. (Tim Donohue is an outright anomaly.) For those who don't know me: I'm a self-taught Python coder, and I've learned just enough Java to muck around a bit at the upper levels of DSpace. I can do a little SQL, though a lot of trial and error is involved and I know nothing of query optimization. I can do a little XSLT, though some of the XPaths in Manakin frankly break my brain. I'm fine with XHTML and CSS, though I'm not up on all the latest CSS hacks. I haven't ever done any serious web programming. I'm good with XML. I'm aware of usability issues and practices, though I don't have any talent for coming up with fixes, and I'm well-grounded in web accessibility. And every single DSpace committer right now is laughing fit to kill, because the above skill list is *pathetic*. As I said, though, I'm atypical *on the technical high end* of librarianship. I don't think DSpace has ever come to terms with what that means. It's not end-user cluelessness that's the problem, as it is with many open-source packages. It's cluelessness *in the managers of the software*, which is a different and rather nastier problem. To tell a story on myself, I told Robert Tansley at OR '07 that I was a beginning-level Java coder and asked what I might contribute to DSpace within the limits of my abilities. He suggested I look at revamping the Browse system, perhaps to piggyback on a Lucene index. I did. Believe me, I shouldn't be *touching* that. I hardly know where to begin, and if I *did* begin, I don't have a solid enough grounding (or, indeed, *any* grounding) in code optimization or testing to know whether what I'd come up with would solve the lingering performance problems. The implications of this disconnect between the developer community and DSpace managers include: - DSpace isn't just difficult to customize for librarians, it is frequently *impossible* to customize, because the box isn't controlled by us but by IT. (Another story: when I interviewed for the position I currently hold, I was told that I could not expect to have server access to DSpace, much less permission to customize it, because to give me those privileges might endanger the library's excellent relationship with the IT group running the DSpace box. This turned out not to be true, for which I am duly grateful, but it goes to show.) Mods and plugins that aren't neatly packaged are just plain non-starters with us. I disagree slightly with Robert that mod adoption is a chicken-and-egg problem, and with Don Gourley that the current API is sufficient for the level of innovation we hope for; I believe that a stable, documented, vetted API and a blessed plugin directory will make a considerable difference in innovation uptake. (Librarians like authoritative sources -- and it's a lot easier for us to approach IT with a "plugin" than with a miscellaneous chunk of Somebody Else's Code.) - Since discussion of DSpace development is (understandably!) heavily tilted toward developers and people with developer-level skills, the developer community has very little access to and therefore comprehension of rubber-meets-road requirements and procedures in real-world library contexts. Surveys are all very well, but are they even reaching the librarians who form the public face of the software (rather than the sysadmins who support it)? I doubt it. I really do. Ethnographic, qualitative study and usability testing with librarians as subjects are likely to be more productive approaches, but they have not been tried. - Librarians tend to have a passive and narrowminded attitude toward our software. (I'll spare everyone the rant about integrated library system vendors fostering this passivity.) What is, is, and there's nothing we can do about it. This means, first, that we just don't think in terms of "this wart can and should be fixed" -- we think instead about workarounds, or we beat our workflows into the ground to match the software. It can be insanely frustrating to elicit requirements and useful feedback from us! Second, it means we don't come forward with suggestions, or even think creatively about how to improve the software; it's not in our culture. - It has historically been extremely difficult for an individual at my level of technical savvy or below to be heard by D
Re: [Dspace-tech] Development goals
On Fri, Nov 16, 2007 at 09:40:33AM +0100, Christophe Dupriez wrote: > To be constructive and pragmatic, my main technical challenge remains: > adding "thesaurus based" query expansion to DSpace to be able to mimic > PubMed searches exhaustivity and precision in DSpace (we now have 75 > thousands documents in our internal repository. MeSH is 30 thousands > subjects headings). I will keep focused on this. I've been saying for some time that, nice as the DSpace user interface is in many respects, it is not and should not be the only way to plumb a DSpace archive. If it is (currently) difficult to get a particular search style put into DSpace, may I suggest trying a different approach. One could harvest metadata via the PMH responder, organize them any way one wishes, and search them in any desired way. One could install, for example, an SRU interface such as OCLC's and build or adapt an external search tool to drive it against the archive's live indices. Should such external searching tools prove widely useful, they could generate interest in porting them into DSpace. If they embody a well-thought-out modular architecture, the porting should not be difficult. In any case they would be usable as-is. -- Mark H. Wood, Lead System Programmer [EMAIL PROTECTED] Typically when a software vendor says that a product is "intuitive" he means the exact opposite. pgpHv7Y94Nt7S.pgp Description: PGP signature - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
Re: [Dspace-tech] Development goals
I do have a great deal of sympathy with Dorothea's original point that most development is guided by uses cases at the larger institutions, in fact I started a conversation on this very point in the user group meeting closing session -- and of course there was disagreement on how to address it or even that there was an issue at all. It's not hard to argue that plenty of innovation and contribution has been stillborn -- a quick look at the patch queue is enough for that. It's tempting and easy to lay the blame solely at the doorstop of the technology, however there are many other issues: - Most DSpace users have immediate requirements and limited resources, and so do the minimum to get the functionality they need. What's needed here is an understanding by institutions of the increased long-term costs of maintaining local customisations compared to the upfront investment in developing something more generally useful. Even the most wonderfully clean and modular system would only ameliorate this problem and not eliminate it. - No matter what tools we put in place, the existence of well-supported and widely adopted add-ons is a chicken-and-egg problem. If people daren't adopt them, no one will work on them, which means... Yes, we can provide central tools for this but it's about people stepping forward and actually doing the work. In the case of TAPIR (and I could stand to be corrected here) everyone pretty much left it to Richard Jones to maintain it, which was clearly never a sustainable solution. TAPIR is a project on SourceForge to which I'm sure Richard would have been more than happy to allow interested contributors access. - Potential contributors need to start a conversation early and be flexible. As I've said before, a contribution to DSpace is a conversation, not a patch file. Often people throw contributions over the fence when they've no more time to work on it. Share early, share often, have a thick skin. - When people do start these conversations, they should get constructive feedback, but it's no one's job to do this yet, so often it doesn't happen. - There's no process whereby decisions can get made in a timely manner. The way things are now, pretty much anyone (certainly any committer) can 'black ball' an idea or contribution. We clearly need something more agile. So the technology is moving in the right direction now; once we have a data model flexible enough to accommodate different use cases, and a way to manage and distribute add-ons that include new UI pages, business logic and have access to persistent storage, we'll be in better shape. However, just as importantly, we will also need better education and communication, and people with time to give others feedback on how to generalise their work. I particularly like Mark's advice, which I'll leave you with: > You should be more aggressive in participating "in the community" on > something like this, prod the community to get more participation, and be > flexible about the final outcome. Rob - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
Re: [Dspace-tech] Development goals
On Nov 16, 2007, at 3:40 AM, Christophe Dupriez wrote: Dear Michele (copy to the community), May be I am basically wrong seing DSpace as a community of practice making a tool to promote the dissemination of the "good" Open Repositories practices. No. I think your right on in this regard, but just not "one tool", many tools that work collaboratively. Yet, also to be a good participant in a larger community of existing tools and platforms. If I understand correctly your plans, DSpace is primarily a community of developpers where users requirements are tackled inside individual institutions and "mostly technical" problems are shared outside. I am sorry that my "dream" is different but I will play the "real game" ! I will follow the Claudia Juergen's advice: "Small contributions are beautiful". I think we need to "be careful" about these definitions. The DSpace Community is a reflection of what its members need and want in an organization of users, managers and developers around the DSpace platform. The most salient roadblock to increasing the transmission of community enhancements into the codebase is that DSpace was basically a monolithic platform with a centralized build process. A significant bottleneck existed (and may still exist until we have a SCM and Issue tracking system that is scalable in terms of Access control) in that the "commiters" managing the process of reviewing and getting changes into the codebase supplied by the community as "patches". The developers who are "commiters" are so because they want to participate more intimately with the future direction of DSpace. The previous viewpoint that "commiters" were basically "servants" or "gate-keepers" to the contributor community is both ill-fitting and unrealistic because a large number of the "commiters" are actually emeritus in their behavior and not very active, leaving much of the work in the role of "gate-keeper" actually to the newly elected commiters. Thus the "paradox" and the "bottleneck". The actual and ideal "maintainers", "shepherds" or "stewards" of the community are not on the continuum of "commiter vs. contributor", but actually on the continuum of "active vs. inactive"! We need a better process for shifting the dial to the "active" side. To be constructive and pragmatic, my main technical challenge remains: adding "thesaurus based" query expansion to DSpace to be able to mimic PubMed searches exhaustivity and precision in DSpace (we now have 75 thousands documents in our internal repository. MeSH is 30 thousands subjects headings). I will keep focused on this. You should be more aggressive in participating "in the community" on something like this, prod the community to get more participation, and be flexible about the final outcome. I think you'll find that there are other developers in the community with the same interest. It would behoove you and them to get out of the woodwork and have real transparent conversations together on the community lists (hint hint, nudge nudge, Richard Rodgers). Cheers, Mark ~ Mark R. Diggory - DSpace Systems Manager MIT Libraries, Systems and Technology Services Massachusetts Institute of Technology - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
Re: [Dspace-tech] Development goals
Dear Michele (copy to the community), May be I am basically wrong seing DSpace as a community of practice making a tool to promote the dissemination of the "good" Open Repositories practices. If I understand correctly your plans, DSpace is primarly a community of developpers where users requirements are tackled inside individual institutions and "mostly technical" problems are shared outside. I am sorry that my "dream" is different but I will play the "real game" ! I will follow the Claudia Juergen's advice: "Small contributions are beautiful". To be constructive and pragmatic, my main technical challenge remains: adding "thesaurus based" query expansion to DSpace to be able to mimic PubMed searches exhaustivity and precision in DSpace (we now have 75 thousands documents in our internal repository. MeSH is 30 thousands subjects headings). I will keep focused on this. Have a nice day! Christophe Michele Kimpton a écrit : Dear Christophe and DSpace community, One of the main projects the Foundation ( not federation, and I point this out as they are completely different) has taken on is to put together a team from the community and get funding for DSpace 2.0. The work to be done will involve core architectural changes- under the hood, so to speak- that will be somewhat transparent to many end users. However, these changes will have large implications down the road, in a good way, for the community at large. One of the complaints is to be able to easily change the UI, or create multiple UI's, Web 2.0 interactions,ect., is due to the fact the code is not modular ( as Tim points out). One of the main goals of 2.0 is to make it more modular so organizations can "plug and play", meaning choose the interface(s) they prefer. It also allows many more developers to participate in the process- as their contributions can be rolled into the releases much more easily, given the code will not have complex interdependencies with the rest of the core code ( we hope). If we are successful in putting together a modular architecture- than we can have multiple UI's, asset stores, workflows ect. As there are no dedicated developers within the community or the Foundation working full time on DSpace- it is important to empower the community to be able to contribute code that fits their organizational needs- and therefore we must put an architecture in place that supports this process. We hope to start the work for DSpace 2.0 this winter. Once 2.0 is in place we can start a process where users can assess user needs and feature requests(developers can do this now on source forge) but realize the work to develop those features will still need to be done within the community, and maybe the community will be willing to pay for development time to make it happen collaboratively, but that remains to be seen. I plan on hiring a Technology Director within the Foundation to help lead this process(2.0 and beyond). We have secured some of the funding and developer time to do the work required. I hope to secure the remaining funding needed over the next few months. If anyone in the community would like to help me in this process( getting funding, donating developer time, volunteering I welcome your help. sincerely, Michele DSpace Foundation Director On Nov 15, 2007, at 3:09 AM, Christophe Dupriez wrote: Hi Tim, (copy to Michele, Dorothea and the Tech list) Thanks for your views and congratulations for your work with IDEALS. Just to be sure to be well understood: I am not in any way proposing to disturb developpers, I am speaking about organising USERS so they express their needs, build concensus and propose developers to build prototypes they can evaluate. I am also proposing to organize better the commitment process to improve consistency and reliability. This will ask for inter-institutional efforts so I also propose institutions to finance parts of those processes. This is the key of adequation and perenity. I am not saying nothing of this is done now, I am just proposing this to be improved under the drive of the Federation. Wishing you and all a very nice day! Christophe Dupriez Tim Donohue a écrit : All, As a Committer, I'm going to go ahead and step out on limb here, and admit that I agree with most of what has been put forth by both Dorothea and Christophe. That being said, I'm not claiming to speak on behalf of all the Committers :) I would *love* a more beautified DSpace...a clean, "flashy", web-2.0 interface, a modular system that is easy to extend via plugins/add-ons, an *easy* way to share/install those plugins/add-ons between institutions, and an *easy* way to upgrade core DSpace (without merge nightmares between your local hacks/customizations and the features of the new version). I'm also in full support of working towards better needs assessment. But, at the same time, a part of me feels that different institutions will have
Re: [Dspace-tech] Development goals
Dear Christophe and DSpace community, One of the main projects the Foundation ( not federation, and I point this out as they are completely different) has taken on is to put together a team from the community and get funding for DSpace 2.0. The work to be done will involve core architectural changes- under the hood, so to speak- that will be somewhat transparent to many end users. However, these changes will have large implications down the road, in a good way, for the community at large. One of the complaints is to be able to easily change the UI, or create multiple UI's, Web 2.0 interactions,ect., is due to the fact the code is not modular ( as Tim points out). One of the main goals of 2.0 is to make it more modular so organizations can "plug and play", meaning choose the interface(s) they prefer. It also allows many more developers to participate in the process- as their contributions can be rolled into the releases much more easily, given the code will not have complex interdependencies with the rest of the core code ( we hope). If we are successful in putting together a modular architecture- than we can have multiple UI's, asset stores, workflows ect. As there are no dedicated developers within the community or the Foundation working full time on DSpace- it is important to empower the community to be able to contribute code that fits their organizational needs- and therefore we must put an architecture in place that supports this process. We hope to start the work for DSpace 2.0 this winter. Once 2.0 is in place we can start a process where users can assess user needs and feature requests(developers can do this now on source forge) but realize the work to develop those features will still need to be done within the community, and maybe the community will be willing to pay for development time to make it happen collaboratively, but that remains to be seen. I plan on hiring a Technology Director within the Foundation to help lead this process (2.0 and beyond). We have secured some of the funding and developer time to do the work required. I hope to secure the remaining funding needed over the next few months. If anyone in the community would like to help me in this process( getting funding, donating developer time, volunteering I welcome your help. sincerely, Michele DSpace Foundation Director On Nov 15, 2007, at 3:09 AM, Christophe Dupriez wrote: > Hi Tim, (copy to Michele, Dorothea and the Tech list) > > Thanks for your views and congratulations for your work with IDEALS. > > Just to be sure to be well understood: I am not in any way > proposing to disturb developpers, I am speaking about organising > USERS so they express their needs, build concensus and propose > developers to build prototypes they can evaluate. I am also > proposing to organize better the commitment process to improve > consistency and reliability. This will ask for inter-institutional > efforts so I also propose institutions to finance parts of those > processes. This is the key of adequation and perenity. > > I am not saying nothing of this is done now, I am just proposing > this to be improved under the drive of the Federation. > > Wishing you and all a very nice day! > > Christophe Dupriez > > Tim Donohue a écrit : >> All, >> >> As a Committer, I'm going to go ahead and step out on limb here, >> and admit that I agree with most of what has been put forth by >> both Dorothea and Christophe. That being said, I'm not claiming >> to speak on behalf of all the Committers :) >> >> I would *love* a more beautified DSpace...a clean, "flashy", >> web-2.0 interface, a modular system that is easy to extend via >> plugins/add-ons, an *easy* way to share/install those plugins/add- >> ons between institutions, and an *easy* way to upgrade core DSpace >> (without merge nightmares between your local hacks/customizations >> and the features of the new version). >> >> I'm also in full support of working towards better needs >> assessment. But, at the same time, a part of me feels that >> different institutions will have some different needs based on how >> they are using of DSpace. So, in the end, allowing for easy >> extensions/modules, and easy sharing of these community-developed >> features is a great way to go. >> >> That being said, I'd like to mention just a few things to look >> forward to with 1.5 and beyond: >> >> 1) I believe there will be vast strides to beautifying DSpace UI, >> once we all get our hands on Manakin in 1.5 (many thanks to Scott >> P & all at Texas A&M). The modularity within Manakin should also >> allow us to all develop new an interesting Themes & Aspects, which >> should be much more shareable amongst institutions. (But, we also >> need to find a place to actually post these for sharing!) >> >> 2) I believe that our move towards the Maven build system (thanks >> to Mark D) with 1.5
Re: [Dspace-tech] Development goals
Hi Tim, (copy to Michele, Dorothea and the Tech list) Thanks for your views and congratulations for your work with IDEALS. Just to be sure to be well understood: I am not in any way proposing to disturb developpers, I am speaking about organising USERS so they express their needs, build concensus and propose developers to build prototypes they can evaluate. I am also proposing to organize better the commitment process to improve consistency and reliability. This will ask for inter-institutional efforts so I also propose institutions to finance parts of those processes. This is the key of adequation and perenity. I am not saying nothing of this is done now, I am just proposing this to be improved under the drive of the Federation. Wishing you and all a very nice day! Christophe Dupriez Tim Donohue a écrit : All, As a Committer, I'm going to go ahead and step out on limb here, and admit that I agree with most of what has been put forth by both Dorothea and Christophe. That being said, I'm not claiming to speak on behalf of all the Committers :) I would *love* a more beautified DSpace...a clean, "flashy", web-2.0 interface, a modular system that is easy to extend via plugins/add-ons, an *easy* way to share/install those plugins/add-ons between institutions, and an *easy* way to upgrade core DSpace (without merge nightmares between your local hacks/customizations and the features of the new version). I'm also in full support of working towards better needs assessment. But, at the same time, a part of me feels that different institutions will have some different needs based on how they are using of DSpace. So, in the end, allowing for easy extensions/modules, and easy sharing of these community-developed features is a great way to go. That being said, I'd like to mention just a few things to look forward to with 1.5 and beyond: 1) I believe there will be vast strides to beautifying DSpace UI, once we all get our hands on Manakin in 1.5 (many thanks to Scott P & all at Texas A&M). The modularity within Manakin should also allow us to all develop new an interesting Themes & Aspects, which should be much more shareable amongst institutions. (But, we also need to find a place to actually post these for sharing!) 2) I believe that our move towards the Maven build system (thanks to Mark D) with 1.5 will be a huge step in the right direction for better modularity within DSpace, and better separation between the core API and various Interfaces (Manakin, JSP, OAI-PMH, LNI, etc.). There are still a few kinks here, but we're learning quickly and attempting to make things easier to manage as separate modules (and also easier to upgrade!). The goal here is to hopefully help allow community-developed customizatins/add-ons to flourish and not be a continual pain in managing/updating. In addition, we want to make them more easily shareable between institutions (i.e. without the pain of merging local code, etc.). I'm not claiming this will all be figured out or 100% perfect in 1.5...but, it is a goal I'm hoping we can get to by 1.6 or 2.0 (or whatever comes after 1.5). As a Committer, I also feel obligated to mention that the Committers are all volunteers. We are working hard to make DSpace better for all of us, but there's only so much we can do (and largely our development work is defined by our the individual interests of the institutions which pay our salaries). Therefore, DSpace is still dependent on new features/ideas/functionality being proposed & developed/prototyped by an active user community. The Committers may be able to step in and help out (when their institutions allow), but I believe an active community is still necessary. Remember, the Committers are often just highly-active community members! Case in point: I was only asked to become a Committer after my giving back to the community (in the form of DSpace tutorials and Q&A on listservs), as well as the large amount of work in designing, re-designing & developing the Configurable Submission (which my institution allowed me the opportunity to take on). I'm really glad to see these discussions taking place! It means we do have people in the community who care strongly about DSpace and are willing to share their opinions and suggestions for moving forward. I encourage you to continue to help drive DSpace in the right direction! Ok...that's my diatribe or rather long $0.02 :) - Tim Christophe Dupriez wrote: Hi ! At PoisonCentre.be, we use DSpace for scientific (medical) information collection, organisation and internal re-publication, e.g. Knowledge sharing (not ETDs)! I find rather funny that this discussion occurs in the technical thread and not the general one. The technicities are the reasons we meet, the subjects vary! I share most of Dorothea opinions. I strongly support the creation of a DSpace group for user needs assesment. The output of this grou
Re: [Dspace-tech] Development goals
All, As a Committer, I'm going to go ahead and step out on limb here, and admit that I agree with most of what has been put forth by both Dorothea and Christophe. That being said, I'm not claiming to speak on behalf of all the Committers :) I would *love* a more beautified DSpace...a clean, "flashy", web-2.0 interface, a modular system that is easy to extend via plugins/add-ons, an *easy* way to share/install those plugins/add-ons between institutions, and an *easy* way to upgrade core DSpace (without merge nightmares between your local hacks/customizations and the features of the new version). I'm also in full support of working towards better needs assessment. But, at the same time, a part of me feels that different institutions will have some different needs based on how they are using of DSpace. So, in the end, allowing for easy extensions/modules, and easy sharing of these community-developed features is a great way to go. That being said, I'd like to mention just a few things to look forward to with 1.5 and beyond: 1) I believe there will be vast strides to beautifying DSpace UI, once we all get our hands on Manakin in 1.5 (many thanks to Scott P & all at Texas A&M). The modularity within Manakin should also allow us to all develop new an interesting Themes & Aspects, which should be much more shareable amongst institutions. (But, we also need to find a place to actually post these for sharing!) 2) I believe that our move towards the Maven build system (thanks to Mark D) with 1.5 will be a huge step in the right direction for better modularity within DSpace, and better separation between the core API and various Interfaces (Manakin, JSP, OAI-PMH, LNI, etc.). There are still a few kinks here, but we're learning quickly and attempting to make things easier to manage as separate modules (and also easier to upgrade!). The goal here is to hopefully help allow community-developed customizatins/add-ons to flourish and not be a continual pain in managing/updating. In addition, we want to make them more easily shareable between institutions (i.e. without the pain of merging local code, etc.). I'm not claiming this will all be figured out or 100% perfect in 1.5...but, it is a goal I'm hoping we can get to by 1.6 or 2.0 (or whatever comes after 1.5). As a Committer, I also feel obligated to mention that the Committers are all volunteers. We are working hard to make DSpace better for all of us, but there's only so much we can do (and largely our development work is defined by our the individual interests of the institutions which pay our salaries). Therefore, DSpace is still dependent on new features/ideas/functionality being proposed & developed/prototyped by an active user community. The Committers may be able to step in and help out (when their institutions allow), but I believe an active community is still necessary. Remember, the Committers are often just highly-active community members! Case in point: I was only asked to become a Committer after my giving back to the community (in the form of DSpace tutorials and Q&A on listservs), as well as the large amount of work in designing, re-designing & developing the Configurable Submission (which my institution allowed me the opportunity to take on). I'm really glad to see these discussions taking place! It means we do have people in the community who care strongly about DSpace and are willing to share their opinions and suggestions for moving forward. I encourage you to continue to help drive DSpace in the right direction! Ok...that's my diatribe or rather long $0.02 :) - Tim Christophe Dupriez wrote: > Hi ! > > At PoisonCentre.be, we use DSpace for scientific (medical) information > collection, organisation and internal re-publication, e.g. Knowledge > sharing (not ETDs)! > > I find rather funny that this discussion occurs in the technical thread > and not the general one. > The technicities are the reasons we meet, the subjects vary! > > I share most of Dorothea opinions. > > I strongly support the creation of a DSpace group for user needs assesment. > The output of this group should be: > 1) use cases, > 2) value of thoses use cases for the institutions we represent, > 3) essential "user side" characteristics of the corresponding > functionalities those uses cases imply. > > From there: > 1) a "designer board" could propose functionalities (no buzzwords!) to > fulfill those needs. > 2) developpers would be invited to find "mentors" within the users > groups and to produce a prototype. > 3) User group would then discuss prototypes results and would choose > those that must be worked further for inclusion in DSpace trunk. > 4) Committers would work on "mature prototypes" (user proof) to make > them 100% compliant to DSpace architecture and coding standards. > > IMHO, this process should be tightly driven by the Foundation and > financed by institutions taking advantage of
Re: [Dspace-tech] Development goals (was: ETDs & Dspace - Best Practices)
There has been quite a lot of work done to build a plug-in framework for DSpace 1.5 and rework the build environment to make it much more modularity-friendly. This is a welcome improvement. Lots of people have been making lots of useful additions to DSpace, but their adoption elsewhere typically requires a good deal of expertise in the management of software development, if not actual development skills. I had to study Subversion rather intensely before I got my arms around the problem of coordinating stock DSpace releases, local modifications, and mod.s we got from others. The fundamental problem is that patching software, and maintaining patches as the underlying software evolves, is difficult. A lot of good work has been done which is hard to share with others. I believe that 1.5 begins to address that issue. It won't be the end of the process, but there *has* been a beginning, and I think a good one. Probably the most popular hard-to-maintain modification to DSpace is style and layout changes, and Manakin makes the coupling between presentation and operation a lot looser and better organized, which is what was needed. We're looking forward to doing less re-work per DSpace release after we've ported our JSPUI changes to XMLUI. -- Mark H. Wood, Lead System Programmer [EMAIL PROTECTED] Typically when a software vendor says that a product is "intuitive" he means the exact opposite. pgpOrnzPVugDZ.pgp Description: PGP signature - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
[Dspace-tech] Development goals (was: ETDs & Dspace - Best Practices)
Hi ! At PoisonCentre.be, we use DSpace for scientific (medical) information collection, organisation and internal re-publication, e.g. Knowledge sharing (not ETDs)! I find rather funny that this discussion occurs in the technical thread and not the general one. The technicities are the reasons we meet, the subjects vary! I share most of Dorothea opinions. I strongly support the creation of a DSpace group for user needs assesment. The output of this group should be: 1) use cases, 2) value of thoses use cases for the institutions we represent, 3) essential "user side" characteristics of the corresponding functionalities those uses cases imply. From there: 1) a "designer board" could propose functionalities (no buzzwords!) to fulfill those needs. 2) developpers would be invited to find "mentors" within the users groups and to produce a prototype. 3) User group would then discuss prototypes results and would choose those that must be worked further for inclusion in DSpace trunk. 4) Committers would work on "mature prototypes" (user proof) to make them 100% compliant to DSpace architecture and coding standards. IMHO, this process should be tightly driven by the Foundation and financed by institutions taking advantage of DSpace know how, technology and emulation. It seems to me that project IDEALS is an example of this: https://services.ideals.uiuc.edu/wiki/bin/view/IDEALS/RequirementsProduction An example of the "users requirements" challenges we could achieve for DSpace: http://www.vufind.org/ http://zoombox.gmu.edu/vufind/ For my institution, I need now to fulfill the challenge of crosslinking different DSpace instances (or collections) to have one serve as an authority list for some fields of others (and to use those relations in searches). Have a nice day! Christophe Dupriez [EMAIL PROTECTED] [EMAIL PROTECTED] Dorothea Salo a écrit : On Nov 13, 2007 1:23 PM, Susan Teague Rector <[EMAIL PROTECTED]> wrote: Our debate here is centered on future support of ETDs in DSpace. We've had to do quite a bit of customization to support ETDs (thank goodness for Tim Donahue's code :)! Does anyone know if there are future plans to better support ETDs in DSpace? With the understanding that I'm not a DSpace committer and not involved in any way with DSpace or the DSpace Foundation except as DSpace user and occasional bug or patch submitter... My sense is that DSpace development has only vaguely and loosely been guided by real-world use cases not arising from its inner circle of contributing institutions. E.g., repeated emails to the tech and dev lists concerning metadata-only deposits (the use case there generally being institutional-bibliography development), ETD management, true dark archiving, etc. etc. have not been answered by development initiatives, or often by anything but "why would you even want that?" incomprehension or "just hack it in like everybody else!" condescension. There are hacks for some of these uses, yes... but from a sysadmin's perspective, hacks endanger smooth upgrade paths, and from the perspective of many librarians, hacks are entirely out of reach because IT rather than the librarian controls the box DSpace lives on. When innovation has occurred around DSpace, it has generally died on the vine because of the aforementioned threat to smooth upgrade paths. TAPIR and Researcher Pages may serve as the requisite gruesome warnings here; they died not because the ideas underlying them were bad (they emphatically weren't! if we still had TAPIR, Susan wouldn't have had to ask the question she just did!), but because almost nobody dared adopt them. I see all kinds of nifty conference presentations involving DSpace mods -- but they provide me no practical benefit whatsoever, because the code isn't out there and I probably couldn't use it if it were! DSpace's lack of a plugin/mod API, coupled with the amazing spaghetti dinner under its hood, has stifled service innovation in the repository space for years, and will continue to do so until the defect is rectified. Neither EPrints nor Fedora is in a much better position just now, but in all honesty, I predict that the first platform to *have* a half-decent mod API (especially one that welcomes mods written in friendlier languages than Java) will experience an explosion of innovations that will eat the other platforms' lunch. Manakin assuredly helps, but not quite enough. SWORD may also help, rather backhandedly, by providing an ingest path that doesn't rely on the horrendous web UI or the awkward batch ingester. We'll see; I'm hopeful. I'd far rather build an ETD app that used SWORD to drop ETDs into DSpace than try to hack DSpace for ETDs myself, much less try to push the committer group to do so. It may be worth noting at this point that I put my votes where my mouth is; when the DSpace development survey came out, I put a mod API at the very top of my desiderata. I encourage other repository managers with
Re: [Dspace-tech] Development goals (was: ETDs & Dspace - BestPractices)
On 13/11/07 23:52, "Christian Voelker" <[EMAIL PROTECTED]> wrote: > I appreciate your comment written with the deep knowledge of a > long term user but I have a hard time to google all the external > references to technologies such as Tapir, Researcher Pages, Sword > an everything else you mention. I would need to know them to > really understand where you are heading to. Can you gimme a link > or a hint? Tapir: - http://www.thesesalive.ac.uk/dsp_home.shtml - http://wiki.dspace.org/index.php/TapirAddOn Researcher pages: - http://tinyurl.com/yveb2u - An example: http://tinyurl.com/yw6sk2 SWORD: - http://www.ukoln.ac.uk/repositories/digirep/index/SWORD - http://sourceforge.net/projects/sword-app/ I hope they help, Stuart _ Gwasanaethau Gwybodaeth Information Services Prifysgol Aberystwyth Aberystwyth University E-bost / E-mail: [EMAIL PROTECTED] Ffon / Tel: (01970) 622860 _ - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
Re: [Dspace-tech] Development goals (was: ETDs & Dspace - Best Practices)
Hello Dorothea, I appreciate your comment written with the deep knowledge of a long term user but I have a hard time to google all the external references to technologies such as Tapir, Researcher Pages, Sword an everything else you mention. I would need to know them to really understand where you are heading to. Can you gimme a link or a hint? Although it does not sound especially polite to call DSpace a spaghetti dinner and provided that your judgement is right, I totally agree on the importance of user driven development and the requirement of a usable and stable API. There are far more places where a digital archive software such as DSpace could be useful besides the academic area but where it is hard to adapt to. It takes advanced skills to leverage the power of this tool but the audience does not necessarily be either on the same level of education nor as homogenous as an academic campus community. There is a page in the wiki which lists projects that use DSpace. Until now I saw this page targeted to the potential user to make him or her trust in the project. Would it be useful to add some two or three lines about the goal of each project to improve the picture for the next time the developers decide on what they will do next? Or do we need formal processes with a review board and so on?. I am sure that this is an important discussion and that it can help to sharpen the profile of the project and make it even more compelling. I feel there is some room for improvement left in that regard. Bye, Christian - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
