evoinfo / cdao Goto Github PK

See http://www.obofoundry.org/ontology/cdao.html

@balhoff @arlin @epontell @rvosa if you don't mind could you take a moment and check the state and files in this repo for whether it is a faithful migration of the CDAO repository on SourceForge?

In the past CDAO used the release date (as YYYY-MM-DD) for constructing a prefix for owl:versionIRI. There are some problems with that pattern (such as being bare of any compatibility semantics), and there is semantic versioning that is increasingly widely adopted for software.

See thread on obo-discuss for fuller explanation and (hopefully) ensuing discussion.

In theory this should have been fixed in 0245c85, but apparently the following was missed. This is what ROBOT reports:

OWL 2 DL Profile Report: Ontology and imports closure NOT in profile. The following violations are present:
Use of non-simple property in a restriction: ObjectMinCardinality(1 <http://purl.obolibrary.org/obo/CDAO_0000194> <http://purl.obolibrary.org/obo/CDAO_0000006>) [SubClassOf(<http://purl.obolibrary.org/obo/CDAO_0000140> ObjectMinCardinality(1 <http://purl.obolibrary.org/obo/CDAO_0000194> <http://purl.obolibrary.org/obo/CDAO_0000006>)) in OntologyID(OntologyIRI(<http://purl.obolibrary.org/obo/cdao.owl>) VersionIRI(<http://purl.obolibrary.org/obo/cdao/2013-02-01/cdao.owl>))]
Use of non-simple property in a restriction: ObjectMinCardinality(1 <http://purl.obolibrary.org/obo/CDAO_0000194> <http://purl.obolibrary.org/obo/CDAO_0000012>) [SubClassOf(<http://purl.obolibrary.org/obo/CDAO_0000026> ObjectMinCardinality(1 <http://purl.obolibrary.org/obo/CDAO_0000194> <http://purl.obolibrary.org/obo/CDAO_0000012>)) in OntologyID(OntologyIRI(<http://purl.obolibrary.org/obo/cdao.owl>) VersionIRI(<http://purl.obolibrary.org/obo/cdao/2013-02-01/cdao.owl>))]

The v1.0 version of CDAO used term IRIs that were constructed from (semi) human-readable labels. In the course of migrating these to OBO-style opaque term IRIs (see 2012-06-06 release) the term identifier hash-suffixes were converted to labels using CamelCase.

These labels should be normalized to separate words by spaces, dashes, or other applicable delimiter, and with appropriate upper/lower case. (See #10 – addressing #2 – as an example.)

Such a change should not obsolete any term, since the semantics of the corresponding terms is not changing at all.

Otherwise, any paraphyletic clade would by implication also be a monophyletic clade, which is false. (See https://en.wikipedia.org/wiki/Paraphyly, for example.)

Yet, the current version of CDAO asserts this. @arlin do you recall why that choice was made?

Originally there was a README, but it didn't get carried over to the subversion line of history, and was never added back in there.

It can probably be seeded from bd696d5 (the first commit), which is unchanged in version 1.0.

The development history of CDAO up until and including v1.0 (http://www.evolutionaryontology.org/cdao/1.0/cdao.owl) (the version originally published) has remained in a CVS repository on SourceForge.net.

The earliest release published under the purl.obolibrary.org URI is essentially that v1.0 version, so I wanted to see whether we can preserve the history of that somehow.

I've now managed to migrate the CVS revision history of the v1.0 release to Git (using git cvsimport and cvsps v2.1 compiled from source). I've pushed up the results here as sf-cvs-trunk, sf-cvs-arlin, and sf-cvs-Enrico_May. The sf-cvs-trunk branch presents a continuous history from 2008-2011 and is what one might consider as the "main trunk" in CVS or master in Git parlance. sf-cvs-arlin seemed to have ended very early on. sf-cvs-Enrico_May contains a significant amount of early history that isn't obviously redundant with the main trunk (using solely commit log messages) but ends years prior to the main trunk; it may have been a tag?

Ideally I would want a continuous history from the beginning to now. That would require grafting the master branch onto the head of sf-cvs-trunk. I could try doing that but the changes would be so drastic that on the level of each file there wouldn't be any continuity worth speaking of. The only exception may be cdao.owl, but that file changed location (from OWL/cdao.owl to the repo root directory).

Thoughts on the merits of this and which CVS migration results (the branches enumerated above) to keep around and which ones not to are welcome.

Tagging @arlin, @epontell, @rvosa (and @bchisham - can't identify the Github user corresponding to F. Prosdocimi).

This issue is motivated by achieving conformance with the OBO dashboard. In the near future, lack of conformance with the dashboard checks will impact an ontology's listing on the OBO homepage.

One of the failures is usage of an object property (part_of) with the same label as one found in RO. OBO ontologies should reuse RO properties whenever possible. In this case, CDAO actually contains another property stated to be equivalent to part_of: belongs_to. This situation isn't really encouraged either.

So I propose that we deprecate part_of, and rewrite any axioms using that property to instead use belongs_to. This should all be logically equivalent. Down the road we can remove the equivalence statement. This plan of action resolves the name conflict with RO, and simplifies the equivalent property situation. Farther down the road we could choose to adopt appropriate RO properties directly.

I created 4 tags (to be promoted to release tags) for the history of CDAO releases:

• cdao-rel-2013-02-01
• cdao-rel-2012-06-06
• cdao-rel-2012-04-12
• cdao-rel-1.0

Once I promote them to releases I can't delete them anymore, hence @balhoff @epontell @arlin could you please review for accuracy etc and give 👍 or 👎 ?

BTW I notice that URLs and commit SHA1s in the tag's comments aren't hyperlinked in the per-tag pages linked to above. They are, however, in the list of tags; simply click the ... dots to expand the description.

The sort-of (at least formerly) official homepage for CDAO at http://www.evolutionaryontology.org remains hosted at Sourceforge, where it is very difficult to maintain and update it. (As a consequence, some of the links, including to CDAO itself, are badly outdated.)

Originally requested by @bendmorrris on CDAO-discuss:

A few of us discussed this briefly at iEvoBio; it would be great to have a concept similar to "has_Root", but for unrooted trees. Some tree formats, such as Newick, represent rooted and unrooted trees identically - an unrooted tree has a "pseudo-root" and is represented the same way as a rooted tree. The position of this pseudo-root is completely arbitrary. If a Newick tree is converted to CDAO and then back to Newick, the resulting tree may appear to be "rooted" differently than the original. While this is technically fine (since it's unrooted, it shouldn't matter where the "pseudo-root" is placed), it may be confusing or irritating to users. Having a property cdao:has_PseudoRoot would ensure that the tree could be retrieved from a triple store and converted back to a Newick tree without changing the position of the pseudo-root - so users would get back a tree that they could easily verify was identical to what they started with.

Currently I'm using has_Root for unrooted trees; this is certainly incorrect, as the pseudo-root is not a root. It's important to distinguish between a true root and what's merely a starting point for convenience but has no real meaning.

See thread on CDAO-discuss for responses.

has_Node (and its subproperties, has_Parent_Node and has_Child_Node) are designed for representing the relationship between an edge and a node. This may be a little confusing with has_Parent and has_Child, which represents the relationship between two nodes in a phylogeny. It might be useful to rename has_Node/has_Parent_Node/has_Child_Node to something that make it clearer that they relate to edges, and are not intended to create sets of things like the similarly named has_Element -- for example, users might expect SetOfNodes to be defined by has_Node rather than has_Element.

There's a term in the ontology for JukesKantor -- the proper spelling would be JukesCantor.

Originally posted to the Sf.net bug tracker by @bomeara