Re: [Treebase-devel] [PhyloWS] PhyloWS, CQL, NeXML on TreeBASE2

[Rutger V. <rut...@gm...>]

> You aren't trying to suggest that dcterms.title or dcterms.identifier should
> mean different things for different finders, right?

I kind of am: in find/study, dcterms.identifier is a study ID, in
find/tree, dcterms.identifier is a tree ID. Internally, the finders
traverse a CQL parse tree and translate these predicates into more
refined subproperties (tb.identifier.study and tb.identifier.tree,
respectively). In other words, if a tree is the subject, then the
predicate dcterms.identifier is interpreted as the refined subproperty
tb.identifier.tree.

By the way, I made a simple ontology (attached) that formalizes this
inheritance. Would be nice to have this available as
http://purl.org/phylo/treebase/terms# or whatever (speaking of which:
have you had a chance to add me to the treebase & phylows purl
domains?) Seems to me that's pretty much in line with the Contextual
part of CQL - I've seen many examples using dublin core predicates
whose exact semantics are context-dependent.

(By the way 2, you're saying "*should* mean different things for
different finders". I don't know whether they *should*, but that's
certainly how they are implemented now.)

> What we should pay attention to though is that the API *allows* optimizing
> of code reuse and clean design of implementations. Are you saying that it
> stands in the way of that, and if so, how does it prevent clean design of
> implementations?

I think it stands in the way of clean design because any finder
(find/tree, find/matrix, find/study) potentially needs to process
predicates from any other domain (e.g. find/tree apparently needs to
know about study IDs), which is harder than just having to deal with
your own domain and subsequently having to project your result set
into a different domain.

Rutger

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