[MOBY-dev] a question and a comment about the new Objectinheritance

Thu May 26 15:04:17 UTC 2005

Benjamin Good wrote:

> Hi Yan,
>
> You make many good points (despite your anti-Java vibe!). The reason 
> that we suggest keeping the primitives in their somewhat strange 
> location within the object ontology is to provide the opportunity for 
> low level services to be discovered in the same manner as all the 
> other services. For example, say we want to post a service that does 
> arithmetic operations or String concatenations or something. If we use 
> the suggested approach, such services can be discovered using exactly 
> the same mechanism that all other services can be discovered. If on 
> the other hand we completely separate these primitives from the 
> ontology, we will have to invent new discovery protocols for handling 
> this use case.
>
> You are right, this is a strange beast of an ontology. Its principal 
> purpose is to describe the nature of being a data-type. As such, 
> including descriptions of what it means to be a primitive piece of a 
> data-type does not seem wrong. I think that when we start using a more 
> typical ontology in addition to this one, whose purpose is to describe 
> the nature of the information represented by these data-types, the 
> distinction will be more clear and the real utility of the Object 
> ontology will be made less ambiguous.
>
> -Ben
>
>
> On May 26, 2005, at 4:19 AM, Yan Wong wrote:
>
>> mark wilkinson wrote:
>>
>>> Good idea!
>>> The reason they weren't implemented initially was simple lack of need.
>>>
>>> M
>>>
>>> -----Original Message-----
>>> From: Benjamin Good <bmg at sfu.ca>
>>> Date: Wed, 25 May 2005 21:03:12 To:Core developer announcements 
>>> <moby-dev at portal.open-bio.org>, markw at illuminae.com
>>> Cc:mobydev <moby-dev at biomoby.org>
>>> Subject: Re: [MOBY-dev] a question and a comment about the new Object
>>> inheritance
>>>
>>> It might actually make sense to implement a few more primitives to 
>>> facilitate WSDL interoperability. Below see a set of standard 
>>> primitives from the Axis user-guide. (Primitives being the things in 
>>> the xml message that easily bind to existing Java classes). I wasn't 
>>> around when you picked the ones you did, so maybe there are reasons 
>>> not to include all of these?
>>>
>>> Standard mappings from WSDL to Java
>>> xsd:base64Binary -> byte[]
>>> xsd:boolean -> boolean
>>> xsd:byte -> byte
>>> xsd:dateTime -> java.util.Calendar
>>> xsd:decimal -> java.math.BigDecimal
>>> xsd:double -> double
>>> xsd:float -> float
>>> xsd:hexBinary -> byte[]
>>> xsd:int -> int
>>> xsd:integer -> java.math.BigInteger
>>> xsd:long -> long
>>> xsd:QName -> javax.xml.namespace.QName
>>> xsd:short -> short
>>> xsd:string -> java.lang.String
>>>
>>> -ben
>>>
>>>
>>>
>>> On May 25, 2005, at 12:32 PM, Mark Wilkinson wrote:
>>>
>>>
>>>> Hi all,
>>>>
>>>> So, I just went through and updated all of my services to follow 
>>>> the new
>>>> Object inheritance system. It took 5 minutes :-) Turns out that 
>>>> most of
>>>> my services only output "Object" anyway, so they don't need any work,
>>>> and the ones that output other things like DNASequence and GO_Term 
>>>> were
>>>> already following the proposed API anyway, so... only TWO of my 
>>>> services
>>>> actually were affected by the proposed change! I hope that others have
>>>> the same experience.
>>>>
>>>> I did, however, notice a potential hiccup that we didn't foresee at 
>>>> the
>>>> meeting. At the moment, binary data in MOBY is passed as a child of
>>>> base-64-encoded, which is a child of String. Under the new system, we
>>>> can't have children of String, so do we then need a new primitive 
>>>> class
>>>> for binary data? I think it still needs to be b64 encoded, but it 
>>>> seems
>>>> to me that it does need its own primitive now.
>>>>
>>>> opinions anyone?
>>>>
>>>> M
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> MOBY-dev mailing list
>>>> MOBY-dev at biomoby.org
>>>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>>>
>>>>
>>>>
>>> http://bioinfo.icapture.ubc.ca/bgood
>>> _______________________________________________
>>> MOBY-dev mailing list
>>> MOBY-dev at biomoby.org
>>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>>
>>> -- 
>>> Mark Wilkinson
>>> ...on the road!
>>> _______________________________________________
>>> MOBY-dev mailing list
>>> MOBY-dev at biomoby.org
>>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>>
>>>
>> Some remarks about Primitives and ontology:
>>
>> First: Do you think that <Integer>FF</Integer> is an integer???
>>
>> If you say no, then you are wrong because FF is a valid hexadecimal 
>> REPRESENTATION of an integer number: 255
>>
>> Reason: The client give the meaning for a message. Forany ordinary 
>> human who achieved child school FF is not an integer but for a 
>> computer IT CAN BE! Of course it is a bit extreme as an example. We 
>> all agree, by convention, that integers are written with Arab figures.
>>
>> In France (I don't know how it is in the rest of Europe) floating 
>> numbers are described as 3,1415 instead of 3.1415 (comma instead of 
>> point) In this case also, we agree by convention, that floating 
>> numbers use the american representation (integer part point 
>> fractional part etc..)
>>
>> Did you know that a Unicode string was inherited from a string ??? to 
>> display exotic but useful characters that does not exist in English 
>> (I don't speak of the strange french characters but also for spanish 
>> german etc..)!) and why not Bytes ??? after all a string is an array 
>> of bytes so bytes should be the actual primitive (String is an object 
>> has Byte) etc.. etc.. In java by default, all strings are unicode 
>> strings (AFAIK) but not all language adopted this convention.
>>
>> Primitives are computer related problems. I don't think it is wise to 
>> implement primitives inside the ontology because it is not in its place!
>>
>> Primitives were intended to solve problems of performance in language 
>> like Java (just see the superb mess between an Integer and an int 
>> both speaks about the same mathematical object everybody knows BUT 
>> for performance issues, it has been implemented this way poisoning 
>> life of millions software enginner and writers - you don't find that 
>> kind of issue in other languages -)
>>
>> As I understand from Moby and the ontology of Moby, we should not mix 
>> computer related problems with "Business logic" related problems.
>>
>> did you know that in ADA (for strict type checking and overflow 
>> control) you can actually subclass an integer in order to define the 
>> precision you want in your numbers and it doesn't violate (in any 
>> case) the object programming paragdim.
>>
>> For example:
>>
>> subtype Natural is Integer range 0.. Integer'Last;
>> subtype Positive is Integer range 1.. Integer'Last;
>> (I hope no one will have a heart attack on seeing these two lines :p)
>>
>> So if you want to know if an Integer is an integer CAST it (that what 
>> I do in Python (for the object mapping with bioMoby XML) ) for 
>> example with java use Integer.parse(etc) for Python use int(string) 
>> etc.. etc..
>>
>> These instructions tells the program that the content of the XML is 
>> an integer (according to your language convention)
>>
>> I think I have been clear and hope I didn't bash anyone too hard :p
>>
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev at biomoby.org
>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>
>>
> http://bioinfo.icapture.ubc.ca/bgood
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
>

I know that we must provide data type descriptions of a biological 
object. but the fact is that we must try to match the biological logic" 
as much as possible. Maybe one solution would be to link the "computer 
logic" (represented by datatypes) with the biological logic (represented 
by the ontology objects)

However putting all the "computer related" informations inside the 
ontology is not a good idea. The ontology should remain the most 
"biological" as possible.

There is another solution instead which I think is more elegant: 
Associate biological objects with computer data types.

For Example: a DNA Sequence is the biological object but FASTA, EMBL and 
all the fancy bioinformatic formats are its computer representation? .

So something like that could emerge: DNA Sequence associated with FASTA, 
EMBL, etc.. FASTA EMBL

FASTA, EMBL, GFF and so on would be in another ontology (more specific 
to bioinformatic/computers)

The idea is to clearly separate the "biological" logic and the "computer 
related" logic.

So as I see things, we have two ontologies representing two logics:
-The biologocial logic represented by the bioMoby ontology
-A data type logic which should be represented by a separated ontology 
with of course our "primitives String/Float/Bytes etc.."

A biological object of the ontology could be linked to a (or several) 
data types thus low level operations (or better computer related 
services/operations) could be discovered in the same way as biological 
services. We would have biological ontology<-> bioinformatic ontology 
relationships that would map the biological logic to the computer logic.

PS: The fact is I am not anti Java (as a language) after all, I used it 
every day since the Beta version (Oak for who can still remember the 
prehistoric details of Java :p who was designed to be a OS for your 
microwave oven ahahaha) However I still have a lot of frustrations on 
the java API because this stuff is a real nightmare and was the main 
drawback of Java for several years (try to implement a simple 
spreadsheet with Swing and you'll know what I mean all other GUI 
language beat Java 100% of the time. A dumber example: Do you remember 
what classes needed to open a file? I still need to copy paste my code 
pattern!)

And I like Java for its philosophy: Code once, execute many (even if 
people, most of the time, do Java programming for Windows 
(95/98/NT/2000/XP) Multi plateform ahahaha)