search

bionicjules / Lollipops

About an ontology combining biology, engineering and evolution
4 stars 0 forks source link

Steps to achieve conformity with Open Bio Ontologies #2

Closed cmungall closed 7 years ago

cmungall commented 8 years ago

Labels

Don't use CamelCase (e.g. SensingColor) or underscores (e.g. sensing_mode) [even if you don't want to conform with OBO, it's a good idea to have a consistent style throughout]

Labels such as 'FA' are opaque

These look like they come from chapter numbers:

Labels should be relatively context neutral. For example, 'secondary structure' is probably better as 'biopolymer secondary structure'

See http://obofoundry.org/principles/fp-012-naming-conventions.html

IDs/URIs

A lot of the URIs look odd, e.g. they have an '' or '*' at the end.

If you are interested in being part of OBO you would use PURLs (once the namespace request is accepted). See

http://obofoundry.org/principles/fp-003-uris.html

Definitions

Classes should have textual or logical definitions. Textual defs should use the IAO annotation property (not rdfs:comment)

BFO conformance

I personally think it is better not to use upper ontology than to use it incorrectly

For example, you have 'space', 'structure' and 'substance' under 'bfo:process', which is not correct

Reuse existing ontologies

Looks like you have created your own taxonomy. We recommend re-using a sub-modules of NCBITaxon

See http://obofoundry.org/principles/fp-005-delineated-content.html

There seems to be a problem with the reuse of uberon classes - you are retaining the fragment but including your own prefix. Also you have minted various new anatomical classes that are either in uberon or should be requested.

I think you're using some uberon classes incorrectly.

You have placed UBERON:0008276 ! plastron

under 'gas exchange organ'.

However, this class is actually the bony underside of a turtle. I think you mean insect plastron, which is totally different

Technical

I recommend importing BFO, not copying axioms into your ontology

Use Cases

I recommend describing uses of the ontology in the github repo

bionicjules commented 8 years ago

Many thanks for all this. I’ve inserted my comments below:

On 9 Jul 2016, at 20:25, Chris Mungall notifications@github.com<mailto:notifications@github.com> wrote:

Labels

Don't use CamelCase (e.g. SensingColor) or underscores (e.g. sensing_mode) [even if you don't want to conform with OBO, it's a good idea to have a consistent style throughout]

I’ve used ‘standard’ index-and-label where I could find another ontology which used a term, or where I was pretty sure none existed. Otherwise I agree it’s a mess, but I’d rather leave it like that until I can know which of the above alternatives will work. It would help if you could indicate (as you have done) which terms I’ve used are unavailable anywhere else. Then I can unify everything properly.

Labels such as 'FA' are opaque

Agreed! There were problems of definition, however. I’ve modified as best I can

These look like they come from chapter numbers:

They are for my own reference. Deleted.

Labels should be relatively context neutral. For example, 'secondary structure' is probably better as 'biopolymer secondary structure'

See http://obofoundry.org/principles/fp-012-naming-conventions.html

Again, my problem is that I don’t know whether definitions are available in other ontologies or references. Once I know one way or the other I can sort it all out. IDs/URIs

A lot of the URIs look odd, e.g. they have an '' or '*' at the end.

My own references. Removed for public consumption

If you are interested in being part of OBO you would use PURLs (once the namespace request is accepted). See

http://obofoundry.org/principles/fp-003-uris.html

Do I have to request the namespace? How? Definitions

Classes should have textual or logical definitions. Textual defs should use the IAO annotation property (not rdfs:comment)

I don’t understand IAO annotation property. BFO conformance

I personally think it is better not to use upper ontology than to use it incorrectly

For example, you have 'space', 'structure' and 'substance' under 'bfo:process', which is not correct

Again, these were shorthand terms for my own use. Removed. But I have a recurring problem with the inventive principles’ in that they make a variety of suggestions which can cut across each other and the BFO classification. I would rather keep things as they are (in the version I’ve modified in the light of your comments) since this is in conformity with the TRIZ system. If I start messing with TRIZ according to BFO edicts, I shall very probably end up with something which will be very difficult for engineers to use. I have tried to re-organise bits of the ‘inventive principles' onto BFO format and I couldn’t make the ontology work. Reuse existing ontologies

Looks like you have created your own taxonomy. We recommend re-using a sub-modules of NCBITaxon

See http://obofoundry.org/principles/fp-005-delineated-content.html

OK - I’ll have a go.

There seems to be a problem with the reuse of uberon classes - you are retaining the fragment but including your own prefix. Also you have minted various new anatomical classes that are either in uberon or should be requested.

I think you're using some uberon classes incorrectly.

You have placed UBERON:0008276http://purl.obolibrary.org/obo/UBERON_0008276 ! plastron

under 'gas exchange organ'.

However, this class is actually the bony underside of a turtle. I think you mean insect plastron, which is totally different

You are right - this means that the UBERON definition of ‘plastron’ should also be made more explicit, does it not? In fact I found a number of definitions in UBERON were rather less than accurate, mostly (of course) in my areas of expertise which are mainly biological materials and entomology. This may be the root of your comment about 'retaining the fragment'. Should I be recommending a change to UBERON? Technical

I recommend importing BFO, not copying axioms into your ontology

If I understand you correctly, I have to an extent mixed and matched a variety of BFOs, since I had difficulty deciding which was the standard (and I am using BFO2 as the main structure). The original BFO2 was imported in its entirety, but then seemed to be available in different forms . . . Please point out my commissions/omissions. Thanks Use Cases

I recommend describing uses of the ontology in the github repo

I have a paper in press which will clear up this point. It will be available in a couple of weeks or so.

Many thanks for all your trouble. I appreciate it.

Best wishes Julian

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://github.com/bionicjules/Lollipops/issues/2, or mute the threadhttps://github.com/notifications/unsubscribe/AHWxAX12VZdsCB0mlMfkW1gHSXQmRQb2ks5qT_XGgaJpZM4JIry0.

cmungall commented 8 years ago

On 10 Jul 2016, at 12:48, Julian Vincent wrote:

However, this class is actually the bony underside of a turtle. I think you mean insect plastron, which is totally different 

You are right - this means that the UBERON definition of ‘plastron’ should also be made more explicit, does it not?

It's fairly explicit: ""A composite bony plate forming the floor of the shell of a turtle consisting of fused dermal elements, including contributions from the clavicles (epiplastrons) and interclavice (epiplastron)"

(it strikes me from your previous comments that you may be using the term "definition" in an odd sense, perhaps meaning label?)

In fact I found a number of definitions in UBERON were rather less than accurate, mostly (of course) in my areas of expertise which are mainly biological materials and entomology. This may be the root of your comment about 'retaining the fragment'. Should I be recommending a change to UBERON? 

Absolutely! You can look up the tracker for any OBO on obofoundry.org. For uberon (which I develop) it is https://github.com/obophenotype/uberon/issues/new

We strive to make the definitions as accurate as possible. However, there may be a verbetrate bias in the naming conventions (hence "plastron" and not "dermal plastron", which is less ambiguous in a pan-metazoan sense). We're open to modifying these.

more on other comments later

bionicjules commented 8 years ago

Many thanks. Comments below:

However, this class is actually the bony underside of a turtle. I think you mean insect plastron, which is totally different

You are right - this means that the UBERON definition of ‘plastron’ should also be made more explicit, does it not?

It's fairly explicit: ""A composite bony plate forming the floor of the shell of a turtle consisting of fused dermal elements, including contributions from the clavicles (epiplastrons) and interclavice (epiplastron)”

Explicit, but not disambiguated. There should at least be a ‘seeAlso’ annotation to an insect plastron (I’ll check the original publications where this was first described for a better name). In which case the existing reference to a plastron should be modified to ‘reptilian plastron’ as a subclass of dermal bone. I’ll check through on some of the stuff relating to keratins as well. I seem to remember picking up a lack of separation between alpha and beta keratins. They are very different mechanically, chemically and phylogenetically. I suppose that the conformation of proteins is dealt with in the GO? What about self-assembly? That too?

(it strikes me from your previous comments that you may be using the term "definition" in an odd sense, perhaps meaning label?)

Not at all (I hope!). I’m using label as the route to an alternative display using names rather than reference numbers. Correct, no?

In fact I found a number of definitions in UBERON were rather less than accurate, mostly (of course) in my areas of expertise which are mainly biological materials and entomology. This may be the root of your comment about 'retaining the fragment'. Should I be recommending a change to UBERON?

Absolutely! You can look up the tracker for any OBO on obofoundry.orghttp://obofoundry.org. For uberon (which I develop) it is https://github.com/obophenotype/uberon/issues/new

We strive to make the definitions as accurate as possible. However, there may be a verbetrate bias in the naming conventions (hence "plastron" and not "dermal plastron", which is less ambiguous in a pan-metazoan sense). We're open to modifying these.

more on other comments later

— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/bionicjules/Lollipops/issues/2#issuecomment-231923034, or mute the threadhttps://github.com/notifications/unsubscribe/AHWxAfH_Ac3Dm78DVOdSnpeW6i4dZOkqks5qUv9sgaJpZM4JIry0.

cmungall commented 8 years ago

On 12 Jul 2016, at 1:19, Julian Vincent wrote:

You are right - this means that the UBERON definition of  ‘plastron’ should also be made more explicit, does it not? 

It's fairly explicit: ""A composite bony plate forming the floor of the  shell of a turtle consisting of fused dermal elements, including  contributions from the clavicles (epiplastrons) and interclavice  (epiplastron)” 

Explicit, but not disambiguated.

I would argue it is unambiguous.

There should at least be a ‘seeAlso’ annotation to an insect plastron (I’ll check the original publications where this was first described for a better name).

I think that is a reasonable request. But this doesn't pertain to the definition. It pertains to a potentially ambiguous label.

Note that we often include an explicit disjointness axiom between two classes that have a potential to be confused due to clashing nomenclature. This is stronger than a seeAlso annotation, and provides logical checks against confusion, as well as making the distinction clear to humans. However, there is no guarantee that this set of axioms is complete due to sheer number of homonyms across metazoan anatomy.

In which case the existing reference to a plastron should be modified to ‘reptilian plastron’ as a subclass of dermal bone.

Here you are talking about a proposed change in label - which is a good suggestion. But nothing to do with the definition.

I’ll check through on some of the stuff relating to keratins as well. I seem to remember picking up a lack of separation between alpha and beta keratins. They are very different mechanically, chemically and phylogenetically.  I suppose that the conformation of proteins is dealt with in the GO? What about self-assembly? That too? 

'keratin filament' is in GO, as would any assembly processes. keratin would be in PRO or in a database or protein families.

(it strikes me from your previous comments that you may be using the  term "definition" in an odd sense, perhaps meaning label?) 

Not at all (I hope!). I’m using label as the route to an alternative display using names rather than reference numbers. Correct, no? 

Yes, but I still feel we're at cross-purposes when talking about definitions.

cmungall commented 8 years ago

Don't use CamelCase (e.g. SensingColor) or underscores (e.g. sensing_mode) [even if you don't want to conform with OBO, it's a good idea to have a consistent style throughout]

I’ve used ‘standard’ index-and-label where I could find another ontology which used a term, or where I was pretty sure none existed. Otherwise I agree it’s a mess, but I’d rather leave it like that until I can know which of the above alternatives will work. It would help if you could indicate (as you have done) which terms I’ve used are unavailable anywhere else. Then I can unify everything properly.

I'm not sure I understand your response. My comment was about the conventions for your rdfs:labels. You are using camel case (i.e. no spaces, each word has a leading upper case). This is not the convention that's used in OBO. See http://obofoundry.org/principles/fp-012-naming-conventions.html

cmungall commented 8 years ago

I personally think it is better not to use upper ontology than to use it incorrectly For example, you have 'space', 'structure' and 'substance' under 'bfo:process', which is not correct

Again, these were shorthand terms for my own use. Removed. But I have a recurring problem with the inventive principles’ in that they make a variety of suggestions which can cut across each other and the BFO classification. I would rather keep things as they are (in the version I’ve modified in the light of your comments) since this is in conformity with the TRIZ system. If I start messing with TRIZ according to BFO edicts, I shall very probably end up with something which will be very difficult for engineers to use. I have tried to re-organise bits of the ‘inventive principles' onto BFO format and I couldn’t make the ontology work.

I'm not sure what inventive principles or TRIZ is. However, I'm not suggesting necessarily you should mess with anything. I'm suggesting it's better not to use BFO rather than use it incorrectly, at least at first. Once your intended semantics are clearer others can better suggest how and if it should be integrated into BFO.

bionicjules commented 8 years ago

I agree with your suggestion for the changes, but I’m fully employed just sorting out the taxonomy at present. When I find out what the current state w.r.t. OBO is with the camelCase examples you point out, I’ll change them to conform with whatever is necessary. As I say, it would help if you could point me towards relevant OBO ontologies or acceptable databases, or let me know if none exists. Thanks.

On 12 Jul 2016, at 21:56, Chris Mungall notifications@github.com wrote:

Don't use CamelCase (e.g. SensingColor) or underscores (e.g. sensing_mode) [even if you don't want to conform with OBO, it's a good idea to have a consistent style throughout]

I’ve used ‘standard’ index-and-label where I could find another ontology which used a term, or where I was pretty sure none existed. Otherwise I agree it’s a mess, but I’d rather leave it like that until I can know which of the above alternatives will work. It would help if you could indicate (as you have done) which terms I’ve used are unavailable anywhere else. Then I can unify everything properly.

I'm not sure I understand your response. My comment was about the conventions for your rdfs:labels. You are using camel case (i.e. no spaces, each word has a leading upper case). This is not the convention that's used in OBO. See http://obofoundry.org/principles/fp-012-naming-conventions.html http://obofoundry.org/principles/fp-012-naming-conventions.html — You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/bionicjules/Lollipops/issues/2#issuecomment-232178669, or mute the thread https://github.com/notifications/unsubscribe/AHWxAU84uOJxOd1m4nQOhAEpxO05umnPks5qU_-QgaJpZM4JIry0.

bionicjules commented 8 years ago

Thanks for the comment and advice. I definitely want to get this ontology into the OBO system. It may be that I’ll have a non-BFO ontology for engineers. Or I may find another way round whilst retaining conformity with BFO. I’m stating preferences, but all are subservient to getting conformity with the BFO principles. If BFO strong it will produce an improved version of what I’m trying to do, and the TRIZ system will find itself updated!

Cheers Julian

On 12 Jul 2016, at 21:59, Chris Mungall notifications@github.com wrote:

I personally think it is better not to use upper ontology than to use it incorrectly For example, you have 'space', 'structure' and 'substance' under 'bfo:process', which is not correct

Again, these were shorthand terms for my own use. Removed. But I have a recurring problem with the inventive principles’ in that they make a variety of suggestions which can cut across each other and the BFO classification. I would rather keep things as they are (in the version I’ve modified in the light of your comments) since this is in conformity with the TRIZ system. If I start messing with TRIZ according to BFO edicts, I shall very probably end up with something which will be very difficult for engineers to use. I have tried to re-organise bits of the ‘inventive principles' onto BFO format and I couldn’t make the ontology work.

I'm not sure what inventive principles or TRIZ is. However, I'm not suggesting necessarily you should mess with anything. I'm suggesting it's better not to use BFO rather than use it incorrectly, at least at first. Once your intended semantics are clearer others can better suggest how and if it should be integrated into BFO.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/bionicjules/Lollipops/issues/2#issuecomment-232179512, or mute the thread https://github.com/notifications/unsubscribe/AHWxAYurdaIPahaBzOUVTe2wJLgt8dKYks5qVABGgaJpZM4JIry0.