[Treebase-devel] CDAO term inclusion community process

[Rutger V. <rv...@in...>]

Hi,

I've done enough experimentation to establish the correct syntax for
attaching valid RDFa attachments to nexml so that standard RDFa
extractors can turn <meta/> elements - the new dictionaries - into RDF
triples. I've implemented this in the java and perl APIs (Jeet: I hope
that the examples I've mailed out give you enough of a template to do
this in python too, but please let me know of I can help - I know that
the wiki needs updating, for starters).

The key issue now is the definition of predicates, i.e. the value of
the @property and @rel attributes. Over the course of many EvoInfo
discussions it's been decided that CDAO will be the principal artifact
for their mediation - so what's the community process for inclusion of
new predicates?

Val and I have sketched out a couple of TreeBASE services whose search
keys should be part of a controlled vocabulary (things like tree.id,
tree.label, etc.), and this is just one use case of a project having a
potentially large number of predicates (other example: Mesquite).

It would be great if team CDAO could tell us where to send our list of
proposed terms and where we can download an amended version of CDAO
that includes them :-)

I note that there is a wiki page about this
(https://www.nescent.org/wg_evoinfo/CDAO_term_request), but ideally
there would be some sort of issue tracker with structured input fields
(e.g. subject/predicate/object name="XXX", suggested superclass="YYY",
suggested datatype(s)="ZZZ", description="..."). Behind this tracker
would be a team of curators that will promptly pick up a posted issue
and work towards a solution.

I realize that this involves a support commitment from team CDAO, but
I think that's what we agreed to over free-form key/value pairs,
homegrown vocabularies or a BioMoby-like free-for-all.

Any comments?

Rutger

-- 
Dr. Rutger A. Vos
Department of zoology
University of British Columbia
http://www.nexml.org
http://rutgervos.blogspot.com