[MOBY-dev] Migration of database to new API

[Mark Wilkinson]

Hi all, 

As we move toward deploying the new API, there are some serious
consequences on the underlying databases.

Let me first re-cap the new API features that I am discussing and what
effects they have on the databases:

1)  Inheritence from primitives through ISA relationships is no longer
allowed.  e.g. plain-text ISA String  is no longer allowed.  To achieve
the same result, you now create an object that inherits from Object and
contains the primitive.  e.g. plain-text ISA Object; plain-text HASA
String.

2)  All service inputs and outputs must now be named (articleName)

------

For case 1, I have written a migration script that does the following:

a)  identifies every object that inherits directly from a primitive
b)  creates a new object called OldObjectName_v2 that inherits from
Object and contains that primitive type through a HASA relationship,
with the contained articleName being the same as the original object
name.  e.g. plain-text  ISA String  results in a new object
plain_text_v2 ISA Object; plain_text_v2 HASA String(plain_text)
c)  updates the description of the original object such that the
description now reads "DEPRECATED - use plain_text_v2 instead"

This is in the Database folder of the CVS.

At present, this script only goes down one level of the object
hierarchy, and does not explicitly deprecate, nor create new object
types for, any children of now deprecated objects, nor for any objects
that contain a deprecated object  Q1:  Should it do so ...or is this
going to create mass confusion for people?   Q2:  How long should the
deprecation period be before we refuse to support the old objects any
longer?  My feeling is that it should be quite limited... e.g. 2 months.
If you can't update your service to use a new object type within two
months, then it gets removed from the registry.  I updated all ~20 of my
services in about 5 minutes, so that gives you a sense of how much
effort it is...

--------

For case 2, I have not yet written a script.  I am loathe to change
people's service registrations at all!  I would prefer that people
update their RDF signatures and let the agent update their service
registration (once we get the agent running - this has been postponed
*yet again* in order to bring our service signature model in sync with
the one that we just jointly developed with myGrid last month).  What
concerns me is that this might require a lot of hand-editing from those
who have hundreds of services registered (e.g. soaplab), so...??  Would
it be preferable for me to script this and just attach arbitrary names
to your inputs/outputs in the database?


This is going to be a painful API change no matter how we play it, but I
want to be sure that we all know what the changes are going to be and
have agreed on the path of least pain before we begin the process.  

It's all for the best!  Honestly!

Mark


-- 
"Ontologists do it with the edges!"

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