dosumis
commented
6 years ago Hi Michael,
Rather a lot to take in here. A few quick comments:
-
The principle of identical 7 digit IDs Classes in SO and MSO that are connected by a "generically depends on" or "is concretized by" relation should have the exact same 7 digit ID number, just with different prefixes (SO vs MSO) to make programmatic IRI identification of counterparts much easier.
I would strongly advise not relying on this. The whole point of numeric IDs is that they are completely free of semantics. It's a heavy burden on maintenance to make sure IDs always line up. One ID in the wrong place can mess it up. If you merge or obsolete in one ontology you always have to do so in the other. There's a strong temptation to build software that relies on ID mapping & then you have the burden for ever. And you may decide that there are cases which are not 1:1 SO:MSO. I say all this as someone who's been burned by this in the past.
The mapping also doesn't make sense without equivalentTo axioms connecting SO and MSO. SubClassOf axioms will be true for all subclasses.
-
As most of the classification hierarchy of MSO and SO will be identical it is essential that you come up with patterns to infer classification in one from classification in the other (for all relevant classes). Without this, they'll inevitably go out of sync.
-
The patterns you've outlined look reasonable. I don't have much time to chat about abstract/upper-ontology modelling, but could potentially help a bit to make sure the patterns you want do useful work in automating classification. Do you have any draft equivalent Class axioms? It might help to build a toy ontology which has examples of terms defined with the various patterns you outline above + some relevant imports. You could then use a reasoner (Elk is probably best) to test classification.
msinclair2
mikebada
@dosumis
In discussion with @keilbeck, we realized that there will be some classes in both the SO and MSO that will have no counterpart in the other ontology. For example, in the MSO, there will be some sequence molecules that either contain no information or for which the information is not yet known. In the SO, there will be some arbitrary artifacts that are not easy to associate with discrete sequence molecules or regions of molecules, such as assemblies and contigs. It won't be possible, then, to generate one ontology from the other in toto, though it should be possible to generate the majority of classes of one ontology from the other. @mikebada has already done a lot of work creating an independent MSO that is BFO-compliant, that integrates with ChEBI, and that annotates what the counterpart for each class is in the SO if known. And he has done so largely using logical axioms, rather than named classes, relying on the reasoner to classify the taxonomy; that implies a design pattern we can extract. I need to discuss this more in detail with him.
Most(all?) of the entities in SO are information entities. In BFO terms, they are generically dependent continuants. SO has 4 top-level classes, all of which would fall under BFO's generically dependent continuant (I think).
One of these, "sequence_attribute", are "attributes describing a quality of sequence". These are abstract qualities of sequence entities. They inhere in specific qualities of specific molecules described in the MSO. The relation between a generically dependent continuant, like the standard text of a novel, and a specifically dependent continuant, like the color of the ink it's printed in in a particular copy of the book, is "is concretized by". I think this relation would hold between sequence_attributes in SO and qualities in MSO. So I'm ready to sketch out a first design pattern:
The other three top level classes of SO (sequence_collection, sequence_feature, and sequence_variant) describe the information (e.g. recognition sites, reference genomes) that inhere in actual sequence molecules as independent continuants in MSO. An anology would be the standard text of a novel and a book, or the print in a book, capable of bearing that text. We can describe now a second design pattern, which will cover the majority of SO and MSO classes:
Some SO classes describe the recognition sites of boundaries between regions. In this case, these SO classes would inhere rather in boundary entities, which are "immaterial entities in BFO. So we have yet another pattern:
From these the majority of classes that should belong to BFO will be generated from SO. We need further a way to infer from SO the key annotations (such as rdfs:label and definition) for a minimally sufficient class definition for the MSO classes. These patterns will also tell us what upper level BFO or ChEBI class the MSO classes are subclasses of, to begin reconstructing the taxonomy of MSO.
A fourth design pattern, to complete the full taxonomic reconstruction of MSO, can in consultation with @mikebada be extracted from the work he has already done.
There will need to be two additional templates:
Generating the subontology of classes that exist only in MSO with no relation to any SO class, and
Generating the subontology of classes that exist only in SO with no relation to any MSO class.
An additional design principle we have adopted for convenience is:
The principle of identical 7 digit IDs Classes in SO and MSO that are connected by a "generically depends on" or "is concretized by" relation should have the exact same 7 digit ID number, just with different prefixes (SO vs MSO) to make programmatic IRI identification of counterparts much easier.
For the addition of future terms:
Any time a new term in SO is added that requires generic dependence on some bearer, an MSO counterpart term with the same 7-digit ID but different namespace must be generated at the same time, and its precise place in the MSO taxonomy decided upon. On the other hand, the only time a new MSO term should be created independently of SO is when some molecular feature with no known genomic annotation or informational importance is discovered and needs to be described.
I am new to this discussion, and have not been in the loop of all the earlier conversations in the community about this project and what the community wants and needs for practical purposes. I value all feedback not just on the theoretical aspects of design templates, and what steps to take next, but also the practical aspects of fulfilling what the community needs and not including superfluous features.