No subject

invisible to users, so it doesn't much matter.  However, from a third
party developer's point of view LSIDs are nicer because they use SOAP and
WSDL and other web service techniques to announce what sort of services
each LSID provides, and you can get the information via a SOAP call. If
we're only concerned about creating a system which SEEK coders plug into,
this isn't a big deal.  If we're interested in other people perhaps
building clients to access SEEK data, the web service abilities of LSIDs
would be nice.

> > It is probably more important to investigate what mechanisms
> > there are to register and maintain the records associated
> > with the GUIDs. Especially in a distributed environment. Who
> > owns the records and how can database migrations etc be
> > facilitated (e.g. all records pointing to a particular
> > location need to be changed). Also how do the systems deal
> > with missing destinations? Can they be redirected to
> > something useful and generate a notice that something needs fixing?

Good questions!  Here are some answers:

1.  Registering and maintaining records associated with GUIDS

In both systems, the actual data associated with the GUIDs lives in a
database which lies outside the system itself.  The Handle System
basically redirects to a URL, but what happens when you get to that URL is
beyond the scope of the handle system.  The same is true for the LSID
system.  It gives the ability to locate and ask questions about how to
learn more about an LSID, but the records pointed to by that LSID are
maintained outside the LSID system.

Here's a bit more detail on the registration and maintanence of the GUIDs
themselves:

	a.  The Handle System
		There's a GUI for modifying, adding and deleting.
		It has good built in authentication, with users and groups
		and the ability to assign add, delete and modify rights to
		Handles.  This tool can be distributed to anyone we want.
		It also allows batch entry, modification and deletion of
		handles

	b.  LSIDs
		Registering and maintaining the records devolves to
		maintaining the underlying database, which is outside the 
		LSID system.  Just like with any distributed database
		project, we'd have to write software to allow access to
		the database

2.  Who owns the records and how can database migrations be facilitated

The ownership of the records pointed to by the GUIDs is outside these
systems.  It really depends on what we implement.  The ownership of the
GUIDs themselves is sort of like above.  With the handle system, you can
batch modify all your handles using a big text file.  With the LSID
system, we'd have to write something to give people the same ability.  

3.  How do the systems deal with missing destinations - can they be
redirected to something useful and generate a notice?

The code for both systems is open so this could be easily added to both.

=====

I'll add sensible responses to failed handle requests, and I'll try to
speed up the registration process by tying it more closely with the
underlying database.  

Seems like there's lots of support for the handle system.  Anyone feeling
like supporting LSIDs?

Dave.