Pauline sent a followup on this that hadn't made it to the list yet: 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. On Saturday, 18 February 2017 13:44:45 UTC+1, Bram Luyten wrote: > > 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 > > > [image: 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]> 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. >> >> >> ------------------------------ >> >> >> 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 >> >> [image: 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]. >> To post to this group, send email to >> [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]. >> To post to this group, send email to >> [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]. >> To post to this group, send email to >> [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.
