[Open-bio-l] RE: seqfeature

[Hilmar Lapp]

Sure it makes sense, but as I just wrote the heavier you rely on ontologies instead of defined attributes, the less useful the schema becomes as an API. It certainly is more flexible then, and of course then everyone can decide him/herself how to store what, but on the downside then two 'biosql-compliant' database instances don't need to be compatible at all, which is a nightmare from a re-usable application (or application/backend-separation) point of view.

Where do you draw the line between explicitely putting an attribute, and deferring to a qualifier /value association (in the extreme case, you get rid of all attributes except PKs and FKs)? If you need it at least 50% of the time? Why not 30%? Or 70%? Some (maybe many) RDBMSs are actually smart enough to not waste disk-space for NULL-valued attributes (if wasting disk-space is your concern).

I'm just trying to say that an API is more useful the more explicit it is. You can define a standard ontology for everyone to adopt, but that may not be so easy. Also, you may argue biosql shouldn't be something any application should use as an API; they'd rather use XML. But wasn't part of the reason for the exercise also to be able to enable applications that work off a standard db interface? I just thought that it was.

	-hilmar
-- 
-------------------------------------------------------------
Hilmar Lapp                            email: lapp@gnf.org
GNF, San Diego, Ca. 92121              phone: +1-858-812-1757
-------------------------------------------------------------



> -----Original Message-----
> From: Thomas Down [mailto:td2@sanger.ac.uk]
> Sent: Wednesday, May 01, 2002 3:10 PM
> To: Hilmar Lapp
> Cc: gmod-devel@lists.sourceforge.net; OBDA BioSQL (E-mail)
> Subject: Re: [Open-bio-l] RE: seqfeature
> 
> 
> On Wed, May 01, 2002 at 10:58:42AM -0700, Hilmar Lapp wrote:
> > I guess I should have said seqfeature (and there is a 
> StrandedFeature or something in BioJava isn't there?). Also, 
> I cared much more about the frame, which is absent too. 
> Wouldn't you want to know the frame for a translation feature?
> 
> Yes, frame is kind-of useful occasionally, if you're dealing
> with partial CDS.  It's also, of course, important if you're
> writing an ensembl-style `gene builder'.  My point was that
> for an everything other than coding exons (or DNA-protein 
> alignment results, which amount to almost the same thing), it
> seems to be a meaningless concept.  Perhaps I misunderstood
> your original post, but it sounded as though you wanted frame
> added as an extra column somewhere in the schema.  I just think
> it should be an optional property (in the qualifier_value table)
> for those types of feature where it's meaningful.
> 
> Does this make sense?
> 
>      Thomas.
> 
> 
> PS.  BioJava also allows you to represent features with
>      frames, when necesary (the FramedFeature interface).
> 
>