Re: [Ncl-devel] annotation API for NCL

[Jeet S. <jee...@gm...>]

I read this briefly earlier this morning (yes, "morning", thanks to 
lingering jet lag + baby feeding times, I have been experiencing this 
phenomenon quite a bit recently), but now the link seems dead ...

Anyway, I think the proposed design makes sense, if I remember correctly 
....
Using the Git-ique metaphors of "plumbing" vs. "porcelain":
The "plumbing" in this case is the data structure associated with the 
reader, which stores the triplets, include the pointer to the 
appropriate Nexus objects.
As you note, added syntactic sugar would function as "porcelain", 
allowing for easier access to the annotations.
Am I right in remembering that, with the proposed porcelain, if I want 
all the annotations referring to a  Tree object, I  can just ask the 
Tree object for all annotations that reference it, and I get back a 
vector (or list)?
I guess the enum mechanism + casting is the only way to reconcile the 
flexibility of annotations' referents with the strong typing of C++.
It would be great if the porcelain could wrap this up as much as possible.

The problem of annotating tree edges/nodes and character 
columns/rows/cells remains. For the former, I personally would prefer to 
avoid  the client-side cost/hassle of tracking a particular node's 
post-order traversal index. Instead, I think that if client code wants 
to access annotations on tree components, it would be perfectly fair to 
expect them to ask for a NCL Tree object and deal or otherwise harvest 
info from that. That way, edge and node annotations can be managed using 
the the same "porcelain" as for any other "first class" NCL objects.

The character matrix case is a little more complicated, as a full 
implementation of a NeXML spec'd character object model requires a 
fat/rich stack of fat/rich classes (in Asia, we might say "prosperous"). 
If this needs and is going to be done as part of the GSoC NCL/NeXML 
project anyway, and if the implementation ends up with character 
cells/rows/columns all being "first class" NCL objects, then the 
annotations might be bundled up with these as part of their porcelain. 
Personally, I would be quite happy for a "prosperous" character object 
model in NCL. But I am not the one doing the coding! If we do not go 
that route, then maybe a specialized data structure associated with a 
character matrix that can facultatively take (a) a row index, (b) a 
column index or (c) a row/column = cell index and return the associated 
list of annotations might be desirable porcelain.

-- jeet

On 5/26/10 4:05 AM, Mark Holder wrote:
> Hi ncl-devel,
> 	This email was going to follow up on a conversation that was started on a thread that I kicked off when announcing the fact that NCL2.1 now has reasonable documentation, but I think that it is better to use a Wiki to launch this discussion rather than lots of email threads.  I'm certainly happy to discuss the issues via email (rather on the wiki), but I thought it would be best to refer interested parties to https://sourceforge.net/apps/mediawiki/ncl/index.php?title=AnnotationAPIDiscussion
> for the initial message in the discussion.
>
> 	The general topic was, "How should NCL store generic annotations and make them available to client code?"
>
> 	The motivation to get moving on this is the fact that Mick Elliot is adding support for nexml and phyloxml as a part of the Google Summer of Code, so we'll need to have a decision soon (next week).
>
>
>
> 	I'm honestly not sure who has access to the Wiki mentioned. I just enabled it as a feature through sourceforge this morning.  Let me know if you have problems reading or writing, and I'll try to figure out how it is administered.
>
>
> all the best,
> Mark
>
>
> Mark Holder
>
> mth...@ku...
> http://phylo.bio.ku.edu/mark-holder
>
> ==============================================
> Department of Ecology and Evolutionary Biology
> University of Kansas
> 6031 Haworth Hall
> 1200 Sunnyside Avenue
> Lawrence, Kansas 66045
>
> lab phone:  785.864.5789
>
> fax (shared): 785.864.5860
> ==============================================
>
>
>
>
>
>
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Ncl-devel mailing list
> Ncl...@li...
> https://lists.sourceforge.net/lists/listinfo/ncl-devel
>
>