Exactly.
My comments for what they're worth:
1. Since technology can be quite ephemeral, identifiers should not be dependent on technology.
2. To avoid collisions, it is necessary to have coordination of ID ranges (i.e. defining namespaces for different id generators) - that's the purpose of DNS in LSIDs and pure URL identifiers - but DNS is a transient technology so relying on DNS for namespace definition seems to be a mistake.
3. There should be well known services for resolving these identifiers - the LSID infrastructure already in place may be helpful in this, as will the Handle/DOI infrastructure.
4. There should be well defined rules for combining and splitting resolver service URLs with identifiers - so that an identifier can be embedded in a URL to be resolved without stating that the URL is the identifier. Ideally these rules should work for not just HTTP urls but also other protocols such as FTP, LDAP, and even ssh.
Following these guidelines would enable full use of the evolving semantic web infrastructure, legacy plain old HTTP services, and for those that really want them, LSIDs.
regards,
Dave V.
On Nov 24, 2008, at 18:11 , Roderic Page wrote:
And the fourth question is, at what point in a setting up a central
service that registers and redirects do we realise that we're
reinventing the wheel and take a hard look at Handles/DOIs?
Regards
Rod
On 21 Nov 2008, at 14:39, Markus Döring (GBIF) wrote:
It's funny that nearly all of us consider stable URLs as the best
option by now, but we still decided to stay with LSIDs during TDWG.
The main argument for LSIDs during the TAG meeting was indeed a social
one: they look more stable, especially in printed publications.
But I have to support Gregor in that initial trust in stable URLs is
achieved by making the URL look stable. Finally it boils down to a
management problem, no matter if we use LSIDs, PURLs or whatever other
technology.
To get forward with this everlasting discussion:
Is there anyone left who would feel bad about moving to stable URLs?
And as a second question, should we have a central domain that
registers services and redirects to the resolving service, so that
people can move their service. Or do we trust the community to keep
their URLs stable themselves?
And if we prefer a central service, should we just use DNS and assign
subdomains for the individual services, e.g. http://rbgk13.tdwg.id/543-544-cfjf3f667
or assign paths within the URL to services, e.g. http://guid.tdwg.org/rbgk13/543-544-cfjf3f667
?
Markus
On Nov 20, 2008, at 11:09 PM, Gregor Hagedorn wrote:
Kevin writes
- ie they cannot be resolved using default HTTP resolution. The
idea of
using the http proxy version of the LSIDs is a good way to get
around this,
but this does have some drawbacks:
- 1st you really need everyone to agree to use it everywhere,
which is a
bit difficult considering it is not at all part of the LSID
standard, and we
struggle to get "everyone" to do anything
- 2nd, it seems very much like a hack - you might as well just use
permanent
http urls - ie the main advantage of LSIDs in this case is the
"encouraging
a degree of thought before making URIs publically available". But
we don't
really need to pick up the whole LSID overhead just to achieve this.
3rd: the system is complicated and it is difficult to guarantee that
the sequence of reciprocal references is correct and in the right
order and place. I believe you would need special validator tools to
find errors in the system.
And, most relevantly, I believe it will exclude many from
participation, because the complexity is a bit scary.
So it seems to me like good old Plain Old URLs are just great! :
-)
Or at least the suggestion of REST styled, permanent HTTP URLs as
GUIDs ???
I fully agree. I believe LSIDs never were meant to be a technical
solution, but rather a technical wedge to hammer in to achieve social
change. All the LSIDs really promise are different management
practices.
As argued in http://wiki.tdwg.org/twiki/bin/view/GUID/CommunityPracticesForHttp-basedGUIDs
I think it is sensible to agree on a community agreed mechanism to
keep some URLs more stable than others. That could be URLs containing
UUIDs, but I would argue for a social convention to agree on a
recognizable string marking URLs that should be kept stable as long
as
possible and at least not re-assigned. There would be little harm to
have a couple of such naming conventions, including e.g. non-english
localizations, but one could be:
x.y.net/stable-id/something/12317982
Gregor
--
---------------------------------
Dr. Gregor Hagedorn
Heinrich-Seidel-Str. 2
12167 Berlin
skype: g.hagedorn
This message is sent on a personal basis and does not constitute an
activity of the German Federal Government or its research
institutions.
_______________________________________________
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
---------------------------------------------------------
Roderic Page
Professor of Taxonomy
DEEB, FBLS
Graham Kerr Building
University of Glasgow
Glasgow G12 8QQ, UK
Email:
r.page@bio.gla.ac.ukTel: +44 141 330 4778
Fax: +44 141 330 2792
AIM:
rodpage1962@aim.comFacebook:
http://www.facebook.com/profile.php?id=1112517192Twitter:
http://twitter.com/rdmpageBlog:
http://iphylo.blogspot.comHome page:
http://taxonomy.zoology.gla.ac.uk/rod/rod.html_______________________________________________
tdwg-tag mailing list
tdwg-tag@lists.tdwg.orghttp://lists.tdwg.org/mailman/listinfo/tdwg-tag