Dear German, Thanks for your support. I understand this can be difficult to implement or that needs time to develop. No problem for applying the proposals later or not applying at all.
Best regards, Germán Biozzoli <germanbiozz...@gmail.com> escribió: > I think that > > ------------ >> * 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 > > --------------- > has no posible conceptual discussion: > > http://www.w3.org/2013/dwbp/wiki/URI_Design_and_Management_for_Persistence > > And of course, correct URIs have effects over SEO, that is an inherent > responsability to IRs platforms. As a DSpace implementor I understand that > it could have no inmediate solution, but to me it's undoubted the correct > requirement for future DSpace versions. > > Regards > German > > > > 2014-09-03 19:53 GMT-03:00 Isidro F. Aguillo <isidro.agui...@cchs.csic.es>: > >> Dear Tim, >> >> Tim Donohue <tdono...@duraspace.org> 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 >> > dspace-gene...@lists.sourceforge.net >> > 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 >> DSpace-tech@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/dspace-tech >> List Etiquette: >> https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette >> -- 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 DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette
