[MOBY-l] SADI and CardioSHARE relative to Re: BioXSD... 8 years later...

Dmitry Repchevsky dmitry.repchevski at bsc.es
Wed Jun 17 07:19:33 UTC 2009


>
> ... Unless we have universal agreement on data-types... which I guess is what BioXSD  
> is trying to achieve... good luck to them!

> In MOBY we do allow inheritence of has and has-a objects within a Moby object.  This situation  
> cannot (sensibly) be represented in XML Schema.
Don't understand here... In XML schema "has"/"hasa" are represented as 
elements within a complex type. Such a type has a name and a schema 
type, you can substitute it by a child element... maybe I just don't 
understand your statement...

> My understanding from Eddie is that there are a  
> couple of Moby objects that cannot be represented in XML Schema without  
> breaking the rules of Schema, so there is a bit of a limitation there.
>   
So far I have converted whole inab ontology tree without any issues... :-)

> Does your XML Schema mapping allow me to send more complex objects into a  
> service that claims to consume only parent-type objects?
That's not the schema itself. Such an object should be casted without a 
problem by JAXB...

here is just an example from "Moby Schema":

<xs:complexType name="GenericSequence">
  <xs:complexContent>
    <xs:extension base="VirtualSequence">
      <xs:sequence>
        <xs:element name="SequenceString" type="ns1:NemusString" 
minOccurs="0"/>
      </xs:sequence>
    </xs:extension>
  </xs:complexContent>
</xs:complexType>

Because in XML tag encoding (using schema) is done using element name 
(not the type), the resulting object for say:
<xs:element name="sequence" type="ns1:AminoAcidSequence" 
form="qualified" minOccurs="0"/>
would be:
<sequence>
  <Length id="" namespace="">11</Length>
  <SequenceString id="" namespace="">ATCATCATCAT</SequenceString>
</sequence>
if we substitute AminoAcidSequence with say AnnotatedAminoacidSequece 
there will be some additional tags, but in a time of decoding we will 
lose it...

If you want your service provide a support to both AminoAcidSequence AND 
NucleotideSequence there is a possibility to use "SeeAlso" Tag.
Actually this tag can be put onto the father so in ontology compile time 
all parents would know their children explicitly.

There is a possibility (I did it once) in JAXB to inject a custom 
classloader. Such a classloader can DYNAMICALLY obtain the needed 
information (for example from registry), generate java code, compile it 
(java6 allows it) and load on-the-fly. This way there is no need in 
compiled ontology at all...

> you cannot predict the structure of the incoming XML...
>   
I prefer JAXB developers to break their heads with it :D

> I think we are starting to get close to a VERY simple solution to OWL/RDF based Web Services, and a registry model.
Being software engineer I'm twice skeptical... ;-) do you have more 
technical information? I seen some of these slides in your presentation 
last Falls.

By the way, even before doing "MobyXSD" (contrary to BioXSD ;-) ) I 
discussed a lot with Jose Maria about OWL2. I tried to generate "MobyOWL2".
There is no problem in it, apart that in Moby Ontology plenty of classes 
(MobyObjects) share the names with their attributes ("has"/"hasa"). This 
is absolutely
forbidden  in OWL... apart of those "problematic" object I was able not 
only to create it, but work with it in Protege! The message that i'ts 
possible to keep the ontology in OWL and use XSD as a serialization 
level for the services. Using dynamic compilation trick it's possible to 
transparently generate appropriate java objects... just some thoughts...

Best regards,

Dmitry.

P.S. I'm working on adding moby-async services support to my proxy. The 
idea is to use WSA-Addressing, So if a client provides a callback the 
service works asynchronously, if not, as usual.

http://inb.bsc.es/documents/java/nemus/index.html
http://inb.bsc.es/documents/java/nemus/executor/wsdl_executor.html






More information about the moby-l mailing list