[Biojava-dev] Re: Flyweight Ontologies?

Matthew Pocock matthew_pocock at yahoo.co.uk
Thu Nov 6 06:27:45 EST 2003


This all sounds good, particularly IDs for all singletons, and 
particularly if there's an easy way to implement it without lots of 
special case code each time.

I think the LSID people would point out at this point that LSIDs should 
be permanent, and immutable, always resolving to the same (or 
equivalent) entity. If we substitute URN for LSID, then I'm happy - 
urn:biojava: or something - I think we're meant to use urn:x-biojava as 
we've not registered the biojava namespace.

Matthew

Schreiber, Mark wrote:

>I think this can be fixed using LSIDs in the same way they turned out to be useful for serialization of Alphabets and Symbols. There would also need to be a registry of Terms, Triples and Ontologies.
>
>Serialization would then be simple. Bundle everything up and distribute it over RMI or what ever. When it gets to the other end it asks the registry on the new JVM if it has objects corresponding to the LSID's. If it does it reconnects to them, if not it deserializes it's ontology payload and registers it. For efficiency you could define ontologies that the other JVM is expected to have an only serialize a placeholder reference and not the whole ontology. The biojava core ontology would be an example. Similar to the WellKnownAtomicSymbols. 
>
>To make this work The Ontology, Term and Triple interfaces should extend Indentifiable so they have a getIdentifier() method. LSIDs will need to be in the core.ontology file. It would be nice if you could identify the parent triple or ontlogy of a Term from the LSID although this may not be possible.
>
>This leads to something of more general interest. I would like to propose that everything in biojava that is singleton or flyweight should implement Identifiable and be registered (ulitmately) with a central LSID registry. For example the getAlphabet and registerAlphabet functions of AlphabetManager would actually access parts of the LSID registry where all this stuff would get stored. Obviously there is some API breakage here but I think the benefits are great now that people are starting to use biojava in a distributed setting more often.
>
>Any thoughts?
>
>- Mark
>
>
>  
>
>>-----Original Message-----
>>From: Matthew Pocock [mailto:matthew_pocock at yahoo.co.uk] 
>>Sent: Thursday, 6 November 2003 1:57 a.m.
>>To: Schreiber, Mark
>>Cc: biojava-dev at biojava.org
>>Subject: Re: Flyweight Ontologies?
>>
>>
>>Oh dear. I can see this being a world of pain. I think ontologies and 
>>terms and triples should be flyweighted in the same spirit that 
>>alphabets and symbols are. However, I was going to defer the book 
>>keeping code untill the reasoner was working so that we could 
>>write it 
>>mainly in the ontology language. Grrr. Perhaps we need stable IDs?
>>
>>Matthew
>>
>>Schreiber, Mark wrote:
>>
>>    
>>
>>>Hi -
>>>
>>>Just looking at some serialization bug fixes and I have a question 
>>>about Ontologies. Should they be flyweight objects?
>>>
>>>The reason I ask is Ontology.Impl is serializable but 
>>>      
>>>
>>doesn't attempt 
>>    
>>
>>>to prevent deep copying. However the Term.Impl equals() 
>>>      
>>>
>>methods asks if the two Ontologies are canonical with an == operator.
>>    
>>
>>>One of these needs to be changed.
>>>
>>>- Mark
>>>
>>>
>>> 
>>>
>>>      
>>>
>>
>>    
>>
>=======================================================================
>Attention: The information contained in this message and/or attachments
>from AgResearch Limited is intended only for the persons or entities
>to which it is addressed and may contain confidential and/or privileged
>material. Any review, retransmission, dissemination or other use of, or
>taking of any action in reliance upon, this information by persons or
>entities other than the intended recipients is prohibited by AgResearch
>Limited. If you have received this message in error, please notify the
>sender immediately.
>=======================================================================
>
>  
>




More information about the biojava-dev mailing list