Hi Miika, happy to hear that you are evaluating DSpace-CRIS. Some contextual informations: my company, CINECA, provides a full CRIS solution implemented as proprietary software: SURplus based on DSpace and DSpace-CRIS http://www.cineca.it/en/content/surplus
SURplus is made of several modules, the publication data collector (OA module) is build upon DSpace and the research portal (ES module) is build upon DSpace-CRIS. In DSpace-CRIS actually is not implemented any validation flow, the data are batch loaded from external database or manually entered by the administrators (this last option obvious work only for small institution). It should be enough simple extend the actual functionalities to allow other groups of users to manage object creation and introduce a "one-step" approval (all the CRIS entities have a flag status private/public that can be used for that). More complex workflow or generalizable workflow need an infrastructure and a set of UIs like the ones used by the DSpace workflow, or if you need to manage grant or patent workflow something much more complex, so it is not a trivial extension. Our commercial solution have a dedicated module for that, SURplus WF. Anyway, the extensible data model of DSpace-CRIS inherited by the use of the JDynA framework assure that any data structure can be represented without loss of details. In general DSpace-CRIS is suitable out-of-box for the dissemination of all research entities and as authority source, often local cache of other systems, for many publication metadata (authors, journal title, publishers, projects, etc.). DSpace with DSpace-CRIS can be easily extended to fullfit all your need about description and validation of publication data (it is how also our commercial solution work). You can have CRIS entities, say researchers, that are used as authority list for some metadata only for a subset of the full list (i.e. only internal for a metadata, only external for another). With some coding, you can also implement contextual filters, i.e. using the publication year. Publication types (book, journal article, etc.) are normally managed using different dspace collections. This allow specific metadata configuration (input-forms), submission flow (item-submission) and validation. Cross validation of multiple metadata should be performed in custom dspace submission steps. The affiliation issue is the most complex one as DSpace-CRIS allows you to store the affiliation history of a Researcher but not to peek a specific affiliation for the authorship of a specific publication. This issue is still an open question in the CERIF euroCRIS standard, http://www.eurocris.org/Index.php?page=featuresCERIF&t=1, (I'm a member of the CERIF Task Group) as this is formally a metadata about the relationship publication-author. In DSpace-CRIS we have the concept of nested object that can be used to record such kind of informations, say the affiliation of an investigator in a project but as the publication are standard DSpace item you cannot benefit of such feature. There are several workaround that can be implemented and should work for you, depending mainly on the analysis that you need to perform on these relationship metadata. You can store the publication-author affiliation data as part of the author metadata in a semi-structured way (i.e. Bollini, Andrea; CINECA) or you can put the affiliation information in an additional table or a column of metadatavalue. The right way to do that should be make the item metadata nestable, probably this is something that we will work on in future. Time span can be managed in several way in DSpace-CRIS as essentially you are free to model your entities. When time span apply to an entity instance, an organization, a project, etc., it is usually most useful to map it to a direct field of the entity. When time span apply to a relationship, i.e. affiliations researcher-orgunit, you can map it to a nested object (with a pointer to the researcher and a pointer to an orgunit) or take advantage of the new attributes start_date, end_date present directly on the JDynA Property object. We are extending these functionalities as we are currently work on the CERIF compliance. As now the nested approach is the only supported by the UI, but we plan to add support also for the other later. First level entities and second level entities differ only from a database perspective as any first level entity class has it own tables, instead second level entities are stored in a single set of tables. From a functional point of view there is not difference, all the functionalities: edit screen, configurable view, configurable relationship, use as authority, statistics, network, etc. are available for both. The JDynA framework support the idea of "types" so that you can have different types of "project", "researcher", "orgunit" that change the list of available fields (actually that don't change repeatability or mandatory settings). It should be enought simple to expose this functionality to DSpace-CRIS as it is the way that the second level entities are managed. Finally you have asked about the submission lookup functionalities. The code is already available on github and we have send a PR for inclusion in 4.0 https://github.com/DSpace/DSpace/pull/306 https://github.com/DSpace/DSpace/pull/78 (a little out-of-date but still valid) We are currently evaluating the best strategy to include that in dspace 4.0 as these PRs, at least for some processing technical aspects, are very close to the BTE from EKT https://github.com/DSpace/DSpace/pull/317 https://github.com/DSpace/DSpace/pull/318 We will prefer, if possible, to have a single way to configure bibliographic imports in dspace. Hope this help, Andrea PS: feel free to ask other questions, it will be great if you can go ahead with your analysis and help us to produce documentation for others. Il 11/10/2013 11.46, Miika Nurminen ha scritto: > Hello, > > I'm investigating options for a new research information system in our > organization. Dspace-CRIS has been considered as one candidate. The > prospect of merging research data with existing Dspace installation > seems promising from the maintenance point of view, and especially the > functionality implemented at the HKU Scholars Hub feels most > impressive. > > We have some quite specific CRIS requirements both related to > validation of publication data (partially posed by the Ministry of > Education so the same requirements apply to other institutions in > Finland as well), and support for various workflows - especially > related to tracking projects and grants. I managed to get test > installation of Dspace-CRIS running, but I have some questions about > the capabilities (or possibilities of customization with "reasonable" > effort - our old system has been developed completely in-house so we > are prepared to do some develepment and certainly collaborate with > other organizations with similar needs as well) of the system. > > - The most pressing concern (since this seems to be currently handled > better in commercial alternatives): is it feasible to implement > customizable workflow processes related to CRIS entities that is > separated from the normal Dspace submission process? > This involves "validation" all all first-level CRIS entities in > general (for example, librarian should check additions to journal > items), and in its most involved form, project/grant management (=Pre- > and Post-Award Process). The basic process should be like: > 1. Researcher fills in some basic metadata about the project > application (name, funders, partners, budget information, etc.) > 2. For "large" projects, financial secretary checks the budget > 3. For all projects, dept. head approves or rejects the application > 4. If the application is approved, data about the funding decision > and possibly spending would be imported from financial system. In most > cases, financial secretary (or administrator) would link the financial > data with project application (using the project code or other > identifier). After the link has been made, new records (=e.g. funding > decisions for different years) related to the project should be > combined to earlier data automatically (based on the linked the > project code). > I assume that the data import or the actual data structure needed to > represent this information is not a problem, and dept. heads or > secretaries can probably be represented using the Dspace authorization > groups, but what about the workflow (notifications, acceptance) > functionality related to the process? There may be also documents > (e.g. funding applications or decisions) related to the process, but > since the actual entity we are interested in this case is the project > - not the documents related to the project (in most cases, they > contain confidential information anyway). > > - Another concern is related to the presentation and validation of > publication information. While Dspace-CRIS allows using > CRIS entities as authority (which is a great feature itself), the > default submission form provided in Dspace seems somewhat restricted. > For example, we would need > - Custom submission forms depending on the type of the publication > (e.g. journal articles, books, or conference papers need partially > different visible fields and validation rules for) > - Validation depending on values entered on multiple metadata fields. > For example - if the publication is marked as "international > collaborative publication" (a field required for national publication > information in Finland), the author affiliations should be checked > such that at least one author is from another, foreign organization. > - Presentation of the list/tree values based on custom queries during > data entry. For example, we would like to store all internal (=our > departments) and external (=funders, collaborators) organizations in > same, hierarchical structure, but depending on the context, only parts > or this list should be visible/searchable. > - A related concern with organizations involves presenting their time > span - over time, departments are splitted or merged and in genral, > have a start or end date. This should be reflected in validation as > well (e.g. compare the publication year to organization's lifespan) > Can (or should?) features like these be implemented on top of default > Dspace submission process, or would it make sense to define a new kind > for workflow functionality on top of Dspace-CRIS (perhaps related to > project workflow mentioned in above point) since JDynA framework seems > already support some of the required validation functionality? > > - The aspect of combining affiliation data to authors is still > somewhat unclear to me. At the HKU Scholars Hub, affiliation data > seems to be "wired" to author profiles (?), but we would need to > differentiate the affiliation information in each publication (most > importantly - has the author written a specific paper _as_ member of > our organization or as "outsider" (preferably with some affiliation as > well) - there are also cases with multiple affiliations (our > university + other) and this should be tracked as well). In addition, > the organizations used in affiliation data should be picked/matched > from a larger organization list or tree (=so you could search for a > given organization and get all persons, publications, grants and other > information related to that organizations). Can this be done with > Dspace-CRIS? From earlier conversations I noticed that the concept of > "nested objects" might help - is there any documentation or additional > data about the way they are defined/applied? > > - The feature list mentions that _second level_ cris entities can be > added using the web ui. How about the expected amount of work for > adding new first level entities (e.g. different kinds of > achievements)? Is this mostly on configuration (hibernate files, form > definitions?) issue or does this involve changes in the Dspace-CRIS > code itself? > > - Are there plans to release the code (or documentation/guidelines) > for "enhanced" submission process as described in OR2013 presentation > (Integrate external bibliographic services in DSpace submission > process)? The ability to import bibliographic metadata from external > services (and preferably merge the data from various sources) is one > of the central requirements for a new CRIS and the functionality > described in the presentation seems to fare (or even surpass) the > features offered by commercial competitors. > > best regards (and sorry for the lengthy post), > > -- > Miika Nurminen > University of Jyväskylä > > ------------------------------------------------------------------------------ > October Webinars: Code for Performance > Free Intel webinars can help you accelerate application performance. > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from > the latest Intel processors and coprocessors. See abstracts and register > > http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk > _______________________________________________ > DSpace-tech mailing list > DSpace-tech@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/dspace-tech > List Etiquette: > https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette -- Andrea Bollini Dipartimento Servizi e Soluzioni per l'Amministrazione Universitaria Divisione Ricerca Via dei Tizii, 6 00185 Roma, Italy tel. +39 06 44 486 087 - mob. +39 348 82 77 525 http://www.cineca.it ------------------------------------------------------------------------------ October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk _______________________________________________ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette
