[MOBY-dev] [moby] Re: Cleaning up the Object ontology - Inheriting from base Object

Pieter Neerincx Pieter.Neerincx at wur.nl
Fri Feb 24 12:00:13 UTC 2006


On 21-Feb-2006, at 9:33 AM, Martin Senger wrote:

>> Could we find common ground if we made an API change that resulted  
>> in the
>> Namespace ontology being hierarchical rather than flat?  If I  
>> understand
>> the problem you are trying to solve, this would make a significant
>> difference - but would it make *enough* difference that you  
>> wouldn't have
>> to create more specific types of simple Objects?
>>
>    Honestly, I do not know. I even do not fully understand your
> "combinatorial explosion", and - mainly - why it would not happen  
> with a
> hierarchy and inheritance within namespaces?

I'm with Martin again here. I do see how what Martin and I want could  
be done with namespaces instead, but I fail to see how this prevents  
the problem Mark described here:

> Object
>    DatabaseObject
>        GenbankObject
>           GenbankSequence
>              GenbankDNASequence
>              GenbankAASequence
>        EMBLObject
>           EMBLSequence
>              EMBLDNASequence
>              EMBLAASequence
>        PDBObject
>           PDBSequence
>
> etc. etc.  From the Rectorian ontology-philosophy, this is a perfect
> example of the "exploding bicycle", and the end result is well
> documented and disasterous!  Even in that example, there would be  
> no way
> to discover a Blast service that operated on GenericSequence  
> objects if
> you had a GenbankDNASequence object in-hand.

What are the relationships in the example above? Would it be possible  
to do the following:

Object
    DatabaseObject ISA Object
        GenbankObject ISA DatabaseObject
           HASA GenbankSequence
              HASA GenbankDNASequence ISA GenericSequence
              HASA GenbankAASequence ISA GenericSequence
        EMBLObject
           EMBLSequence
              EMBLDNASequence
              EMBLAASequence
        PDBObject
           PDBSequence

That would still not be an elegant object structure, but it's  
difficult to make sure people don't register clumsy object structures  
or create yet another redundant object for something that's already  
there. I don't see how using a less flat namespace ontology would   
prevent that, because in that case I could register:

Namespace
    DatabaseNS
        GenbankNS
           GenbankSequenceNS
              GenbankDNASequenceNS
              GenbankAASequenceNS
        EMBL_NS
           EMBLSequenceNS
              EMBLDNASequenceNS
              EMBLAASequenceNS
        PDB_NS
           PDBSequenceNS

In that case if a service is registered to take a GenericSequence  
object as input, but it's limited to the GenbankDNASequenceNS  
namepsace, you still won't be able to use it if GenbankDNASequenceNS  
wasn't registered to be 'ISA GenericSequenceNS'.

I'm a bit confused here....

Pi

> That would also mean that we
> would have two trees, one (roughly speaking) describing syntax  
> (data type
> tree) and one describing semantics (namapsce tree). That would not  
> be easy
> to explain, maintain and use...
>    I am tempted to say that I wuold still use data types to express  
> how a
> reality is related, and I would use namespaces as an additional
> information - where I would welcome less flat alternative.
>
>    Martin
>
> -- 
> Martin Senger
>    email: martin.senger at gmail.com
>    skype: martinsenger
> consulting for:
>    International Rice Research Institute
>    Biometrics and Bioinformatics Unit
>    DAPO BOX 7777, Metro Manila
>    Philippines, phone: +63-2-580-5600 (ext.2324)
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://biomoby.org/mailman/listinfo/moby-dev


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






More information about the MOBY-dev mailing list