Central LSID registration authority?

Donald Hobern dhobern at GBIF.ORG
Wed Apr 19 15:01:33 CEST 2006


I've added some starting comments on the question of whether or not a
"central LSID registration authority" would be useful to our community:



http://wiki.gbif.org/guidwiki/wikka.php?wakka=GUIDCentralRegistrationAuthori
ty (text appended below)



This is one of the Infrastructure Working Group topics.



As I have noted, there are topics which could be addressed under this title
but which I have deliberately excluded.  Please address these if you think
they are valuable.



Please provide your input.



Thanks,



Donald

---------------------------------------------------------------
Donald Hobern (dhobern at gbif.org)
Programme Officer for Data Access and Database Interoperability
Global Biodiversity Information Facility Secretariat
Universitetsparken 15, DK-2100 Copenhagen, Denmark
Tel: +45-35321483   Mobile: +45-28751483   Fax: +45-35321480
---------------------------------------------------------------



A central LSID registration authority could take several different forms.
The following is an attempt to outline some options, so that subsequent
discussion can focus more clearly on the benefits of each.

I'm going to start by ignoring the possibility of establishing a central
LSID registration authority as some kind of registrar approving or recording
new LSID authorities within our domain. I'm also going to ignore the
possibility of requiring all LSIDs to be registered within a single
namespace. I cannot see value in either of these "options". If anyone wishes
to propose them, please go ahead.

It is assumed here that the purpose of such an authority would be to provide
a mechanism for data providers to associate LSIDs with their records without
having to establish and maintain an LSID resolver in their own namespace.
This could for example be because the data set in question is likely to be
moved to a different home, or because the data provider cannot get
permission to register an LSID provider with DNS, or because the data
provider's host institution has restrictive rules on firewall access.

Under these circumstances a data provider may still wish to be able to
assign LSIDs to each data record and to have the LSID resolve correctly to
the appropriate data and metadata.

Some options:


1. Central hosting of data/metadata


The simplest option technically (or at least simplest with respect to the
assignment of LSIDs) may be for the central LSID registration authority
actually to host the data sets in question on behalf of the data provider.


2. Central proxy LSID resolver


If the data provider is able to establish an LSID resolver but is unable or
unwilling to register this resolver with DNS, a central LSID registration
authority might establish a proxy LSID resolver, which redirects to the
known location of the actual LSID resolver. In other words, assuming that
the central LSID registration authority has an LSID resolver registered for
clra.org and running on lsid.clra.org, and the data provider has established
its own unregistered LSID resolver on lsid.dp.org, the data provider can
issue LSIDs of the form urn:lsid:clra.org:<DatasetName
<http://wiki.gbif.org/guidwiki/wikka.php?wakka=DatasetName/edit> >:<RecordId
<http://wiki.gbif.org/guidwiki/wikka.php?wakka=RecordId/edit> >. Requests
for data or metadata will be directed to lsid.clra.org, which resolves
<DataSetName
<http://wiki.gbif.org/guidwiki/wikka.php?wakka=DataSetName/edit> > to be
associated with the unregistered LSID resolver on lsid.dp.org, and directs
the request to lsid.dp.org for resolution.

This again should be relatively simple to implement, and could be of use in
some circumstances. The data provider and the central LSID registration
authority clearly need to coordinate the elements included in the LSID
string.


3. Central LSID resolver with non-LSID proxy resolution


Slightly more complex (and potentially with too many uncertainties), a data
provider could register a provider tool using some other protocol (e.g.
TAPIR) and rely on an external proxy LSID resolver to map LSID requests to
the appropriate protocol. For example, assume that a TAPIR provider is set
up on tapir.dp.org to serve data in some version of darwin core which
includes a <darwin:lsid> element. The records in the TAPIR provider are all
set up to include values for this element of the form
urn:lsid:clra.org:<DatasetName
<http://wiki.gbif.org/guidwiki/wikka.php?wakka=DatasetName/edit> >:<RecordId
<http://wiki.gbif.org/guidwiki/wikka.php?wakka=RecordId/edit> >. Requests
for data or metadata will be directed to lsid.clra.org, which resolves
<DataSetName
<http://wiki.gbif.org/guidwiki/wikka.php?wakka=DataSetName/edit> > to be
associated with the TAPIR provider on tapir.dp.org, issues an appropriate
TAPIR request for the record with the appropriate value for <darwin:lsid>
and then formats the data or metadata appropriately for an LSID response.

This is again not complex to implement, but requires even more coordination
than with option 2. It could however be applicable in any case in which a
data provider has any mechanism for sharing their data online, regardless of
what additional firewall restrictions are in place.


This is doubtless not a complete set of options, but should be enough to
begin discussion. So, do you see value in considering any of these options
as part of the infrastructure we plan to adopt. It may of course be that any
and all of these can be used transparently within any LSID-based network,
but we should consider whether there are immediate benefits in offering some
kind of central service (through TDWG, GBIF or others) for these purposes.


------=_NextPart_000_00A5_01C663C2.2590A700
Content-Type: text/html;
        charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:st1=3D"urn:schemas-microsoft-com:office:smarttags" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"country-region" downloadurl=3D"http://www.5iantlavalamp.com/"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"City" =
downloadurl=3D"http://www.5iamas-microsoft-com:office:smarttags"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"place" downloadurl=3D"http://www.5iantlavalamp.com/"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0cm;
        margin-bottom:.0001pt;
        font-size:12.0pt;
        font-family:"Times New Roman";}
h5
        {mso-margin-top-alt:auto;
        margin-right:0cm;
        mso-margin-bottom-alt:auto;
        margin-left:0cm;
        font-size:10.0pt;
        font-family:"Times New Roman";}
a:link, span.MsoHyperlink
        {color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {color:purple;
        text-decoration:underline;}
span.EmailStyle17
        {mso-style-type:personal-compose;
        font-family:Arial;
        color:windowtext;}
@page Section1
        {size:612.0pt 792.0pt;
        margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.Section1
        {page:Section1;}
-->
</style>

</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'>I&#8217;ve added some starting comments on the
question of whether or not a &#8220;central LSID registration =
authority&#8221; would
be useful to our community:<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'><a
href=3D"http://wiki.gbif.org/guidwiki/wikka.php?wakka=3DGUIDCentralRegist=
rationAuthority">http://wiki.gbif.org/guidwiki/wikka.php?wakka=3DGUIDCent=
ralRegistrationAuthority</a>
(text appended below)<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'>This is one of the Infrastructure Working =
Group
topics. &nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'>As I have noted, there are topics which could =
be
addressed under this title but which I have deliberately excluded.&nbsp; =
Please
address these if you think they are =
valuable.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'>Please provide your =
input.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'>Thanks,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'>Donald<br>
&nbsp;<br>
---------------------------------------------------------------<br>
Donald Hobern (<a =
href=3D"mailto:dhobern at gbif.org">dhobern at gbif.org</a>)<br>
Programme Officer for Data Access and Database Interoperability <br>
Global Biodiversity Information Facility Secretariat <br>
Universitetsparken 15, DK-2100 <st1:place w:st=3D"on"><st1:City =
w:st=3D"on">Copenhagen</st1:City>,
 <st1:country-region =
w:st=3D"on">Denmark</st1:country-region></st1:place><br>
Tel: +45-35321483&nbsp;&nbsp; <st1:place w:st=3D"on"><st1:City =
w:st=3D"on">Mobile</st1:City></st1:place>:
+45-28751483&nbsp;&nbsp; Fax: +45-35321480<br>
---------------------------------------------------------------</span></f=
ont><font
size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:Arial'><o:p></o:p></span></font></p=
>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
lang=3DEN-GB
style=3D'font-size:12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><font size=3D3
face=3D"Times New Roman"><span lang=3DEN-GB style=3D'font-size:12.0pt'>A =
<strong><b><font
face=3D"Times New Roman">central LSID registration =
authority</font></b></strong>
could take several different forms. The following is an attempt to =
outline some
options, so that subsequent discussion can focus more clearly on the =
benefits
of each.<br>
<br>
<em><i><font face=3D"Times New Roman">I'm going to start by ignoring the
possibility of establishing a </font></i></em><strong><b><i><font
face=3D"Times New Roman"><span style=3D'font-style:italic'>central LSID
registration authority</span></font></i></b></strong><em><i><font
face=3D"Times New Roman"> as some kind of registrar approving or =
recording new
LSID authorities within our domain. I'm also going to ignore the =
possibility of
requiring all LSIDs to be registered within a single namespace. I cannot =
see
value in either of these &quot;options&quot;. If anyone wishes to =
propose them,
please go ahead.</font></i></em><br>
<br>
It is assumed here that the purpose of such an authority would be to =
provide a
mechanism for data providers to associate LSIDs with their records =
without
having to establish and maintain an LSID resolver in their own =
namespace. This
could for example be because the data set in question is likely to be =
moved to
a different home, or because the data provider cannot get permission to
register an LSID provider with DNS, or because the data provider's host
institution has restrictive rules on firewall access.<br>
<br>
Under these circumstances a data provider may still wish to be able to =
assign
LSIDs to each data record and to have the LSID resolve correctly to the
appropriate data and metadata.<br>
<br>
Some options:<o:p></o:p></span></font></p>

<h5><b><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>1.
Central hosting of data/metadata<o:p></o:p></span></font></b></h5>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><font size=3D3
face=3D"Times New Roman"><span lang=3DEN-GB =
style=3D'font-size:12.0pt'>The simplest
option technically (or at least simplest with respect to the assignment =
of
LSIDs) may be for the <strong><b><font face=3D"Times New Roman">central =
LSID
registration authority</font></b></strong> actually to host the data =
sets in
question on behalf of the data provider. <o:p></o:p></span></font></p>

<h5><b><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>2.
Central proxy LSID resolver<o:p></o:p></span></font></b></h5>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><font size=3D3
face=3D"Times New Roman"><span lang=3DEN-GB =
style=3D'font-size:12.0pt'>If the data
provider is able to establish an LSID resolver but is unable or =
unwilling to
register this resolver with DNS, a <strong><b><font face=3D"Times New =
Roman">central
LSID registration authority</font></b></strong> might establish a proxy =
LSID
resolver, which redirects to the known location of the actual LSID =
resolver. In
other words, assuming that the central LSID registration authority has =
an LSID
resolver registered for <strong><b><font face=3D"Times New =
Roman">clra.org</font></b></strong>
and running on lsid.clra.org, and the data provider has established its =
own
unregistered LSID resolver on lsid.dp.org, the data provider can issue =
LSIDs of
the form <strong><b><font face=3D"Times New =
Roman">urn:lsid:clra.org:&lt;<a
href=3D"http://wiki.gbif.org/guidwiki/wikka.php?wakka=3DDatasetName/edit"=

title=3D"Create this page">DatasetName</a>&gt;:&lt;<a
href=3D"http://wiki.gbif.org/guidwiki/wikka.php?wakka=3DRecordId/edit"
title=3D"Create this page">RecordId</a>&gt;</font></b></strong>. =
Requests for
data or metadata will be directed to lsid.clra.org, which resolves =
&lt;<a
href=3D"http://wiki.gbif.org/guidwiki/wikka.php?wakka=3DDataSetName/edit"=

title=3D"Create this page">DataSetName</a>&gt; to be associated with the
unregistered LSID resolver on lsid.dp.org, and directs the request to
lsid.dp.org for resolution.<br>
<br>
This again should be relatively simple to implement, and could be of use =
in
some circumstances. The data provider and the central LSID registration
authority clearly need to coordinate the elements included in the LSID =
string.<o:p></o:p></span></font></p>

<h5><b><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>3.
Central LSID resolver with non-LSID proxy =
resolution<o:p></o:p></span></font></b></h5>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
lang=3DEN-GB
style=3D'font-size:12.0pt'>Slightly more complex (and potentially with =
too many
uncertainties), a data provider could register a provider tool using =
some other
protocol (e.g. TAPIR) and rely on an external proxy LSID resolver to map =
LSID
requests to the appropriate protocol. For example, assume that a TAPIR =
provider
is set up on tapir.dp.org to serve data in some version of <st1:City =
w:st=3D"on">darwin</st1:City>
core which includes a &lt;<st1:City w:st=3D"on"><st1:place =
w:st=3D"on">darwin</st1:place></st1:City>:lsid&gt;
element. The records in the TAPIR provider are all set up to include =
values for
this element of the form <strong><b><font face=3D"Times New =
Roman">urn:lsid:clra.org:&lt;<a
href=3D"http://wiki.gbif.org/guidwiki/wikka.php?wakka=3DDatasetName/edit"=

title=3D"Create this page">DatasetName</a>&gt;:&lt;<a
href=3D"http://wiki.gbif.org/guidwiki/wikka.php?wakka=3DRecordId/edit"
title=3D"Create this page">RecordId</a>&gt;</font></b></strong>. =
Requests for
data or metadata will be directed to lsid.clra.org, which resolves =
&lt;<a
href=3D"http://wiki.gbif.org/guidwiki/wikka.php?wakka=3DDataSetName/edit"=

title=3D"Create this page">DataSetName</a>&gt; to be associated with the =
TAPIR
provider on tapir.dp.org, issues an appropriate TAPIR request for the =
record
with the appropriate value for &lt;darwin:lsid&gt; and then formats the =
data or
metadata appropriately for an LSID response.<br>
<br>
This is again not complex to implement, but requires even more =
coordination
than with option 2. It could however be applicable in any case in which =
a data
provider has any mechanism for sharing their data online, regardless of =
what
additional firewall restrictions are in =
place.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
lang=3DEN-GB
style=3D'font-size:12.0pt'><br>
This is doubtless not a complete set of options, but should be enough to =
begin
discussion. So, do you see value in considering any of these options as =
part of
the infrastructure we plan to adopt. It may of course be that any and =
all of
these can be used transparently within any LSID-based network, but we =
should
consider whether there are immediate benefits in offering some kind of =
central
service (through TDWG, GBIF or others) for these =
purposes.<o:p></o:p></span></font></p>

</div>

</body>

</html>


More information about the tdwg-tag mailing list