[MOBY-dev] [moby] Re: Notice that the ever elusive agent will start curating in 2 weeks

[Mark Wilkinson]

I suppose I should wade in here, though Eddie is doing a great job of
making the case :-)

Here are my thoughts on the issue, in no particular order:

*  I would support the proposal to extend the duration over which the
agent "visits" but does not de-register.  Three months seems reasonable,
maybe longer if we discover problems.

*  The Agent idea has been the most protracted API change we have ever
had.  The "guts" of the API change were made almost a year ago, the
discussions about it have been going on for longer than that, and the
registry API has been behaving as if the agent were functional for at
least that long (e.g. not being able to deregister services that had a
Signature URL).  As such, the switch to an agent-based curation system
should not come as any surprise, and we should not over-react to it.
The changes are not that large given that the API as it exists has
already accommodated them, and primarily give us benefit more than they
cause barriers.

*  The move to an RDF signature-based system is an ENORMOUS benefit to
us - and we have all agreed on that in previous meetings.  It allows us,
as service providers, to add additional metadata about our services, and
perhaps more importantly, it forms the basis of the LSID resolution for
Service Instance LSID's (the service provider themselves becomes the
LSID resolution service by putting their signature RDF at the location
that they have registered in MOBY Central).

*  The "immediacy" of calls to MOBY Central should not (if I understand
Eddie's changes to the code) be affected.  If you want to register a
service, you can continue to use the registerService API call.  If you
want to deregister a service, you simply remove that service RDF
signature and it will be deregistered "passively".  To "actively" or
immediately deregister a service, simply remove the service RDF and call
"registerService" passing the SignatureURL.  This will invoke the agent
to immediately crawl to you, discover that the document is now gone, and
deregister your service.  This we maintain the immediacy of
registration/deregistration but gain the security that only you can
deregister your services.

*  The policy of the curation behaviour of the agent is not hard-coded.
Every registry curator can set their own policy in the agent
configuration file - individual registry curators may or may not chose
to deregister services, or to give more or less warning, or to run the
agent more or less often, as they see fit.

*  The policy of the MOBY Central registry at iCAPTURE is currently
being drawn-up.  A first draft is available (click on Project Docs on
the right side of the moby homepage) for comment.  Like any other public
resource, the host and curator of that resource must make appropriate
decisions that are both sustainable, and provide the maximum benefit to
their community given the resources available. As host and curator of
the iCAPTURE registry, I will set the policy of this instance of the
registry with that goal in mind.  Some may consider this being a
dictator, some may consider it being responsible.

*  I do not support "gradfathering", since this will require changes at
the code level, and in fact, behavioural changes in the API that would
have to be documented.  A three-month passive trial period for the Agent
sounds like a functionally equivalent but better alternative,
particularly since the move to RDF is essential and parallel to our
adoption of the LSID resolution system.

*  I disagree with having to code circumstantial exceptions into the
clients (e.g. ignoring localhost).  Not only would this exception have
to be coded into every client, but in those instances where "localhost"
was meaningful and useful (e.g. if you are using Taverna and you are
hosting a MOBY Central registry on your own hard drive that Taverna is
connecting to) that exception would have to be removed from the client
such that you could discover your own services... and moreover, by
removing that exception, you then begin to discover services that are
"localhost" to someone else's machine...  Individual registry hosts can
create their own policy on this, but it seems to me that the only
feasible way to deal with this problem is for clients to accept
localhost whenever they find it, but for registry hosts to determine
whether a localhost registration is appropriate in their registry.


Those are just the thoughts off the top of my head.  I need to drop out
of this discussion again for a while as I have a ton of essay marking to
do :-)  Darn students!  They do love to express themselves....

Cheers all!

Mark


-- 
--
...his last words were 'Hey guys!  Watch this!'
--
Mark Wilkinson
Asst. Professor
Dept. of Medical Genetics
University of British Columbia
PI in Bioinformatics
iCAPTURE Centre
St. Paul's Hospital
Rm. 166, 1081 Burrard St.
Vancouver, BC, V6Z 1Y6
tel: 604 682 2344 x62129
fax: 604 806 9274

"For most of this century we have viewed communications as a conduit, 
       a pipe between physical locations on the planet. 
What's happened now is that the conduit has become so big and interesting 
      that communication has become more than a conduit, 
       it has become a destination in its own right..."

                Paul Saffo - Director, Institute for the Future