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 <[email protected]>:
> 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
>
------------------------------------------------------------------------------
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
