Augment available metadata for various models

[jvendetti]

Context

In order to accomplish various pieces of work for the BioPortal U24 grant, we need to incorporate more metadata for some of the models in this library. Some examples:

• Allow users to add their GitHub usernames so that we can generate better issue content for ontology change requests
• Add a language attribute for ontologies so that we can offer more intelligent sorting and/or usability metrics

In addition, Mark Musen expressed a desire to move towards the ability to say that BioPortal is compliant with a metadata standard. Should this be MOD?

See Also

• upgrade metadata handling in BioPortal bioportal-project#106
• Add ontology language bioportal-project#304
• Implement ontology usability scores bioportal-project#296
• Add GitHub username and ORCID iD as attributes on the User model #160

[jonquet]

Adopting MOD would be perfect. Now MOD is developed within FAIR-IMPACT and the version 3 that will be properly an extension of DCAT2 will be published soon.

In 2017 we worked in MOD1.2 then 1.4 in parallel. See: https://hal-lirmm.ccsd.cnrs.fr/lirmm-01852080
Any new properties added to the model were taken from MOD1.4 but for the properties (the one BioPortal already provided) were not changed for backward compatibility.

Now I have no problem to say that we are "compliant with MOD" because we have a property field that is 85% (to be verified) the one "sugegsted" by MOD and we have a property for each of the 128 properties MOD suggest. But if you do call our service, the JSON-LD returned is not fully pure MOD.

We are currently revisiting this to be able to change our metadata exports and have them respect multiple profiles: DCAT/DC, Schema.org, Datacite, ... and MOD3.
The profile that will return the maximum number of properties (hence the maximum level of details/information for an ontology) will both be the "AgroPortal default" and the MOD one.

If all OntoPortal move to MOD2 (or 3) and assume a non backward compatibility change, then yes, we should go for MOD. But ... if MOD change again we are goiung to change our backend each time... so I am more building on the exports mechanism now.

[jvendetti]

@jonquet - based on your comments above, I find the "Versions" section of the MOD README.md file confusing. It lists MOD 1.4 as the stable version, characterizes 2.0 as "alpha", and 2.1 as "under discussion". But above you're talking about verson 3.

What version is considered the latest stable version?

Given limited developer resources, the idea of having to maintain backward compatibility is less appealing to me, though we've not discussed this internally.

[jonquet]

You're right.. originally v3 being prepared by/with @agbeltran was called v2.1. Now we call it v3.

The main difference between v1.4 and v2 is the model (v2 was the first version based on DCAT, v3 will be more stable for this aspect) and the re-adoption of many properties within the mod namespace.

Properties will not change between v2 and v3. So you're good looking into v2.