[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