Align ontology metadata with fields used in other ontology portals

[cmungall]

We should try and use the same IRIs for our metadata properties as is used in other ontology portals such as the ontoportal family (bioportal; @graybeal, agroportal; @jonquet). Where we cannot re-use, there should be mappings between the properties.

Recall that OBO curates some ontology metadata centrally (in the frontmatter/md files, as key-val pairs), and this is converted to json-ld/turtle via scripts in this repo (where we can choose which IRIs to use).

Ontologies also include metadata in their OWL (to varying degrees of completeness; and we have carrot/stick abilities via dashboard here). Where these overlap the values should be the same for the central metadata as for that which is in the ontology.

See also:

• 824 Align with widoco

[bpeters42]

I thought going beyond sharing IRIs, and having a more formal specification including a reference implementation and validation. Simple things such as that contact emails should be emails, links should resolve, clarifying what elements are mandatory. The OBO registry will likely be more strict in their implementation, but I am sure we can agree on a subset of minimal standards below which it makes no sense to capture ontology metadata at all.

[cmungall]

Agreed. I think doing this in ShEx makes sense

On Mon, Dec 9, 2019, 15:36 bpeters42 notifications@github.com wrote:

I thought going beyond sharing IRIs, and having a more formal specification including a reference implementation and validation. Simple things such as that contact emails should be emails, links should resolve, clarifying what elements are mandatory. The OBO registry will likely be more strict in their implementation, but I am sure we can agree on a subset of minimal standards below which it makes no sense to capture ontology metadata at all.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/OBOFoundry/OBOFoundry.github.io/issues/1087?email_source=notifications&email_token=AAAMMONW5IHWH22G6EAFZELQX3I7FA5CNFSM4JYRKOZKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGLCYPY#issuecomment-563489855, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAMMOJPLLTU4MNMQPMIT6TQX3I7FANCNFSM4JYRKOZA .

[jonquet]

Hello, our work on ontology metadata in AgroPortal is extensively described here: https://link.springer.com/article/10.1007/s13740-018-0091-5

We are still working on MOD1.4 here: https://github.com/sifrproject/MOD-Ontology Hopefully this could converge toward a tentative agreement btw ontology repositories to describe metadata.

Independently of the common model, our philosophy is "flexible in inputs, unified in outputs" : AgroPortal now recognizes 346 properties from 23 existing metadata vocabularies that could be used to describe different aspects of ontologies. We use them to populate an internal model of 127 properties implemented in the portal and harmonized for all the ontologies. None of these are mandatory of course.

Our curator edit the metadata manually ... e.g., http://agroportal.lirmm.fr/ontologies/ENVO Then the idea is to use the "Get my metadata back" button for a developer to export the metadata (following a specific profile... e.g., Schema.org, DCAT... profiles not implemented yet) and put it where he/she believe its important... possibly in the original ontology file, for further use of the file by other repository or semantic tool will get the metadata then.

For the OBO Foundry ontologies http://agroportal.lirmm.fr/ontologies?filter=OBO-FOUNDRY We use the YAML file to get some metadata. But we have not yet written a wrapper to do it automatically (althought its planned). The list of metadata we now is : http://obofoundry.github.io/registry/context.jsonld

OK to help to the mapping to AgroPortal/BioPortal and MOD if a document (table) is created somewhere.

And we also want to plug-in a SHACL validation that will verify the presence of a few metadata and structural checks before parsing in AgroPortal.

[nlharris]

This seems like a worthwhile but non-trivial endeavor. Not clear anyone has the bandwidth to work on this yet. (@cmungall maybe this could be something BioPortal could investigate in the future?)

[graybeal]

Non-trivial is an appropriate word. A likely path forward from BioPortal's perspective is that the OntoPortal Alliance will settle on a (MOD-based) default set of attributes that are supported, and a consistent means for managing metadata in all the OntoPortal deployments.

Whether that extends to the extensive pre-processing and curation-based approach that Clement outlines above, and whether BioPortal is able to deploy an extensive metadata solution at scale, are things that will have to be sorted over time, and may not impact OBO Foundry in any case.

I think the principal question is what attributes should each repository to understand? IMHO, understanding the entire default set of OntoPortal-supported attributes, but maybe actively managing/presenting to users only a small subset of them, is appropriate for every repository.

I could imagine the OntoPortal Alliance and anyone else interested 'co-hosting' a workshop and maybe hackathon to work through this, someday.

[cmungall]

I think it's actually pretty easy from OBO's perspective, we have a small set of fields

[nlharris]

Ok, then who could be assigned to work on this?