[moby] Re: [MOBY-dev] Migration of database to new API

Thu Oct 6 21:39:45 UTC 2005

It's not just that, it's also the "spirit" of the matter.  e.g. our
LSID's are based on the name of the object.  Granted, we currently only
return metadata, so we could in principle re-define the object without
breaking the LSID standard, but it does break the "spirit" of the
identifier.

But having said that, I don't particularly care one way or the other.
It's painful no matter what we do.

1)  If we change to _2, deprecate the old ones, and after 6 weeks delete
the old, leaving the _2's in their place then:
	a)  people who are affected will have to update their servces
	b)  people will have to re-register their services

2)  If we change to _2 temporarily, deprecate, delete, and then rename
the _2's back again after 6 weeks:
	a)  people affected will have to either 
		i) update their services, re-register, then
		ii) update their services again and re-register
	OR
		i) update their services and NOT re-register, and
		ii) their services will be "illegal" for 6 weeks,

There's no painless way to do this, so whatever the community feels is
best...

M

On Thu, 2005-10-06 at 13:55 -0700, Edward Kawas wrote:
> Hi,
> 
> I am working on this script right now as we speak, but I
> just wanted to get feedback (for a second time).
> 
> >From what I understand, I am going to go through the
> ontology, and deprecate any data type that inherits from a
> primitive. Any object that I deprecate will be duplicated
> and have an _2 appended to its name as well as having its
> ISA relationship set to object and adding a HASA primitive
> relationship. So far so good.
> 
> In six weeks, I am going to go through the ontology and
> remove all objects that inherit from a primitive, leaving
> those that were duplicated with an _2 alone. Therefore, in 6
> weeks, we will have objects like text-plain_2, text-xml_2,
> etc.
> 
> I know that some people are fine with this and others are
> not. Some might not even care. However, what I want to know
> is what MOBYers think and if anyone has any other
> comments/suggestions. So please let me know.
> 
> Just to get this started, I am still pretty iffy about
> leaving x_2 data types in the ontology. I do see Marks point
> on how services that are not updated choking since they
> expect the data type to inherit from a primitive. Any ideas?
> 
> Thanks,
> 
> Eddie
> 
> > -----Original Message-----
> > From: Mark Wilkinson [mailto:markw at illuminae.com]
> > Sent: Thursday, October 06, 2005 9:08 AM
> > To: Core developer announcements
> > Cc: Eddie Kawas
> > Subject: Re: [moby] Re: [MOBY-dev] Migration of database
> > to new API
> > 
> > As you have noticed, the change has already happened at
> > the code level
> > just to prevent any more registrations of what will soon
> > be illegal
> > objects.  I have a script that will update the database
> > records of the
> > ontologies and deprecate the old nodes, but we haven't yet
> > run it on the
> > public registry.  Eddie is going to make a couple of
> > changes to it over
> > the next day or two, and then will send out a heads-up
> > that the
> > ontologies are changing forever, and a tutorial on how to
> > do the update
> > for service providers.  We'll give a reasonable amount of
> > time for
> > people to update their services (say, 6 weeks) and then we
> > will delete
> > the old nodes from the ontology completely.  The script is
> > in the CVS so
> > anyone running a registry can do the same thing.
> > 
> > When I went to update my own services it took me less than
> > 5 minutes to
> > do so, so 6 weeks should be more than enough time for
> > anyone who is
> > actively concerned about their service :-)
> > 
> > Cheers!
> > 
> > M
> > 
> > 
> > 
> > On Thu, 2005-10-06 at 17:32 +0200, Pieter Neerincx wrote:
> > > On 27-Aug-2005, at 12:20 AM, Mark Wilkinson wrote:
> > >
> > > > 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.
> > >
> > > Hi Mark et al.,
> > >
> > > Any idea when this change will happen? If I look in the
> > Central that
> > > is running the latest and greatest codebase, the
> > forbidden ISA [some
> > > primitive] relationships are still in place :(. What is
> > even worse is
> > > that the primitive DateTime ISA String. As a result I
> > can not get one
> > > of my Objects (that plays by the rules of the latest
> > specs)
> > > registered. At least I suspect this to be the problem. I
> > don't get an
> > > error message when register my object, but it has
> > amongst others a
> > > HASA DataTime and that relationship is not getting
> > registered...
> > >
> > > Cheers,
> > >
> > > Pi
> > >
> > >
> > >
> > >
> > > Wageningen University and Research centre (WUR)
> > > Laboratory of Bioinformatics
> > > Transitorium (building 312) room 1034
> > > Dreijenlaan 3
> > > 6703 HA Wageningen
> > > The Netherlands
> > > phone: 0317-483 060
> > > fax: 0317-483 584
> > > mobile: 06-143 66 783
> > > pieter.neerincx at wur.nl
> > >
> > >
> > >
> > > _______________________________________________
> > > MOBY-dev mailing list
> > > MOBY-dev at biomoby.org
> > > http://www.biomoby.org/mailman/listinfo/moby-dev
> > --
> > "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
> 
-- 
"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