Date & Time
- Main call Dec 09th 16:00 UTC/GMT - 11:00 ET
Satellite call Dec 10th 08:00 UTC/GMT - 03:00 ETCANCELLED
What is the difference between the "main call" and satellite call?
Dial-in
We will use the international conference call dial-in. Please follow directions below.
- U.S.A/Canada toll free: 866-740-1260, participant code: 2257295
- International toll free: http://www.readytalk.com/intl
- Use the above link and input 2257295 and the country you are calling from to get your country's toll-free dial in #
- Once on the call, enter participant code 2257295
DSpace project governance changes
2014 Meeting objectives
From August until December 2014, the monthly DCAT meetings are centered around defining, refining and prioritizing DSpace use cases.
These use cases are expected to have an important impact on the medium and long term roadmap of DSpace, starting with DSpace 6 in 2015.
December Meeting Agenda: Structure use cases
During the December meeting we will be discussing structure use cases. Structure use cases are all needs that relate to DSpace's currently hierarchical data model of Communities / Collections / Items / Bitstreams, with associated configuration, metadata and authorizations. Are there things that you or your faculty wishes to do with DSpace that's currently not possible due to the structure of the system? Let us know!
We rather want to cover more use cases than to stick to a limited number, allowing to dig deeper in detail. This is why we will be asking the participants in the call for their institutions or personal priority after devoting ~5 minutes to an explanation and discussion about the actual use case. This means we hope to cover at least 10 use cases during the call.
Structure use cases that were already identified and logged in the Use Case space:
The best way to participate and contribute
If you have some time to spare to prepare for this meeting, it would be great if you could briefly list the most important structure use cases for you or your institution, especially if they are currently unsupported by DSpace.
- Sign up for an account on this wiki and log in.
- Put your use cases in the comment section of this page.
- Join either the main call or satellite call and tell us about your use cases
Discussed use cases
- ...
Call Attendees (main+satellite)
- Bram Luyten (@mire) - @mire
Maureen Walsh - Ohio State University
- Ignace Deroost - @mire
Pauline Ward - University of Edinburgh
Kate Dohe - Georgetown University
- Felicity Dykas - University of Missouri
- Elin Stangeland - University of Oslo
- Terrence W Brady - Georgetown University
- Sarah Potvin - Texas A&M
- Valorie Hollister - Durapace
- Peter Dietz - Longsight
- Mark Diggory - @mire
- Aaron Collier - CSU
- Steven - University of Minnesota
6 Comments
Peter Dietz
Community, Collection, Container
What is the use of a Collection vs Community? Is this a real term that can distinguish people on your campus? Collection and Community in DSpace have many overlapping features, that I'm wondering about merging them into the same thing, and calling it container. Container is like Community, in that it can have sub-Containers, and Container would be like Collection, in that you can submit Items to it.
Reorganizing Hierarchy
I would also be interested in seeing "Drag and Drop" rearranging of Community/Collection/Container hierarchy. This is something that happens from time to time, and rather than having to have your technical administrator manually craft some SQL to accomplish this, to instead allow DSpace to have a proper method of accomplishing this.
Bitstream Relationships
I don't like the BUNDLE object, I'd rather that just be some sort of metadata about Bitstreams. I would like to see relationships between bitstreams though. And a clearer process to store a master version of an object (TIFF), and then have a route for DSpace to either generate derivatives/renditions on-the-fly, or a background process to create renditions. Then you could have policy rules / preset templates that say that for image-type master's you'll want XL png, L png, M png, S png, thumbnail png to be generated, which a UI can use depending on context. There could be similar presets for document type content, where some bitstream structure (plus other DSpace components) allows you to map between master and various derivatives (PDF, ODF, RDF, txt, png slides).
Dynamic Collections / Facet browsing
I like Terry's idea of "Dynamic Collections". We have a site that maps imported items into say 5+ owning collections at once (I've modified SAFBuilder and Longsight's ItemImport to handle this), when really I think some of this could be metadata that dynamic views (Discovery facets?) would be another way of accomplishing this. Instead of this Item has owning collections for example of: 1820's Photographs, East London, Photographs of People, James Family, Black and White Photographs, to instead just have a way to use that as metadata, and browse results for groups of facets.
Pauline Ward
I think some of our users would at some stage like to be able to create Collections within Collections, e.g. as a large number of datasets get added to a Collection over time, it would be nice to be able to add a little more organisation, so that the browsing user can easily click on a subset which the submitter has chosen to group according to topic or year or some other criterion. If containers would allow this to be made easier, that'd be a good thing. However, I am slightly worried by the name 'Container', I'm not sure that is very user-friendly. Couldn't we just move to having only Collections?
I also agree about making it easier to reorganise the hierarchy.
Bram Luyten (Atmire)
I'm interested in discussing the use case that was already added by Mark Diggory:
Structure - Describe Individual Bitstream within an Item
Pauline Ward
I must say as a fairly new user of DSpace, that I've found it takes a long time to get to grips with the structure, and I find myself repeatedly having to explain it very carefully to submitters. It's good to have flexibility in the structure. I wish there was a bit more transparency in the structure i.e. for it to be much clearer to the administrator or the submitter (and also to the casual browsing user) what the structure is. For example - in our database we usually set permissions on a Collection such that the initial depositor will be the only user with permission to submit further datasets to the Collection. This is rather counterintuitive though, because the Collection sits within a Community. There may or may not be other researchers who are admins of the Community, but they would usually not have any permissions to edit datasets sitting in the Collections belonging to that Community. So I think it would be helpful if that was more obvious e.g. at the stage of creating the Collection, and at the stage of submitting an Item.
Pauline Ward
Not sure where is the best place to post / send this, sorry, but I would like to suggest for the 2015 programme that coping with very large files should be a focus. In particular, how to protect the database from risk of overload due to multiple users downloading very large files. Based on our experience here at Edinburgh I'm talking about deposits containing files ranging in size from 3Gb to 300Gb (because we can handle files of 2Gb or smaller easily, and because we've not yet had any depositor ask to deposit anything larger than 300Gb). Please let me know if I should re-post/send this in a different place, thanks v much.
Peter Dietz
Hi Pauline,
This would make for a good question to the dspace-tech mailing list. You could what's the largest content that people store/serve from their repository. There could be a review of the file serving lifecycle, to ensure that resources aren't being hold on to for too long. For a 1MB file, it doesn't matter if the resources are closed at the end, since that is a tiny resource, and will be complete quickly. But, for something that will involve a lot of IO, and take a long time, it would be best if its just a matter of sending IO through tomcat/webserver, and not DSpace holding on to DB connections / statistics events for this whole time.