Blog: UUIDs may be Dangerous
Hi All,
I took a couple of days off but couldn't help thinking about GUIDs and UUIDs especially after the various discussion that were had in Fremantle. I have written these up in a blog here:
http://www.hyam.net/blog/archives/90
in case you are interested,
Your thoughts are always welcome.
Roger
------------------------------------------------------------- Roger Hyam Roger@BiodiversityCollectionsIndex.org http://www.BiodiversityCollectionsIndex.org ------------------------------------------------------------- Royal Botanic Garden Edinburgh 20A Inverleith Row, Edinburgh, EH3 5LR, UK Tel: +44 131 552 7171 ext 3015 Fax: +44 131 248 2901 http://www.rbge.org.uk/ -------------------------------------------------------------
Yes, that was my instinctive response to the suggestion to use UUIDs at TDWG. They are easy and may help, but they have distinctive disadvantages.
From a recent discussion with Tim, and having just been to the sem web conference (http://iswc2008.semanticweb.org) , I am also rather unsure about LSIDs in their pure form, in that they are not at all semantic web friendly - 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.
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 ???
Kevin
From: tdwg-tag-bounces@lists.tdwg.org [mailto:tdwg-tag-bounces@lists.tdwg.org] On Behalf Of Roger Hyam Sent: Friday, 21 November 2008 3:34 a.m. To: Technical Architecture Group mailing list Subject: [tdwg-tag] Blog: UUIDs may be Dangerous
Hi All,
I took a couple of days off but couldn't help thinking about GUIDs and UUIDs especially after the various discussion that were had in Fremantle. I have written these up in a blog here:
http://www.hyam.net/blog/archives/90
in case you are interested,
Your thoughts are always welcome.
Roger
------------------------------------------------------------- Roger Hyam Roger@BiodiversityCollectionsIndex.orgmailto:Roger@BiodiversityCollectionsIndex.org http://www.BiodiversityCollectionsIndex.orghttp://www.BiodiversityCollectionsIndex.org/ ------------------------------------------------------------- Royal Botanic Garden Edinburgh 20A Inverleith Row, Edinburgh, EH3 5LR, UK Tel: +44 131 552 7171 ext 3015 Fax: +44 131 248 2901 http://www.rbge.org.uk/ -------------------------------------------------------------
________________________________ Please consider the environment before printing this email Warning: This electronic message together with any attachments is confidential. If you receive it in error: (i) you must not read, use, disclose, copy or retain it; (ii) please contact the sender immediately by reply email and then delete the emails. The views expressed in this email may not be those of Landcare Research New Zealand Limited. http://www.landcareresearch.co.nz
Rest-style permanent HTTP URL sounds like a way to Keep It Simple.
Chuck
________________________________
From: tdwg-tag-bounces@lists.tdwg.org on behalf of Kevin Richards Sent: Thu 11/20/2008 3:05 PM To: Roger Hyam - Biodiversity Collections Index; Technical Architecture Groupmailing list Subject: Re: [tdwg-tag] Blog: UUIDs may be Dangerous
Yes, that was my instinctive response to the suggestion to use UUIDs at TDWG. They are easy and may help, but they have distinctive disadvantages.
From a recent discussion with Tim, and having just been to the sem web conference (http://iswc2008.semanticweb.org http://iswc2008.semanticweb.org/ ) , I am also rather unsure about LSIDs in their pure form, in that they are not at all semantic web friendly - 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.
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 ???
Kevin
From: tdwg-tag-bounces@lists.tdwg.org [mailto:tdwg-tag-bounces@lists.tdwg.org] On Behalf Of Roger Hyam Sent: Friday, 21 November 2008 3:34 a.m. To: Technical Architecture Group mailing list Subject: [tdwg-tag] Blog: UUIDs may be Dangerous
Hi All,
I took a couple of days off but couldn't help thinking about GUIDs and UUIDs especially after the various discussion that were had in Fremantle. I have written these up in a blog here:
http://www.hyam.net/blog/archives/90
in case you are interested,
Your thoughts are always welcome.
Roger
------------------------------------------------------------- Roger Hyam Roger@BiodiversityCollectionsIndex.org http://www.BiodiversityCollectionsIndex.org http://www.biodiversitycollectionsindex.org/ -------------------------------------------------------------
Royal Botanic Garden Edinburgh
20A Inverleith Row, Edinburgh, EH3 5LR, UK
Tel: +44 131 552 7171 ext 3015
Fax: +44 131 248 2901
-------------------------------------------------------------
________________________________
Please consider the environment before printing this email Warning: This electronic message together with any attachments is confidential. If you receive it in error: (i) you must not read, use, disclose, copy or retain it; (ii) please contact the sender immediately by reply email and then delete the emails. The views expressed in this email may not be those of Landcare Research New Zealand Limited. http://www.landcareresearch.co.nz
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-basedGUID... 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
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-basedGUID... 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
I favour
* Implementations that play well with others * Implementations that others will understand, having familiarised themselves with the Semantic Web * Implementations that are easy (for data providers, in particular)
So I think that means I favour:
* Stable URLs * A central service that is as stable as possible. Does the use of a DNS for each individual service imply that the DNS may be more fallible as the number of services increases? Does that mean that using paths within the URL is both easier and less fallible? If so, that gets my vote.
Does this preclude LSIDs from being used?
Cheers, Ben
-----Original Message----- From: tdwg-tag-bounces@lists.tdwg.org [mailto:tdwg-tag-bounces@lists.tdwg.org]On Behalf Of "Markus Döring (GBIF)" Sent: Friday, 21 November 2008 23:39 To: Gregor Hagedorn Cc: Kevin Richards; Technical Architecture Group mailing list Subject: Re: [tdwg-tag] Blog: UUIDs may be Dangerous
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-basedGUID...
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
This email, together with any attachments, is intended for the addressee only. It may contain confidential or privileged information. If you are not the intended recipient of this email, please notify the sender, delete the email and attachments from your system and destroy any copies you may have taken of the email and its attachments. Duplication or further distribution by hardcopy, by electronic means or verbally is not permitted without permission.
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-basedGUID... 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.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
How do we get from using URLs to having a central service? If we have a central service then we don't need to use URLs (we could use Handle, LSID or even UUID or all of them). The service is just a mapping from string to URL.
If we do advocate use of URLs we need guidelines on how to use them. They may be protocol dependent but they should be independent of other technologies. Should they be short? Should the be recognizable as permanent? Should they do HTTP Range 14 compliant 303 redirects? What is the return type? Content negotiation? etc etc
How about a central service that you can register any string with? This could run in parallel with an identifier service.....hmmmm?
BTW: It is funny that my blog on UUIDs got us to talking about not using LSIDs!
Roger
On 24 Nov 2008, at 08: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-basedGUID... 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.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
How do we get from using URLs to having a central service? If we have a central service then we don't need to use URLs (we could use Handle, LSID or even UUID or all of them). The service is just a mapping from string to URL.
in order to facilitate stable URLs in a world of changing domains. Redirection to relocated services can be done by institutions, but changing domains are still a problem we can solve with a central redirection service
Markus
If we do advocate use of URLs we need guidelines on how to use them. They may be protocol dependent but they should be independent of other technologies. Should they be short? Should the be recognizable as permanent? Should they do HTTP Range 14 compliant 303 redirects? What is the return type? Content negotiation? etc etc
How about a central service that you can register any string with? This could run in parallel with an identifier service.....hmmmm?
BTW: It is funny that my blog on UUIDs got us to talking about not using LSIDs!
Roger
On 24 Nov 2008, at 08: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-basedGUID... 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.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
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-basedGUID... 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.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
I think Dave's comments are worth a lot :-). I understand that both IDs and their mappings to resolvers should be technology-neutral. I would greatly welcome this.
My own position is based on a much more limited perspective: Does the identifier system plays well with standard software, or is it creating a walled garden for those installing custom LSID software?
http://wiki.tdwg.org/twiki/bin/view/GUID/LsidHttpProxyUsageRecommendation is a valid attempt to support semantic reasoners. It is, as stated in its purpose, for those desiring to use LSIDs at all, and thus by necessity asymmetrical. It is just a bit complicated (and perhaps error prone) to publish all your data under LSIDs, but then never use them when referring to your own data.
With a technology independent ID, you could use http consistently, without preventing LSID users from translating URL-based-ID to neutral-ID to LSID-based-ID.
Gregor
In principle, if not properly resolved, the two alternatives produce different kinds of errors for http clients. The first would produce "Address not found" and the other "File not found". If one of those provides more robust error management at either resolver or client(e.g. reporting, tracking down the correct GUID, etc.), that one would be preferable. Not that I can see any relevant difference...I just offer a criterion that might affect choice.
On Fri, Nov 21, 2008 at 9:39 AM, "Markus Döring (GBIF)" mdoering@gbif.org wrote:
...
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 ?
participants (9)
-
"Markus Döring (GBIF)" -
Bob Morris -
Chuck Miller -
Dave Vieglais -
Gregor Hagedorn -
Kevin Richards -
Richardson, Ben -
Roderic Page -
Roger Hyam