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

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

On Jul 7, 2009, at 8:58 PM, Rutger Vos wrote:

>> 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.

I think that's a very bad idea. It defeats the purpose of a controlled  
vocabulary (let alone ontology) to formalize unambiguously what we  
mean, and that we mean the same thing when we use the same term in the  
same application.

> 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.

To me this is backwards to how an ontology works. You would use the  
refined sub-properties, and if an agent doesn't understand what to do  
with it it would use the ontology to get at a more general term which  
it might recognize.

In RDF and OWL properties don't change their meaning based on subject  
or object. Rather, subject and object can change their semantics by  
applying a property (that has range or domain defined) to them.

> By the way, I made a simple ontology (attached) that formalizes this  
> inheritance.

What I can see is that they are declared as subproperty of  
dc.identifier. They make no assertions about range or domain, no?

> I've seen many examples using dublin core predicates whose exact  
> semantics are context-dependent.

Yes, but not within the same application profile (metadata  
vocabulary), right?

>
>> 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

But that is only true for TreeBASE. That one finder implementation in  
TreeBASE should not cooperate with another finder implementation in  
TreeBASE is your design decision, not one from PhyloWS, right?

	-hilmar


-- 
===========================================================
: Hilmar Lapp  -:- Durham, NC -:- informatics.nescent.org :
===========================================================