[seek-dev] Re: metacatiness

[dave thau]

>Finally, I think it would be good to use LSIDs directly in metacat, so
>that EML documents themselves might contain LSID identifiers.  Could you
>comment on what would be needed to make an LSID server be shipped as a
>standard part of a metacat db to resolve identifiers for objects that
>might be stored in that metacat?

Well, the java code for the lsid server is open source and the license
seems to let you redistribute and alter to your heart's content so I don't
think there are any limitations there - although I'm no lawyer so don't
sue me if I'm wrong.

The code is pretty straight-forward, and runs in tomcat like metacat, so
there shouldn't be a problem including the LSID code as a second servlet
running under tomcat (see also problem area #3).

I can think of four problematic areas and one far-fetched caveat:

Problem area 1:  Assigning the lsids.

You've mentioned a translation

sev.13703.1 -> urn:lsid:blah.org:sev:13703:1

This is fine as long as the strings sev, 13703 and 1 are guaranteed to
contain no periods (probably) or colons (maybe?)

Problem area 2: Configuring the SRV record in DNS.

I think I can handle all the configuration issues with some clever ant
tricks.  If ant isn't used to configure the metacat database when it's
shipped, whatever configuration tool you use will have to be tweaked to
install the LSID stuff too.  The only thing that I don't think can be
handled via automatic configuration is adding the SRV record into the
appropriate DNS file.  Whoever installs metacat would have to do that by
hand to make the LSIDs public.

Problem area 3:  The LSID stuff has to run in tomcat context "authority."

The LSID stuff would have to run as a separate servlet with context
"authority".  See section 13.2.2.2 of the LSID specification if you want
to know why.  It looks like this might be changible if it's a problem, so
if it is let me know and I can look into changing it.  My instinct is that
it would be unwise to mess with it.

Problem area 4:  Already existing LSID authorities.

Because of problem areas #1 and #3, someone with an already set up LSID
authority might have problems. They might have to run one authority on a
separate port, or on a different machine.  This would involve some
configuration by hand.  If we went with a translation like one of these:

sev.13703.1 -> urn:lsid:blah.org:metacat:sev.13703.1
sev.13703.1 -> urn:lsid:blah.org:metacat:sev.13703:1

It'd be easier to automatically reconfigure an already existing LSID server.

Far-fetched caveat: Using arbitrary namespaces.

In this translation:

sev.13703.1 -> urn:lsid:blah.org:sev:13703:1

you're creating an arbitrary(?) namespace based on the metacat name.  This
is fine except in the following situation.  Let's say somebody wants to
use their lsid authority for non-metacat purposes.  They could do that by
changing one of the LSID configuration files to say that "things with
namespace foo should not be handled by the metacat code, but should
instead be handled by these java classes."  The only caveat is that they'd
have to make sure that no metacat record uses the namespace they use for
non-metacat purposes.

Ok, I think that's about it.  I'm completely unfamiliar with the metacat
code, so there may be something in there which may cause problems.  If you
have any suspicions let me know and I'll look into it.

Dave