From: Chris M. <cj...@fr...> - 2007-02-18 22:28:30
|
There a number of people wanting to add various relations to RO - many of these are definite candidates for inclusion, others may have problems conforming to the definitional standards to which the RO aspires, others may be redundant with existing relations. Rather than have these relation representations and their dependent ontologies and mappings wait in stasis, we should have a formal process of granting these relations provisional identifiers and some kind of status tag. This will help us both with the process of vetting the relations, and with sharing the resources on which the relation definitions depend. Normal OBO lifecycle policy can be applied for when and if these relations make their way into RO-proper; this policy covers splits, merges and obsoletions of definitions. If a provision relation gets promoted to RO without any major changes to its definitions, a new ID will be granted in the OBO_REL ID-space, and the provisional ID will act as a secondary ID, allowing automated promotion of representation using these IDs. If the provisional relation is replaced by a better- defined relation in RO, the provisional ID will be obsoleted, and a 'replaced_by' or 'consider' metadata tag will be attached to it, allowing for automated and semi-automated updates of representations that used the preliminary relation. This could be done in two ways: keep the provisional identifiers in RO-proper, but have the status marked in a computationally transparent way, such that these relations are clearly distinct from the heavily vetted relations have a distinct RO applications/supplemental ontology (RO-temp?) clearly distinct from RO-proper. This would also allow a more general umbrella ontology, incorporating both. I can take care of either implementation I would favour the latter. It should be made clear that inclusion in RO-temp is not necessarily indicative of lower quality, it is merely indicative of the fact that incorporation into RO-proper is a slow process. This could be implemented fairly quickly - it would also allow Larry and Mike to share their mappings in a more interoperable way, which would give us more concrete use cases for further discussion. |