We will use the international conference call dial-in. Please follow directions below.
Discussion topic: JIRA ticket review
Together we will discuss issues that developers have identified would benefit from DCAT input as well as any issues/tickets added to the meeting page to address.
Tickets to discuss: [In Progress]
(Also the more general discussion on: when a new feature/contribution relies on specific metadata fields, should it add extra fields, or to which extent should it build on the existing schema's)
Discussion topic: DCAT objectives and meeting topics for the first half of 2017
Together we will discuss the feedback from the call for 2017 topics and any comments added to the meeting page on what DCAT should be discussing in the next months.
Look through the JIRA tickets needing review for any that you would like to discuss (add tickets of interest to the comments).
Bring your questions/comments/topics/tickets/issues you would like to discuss to the call, or add them to the comments of this meeting page.
If you can join the call, or are willing to comment on the topics submitted via the meeting page, please add your name, institution, and repository URL to the Call Attendees section below.
During January's call the DCAT discussed two main topics. First we discussed some Jira tickets which may benefit from DSpace input. Secondly there was an open conversation on proposal topics for 2017's DCAT meetings.
The following tickets were covered.
The ScienceDirect integration with DSpace imports metadata from Elsevier's ScienceDirect service into DSpace. This feature (re-)opened the discussion on the creation of new metadata fields for new features. The main question is that, if a contribution requires specific metadata fields, should it be justified to create such new metadata fields, or should they work with existing metadata fields only.
From one point of view, using existing metadata fields seems beneficial, as it avoids redundant metadata fields and clutter. On the other hand, this also means those integrations become dependent on some of the standard metadata fields, which in some cases may cause issues. To illustrate this with an example: Considering a DSpace repository with a SWORD integration, and this integration is only allowed to use standard Dublin Core metadata fields. In case an institution would like to alter metadata fields, this would compromise the SWORD integration. In case there were specific metadata fields for SWORD added to the metadata schema, this change would not affect the integration. In general we could conclude the choice is between remaining a fairly small amount of metadata fields, or allowing for DSpace admins to more conveniently customize metadata fields.
In 2015, the Google Scholar team provided Georgetown University with some recommendations. These are general recommendations which could apply to all DSpace instances.
This ticket is marked as a fix for DSpace 7. However, considering the usefulness of this improvement, and the fact that DSpace 7 is only to be expected in 2018, DCAT decided this fix should already be included in a DSpace 6.x release. It is still to be considered whether this is really achievable. Subtasks 1 and 4 may be relatively little work, subtasks 2 and 3 are definitely not. These issues may be hard to tackle before the next release.
A coment was made specifically for point 2: For dissertations/theses, please change "citation_publisher" to "citation_dissertation_institution. It is unclear how to distinguish theses and dissertations from other DSpace content. We would probably need to use different metadata profiles depending on the content type.
At this moment, the file linked to in citation_pdf_url can be files other than text files, such as JPEG files. This is due to the way DSpace is deciding which bitstream to link to, as described in the ticket.
Google recommended to create a white-list of textual formats which are valid for citation_pdf_url. This should avoid files other than the actual text file to be added to citation_pdf_url.
As DCAT agreed with this approach, they made a comment on the jira ticket stating this would be indeed the right thing to do.
The only issue foreseen during the meeting was that for the specific case where you would have image files which include the text, this white-list would disable DSpace to link to their bitstreams in citation_pdf_url. For this reason it may be beneficial to use this white-list as the default filter, but allow DSpace administrators to disable the white-list in a configuration file.
DSpace 5 has an improved thumbnail generator, which creates more qualitative thumbnails. When upgrading to DSpace 5 it is often not possible to run this generator (filtermedia) without forcing it. Forcing ensures that all thumbnails are generated again, and avoids the skipping of pre-existing thumbnails. However, this disables filter media's resume functionality. This implies that when the filter media job crashes or stops, all of the newly created thumbnails will have to be generated once more.
It would be beneficial to have a thumbnail removal filter to be able to use filter media's resume option after upgrading to DSpace 5 or up. With a thumbnail removal filter it would be possible to delete all pre-existing thumbnails and generate new thumbnails without having to force filter media, and thus enabling the resume functionality.
This ticket states the need for a code review for some functionality developed by Atmire. It would be rather controversial however if someone from Atmire would perform this review. For that reason a reviewer from outside of Atmire is requested.
Up to now DSpace does not include full-text indexing functionality for .docx files. This would be very useful for DSpace. Hence a volunteer is needed to start making progress.
Although the RIOXX metadata profile was originally created to make a metadata scheme compliant with UK regulations, this schema has already proven its use for institutions outside of the uk. It may be worthwhile to consider including this metadata scheme in DSpace's default code base.
Following topics were proposed by DCAT members
The DSpace 7 UI outreach group is still open for people interested to join. This task-force will meet bi-weekly and wil reach out and deeply engage the DSpace community in aspects of DSpace 7 development. The first scheduled meeting will be held Januari 18th 2017.