Email Gateway (Aug 22 2022 at 09:58): Email Gateway (Aug 22 2022 at 09:58):From: Lars Hupel <hupel@in.tum.de>
Dear list,
I think we should seriously consider moving the AFP away from
SourceForge. The final nail in the coffin is that the company behind
SF.net started replacing genuine downloads with their own versions with
added adware. The latest evidence is from the GIMP project:
<https://mail.gnome.org/archives/gimp-developer-list/2015-May/msg00097.html>
In that particular case, it affected an inactive project. The AFP is
very much not inactive, but nonetheless, nobody guarantees that SF.net
won't further extend this practice. They will probably not touch the
Mercurial source repositories, but the official AFP download uses
SF.net's download facility:
<http://sourceforge.net/projects/afp/files/latest/download>
Better alternatives exist, for example Bitbucket. They also offer
repository hosting, web hosting, and file download.
Cheers
Lars
Email Gateway (Aug 22 2022 at 09:58):From: Gerwin Klein <Gerwin.Klein@nicta.com.au>
We’ve already thought about that, it’s not the first malware incident at SF.
So far, I’m monitoring the situation for the AFP - content-wise we’re not dependent on anything SF is doing and could move any time.
The problem is URL stability: lots of papers have citations pointing to afp.sf.net, which would then all be dead or worse, point to uncontrolled content.
Cheers,
Gerwin
The information in this e-mail may be confidential and subject to legal professional privilege and/or copyright. National ICT Australia Limited accepts no liability for any damage caused by this email or its attachments.
Email Gateway (Aug 22 2022 at 09:59):From: David Cock <david.cock@inf.ethz.ch>
Could we get a stable domain now, and point it at afp.sf.net, so that
people can start citing that instead, and if/when a move is necessary,
no new dangling citations are created?
Dave
Email Gateway (Aug 22 2022 at 09:59):From: Manuel Eberl <eberlm@in.tum.de>
Could we not maintain a skeleton web site at afp.sf.net that simply
forwards the afp.sf.net URLs to the new location?
I also think that it would be prudent to move away from hosting any
actual content on Sourceforge as soon as possible.
Manuel
Email Gateway (Aug 22 2022 at 09:59):From: Lars Hupel <hupel@in.tum.de>
Better alternatives exist, for example Bitbucket. They also offer
repository hosting, web hosting, and file download.
I need to adjust this claim. The web hosting support neither offers SSI
(which, if I remember correctly, is used by the AFP), nor custom
domains. But that could be done by pushing the generated web pages to
some server at, say, TUM.
Email Gateway (Aug 22 2022 at 09:59):From: Lars Hupel <hupel@in.tum.de>
That is completely true. I don't think that's an argument in favour of
SF.net though ("sunk cost"), rather an argument for moving away (or at
least install a custom domain) as soon as possible. As David pointed
out, that could be done right now.
Email Gateway (Aug 22 2022 at 09:59):From: Gerwin Klein <Gerwin.Klein@nicta.com.au>
That would indeed be a possibility if we accept that SF will most likely become untenable in the future.
Let me start looking into the details of that.
Cheers,
Gerwin
Email Gateway (Aug 22 2022 at 09:59):From: Gerwin Klein <Gerwin.Klein@nicta.com.au>
Hosting is not the problem, there are plenty of options that we can figure out.
Cheers,
Gerwin
The information in this e-mail may be confidential and subject to legal professional privilege and/or copyright. National ICT Australia Limited accepts no liability for any damage caused by this email or its attachments.
Email Gateway (Aug 22 2022 at 10:00):From: Manuel Eberl <eberlm@in.tum.de>
The obvious solution that comes to my mind for the URL persistence
problem is to obtain a DOI for every AFP entry. As far as I know,
solving this kind of problem is precisely their purpose.
Manuel
Email Gateway (Aug 22 2022 at 10:00):From: Manuel Eberl <eberlm@in.tum.de>
Lars Hupel just informed me that DOIs cost a significant amount of
money, apparently. (several hundred USD per year)
Another solution would be NBN-Resolving, which is affiliated with the
German National Library: https://nbn-resolving.org
The TUM library is a partner institution of them, they use it e.g. for
PhD theses, so they seem to have some access to NBN-Resolving. I wonder
if we could use that as well, by going through the TUM library?
Manuel
Email Gateway (Aug 22 2022 at 10:00):From: Dmitriy Traytel <traytel@in.tum.de>
What about arxiv.org? This should give free and persistent addresses.
(We could submit the generated documents there.)
Dmitriy
Email Gateway (Aug 22 2022 at 10:00):From: Manuel Eberl <eberlm@in.tum.de>
I just noticed that, apparently, this nbn-resolving service is free.
We could register ourselves as a partner institution with the German
National Library.
http://www.dnb.de/urnservice (German)
http://d-nb.info/1029114455/34 (German)
The only restrictions are that we have someone who responds to inquiries
via email and register at least one URN a year.
One potential problem is that it appears from the PDF that the
referenced works (i.e. AFP entries) must be submitted to the German
National Library. I am not sure what that means in practice for
something like AFP entries. They do state explicitly that using the URN
service is possible even for publications that the German National
Library does not ordinarily collect.
Manuel
Email Gateway (Aug 22 2022 at 10:00):From: bnord <bnord01@gmail.com>
That actually depends solely on the registration agency. TIB [1] (and
other members of DataCite [2]) for instance offers "DOI registration
free of costs for all academic institutions based in the Federal
Republic in Germany."
[1] http://www.tib-hannover.de/en/dienstleistungen/doi-service/
[2] https://www.datacite.org
Email Gateway (Aug 22 2022 at 10:00):From: Gerwin Klein <Gerwin.Klein@nicta.com.au>
DOI and NBN are not straightforward for the AFP.
We have looked into these before, but it’s unclear what a DOI should point to for instance. They are designed to point at precisely one static digital artefact. Entries in the AFP have a unique submission point, but then evolve over time.
The current citation URL scheme does this nicely: the year tells you which release, and the URL shows you all of them. (The disadvantage of the URL scheme can be seen now).
There are other issues as well: it doesn’t only need to be affordable over long stretches of time, it also needs to be automatable, at least mostly.
Maybe time to revisit that discussion. Possible that these issues can be solved.
Cheers,
Gerwin
Email Gateway (Aug 22 2022 at 10:01):From: Till Mossakowski <till@iws.cs.uni-magdeburg.de>
It is also possible to use PURLs, see
https://en.wikipedia.org/wiki/Persistent_uniform_resource_locator
http://purl.org
Till
Last updated: Apr 26 2024 at 04:17 UTC