Forgive me if this has already been mentioned:

The Google Terms of Service contain the text

"Users residing in countries on the United States Office of Foreign Assets Control sanction list, including Cuba, Iran, Libya, North Korea, Sudan and Syria, may not post or access Content available through the Google Code website."

Residents of which, if any, of these countries are ineligible to be TDWG members?

--Bob

On Wed, Aug 26, 2009 at 1:31 PM, Roderic Pager.page@bio.gla.ac.uk wrote:

I suspect that what's executing isn't needed (from memory the web site was somewhat over designed).

SourceForge drives me nuts, Google Code is much simpler (and there are some neat features such as web hooks, wikis for entering documentation, etc.).

I vote we move it to a site that actually works, and is easy to use (i.e., not SourceForge).

Regards

Rod

On 26 Aug 2009, at 18:06, Dave Vieglais wrote:

...

Looks like the site lsids.sourceforge.net is trying to execute something. If that's the case, then I don't believe moving to google code is going to help as I'm pretty sure they don't provide a hosting service (that will run CGIs for example).

The first thing that really needs to be done is one of the project developers/admins should log in to the project through the source forge shell service and take a look at how the web site is setup. Then figure out if the site can be modified to continue working under sourceforge or if an alternative hosting service needs to be found.

Admins of the source forge project are listed right on the source forge project page ( http://sourceforge.net/projects/lsids/develop ):

• bhszekel-oss       • kevin_richards       • scachett       • timrobertson100

To log in using a shell account:

https://sourceforge.net/apps/trac/sourceforge/wiki/Shell%20service

Then, when someone figures out the problem and solution, document it someplace and put it under source control.

Hope this is of some help.

Dave V.

On Aug 26, 2009, at 11:27 AM, Aaron Steele wrote:

...

I haven't heard an update on this, although I do think that Google Code is the right tool for the job here.

On Wed, Aug 26, 2009 at 7:05 AM, Roderic Pager.page@bio.gla.ac.uk wrote:

...

Did anybody make a decision about moving to Google Code? How about we do this ASAP as the fact we can't keep http://lsids.sourceforge.net running is making us look more than a little foolish.

I'd be happy to move stuff across so long as however is an admin on the SourceForge account is on the ball and approves using the same name...

Regards

Rod

On 16 Aug 2009, at 00:16, Aaron Steele wrote:

...

...

Are there any non-US countries that offer services like Google and Sourceforge but don't distinguish based on the host address? Users in these countries can easily get around these restrictions anyway using Tor for instance, but that isn't the point.

I have no knowledge of viable non-US project hosting services. _______________________________________________ tdwg-tag mailing list tdwg-tag@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tag

---

Roderic Page Professor of Taxonomy DEEB, FBLS Graham Kerr Building University of Glasgow Glasgow G12 8QQ, UK

Email: r.page@bio.gla.ac.uk Tel: +44 141 330 4778 Fax: +44 141 330 2792 AIM: rodpage1962@aim.com Facebook: http://www.facebook.com/profile.php?id=1112517192 Twitter: http://twitter.com/rdmpage Blog: http://iphylo.blogspot.com Home page: http://taxonomy.zoology.gla.ac.uk/rod/rod.html

--

Sent from Berkeley, CA, United States _______________________________________________ tdwg-tag mailing list tdwg-tag@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tag

---

Roderic Page Professor of Taxonomy DEEB, FBLS Graham Kerr Building University of Glasgow Glasgow G12 8QQ, UK

Email: r.page@bio.gla.ac.uk Tel: +44 141 330 4778 Fax: +44 141 330 2792 AIM: rodpage1962@aim.com Facebook: http://www.facebook.com/profile.php?id=1112517192 Twitter: http://twitter.com/rdmpage Blog: http://iphylo.blogspot.com Home page: http://taxonomy.zoology.gla.ac.uk/rod/rod.html

---

tdwg-tag mailing list tdwg-tag@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tag

-----Original Message----- From: tdwg-tag-bounces@lists.tdwg.org [mailto:tdwg-tag- bounces@lists.tdwg.org] On Behalf Of Dave Vieglais Sent: Wednesday, August 26, 2009 10:58 AM To: Bob Morris Cc: tdwg-tag@lists.tdwg.org Subject: Re: [tdwg-tag] LSID Sourceforge URL & LSID Best Practices

See also:

https://sourceforge.net/apps/trac/sitelegal/wiki/Terms%20of %20Use#a4.NOUNLAWFULORPROHIBITEDUSE

Right, so given that SourceForge is also based in the US, they are also obliged to impose the same restrictions. The restricted access issue doesn't distinguish SourceForge and GoogleCode.

We need to hear from the admins of the SourceForge site. It could be that when it was established, the thought was that LSID would be broader than the biodiversity community. I don't know what the status of LSID in other communities is, but I have a feeling we may be on our own now. Therefore, the rationale for NOT running the primary resolver at GBIF may have faded. Tim? Donald? Kevin?

-Stan

My comments about SourceForge are based on my experience using it as a developer 3-4 years ago (the SSH setup was horrific, it might be better now) and as a user (the site is big, slow, and ugly).

Re terms of service, I think this is simply an excuse for not doing anything. I suspect that the citizens of Cuba, Iran, Libya, North Korea, Sudan and Syria have more pressing things to worry about that whether they can access the LSID site (which at present, nobody can).

Regards

Rod

On 26 Aug 2009, at 19:26, Hilmar Lapp wrote:

On Aug 26, 2009, at 1:46 PM, Bob Morris wrote:

...

Residents of which, if any, of these countries are ineligible to be TDWG members?

Just a question: in which country is TDWG incorporated? I hope not in the US?

Because otherwise there is in fact court precedent that they are ineligible (though it has remained a sticky issue and a lawyer would need to scrutinize it if you really want to know).

-hilmar

=========================================================== : Hilmar Lapp -:- Durham, NC -:- hlapp at duke dot edu : ===========================================================

--------------------------------------------------------- Roderic Page Professor of Taxonomy DEEB, FBLS Graham Kerr Building University of Glasgow Glasgow G12 8QQ, UK

Email: r.page@bio.gla.ac.uk Tel: +44 141 330 4778 Fax: +44 141 330 2792 AIM: rodpage1962@aim.com Facebook: http://www.facebook.com/profile.php?id=1112517192 Twitter: http://twitter.com/rdmpage Blog: http://iphylo.blogspot.com Home page: http://taxonomy.zoology.gla.ac.uk/rod/rod.html

On Aug 26, 2009, at 4:07 PM, Blum, Stan wrote:

TDWG is incorporated in the US, but that doesn't mean it can't be incorporated elsewhere, too.

Is this being pursued? You might be interested in this (from 2007, so you may have come across it long ago):

http://web.isna.ir/ISNA/NewsView.aspx?ID=News-898597&Lang=E

-hilmar

lol... following that absolutely appalling pun, herewith my resignation from all matters tdwg, lsid, google, sourceforge, informatics, internet and biodiversity in general.

jim

On Thu, Aug 27, 2009 at 8:26 AM, greg whitbreadghw@anbg.gov.au wrote:

Donat, for example, will be caught between Iraq and a hard place.

OK, the message I'm getting is that:

1. It's perfectly acceptable for the public face of a major biodiversity informatics project to be broken in a way that makes us look amateurish.

2. TDWG must guarantee universal analysis at all times (even thought China may, on a whim, ban access to any site it choses).

3. That TDWG is already using Google Code for Darwin Core (http://code.google.com/p/darwincore/ ) is, of course, irrelevant to this discussion, as is the fact that Google Code seems fine for GBIF (http://code.google.com/p/gbif-ecat/ ) and EOL (http://code.google.com/p/eol-website/ ) projects.

4. Nobody thought these issues were important when the original project was set up on SourceForge (http://en.wikipedia.org/wiki/SourceForge ).

5. That Greg Whitbread's puns are appalling.

I'm clearly too worked up about this, but all I'm looking for is a simple fix to a simple problem. Instead, we're off on some tangent about incorporation, instead of actually dealing with the issue at hand. Perhaps I shouldn't get too bothered, and take this discussion as tacit agreement that LSIDs are doomed anyway.

Regards

Rod

--------------------------------------------------------- Roderic Page Professor of Taxonomy DEEB, FBLS Graham Kerr Building University of Glasgow Glasgow G12 8QQ, UK

Email: r.page@bio.gla.ac.uk Tel: +44 141 330 4778 Fax: +44 141 330 2792 AIM: rodpage1962@aim.com Facebook: http://www.facebook.com/profile.php?id=1112517192 Twitter: http://twitter.com/rdmpage Blog: http://iphylo.blogspot.com Home page: http://taxonomy.zoology.gla.ac.uk/rod/rod.html

Rod's somewhat hyperbolic interpretation of this thread notwithstanding, I think it's fair to say that everybody cares. But everybody is also hugely over-committed and under-funded.

Biodiversity Informatics is now in its adolescence. Growing pains (and tantrums) are to be expected. In an ideal world, all endeavors (including human maturation) would bypass the teenage years. Speaking as the parent of a teenager, I can sympathize with the frustrations and the temptation to throw in the towel. But I maintain confidence (both as a parent, and as a pseudo-practitioner of Biodiversity Informatics stuff) that this development phase will eventually pass; and things will be better on the other side.

So...back to my original questions:

1) Should the orange LSID icon (i.e., http://zoobank.org/images/lsidlogo.jpg) be displayed next to LSIDs on HTML pages (as per recommendation #33 on p. 23 of the LSID draft Applicability Statement, http://www.tdwg.org/fileadmin/subgroups/guid/LSID_Applicability_Statement_dr aft.pdf)?

2) If so, what should it link to (if anything)? The aforementioned Applicability Statement says, "An icon linking to an explanation of the LSID should be present...", and the suggested text is “This is a Life Sciences Identifier (LSID), a permanent, globally unique identifier for this data item. Use this LSID whenever you need to refer to this data item.” On the ZooBank site, I use this text for the mouse-over on the icon, but I wanted the icon itself to link to something more substantative, so I linked to http://lsids.sourceforge.net/

3) Given that http://lsids.sourceforge.net/ leads me to an "embarassing" terminus, should I:

a) simply change the link to http://sourceforge.net/projects/lsid/ ?

b) remove the link entirely?

c) wait until this thread reaches an eventual conclusion, and shift to a google code (or whatever) link?

I'm thinking that in the short-term (i.e., tomorrow), I'll go with option "a". In the middle term (i.e., if/when it's clear that sourceforge will not be the permanent home) I'll go with option "b". In the long term, I'll go with whatever emerges out of option "c".

Thanks for any feedback...

Aloha, Rich

-----Original Message----- From: tdwg-tag-bounces@lists.tdwg.org [mailto:tdwg-tag-bounces@lists.tdwg.org] On Behalf Of Tony.Rees@csiro.au Sent: Wednesday, August 26, 2009 8:56 PM To: r.page@bio.gla.ac.uk; tdwg-tag@lists.tdwg.org Subject: Re: [tdwg-tag] LSID Sourceforge URL & LSID Best Practices

Rod page wrote:

<snip> 1. It's perfectly acceptable for the public face of a major biodiversity informatics project to be broken in a way that makes us look amateurish. </snip>

At the e-Biosphere open discussion session, I reported an interesting and unfortunately not totally uncommon experience with major biodiversity informatics sens. lat, that several were either broken (e.g. OBIS searches for common taxa) or returned incomplete, or over-complete (correct + incorrect) data, and nobody seemed to care at this point. I guess it's just not mission-critical enough for anyone who does care??

Regards - Tony

Tony Rees Manager, Divisional Data Centre, CSIRO Marine and Atmospheric Research, GPO Box 1538, Hobart, Tasmania 7001, Australia Ph: 0362 325318 (Int: +61 362 325318) Fax: 0362 325000 (Int: +61 362 325000) e-mail: Tony.Rees@csiro.au Manager, OBIS Australia regional node, http://www.obis.org.au/ Biodiversity informatics research activities: http://www.cmar.csiro.au/datacentre/biodiversity.htm Personal info:

http://www.fishbase.org/collaborators/collaboratorsummary.cfm?%3E id=1566

-----Original Message----- From: tdwg-tag-bounces@lists.tdwg.org [mailto:tdwg-tag-bounces@lists.tdwg.org] On Behalf Of Roderic Page Sent: Thursday, 27 August 2009 4:51 PM To: Technical Architecture Groupmailing list Subject: Re: [tdwg-tag] LSID Sourceforge URL & LSID Best Practices

OK, the message I'm getting is that:

1. It's perfectly acceptable for the public face of a major

biodiversity informatics project to be broken in a way that makes us look amateurish.

2. TDWG must guarantee universal analysis at all times (even

thought China may, on a whim, ban access to any site it choses).

3. That TDWG is already using Google Code for Darwin Core

(http://code.google.com/p/darwincore/ ) is, of course, irrelevant to this discussion, as is the fact that Google Code seems fine for GBIF (http://code.google.com/p/gbif-ecat/ ) and EOL (http://code.google.com/p/eol-website/ ) projects.

4. Nobody thought these issues were important when the original

project was set up on SourceForge (http://en.wikipedia.org/wiki/SourceForge ).

5. That Greg Whitbread's puns are appalling.

I'm clearly too worked up about this, but all I'm looking for is a simple fix to a simple problem. Instead, we're off on some tangent about incorporation, instead of actually dealing with the issue at hand. Perhaps I shouldn't get too bothered, and take this discussion as tacit agreement that LSIDs are doomed anyway.

Regards

Rod

---

Roderic Page Professor of Taxonomy DEEB, FBLS Graham Kerr Building University of Glasgow Glasgow G12 8QQ, UK

Email: r.page@bio.gla.ac.uk Tel: +44 141 330 4778 Fax: +44 141 330 2792 AIM: rodpage1962@aim.com Facebook: http://www.facebook.com/profile.php?id=1112517192 Twitter: http://twitter.com/rdmpage Blog: http://iphylo.blogspot.com Home page: http://taxonomy.zoology.gla.ac.uk/rod/rod.html

---

tdwg-tag mailing list tdwg-tag@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tag _______________________________________________ tdwg-tag mailing list tdwg-tag@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tag

Not all Aussies...

- Tony

-----Original Message----- From: tdwg-tag-bounces@lists.tdwg.org [mailto:tdwg-tag-bounces@lists.tdwg.org] On Behalf Of Richard Pyle Sent: Thursday, 27 August 2009 5:47 PM To: tdwg-tag@lists.tdwg.org Subject: [tdwg-tag] Correction

I said:

But everybody is also hugely over-committed and under-funded.

Except, of course, for the Aussies, who are merely over-committed.

Rich

_______________________________________________ tdwg-tag mailing list tdwg-tag@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tag

Rich's first short-term solution to change the link in the left hand lists on the TDWG site is now done, it points to http://sourceforge.net/projects/lsid/. You may need to refresh your browsers to see this.

I'm going to take a quick trip around the site to see if I can see other links to this site and point them there as well.

Piers

-----Original Message----- From: tdwg-tag-bounces@lists.tdwg.org [mailto:tdwg-tag-bounces@lists.tdwg.org] On Behalf Of Richard Pyle Sent: Thursday, 27 August 2009 3:45 PM To: Tony.Rees@csiro.au; r.page@bio.gla.ac.uk; tdwg-tag@lists.tdwg.org Subject: Re: [tdwg-tag] LSID Sourceforge URL & LSID Best Practices

Rod's somewhat hyperbolic interpretation of this thread notwithstanding, I think it's fair to say that everybody cares. But everybody is also hugely over-committed and under-funded.

Biodiversity Informatics is now in its adolescence. Growing pains (and tantrums) are to be expected. In an ideal world, all endeavors (including human maturation) would bypass the teenage years. Speaking as the parent of a teenager, I can sympathize with the frustrations and the temptation to throw in the towel. But I maintain confidence (both as a parent, and as a pseudo-practitioner of Biodiversity Informatics stuff) that this development phase will eventually pass; and things will be better on the other side.

So...back to my original questions:

1) Should the orange LSID icon (i.e., http://zoobank.org/images/lsidlogo.jpg) be displayed next to LSIDs on HTML pages (as per recommendation #33 on p. 23 of the LSID draft Applicability Statement, http://www.tdwg.org/fileadmin/subgroups/guid/LSID_Applicability_Statement_dr aft.pdf)?

2) If so, what should it link to (if anything)? The aforementioned Applicability Statement says, "An icon linking to an explanation of the LSID should be present...", and the suggested text is "This is a Life Sciences Identifier (LSID), a permanent, globally unique identifier for this data item. Use this LSID whenever you need to refer to this data item." On the ZooBank site, I use this text for the mouse-over on the icon, but I wanted the icon itself to link to something more substantative, so I linked to http://lsids.sourceforge.net/

3) Given that http://lsids.sourceforge.net/ leads me to an "embarassing" terminus, should I:

a) simply change the link to http://sourceforge.net/projects/lsid/ ?

b) remove the link entirely?

c) wait until this thread reaches an eventual conclusion, and shift to a google code (or whatever) link?

I'm thinking that in the short-term (i.e., tomorrow), I'll go with option "a". In the middle term (i.e., if/when it's clear that sourceforge will not be the permanent home) I'll go with option "b". In the long term, I'll go with whatever emerges out of option "c".

Thanks for any feedback...

Aloha, Rich

-----Original Message----- From: tdwg-tag-bounces@lists.tdwg.org [mailto:tdwg-tag-bounces@lists.tdwg.org] On Behalf Of Tony.Rees@csiro.au Sent: Wednesday, August 26, 2009 8:56 PM To: r.page@bio.gla.ac.uk; tdwg-tag@lists.tdwg.org Subject: Re: [tdwg-tag] LSID Sourceforge URL & LSID Best Practices

Rod page wrote:

<snip> 1. It's perfectly acceptable for the public face of a major biodiversity informatics project to be broken in a way that makes us look amateurish. </snip>

At the e-Biosphere open discussion session, I reported an interesting and unfortunately not totally uncommon experience with major biodiversity informatics sens. lat, that several were either broken (e.g. OBIS searches for common taxa) or returned incomplete, or over-complete (correct + incorrect) data, and nobody seemed to care at this point. I guess it's just not mission-critical enough for anyone who does care??

Regards - Tony

Tony Rees Manager, Divisional Data Centre, CSIRO Marine and Atmospheric Research, GPO Box 1538, Hobart, Tasmania 7001, Australia Ph: 0362 325318 (Int: +61 362 325318) Fax: 0362 325000 (Int: +61 362 325000) e-mail: Tony.Rees@csiro.au Manager, OBIS Australia regional node, http://www.obis.org.au/ Biodiversity informatics research activities: http://www.cmar.csiro.au/datacentre/biodiversity.htm Personal info:

http://www.fishbase.org/collaborators/collaboratorsummary.cfm?%3E id=1566

-----Original Message----- From: tdwg-tag-bounces@lists.tdwg.org [mailto:tdwg-tag-bounces@lists.tdwg.org] On Behalf Of Roderic Page Sent: Thursday, 27 August 2009 4:51 PM To: Technical Architecture Groupmailing list Subject: Re: [tdwg-tag] LSID Sourceforge URL & LSID Best Practices

OK, the message I'm getting is that:

1. It's perfectly acceptable for the public face of a major

biodiversity informatics project to be broken in a way that makes us look amateurish.

2. TDWG must guarantee universal analysis at all times (even

thought China may, on a whim, ban access to any site it choses).

3. That TDWG is already using Google Code for Darwin Core

(http://code.google.com/p/darwincore/ ) is, of course, irrelevant to this discussion, as is the fact that Google Code seems fine for GBIF (http://code.google.com/p/gbif-ecat/ ) and EOL (http://code.google.com/p/eol-website/ ) projects.

4. Nobody thought these issues were important when the original

project was set up on SourceForge (http://en.wikipedia.org/wiki/SourceForge ).

5. That Greg Whitbread's puns are appalling.

I'm clearly too worked up about this, but all I'm looking for is a simple fix to a simple problem. Instead, we're off on some tangent about incorporation, instead of actually dealing with the issue at hand. Perhaps I shouldn't get too bothered, and take this discussion as tacit agreement that LSIDs are doomed anyway.

Regards

Rod

---

Roderic Page Professor of Taxonomy DEEB, FBLS Graham Kerr Building University of Glasgow Glasgow G12 8QQ, UK

Email: r.page@bio.gla.ac.uk Tel: +44 141 330 4778 Fax: +44 141 330 2792 AIM: rodpage1962@aim.com Facebook: http://www.facebook.com/profile.php?id=1112517192 Twitter: http://twitter.com/rdmpage Blog: http://iphylo.blogspot.com Home page: http://taxonomy.zoology.gla.ac.uk/rod/rod.html

---

tdwg-tag mailing list tdwg-tag@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tag _______________________________________________ tdwg-tag mailing list tdwg-tag@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tag

_______________________________________________ tdwg-tag mailing list tdwg-tag@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tag

Oops! It seems our emails crossed each other.

Nope....when I hit http://lsids.sourceforge.net/ I still get the following error message:

"Cannot find configuration. This file is probably executed from the wrong location."

Aloha, Rich

-----Original Message----- From: Hilmar Lapp [mailto:hlapp@duke.edu] Sent: Thursday, August 27, 2009 7:37 AM To: Richard Pyle Cc: Tony.Rees@csiro.au; r.page@bio.gla.ac.uk; tdwg-tag@lists.tdwg.org Subject: Re: [tdwg-tag] LSID Sourceforge URL & LSID Best Practices

Hi Rich:

On Aug 27, 2009, at 3:45 AM, Richard Pyle wrote:

...

3. Given that http://lsids.sourceforge.net/ leads me to an

"embarassing" terminus, should I:

This should work again now. Just in case you wanted to change it back :)

-hilmar

=========================================================== : Hilmar Lapp -:- Durham, NC -:- hlapp at duke dot edu : ===========================================================

Rich, it's probably a cached page. I got the same, refreshed the page, and now it's all good.

Regards

Rod

On 27 Aug 2009, at 18:41, Richard Pyle wrote:

Oops! It seems our emails crossed each other.

Nope....when I hit http://lsids.sourceforge.net/ I still get the following error message:

"Cannot find configuration. This file is probably executed from the wrong location."

Aloha, Rich

...

-----Original Message----- From: Hilmar Lapp [mailto:hlapp@duke.edu] Sent: Thursday, August 27, 2009 7:37 AM To: Richard Pyle Cc: Tony.Rees@csiro.au; r.page@bio.gla.ac.uk; tdwg-tag@lists.tdwg.org Subject: Re: [tdwg-tag] LSID Sourceforge URL & LSID Best Practices

Hi Rich:

On Aug 27, 2009, at 3:45 AM, Richard Pyle wrote:

...

3. Given that http://lsids.sourceforge.net/ leads me to an

"embarassing" terminus, should I:

This should work again now. Just in case you wanted to change it back :)

-hilmar

=========================================================== : Hilmar Lapp -:- Durham, NC -:- hlapp at duke dot edu : ===========================================================

--------------------------------------------------------- Roderic Page Professor of Taxonomy DEEB, FBLS Graham Kerr Building University of Glasgow Glasgow G12 8QQ, UK

Email: r.page@bio.gla.ac.uk Tel: +44 141 330 4778 Fax: +44 141 330 2792 AIM: rodpage1962@aim.com Facebook: http://www.facebook.com/profile.php?id=1112517192 Twitter: http://twitter.com/rdmpage Blog: http://iphylo.blogspot.com Home page: http://taxonomy.zoology.gla.ac.uk/rod/rod.html

OK, it seems to be working fine for me now.

Many thanks!!!

Aloha, Rich

-----Original Message----- From: Piers Higgs [mailto:Piers@gaiaresources.com.au] Sent: Thursday, August 27, 2009 2:11 PM To: Hilmar Lapp; Richard Pyle Cc: tdwg-tag@lists.tdwg.org Subject: RE: [tdwg-tag] LSID Sourceforge URL & LSID Best Practices

... and changed back again. Again, you may need a refresh of the pages to see the changes.

P

-----Original Message----- From: tdwg-tag-bounces@lists.tdwg.org [mailto:tdwg-tag-bounces@lists.tdwg.org] On Behalf Of Hilmar Lapp Sent: Friday, 28 August 2009 1:37 AM To: Richard Pyle Cc: tdwg-tag@lists.tdwg.org; Tony.Rees@csiro.au Subject: Re: [tdwg-tag] LSID Sourceforge URL & LSID Best Practices

Hi Rich:

On Aug 27, 2009, at 3:45 AM, Richard Pyle wrote:

...

3. Given that http://lsids.sourceforge.net/ leads me to an

"embarassing" terminus, should I:

This should work again now. Just in case you wanted to change it back :)

-hilmar

=========================================================== : Hilmar Lapp -:- Durham, NC -:- hlapp at duke dot edu : ===========================================================

---

tdwg-tag mailing list tdwg-tag@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tag

The site is fixed and back to life. Thanks to Tim for granting me access. Gory details below. I haven't check all links, so it may not all work. If you find something that doesn't, let us know.

-hilmar

It turns out I was wrong about it using WordPress. Instead it uses a custom-installed Typo3 (http://typo3.com) as the CMS. The installation was referring to a location for web-application file storage that does no longer exist. I created the necessary file structure at the new location, and restored the content from a backup I found among the website files, which was apparently taken Apr 7, 2008.

SourceForge backed up the files from the old webserver file storage location, but at a location that's not accessible through the normal shell access. Due to the nested directory structure I would need to use something like rsync to pull it down recursively, and if we encounter problems with the restore from backup I can look into that. However, looking around there and spot checking the files seemed to be all of the same date and size as in the backup I used for restoring, so maybe we're good already in terms of having the latest version before it all went broke. BTW this must have happened on Sep 18, 2008; I guess the site was broken for almost a year ...

SourceForge now provides hosted apps that are customizable but maintained by Sf.net. Not surprisingly, they advise against installing your own, as projects have to maintain and upgrade those themselves. I have enabled MediaWiki and WordPress but there are other options too (https://sourceforge.net/apps/trac/sourceforge/wiki/Hosted%20Apps ). Sooner or later the content should be probably migrated away from the custom Typo3 installation to one of these hosted applications, unless someone knows of a specific advantage of sticking with Typo3.

Thanks, Hilmar and all others who agitated, circumscribed the problem (from multiple directions), brought an excellent pun (they should be proud, not disown you Greg!), and ultimately persisted to get a link working again! Who knew the can of worms I had opened? --Gail

On Aug 27, 2009, at 12:19 PM, Hilmar Lapp wrote:

The site is fixed and back to life. Thanks to Tim for granting me access. Gory details below. I haven't check all links, so it may not all work. If you find something that doesn't, let us know.

-hilmar

It turns out I was wrong about it using WordPress. Instead it uses a custom-installed Typo3 (http://typo3.com) as the CMS. The installation was referring to a location for web-application file storage that does no longer exist. I created the necessary file structure at the new location, and restored the content from a backup I found among the website files, which was apparently taken Apr 7, 2008.

SourceForge backed up the files from the old webserver file storage location, but at a location that's not accessible through the normal shell access. Due to the nested directory structure I would need to use something like rsync to pull it down recursively, and if we encounter problems with the restore from backup I can look into that. However, looking around there and spot checking the files seemed to be all of the same date and size as in the backup I used for restoring, so maybe we're good already in terms of having the latest version before it all went broke. BTW this must have happened on Sep 18, 2008; I guess the site was broken for almost a year ...

SourceForge now provides hosted apps that are customizable but maintained by Sf.net. Not surprisingly, they advise against installing your own, as projects have to maintain and upgrade those themselves. I have enabled MediaWiki and WordPress but there are other options too (https://sourceforge.net/apps/trac/sourceforge/wiki/Hosted%20Apps ). Sooner or later the content should be probably migrated away from the custom Typo3 installation to one of these hosted applications, unless someone knows of a specific advantage of sticking with Typo3.

--

: Hilmar Lapp -:- Durham, NC -:- hlapp at duke dot edu :

---

tdwg-tag mailing list tdwg-tag@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tag

==== A learning experience is one of those things that says, 'You know that thing you just did? Don't do that.' -- Douglas Adams

Gail E. Kampmeier Sr. Research Entomologist Illinois Natural History Survey Institute of Natural Resource Sustainability University of Illinois at Urbana-Champaign Box 5 NSRC, MC-637 1101 W. Peabody, Urbana, IL 61801 USA ph. 217-333-2824 fax 217-244-1707 email: gkamp@illinois.edu **note change** http://www.inhs.illinois.edu/~gkamp/

On Thu, Aug 27, 2009 at 3:57 AM, Jim Croftjim.croft@gmail.com wrote:

1. Building mission-critical stuff around a single point of failure

without distributed replicated redundancy is amateurish, ultimately doomed to failure, and I am amazed that everybody does it.   The drive for an easy solution with smart response times wins every time.  IMO, the Australia's Virtual Herbarium took a step backward when it moved from a distributed to a cached solution without building in fail-over redundancy.  Yes, the new version is quicker but when it does not work you are clean out of luck.  If we are going to build anything that is going to become mission-critical and expect people to use it, then I want more than one of them.

The recent LSID sourceforge failure was not a technical failure; it was an administrative one. Many people had the password required to fix the site, but none was taking care of the problem. Having multiple A records directing to redundant servers would not have helped if none of those servers had the correct content.

Assuming the administrative powers are willing to make the necessary resolution configuration changes (such as establishing A records or reconfiguring a server), then the technical setup can be improved over time as needed. That is, one can start out with a single technical point of failure, and then switch to a redundant system as resources and motivation for one improve. But all the technical prowess in the world can't cause a URI or handle to resolve properly if there is not the willingness to make it do so from those who control the namespace.

This is, of course, an argument in favor of systems (such as the Linnaean one) that don't rely on a central resolution authority, but rather allow consumer choice by encouraging a market for name resolvers (Harvard's library doesn't have that genus revision? Try Yale's). Instituting something like this in any general way is probably beyond the abilities and interests of today's purveyors of web infrastructure. The fact that ICANN and DNS work as well as they do prevents anyone from working on an administratively decentralized alternative.

That said, I agree completely that redundancy is a great thing for both technical and administrative reasons, and should be encouraged even if the replica has to be accessed via different URIs than the original. Ad hoc client (or server, or proxy) software can convert published (unresolvable) URIs to replica URIs for the time being, and maybe in the future there might even be standards for configuring resolver choice - maybe even inside web browsers.

Jonathan

On Sun, Aug 30, 2009 at 12:29 AM, Bob Morrismorris.bob@gmail.com wrote:

On Fri, Aug 28, 2009 at 11:52 AM, Jonathan Reesjar@creativecommons.org wrote:

...

... The fact that ICANN and DNS work as well as they do prevents anyone from working on an administratively decentralized alternative.

Umm, I would say that DNS is a giant success story about administratively decentralized technology, but my parsing of this sentence makes me believe that you think it is not administratively decentralized but should be.  I suppose only the TLD servers have their DNS records administered of necessity by a single agency, and those provide substantial redundancy.

Sorry I was not clear. Yes, DNS/ICANN is a success story for decentralization. I was not referring to the system as a whole but rather to individual domain names. If the owner of a domain disappears or reorganizes, then all users of its URIs are screwed - the well-known 404 problem. This phenomenon is what I've been calling an "administrative single point of failure" resulting from "administrative centralization", in contrast to "technical single point of failure". No amount of technical replication can address this vulnerability. Just saying that a URI is "persistent" does not make it so, and we know that domains go south in spite of the best intentions of those who originally create and disseminate its URIs, and in spite of the availability of technical replicas (at other locations) of the data that users need.

The only alternative to DNS/ICANN is some alternative to it (sorry) - say, if domain D goes away but a copy of the needed information exists at E, then configure clients somehow to resolve D to E instead of to what ICANN tells you. This is what I've been calling "administrative" redundancy, which has a distinctly different character from mere technical redundancy. My point was just that even though such consumer choice would be wonderful, in principle, and resembles the way that historically robust systems such as the Linnaean system and libraries work (and that would be required in order for many kinds of URN to work), it is a fantasy - it's very unlikely to come about, because DNS/ICANN works so well. (Same argument applies to handle system.) Consumers are left with no power, and putatively-persistent-URI creators, in selfless service to consumers, have to voluntarily take on the burden to just "try very hard" to make domains used in URIs be well-behaved in perpetuity.

Jonathan

Ah, I take your point. However, it is not about the persistence of the URI qua URI, but rather of the "actionability" (e.g. resolvability) in the sense of the recent GUID report.

There are separate issues about the persistence of the identifier itself. Some organizations permit their employees to use their DNS names for various purposes only during the length of their employment, after which they are required to remove all trace of that use of the name from the internet, whether such removal is technically feasible or not. If I recall correctly, German federal government employees are subject to that requirement. Even when there is no such requirement, I should think that an organization that is the registrant of a DNS name is likely to assert that it owns that name in most legal jurisdictions, and can take whatever legal or technical actions it wishes to control its use. For example, if you produce a URI containing the string creativecommons.org today, even with permission of the owner of that domain name, it is quite possible that said owner, or someone else with one or another ownership of the name "creativecommons.org", might tomorrow be able to enforce on all users of your URI that they stop using it.

On Tue, Sep 1, 2009 at 10:02 AM, Jonathan Reesjar@creativecommons.org wrote:

On Sun, Aug 30, 2009 at 12:29 AM, Bob Morrismorris.bob@gmail.com wrote:

...

On Fri, Aug 28, 2009 at 11:52 AM, Jonathan Reesjar@creativecommons.org wrote:

...

... The fact that ICANN and DNS work as well as they do prevents anyone from working on an administratively decentralized alternative.

Umm, I would say that DNS is a giant success story about administratively decentralized technology, but my parsing of this sentence makes me believe that you think it is not administratively decentralized but should be.  I suppose only the TLD servers have their DNS records administered of necessity by a single agency, and those provide substantial redundancy.

Sorry I was not clear. Yes, DNS/ICANN is a success story for decentralization. I was not referring to the system as a whole but rather to individual domain names. If the owner of a domain disappears or reorganizes, then all users of its URIs are screwed - the well-known 404 problem. This phenomenon is what I've been calling an "administrative single point of failure" resulting from "administrative centralization", in contrast to "technical single point of failure". No amount of technical replication can address this vulnerability. Just saying that a URI is "persistent" does not make it so, and we know that domains go south in spite of the best intentions of those who originally create and disseminate its URIs, and in spite of the availability of technical replicas (at other locations) of the data that users need.

The only alternative to DNS/ICANN is some alternative to it (sorry) - say, if domain D goes away but a copy of the needed information exists at E, then configure clients somehow to resolve D to E instead of to what ICANN tells you. This is what I've been calling "administrative" redundancy, which has a distinctly different character from mere technical redundancy. My point was just that even though such consumer choice would be wonderful, in principle, and resembles the way that historically robust systems such as the Linnaean system and libraries work (and that would be required in order for many kinds of URN to work), it is a fantasy - it's very unlikely to come about, because DNS/ICANN works so well. (Same argument applies to handle system.) Consumers are left with no power, and putatively-persistent-URI creators, in selfless service to consumers, have to voluntarily take on the burden to just "try very hard" to make domains used in URIs be well-behaved in perpetuity.

Jonathan

Hi all,

Jim Croft wrote:

<snip> 1. Building mission-critical stuff around a single point of failure without distributed replicated redundancy is amateurish, ultimately doomed to failure, and I am amazed that everybody does it. The drive for an easy solution with smart response times wins every time. IMO, the Australia's Virtual Herbarium took a step backward when it moved from a distributed to a cached solution without building in fail-over redundancy. Yes, the new version is quicker but when it does not work you are clean out of luck. If we are going to build anything that is going to become mission-critical and expect people to use it, then I want more than one of them. </snip>

Actually I believe your criticism is only partly correct. Centralising a copy of, and indexes of, distributed resources (i.e. a hybrid distributed+centralised model) is a good thing in some crucial respects - (1) speeds up query time and also (2) eliminates the sometimes patchy real time connection issues to remote servers. In addition one can hopefully (3) centralise the copies in well supported and maintained location/s with economies of scale for content maintenance, QA, and IT support e.g. 24/7 failover service. The residual problems are then (as you correctly say) mirroring (duplicate central caches/indexes in alternate locations) plus (as you do not say) synchronisation (ensuring that changes at the remote points-of-truth are rapidly propagated), however a rollback to the completely distributed model is in my view not the answer.

Just my 2 cents worth,

- Tony