search

ESIPFed / sweet

Official repository for Semantic Web for Earth and Environmental Terminology (SWEET) Ontologies
Other
117 stars 33 forks source link

Add an ontology editors/style guide #46

Open cmungall opened 7 years ago

cmungall commented 7 years ago

You have great docs for making issues/PRs etc: https://github.com/ESIPFed/sweet/blob/master/CONTRIBUTING.md

There are some implicit assumptions here. Some may seem obvious. E.g. if I create a class in module foo, my URI should be ...foo#MyClassName. The class name should be camel case to comply with existing sweet conventions.

Some may be less obvious. What if I want to add a synonym: should I do this as an annotation :MyClass :hasSynonym "my synonym"? Or equivalence axiom? Presumably the latter to abide by SWEET conventions.

If I submit a batch of classes without definitions, will they be accepted?

How should I record the fact that I contributed as metadata? Should I use my ORCID? Which annotation property.

Should editors use a reasoner? Which one? Should inferred axioms be asserted? When should an existential restriction be used over a subclass between named classes? Etc.

An example of an editors guide for an OBO: http://go-ontology.readthedocs.io/

This may seem overly strict. We force all editors to use the same version of Protege, have the same plugins installed, have the same new entities configuration, etc. This may not be appropriate for SWEET. You can have a much more free for all attitude - but in this case I recommend being extra rigorous with logical and lint tests in your .travis.yml

graybeal commented 7 years ago

I like being exposed to all these best practices, thanks for that. Though I suspect SWEET may not be at that level of community sophistication or control, as you are mentioning.

One quibble: Please do not use # as the delimiter. This forces W3C-html-specs-compliant servers to provide the whole ontology and the browser to download it all and then figure out where the term in question is. Very slow and very hard to make interoperable with the usual content resolution standards.

Slash (/) as the delimiter avoids this problem (and is more readable IMHO).

dr-shorthair commented 7 years ago

I’m not quite so hard line on this (# separator).

If the items are designed to be used individually, then allow them to be accessed individually - which # does not. And don’t use # if the resource is part of a set of more than 100 items.

But I often use # URIs in the context of a small ontology, with the argument that elements of an ontology should be understood in context.

graybeal commented 7 years ago

Yes, good observation. My urge is driven by my repository service roots, which wishes for one-size-fits-all, elegant, feature-rich service solutions. But of course the truth is there will be # paths forever and they will also have to be supported.

carueda commented 7 years ago

Just entered #48 as I think this particular aspect of slash vs. hash deserves its own entry for further discussion and resolution.

cmungall commented 7 years ago

If changes in the URIs are on the table, would use of meaning-free numeric identifiers a la OBO also be under consideration.

Meaningful URIs with CamelCase etc are definitely useful for schema-type ontologies but there are arguments to be made for use of semantic-free IDs for knowledge ontologies.

dr-shorthair commented 7 years ago

I would lean towards the status quo (meaningful URIs) partly because it is the status quo - no need to be disruptive if there isn't an overwhelming reason. Legacy SWEET always ran this way, and though it is anglo-centric, given the baseline it won't be hard to keep going.

brandonnodnarb commented 7 years ago

+1 @dr-shorthair re: status quo on meaningful URIs. Can make the CamelCase terms hashes (for example) if and when it becomes untenable.

rduerr commented 5 years ago

OK, this is way overdue. In other words, I have definitions to add, places where I’d like SWEET to directly reference an ENVO term and its definition. The whole contributor thing also needs to be worked out... Any possibility of just cutting and pasting at least those sections of the OBO guidelines (which I admit I haven’t read but just having a pattern to follow is fine for me)...

cmungall commented 5 years ago

My personal preference is to track provenance at the axiom level. Thus a single class may have a definition from a DOI, a synonym from ENVO, a comment from an ORCID, etc.

I should warn you that axiom annotations are very verbose in RDF. It doesn't bother us so much as ontology developers work at the level of Protege and developers work at the level of the OWLAPI, so YMMV. If SWEET ontology developers and consumers work more at the RDF level (either ttl, or any other RDF-level serialization) then you'll find axiom annotation tedious.

As a pragmatic compromise, if your main use case is tracking provenance of definitions only, you can just use a normal triple at the level of the class, some OBOs do this, they use 'definition source' as the property. See: https://github.com/information-artifact-ontology/ontology-metadata/issues/43

If you later decide you need per-axiom provenance, you can do a one time transform of these.

See also https://github.com/information-artifact-ontology/ontology-metadata/issues/43