Dear Tim, Tim Donohue <[email protected]> escribió:
> Hello Isidro, > > DuraSpace (the stewarding organization behind DSpace and Fedora > repository software) was planning to send you a compiled list of the > concerns with your proposal. As you can tell from the previous email > thread, many of the users of DSpace have similar concerns. Rather than > bombard you with all of them individually (which you could see from > browsing the thread), we hoped to draft up a response summarizing the > concerns of the DSpace community. Thanks a lot. That is far beyond my better expectations. > Below you'll find an initial draft of the summarized concerns. The rule > numbering below is based on the numbering at: > http://repositories.webometrics.info/en/node/26 > > --- Concerns with the Proposal from Ranking Web of Repositories > > * Rule #2 (IRs that don't use the institutional domain will be excluded) > would cause the exclusion of some IRs which are hosted by DSpace service > providers. As an example, some DSpaceDirect.org users have URLs > https://[something].dspacedirect.org which would cause their exclusion > as it is a non-institutional domain. Many other DSpace hosting providers > have similar non-institutional domain URLs by default. Major issue. Repository is not another bibliographic database, it is the archive of the academic output of the institution. And as such it should be iron brand. If .. the institution is very small or in a country with limited resources the hosting option is perfectly valid and we will do an exception. But in these cases, Is not a redirection possible? If .. the problem is related to governance we should not reward the institution bad practice. > * Rule #4 (Repositories using ports other than 80 or 8080) would wrongly > exclude all DSpace sites which use HTTPS (port 443). Many institutions > choose to run DSpace via HTTPS instead of HTTP. No problem adding a few more ports to the short list > * Rule #5 (IRs that use the name of the software in the hostname would > be excluded) may also affect IRs which are hosted by service providers > (like DSpaceDirect). Again, some DSpaceDirect customers have URLs which > use *.dspacedirect.org (includes "dspace"). This rule would also exclude > MIT's IR which is the original "DSpace" (and has used the same URL for > the last 10+ years): http://dspace.mit.edu/ This is easy. Imagine that the people at MIT decide next week they prefer eprints or other new software. A repository is a repository, why not a final one like?: repository.mit.edu On the other side, I wrote all my papers using MS Word and never cited that fact in any of them, less of all in the authorship > * Rule #6 (IRs that use more than 4 directory levels for the URL address > of the full texts will be excluded.) may accidentally exclude a large > number of DSpace sites. The common download URLs for full text in DSpace > are both are at least 4 directory levels deep: > > - XMLUI: [dspace-url]/bitstream/handle/[prefix]/[id]/[filename] > - JSPUI: [dspace-url]/bitstream/[prefix]/[id]/[sequence]/[filename] > > NOTE: "prefix" and "id" are parts of an Item's Handle > (http://hdl.handle.net/), which is the persistent identifier assigned to > the item via the Handle System. So, this is how a persistent URL like > http://hdl.handle.net/1721.1/26706 redirects to an Item in MIT's DSpace. I understand the technical part, but this for the needs of the sysadmin of the system (=NE person). Now, please take into account the needs of 10,000 internal end-users authors. Why not redirect (aliasing?)? > * Rule #7 (IRs that use more than 3 different numeric (or useless) codes > in their URLs will be excluded.). It is unclear how they would determine > this, and what the effect may be on DSpace sites worldwide. Again, > looking at the common DSpace URL paths above, if a file had a "numeric" > name, it may be excluded as DSpace URLs already include 2-3 numeric > codes by default ([prefix],[id], and [sequence] are all numeric). I have a personal example. 20 years ago my email admin decided my email account should be 'dctfa11', abusing from your notation ([prefix],[id], and [sequence]). After several years it was possible to change to 'isidro.aguillo'. I going to use the URL of my papers to cite them, to marketing them, to copy in my CV, ..... Please, help me translating /56/89/567894 into aguillo2014b > * Rule #8 (IRs with more than 50% of the records not linking to OA full > text versions..). Again, unclear how they would determine this, and > whether the way they are doing so would accidentally exclude some major > DSpace sites. For example, there are major DSpace sites which include a > larger number of Theses/Dissertations. These Theses/Dissertations may > not be 100% Open Access to the world, but may be fully accessible > everyone "on campus". 50%!!! A 'place' with less than 50% of the full texts unavailable is NOT an Open Access Repository. > Another, perhaps more serious concern, is on the timeline you propose. > You suggest a timeline of January 2015 when these newly proposed rules > would be in place. Yet, if these rules were to go in place, some rules > may require changes to the DSpace software itself (as I laid out above, > some rules may not mesh well with DSpace software as it is, unless I'm > misunderstanding the rule itself). Do not worry about that, the objective is to promote better practices, the timing can be flexible > Unfortunately, based on our DSpace open source release timelines, we > have ONE new release (DSpace 5.0) planned between now and January 2015. > Even if we were able to implement some of these recommended changes at a > software level, the vast majority (likely >80-90%) of DSpace instances > would likely NOT be able to upgrade to the latest DSpace version before > your January deadline (as the 5.0 release is scheduled for Nov/Dec). > Therefore, as is, your January 2015 ranking may accidentally exclude a > large number of DSpace sites from your rankings, and DSpace is still the > most widely used Institutional Repository software in the world. i am not your enemy, my aim is to help as much as possible in the success of Open Access initiatives. For now I would like you understand there are other stakeholders involved with needs probably not well explained. > So, in general, I think our response is that these proposed > rules/guidelines are a bit concerning to many users of DSpace (as you > can see from this long thread of concerns from various people and > institutions). We worry that a larger number of DSpace instances would > be accidentally excluded from the rankings, which makes the final > ranking less useful to users of DSpace overall. > > I know DuraSpace would be open to discussing this with you and your > colleagues. Perhaps there's a middle ground here, or a way to slowly > "roll out" some of your recommended changes. This could allow DSpace > developers more time to enhance DSpace software itself, and allow users > of DSpace more time to upgrade to ensure they are included in the > Rankings. (Note: we've similarly had discussions with the Google Scholar > team to help gradually add improvements to DSpace to better meet their > indexing needs...so it seems like the same could occur with the > Webometrics team.) > > I've copied our DuraSpace Chief Strategy Officer, Jonathan Markow, on > this message as well. > > Tim Donohue > Technical Lead for DSpace & DSpaceDirect > DuraSpace.org | DSpace.org | DSpaceDirect.org > > ------------------------------------------------------------------------------ > Slashdot TV. > Video for Nerds. Stuff that matters. > http://tv.slashdot.org/ > _______________________________________________ > Dspace-general mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/dspace-general Thanks again, -- Isidro F. Aguillo, HonPhD Cybermetrics Lab (3C1). CCHS - CSIC Albasanz, 26-28. 28037 Madrid. Spain isidro.aguillo @ cchs.csic.es www. webometrics.info ------------------------------------------------------------------------------ Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ _______________________________________________ DSpace-tech mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dspace-tech List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette
