Implementation of the OMTD wrapper proxy with OMTD-Share format

[jonquet]

This task will see the implementation within AgroPortal REST API of a specific Web service that will list the ontologies of AgroPortal following OMTD-SHARE format. The service will be accessible at the following URL: http://services.agroportal.lirmm.fr/ontologies?format=omtd-share

and will return contain a XML or JSON document similar to the examples here: https://openminted.github.io/releases/omtd-share/3.0.1-SNAPSHOT/examples/ontologiesTerm.zip

[twktheainur]

• General NCBO proxy architecture set-up
• Handler module for OMTD-Share metadata set-up
• OMTD-Share XSD mapped to java classes through the JAXB framework (transparent marshalling and unmarshalling). The java classes are materialised from the XSD files at each compilation with the main jaxb2 plugin
• Human-readable serialization in XML (text/xml) generated properly
• In progress: Mapping Json properties to the appropriate java classes of the OMTD-Share JAXB model

[jonquet]

Similarly, we will need to deal with the other REST calls:

/ontologies/ACRONYM?format=omtd-share /ontologies/ACRONYM/submissions/XX?format=omtd-share /ontologies/ACRONYM/latest_submission?format=omtd-share /submissions?format=omtd-share

Actually, the services that need to be consumed to produce a complete OMTD-share format are the ones returning the submission information (which embed the ontology object). Therefore:

The wrapper needs to intercept /submissions and /ontologies/ACRONYM/submissions/ to transform the JSON into OMTD-share format. And rerout /ontologies to /submissions

[twktheainur]

Concerning the implementation of the mappings

Beyond a mapping between a single OMTDShare and a list of *Portal properties with a fallback strategy that correspond to a few cases, the XSD schema is often more complex and the mapping includes conditional statements on specific values (e.g. public or contactPoint).

Consequently, merely writing a flat file with simple property mappings is insufficient to fully specify the mapping in the implementation, which means part of the logic specific to some elements will be encoded in code while the name of the properties will be defined externally. This violates the locality of the code and will be a hinderance to maintainability. Therefore, the best solution is to put everything in the code and make it very readable and easy to modify rather than mixing a mapping file with hard-coded logic. The alternative is to define a complete file format to specify the mapping, where, for each type of OMTDShare tag (simple xs:element, complex xs:complexType, or a combination of xs:ComplexType and xs: sequence) one can map a set of properties from *Portal or fixed values. For each portal property or combination of portal properties, one should be able to define complex conditions, which would need to be expressed in a custom context-free grammar. The latter solution is more generic, but would require a very significant development time, while the benefits in terms of maintainability would be minimal compared to the all code solution.

[twktheainur]

Issues concerning specific mappings (see comments in the google drive sheet document):

• ms:resourceShortName is the XSD specification also defined to be equal to the acronym
• ms:contactPoint: When homepage or documentation are absent and there are several contacts, we can only put one email address. Proposed heuristic: email address of the first contact
• license in bioportal: The inclusion of licensing information is not present in their linked-data model, they add the licenses ad hoc on a case-by-case basis, when someone makes a request on their support mailing list.
  • ms:resourceIdentifier: For some ontologies, URI/identifier are not valide values, for example, for CO_325, the URI property equals http://purl.obolibrary.org/obo/TEMP.owl, which is obviously incorrect
  • ms:language: IETFBP47 does authorise 2/3 letter codes from the various ISO standards, which is what lexvo uses
  • ms:contactPerson/ms:contactGroup: We have no way of knowing if a contact is a group or a person in Agroportal or Bioportal, unless we build a list of groups/organization manually that we can then use to decide which is which. I am implementing all contacts as persons for now. Similarly, the OMTDShare model separates surname and given name, while in *portal the full name is stored in one field. There is no easy way to know which is which. In the meantime I am putting the full name under surname

Other issues are likely to arise as I progress through the implementation of all the mappings

[twktheainur]

@jonquet @antool Implementation is now complete in commit 699e478. Deployed on stageportal for testing. Supports the following URLs:

/ontologies/ACRONYM?format=omtd-share //goes to latest_submission /ontologies/ACRONYM/submissions/XX?format=omtd-share /ontologies/ACRONYM/latest_submission?format=omtd-share /submissions?format=omtd-share //Downloads submissions.zip, one ACRONYM.xml file per ontology /ontologies?format=omtd-share //Downloads ontologies.zip, one ACRONYM.xml file per ontology

Please test and give me the green light to migrate to production.

[jonquet]

For testing per ontology: http://services.stageportal.lirmm.fr/ontologies/MDRFRE?format=omtd-share http://services.stageportal.lirmm.fr/ontologies/MDRFRE/submissions/1?format=omtd-share http://services.stageportal.lirmm.fr/ontologies/MDRFRE/latest_submission?format=omtd-share

For testing for all: http://services.stageportal.lirmm.fr/submissions?format=omtd-share http://services.stageportal.lirmm.fr/ontologies?format=omtd-share

For testing parameter transfer http://services.stageportal.lirmm.fr/ontologies/MDRFRE/submissions/1display_links=false&display_context=false

[twktheainur]

Now in production, commit 5e8844d

[jonquet]

A few working examples:

• All ontologies http://services.agroportal.lirmm.fr/ontologies/?format=omtd-share

• One ontology http://services.agroportal.lirmm.fr/ontologies/FOODON/?format=omtd-share