Re: [Treebase-devel] [Nexml-discuss] CDAO term inclusion community process

[Hilmar L. <hl...@du...>]

On Jun 5, 2009, at 3:53 AM, Rutger Vos wrote:

> You can see in the produced nexml that mesquite is also storing  
> internal object IDs to various predicates under the msq: namespace  
> prefix (i.e. msq:taxaUID,
> msq:taxonUID and msq:treeUID). Can we have something like these as
> properties in CDAO? The TreeBASE2 team has been sketching out some
> service queries which we would like to implement, and we want the
> search fields we expose be mediated by CDAO.

I think that's a good starting point but the way I'm thinking about  
this at present the "standard" context set (i.e., vocabulary) for  
PhyloWS finder queries would be informed by (and possibly directly  
import from) CDAO, but would not be CDAO itself but rather a separate  
compact vocabulary.

That's because CDAO (in my understanding) is an ontology meant to  
formalize our current knowledge about evolutionary substrates,  
processes, phenomena, and data, and how these relate to each other.  
That's different from a compact metadata vocabulary that people browse  
through to quickly identify the suitable term(s) for their query.  
PhyloWS needs the latter, but doesn't in fact need the former. (Though  
the data it returns will be better interpretable if it is  
comprehensively annotated with CDAO.)

Having said that, I don't think that diminishes in any way the need  
for a formal, documented, and agreed upon procedure for requesting  
CDAO term and relationship additions and modifications by the community.

> [...] Can we have something like that? I like Hilmar's suggestion of  
> being
> able to put it in a queue somewhere, but I would be very interested to
> see what Brandon comes up with for term suggestion interface -
> obviously it will be better for all involved if the term suggestion
> was as specific as possible, perhaps already fitted into CDAO's class
> hierarchy (as opposed to a rambling email like this one).


Note that this can be solved by conventions - in the end it is humans  
that need to look at this anyway, not machines. Almost all the OBO  
Foundry ontologies use the tracker system I believe, and there are  
quite a few of them, so there's some evidence that it can work.

Another example is Darwin Core, which uses the Google Code issue  
tracker and pre-defined templates (try to create a new issue and  
choose new term):
http://code.google.com/p/darwincore/wiki/SubmittingIssues

	-hilmar

-- 
===========================================================
: Hilmar Lapp  -:-  Durham, NC  -:- hlapp at duke dot edu :
===========================================================