Page tree
Skip to end of metadata
Go to start of metadata

Date & Time

  • Main call Dec 09th 16:00 UTC/GMT - 11:00 ET 
  • Satellite call Dec 10th 08:00 UTC/GMT - 03:00 ET CANCELLED

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

In conjunction with the new DuraSpace membership program there is a new governance model for the project providing a larger role for the community.
Currently assembling the DSpace Leadership Group: includes representative from member institutions who have contributed >$10K to the project as well as elected representatives from those who've contributed at either the $5K or $2.5K level.
The Leadership Group will work with the DSpace Steering Group (which is more of the management group for the project) and has a role in approving the annual DSpace budget (how to spend membership $s), the project roadmap as well as helping to establish the community direction.
Leadership Group members will be formally announced in January.
For more information on DSpace governance visit http://www.dspace.org/governanc

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:

TitleCreatorModified
Admin UI - Simplify Collection Creation Based on TemplateMonika MevenkampJun 22, 2015
Structure - Check Bitstream names against allowed file name patternMonika MevenkampJun 12, 2015
Structure - Format checking of data entry in input formsMonika MevenkampJun 12, 2015
End User - Image file display (pan, zoom, size options)Maureen WalshMay 12, 2015
Structure - Generated provenance for all added bitstreamsMaureen WalshMay 11, 2015
Structure - Apply licenses to bitstreamsMaureen WalshMay 11, 2015
Structure - Generate technical metadata per bitstreamMaureen WalshMay 11, 2015
Structure - Simple AssetStore for Human TraversalTim DonohueApr 28, 2015
Structure - purpose of bundle layerIgnace DeroostApr 09, 2015
Structure - Create the ability to place "dynamic collections" (pre-faceted view of a collection) within the community hierarchy.Terry BradyApr 06, 2015
Structure - Drag and drop opportunities for changing collections structureIgnace DeroostDec 10, 2014
Structure - Manual Creation of "New Editions" of an ItemMark DiggoryApr 28, 2014
Structure - Automated Retention of All changes to ItemsMark DiggoryApr 28, 2014
Structure - Create / manage files and metadata (as an Item)Mark DiggoryApr 26, 2014
Structure - Relationships between objectsMark DiggoryApr 26, 2014
Structure - Support for hierarchical metadata formats (e.g. METS / MODS)Mark DiggoryApr 26, 2014
Structure - Community and Collection hierarchy (or generic containers)Mark DiggoryApr 26, 2014
Structure - Metadata for all levels of object hierarchyMark DiggoryApr 26, 2014
Structure - Manage Lists, Controlled Vocabularies and Authority ControlMark DiggoryApr 26, 2014
Structure - Describe Individual Bitstream within an ItemMark DiggoryApr 26, 2014
Structure - Associate Separate Properties with Each DSpace CommunityMark DiggoryApr 26, 2014
Structure - Support for derivative objectsMark DiggoryApr 26, 2014
Structure - Management of Deposits / SubmissionsMark DiggoryApr 26, 2014
Structure - Automated Update of Existing ItemsMark DiggoryApr 26, 2014
Structure - Manual Edit of Existing ItemsMark DiggoryApr 26, 2014
Structure - Automated Deposit of New ItemsMark DiggoryApr 26, 2014
Structure - Manual Submission of New ItemsMark DiggoryApr 26, 2014

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.

  1. Sign up for an account on this wiki and log in.
  2. Put your use cases in the comment section of this page. 
  3. Join either the main call or satellite call and tell us about your use cases 

Discussed use cases

  • ...

 

Call Attendees (main+satellite)

  • No labels

6 Comments

  1. 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.

     

     

    1. 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.

  2. I'm interested in discussing the use case that was already added by Mark Diggory:

     Structure - Describe Individual Bitstream within an Item

    • richer metadata on the bitstream level, for example:
      • preservation metadata
      • version descriptor (preprint, postprint, ...) in the case of a typic academic IR.

     

  3. 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. 

  4. 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.

    1. 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.