Thanks very much Bram. Those sound like functions that would be a great help to us. I have just been training two new colleagues to check and approve submissions, which has made me think a bit about some DSpace functionality and documentation.
I would also love to see these improvements re the file format registry: 1. The file format registry should be searchable; whereas currently the descriptive information and list of file format extensions is hidden, such that the user has to click on each format to see which file extensions it is linked to. We currently have 343 formats, with a further five or so we're preparing to add, so that is a lot of clicking around. 2. When viewing the list of bitstreams in a submitted item, the system should provide a link to (or a tool-tip containing) the file format name and description. For example we've recorded .mat as a file extension of a format we call "Matlab". But when my trainee colleague examines a submission containing .mat files, all DSpace shows him as format information is "Text" because that is the MIME type we have recorded for that file type. He found this confusing. And when we looked at the file format registry to get some more information on this mysterious .mat extension, of course a Ctrl-F to Find "mat" in the page which lists our 343 formats produced many spurious matches because it hit every occurrence of the word "information". Whereas a Ctrl-F to find ".mat" produced no hits because that did not match the *name* of the format, 'Matlab'. So the registry was effectively useless. If the registry was more easily searchable, it would be more worthwhile for us to use it to record information in it. 3. When viewing the list of bitstreams on the full item view of a deposit, a user should be provided with a link to (or a tool-tip containing) the file format name and description. If this were the case, we could record information in our file format registry that would help users to read and process data in formats unfamiliar to them. Whereas currently, we probably add that information to a deposit the first time we receive a submission of a particular format, because we noticed the "unknown" file format and so we investigated. Whereas the second submission we receive containing that format will be labelled 'Known' or 'Supported' and so we won't feel the need. But the end-users might want that information. 4. We should at least have the option to attach file format registry information to a bitstream retrospectively. It is very disheartening to receive a submission containing a previously-unseen file extension, put a lot of work into assessing and deciding how to categorise it (Known/Supported), record all that in the file format registry, and then see that the new categorisation cannot be applied to the very submission which prompted it. And that there's nothing we can do about it. 5. The registry could be used to provide feedback to a submitter during the submission process about their choice of file format. When they have uploaded some files and progress to the next page, DSpace could check the registry. And if their files are 'Unknown' it could say: "This filename has not been deposited previously. Please provide the following information: Which software was used to create the file? Is the file format a standard in your field? ". And if their files are 'Known' it could say: "This file extension is associated with a file format which is not considered a recommended file preservation standard. Please review our guidance on recommended file formats and if possible convert the file or add a version which is a standard preservation format." Do please let me know if there's something further I can do to perhaps move things forward. Best regards, :p Pauline Ward Research Data Service Assistant University of Edinburgh Argyle House, 3 Lady Lawson St, Edinburgh tel: 0131 651 5277 @PaulineData<https://twitter.com/paulinedata> The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. ________________________________ From: [email protected] <[email protected]> on behalf of Bram Luyten <[email protected]> Sent: 18 February 2017 12:44 To: [email protected] Cc: DSpace Community; DSpace Technical Support Subject: Topic for a future DCAT call: "Future of the fileformat registry" Hi Pauline, your suggestion merits its own thread. I definitely agree that the file format registry, and broader, the digital preservation capabilities of DSpace deserve more attention and improvement. The fact that we're currently only looking at file extension and that we haven't hooked in something like DROID or PRONOM for more solid file format identification is also a blind spot. Would be curious to see what your biggest issues and suggestions are for the file format registry. thanks, Bram [logo] Bram Luyten 250-B Suite 3A, Lucius Gordon Drive, West Henrietta, NY 14586 Esperantolaan 4, Heverlee 3001, Belgium atmire.com<http://atmire.com/website/?q=services&utm_source=emailfooter&utm_medium=email&utm_campaign=braml> On 18 February 2017 at 13:19, WARD Pauline <[email protected]<mailto:[email protected]>> wrote: It's not a pressing issue for us at Edinburgh. I think actually the File Format Registry could be made much more functional (compared to how it works in v5.2), much more useful both for curators, depositors and especially end-users. Of course, I'm running a research *data* repository, so new file formats generate a lot of work for us. There's been an acceleration of the appearance of new file formats I think, certainly in the deposits we're receiving. But maybe colleagues running publication repositories would be less interested in that...? Should I just maybe draft up some suggestions into use cases? Or, Bram, do you know, is the file format registry an area that has been improved in v6? Thanks very much. :p Pauline Ward Research Data Service Assistant University of Edinburgh Argyle House, 3 Lady Lawson St, Edinburgh tel: 0131 651 5277 @PaulineData<https://twitter.com/paulinedata> The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. ________________________________ From: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> on behalf of Bram Luyten <[email protected]<mailto:[email protected]>> Sent: 18 February 2017 10:46 To: [email protected]<mailto:[email protected]>; DSpace Community; DSpace Technical Support Subject: Topic for a future DCAT call: "The need for speed - let's talk DSpace performance" Hi, apologies for cross posting but though this would be of interest to the different lists. Because this could be a relatively technical topic, I wanted to see if there's an interest to dedicate one of the next DCAT calls to DSpace performance: - are your pages loading fast enough? - are you suffering from downtime and how are you dealing with this? - which performance related JIRA tickets are out there and should we raise attention to them? - Show & tell of approaches, for example, https://wiki.duraspace.org/display/~terrywbrady/Using+New+Relic+to+Monitor+XMLUI What do you think? Too technical? Relevant? Should we schedule it? cheers, Bram [logo] Bram Luyten 250-B Suite 3A, Lucius Gordon Drive, West Henrietta, NY 14586 Esperantolaan 4, Heverlee 3001, Belgium atmire.com<http://atmire.com/website/?q=services&utm_source=emailfooter&utm_medium=email&utm_campaign=braml> -- You received this message because you are subscribed to the Google Groups "DSpace Community Advisory Team" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]<mailto:[email protected]>. To post to this group, send email to [email protected]<mailto:[email protected]>. Visit this group at https://groups.google.com/group/DSpaceCommunityAdvisoryTeam. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "DSpace Community Advisory Team" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]<mailto:[email protected]>. To post to this group, send email to [email protected]<mailto:[email protected]>. Visit this group at https://groups.google.com/group/DSpaceCommunityAdvisoryTeam. For more options, visit https://groups.google.com/d/optout. The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. -- You received this message because you are subscribed to the Google Groups "DSpace Community Advisory Team" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]<mailto:dspacecommunityadvisoryteam%[email protected]>. To post to this group, send email to [email protected]<mailto:[email protected]>. Visit this group at https://groups.google.com/group/DSpaceCommunityAdvisoryTeam. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "DSpace Community Advisory Team" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]<mailto:[email protected]>. To post to this group, send email to [email protected]<mailto:[email protected]>. Visit this group at https://groups.google.com/group/DSpaceCommunityAdvisoryTeam. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "DSpace Community" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/dspace-community. For more options, visit https://groups.google.com/d/optout.
