Thread: [Nexml-discuss] Expressing simmap trees in nexml?

Hi list,

I am wondering if anyone has either an example or recommendation on how to
express a simmap / stochastic character map on a phylogeny in nexml? (e.g.
see http://www.simmap.com/pgs/docs.html for background).

Briefly, this would involve for each edge, specifying the state the edge
was in.  Perhaps the most logical thing would be to add non-branching nodes
wherever the character changes state, and then we would need an appropriate
meta tag indicating the branch has state id xxx (referencing the `states`
element in `characters` element perhaps).

(This issue arises in working out use cases for our R parser,
https://github.com/ropensci/RNeXML/issues/48)

Thanks for any ideas or suggestions!

Carl

-- 
Carl Boettiger
UC Santa Cruz
http://carlboettiger.info/

Hi Carl,

just typed the same response to your #48 before reading this email. I guess
the best way would be as you say: by introducing an unbranched internal
node for each stretch of mapped state. The other way might be to have
multiple meta annotations on a single "edge" element, but then you might
have to have some sort of convention to specify in which order the
stretches need to be applied to the edge (=ugly).

Rutger


On Sat, Nov 30, 2013 at 10:27 PM, Carl Boettiger <cbo...@gm...> wrote:

> Hi list,
>
> I am wondering if anyone has either an example or recommendation on how to
> express a simmap / stochastic character map on a phylogeny in nexml? (e.g.
> see http://www.simmap.com/pgs/docs.html for background).
>
> Briefly, this would involve for each edge, specifying the state the edge
> was in.  Perhaps the most logical thing would be to add non-branching nodes
> wherever the character changes state, and then we would need an appropriate
> meta tag indicating the branch has state id xxx (referencing the `states`
> element in `characters` element perhaps).
>
> (This issue arises in working out use cases for our R parser,
> https://github.com/ropensci/RNeXML/issues/48)
>
> Thanks for any ideas or suggestions!
>
> Carl
>
> --
> Carl Boettiger
> UC Santa Cruz
> http://carlboettiger.info/
>
>
> ------------------------------------------------------------------------------
> Rapidly troubleshoot problems before they affect your business. Most IT
> organizations don't have a clear picture of how application performance
> affects their revenue. With AppDynamics, you get 100% visibility into your
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics
> Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk
> _______________________________________________
> Nexml-discuss mailing list
> Nex...@li...
> https://lists.sourceforge.net/lists/listinfo/nexml-discuss
>
>


-- 

Dr. Rutger A. Vos
Bioinformaticist
Naturalis Biodiversity Center
Visiting address: Office A109, Einsteinweg 2, 2333 CC, Leiden, the
Netherlands
Mailing address: Postbus 9517, 2300 RA, Leiden, the Netherlands
http://rutgervos.blogspot.com

Adding non-branching nodes is certainly a possibility but sounds like a hack to me. While there's plenty of room for hacks in NeXML due to its built-in flexibility, one of its benefits should be to obviate the need for hacks, in contrast to formats like Newick. It seems to me that unlike annotations such as a traditional branch length which apply to the branch (edge) as a whole, here we have annotations that apply to an edge only for a certain length (amount of time). So rather than a simple scalar it seems to me we have a structured annotation value here, which NeXML metas are perfectly capable of expressing. Why not do it that way rather than invent an unnecessary hack as a convention?

	-hilmar

On Dec 2, 2013, at 8:16 AM, Rutger Vos wrote:

> Hi Carl,
> 
> just typed the same response to your #48 before reading this email. I guess the best way would be as you say: by introducing an unbranched internal node for each stretch of mapped state. The other way might be to have multiple meta annotations on a single "edge" element, but then you might have to have some sort of convention to specify in which order the stretches need to be applied to the edge (=ugly).
> 
> Rutger
> 
> 
> On Sat, Nov 30, 2013 at 10:27 PM, Carl Boettiger <cbo...@gm...> wrote:
> Hi list,
> 
> I am wondering if anyone has either an example or recommendation on how to express a simmap / stochastic character map on a phylogeny in nexml? (e.g. see http://www.simmap.com/pgs/docs.html for background).  
> 
> Briefly, this would involve for each edge, specifying the state the edge was in.  Perhaps the most logical thing would be to add non-branching nodes wherever the character changes state, and then we would need an appropriate meta tag indicating the branch has state id xxx (referencing the `states` element in `characters` element perhaps).  
> 
> (This issue arises in working out use cases for our R parser, https://github.com/ropensci/RNeXML/issues/48)
> 
> Thanks for any ideas or suggestions!
> 
> Carl
> 
> -- 
> Carl Boettiger
> UC Santa Cruz
> http://carlboettiger.info/
> 
> ------------------------------------------------------------------------------
> Rapidly troubleshoot problems before they affect your business. Most IT
> organizations don't have a clear picture of how application performance
> affects their revenue. With AppDynamics, you get 100% visibility into your
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk
> _______________________________________________
> Nexml-discuss mailing list
> Nex...@li...
> https://lists.sourceforge.net/lists/listinfo/nexml-discuss
> 
> 
> 
> 
> -- 
> 
> Dr. Rutger A. Vos
> Bioinformaticist
> Naturalis Biodiversity Center
> Visiting address: Office A109, Einsteinweg 2, 2333 CC, Leiden, the Netherlands
> Mailing address: Postbus 9517, 2300 RA, Leiden, the Netherlands
> http://rutgervos.blogspot.com
> ------------------------------------------------------------------------------
> Rapidly troubleshoot problems before they affect your business. Most IT 
> organizations don't have a clear picture of how application performance 
> affects their revenue. With AppDynamics, you get 100% visibility into your 
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk_______________________________________________
> Nexml-discuss mailing list
> Nex...@li...
> https://lists.sourceforge.net/lists/listinfo/nexml-discuss

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

Hilmar, Rutger, list,

Thanks for the replies -- I see the merits of both perspectives, though I'm
not quite sure how I would implement Hilmar's case.

On one hand, as Hilmar says the 'stochastic character map' really is an
annotation ('painting') of the existing phylogeny, so it feels wrong to
edit the topology merely to accommodate an annotation. From the user
perspective, an R user should be able to write R's ape::phylo object out as
NeXML with or without the annotation, and read back in the same phylo
object.  I'm open to suggestions on how to construct such an annotation
though.

Perhaps an edge that changed from state 1 to state 2 might be annotated as:


```xml
<states>
  <state id="s1" label="description of state">
  <state id="s2" label="description of alternative state">
  ...
  <edge id="e1" source="n1" target="n2" about="#e1" length="6.4">
    <meta property="x:order" content="1"  xsi:type="nex:LiteralMeta" id =
"m1" about="#m1">
      <meta property="x:length" content="3.4" xsi:type="nex:LiteralMeta" id
= "m2" />
      <meta property="x:hasState" content="s1" xsi:type="nex:LiteralMeta"
id = "m3" />
    </meta>
   <meta property="x:order" content="2"  xsi:type="nex:LiteralMeta" id =
"m4"  about="#m4">
      <meta property="x:length" content="3.0" xsi:type="nex:LiteralMeta" id
= "m5"/>
      <meta property="x:hasState" content="s2" xsi:type="nex:LiteralMeta"
id = "m6"/>
    </meta>
  </edge>
```

Obviously I have just made up the properties `x:`.  How would I go about
establishing a formal namespace for such properties?

Clearly several alternative annotations could be proposed here.  For
instance, could either declare `start`, `stop`, and `state` times for each
section, instead?

Also, not sure if my nesting of meta elements is appropriate. Perhaps they
should all be wrapped in a `meta` declaring something like
`hasStochasticCharacterMapping`.



Alternatively, after introducing the nodes, the annotation is more straight
forward.  I might suggest something like:

```xml
<states>
  <state id="s1" label="description of state">
  ...
  <edge id="e1" source="n1" target="n2" about="#e1" length="3.4">
    <meta property="x:hasState" content="s1" xsi:type="nex:LiteralMeta" id
= "m1"/>
  </edge>
```

needing only a better property and a real namespace for the concept "has
state"

there is a possible use-case in introducing new nodes, in that there are R
functions that can deal with these paintings but only when they change at
nodes.  Still, I suppose. such a case should be dealt with at the R end,
not be a side-effect of trying to serialize the data.



Anyway, sorry for the long reply. Any input on which alternative to use and
how the annotation might best be constructed would be great.  Hopefully my
quick examples provide some starting point to critique and modify.




On Mon, Dec 2, 2013 at 8:47 AM, Hilmar Lapp <hl...@ne...> wrote:

> Adding non-branching nodes is certainly a possibility but sounds like a
> hack to me. While there's plenty of room for hacks in NeXML due to its
> built-in flexibility, one of its benefits should be to obviate the need for
> hacks, in contrast to formats like Newick. It seems to me that unlike
> annotations such as a traditional branch length which apply to the branch
> (edge) as a whole, here we have annotations that apply to an edge only for
> a certain length (amount of time). So rather than a simple scalar it seems
> to me we have a structured annotation value here, which NeXML metas are
> perfectly capable of expressing. Why not do it that way rather than invent
> an unnecessary hack as a convention?
>
> -hilmar
>
> On Dec 2, 2013, at 8:16 AM, Rutger Vos wrote:
>
> Hi Carl,
>
> just typed the same response to your #48 before reading this email. I
> guess the best way would be as you say: by introducing an unbranched
> internal node for each stretch of mapped state. The other way might be to
> have multiple meta annotations on a single "edge" element, but then you
> might have to have some sort of convention to specify in which order the
> stretches need to be applied to the edge (=ugly).
>
> Rutger
>
>
> On Sat, Nov 30, 2013 at 10:27 PM, Carl Boettiger <cbo...@gm...>wrote:
>
>> Hi list,
>>
>> I am wondering if anyone has either an example or recommendation on how
>> to express a simmap / stochastic character map on a phylogeny in nexml?
>> (e.g. see http://www.simmap.com/pgs/docs.html for background).
>>
>> Briefly, this would involve for each edge, specifying the state the edge
>> was in.  Perhaps the most logical thing would be to add non-branching nodes
>> wherever the character changes state, and then we would need an appropriate
>> meta tag indicating the branch has state id xxx (referencing the `states`
>> element in `characters` element perhaps).
>>
>> (This issue arises in working out use cases for our R parser,
>> https://github.com/ropensci/RNeXML/issues/48)
>>
>> Thanks for any ideas or suggestions!
>>
>> Carl
>>
>> --
>> Carl Boettiger
>> UC Santa Cruz
>> http://carlboettiger.info/
>>
>>
>> ------------------------------------------------------------------------------
>> Rapidly troubleshoot problems before they affect your business. Most IT
>> organizations don't have a clear picture of how application performance
>> affects their revenue. With AppDynamics, you get 100% visibility into your
>> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics
>> Pro!
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Nexml-discuss mailing list
>> Nex...@li...
>> https://lists.sourceforge.net/lists/listinfo/nexml-discuss
>>
>>
>
>
> --
>
> Dr. Rutger A. Vos
> Bioinformaticist
> Naturalis Biodiversity Center
> Visiting address: Office A109, Einsteinweg 2, 2333 CC, Leiden, the
> Netherlands
> Mailing address: Postbus 9517, 2300 RA, Leiden, the Netherlands
> http://rutgervos.blogspot.com
> ------------------------------------------------------------------------------
> Rapidly troubleshoot problems before they affect your business. Most IT
> organizations don't have a clear picture of how application performance
> affects their revenue. With AppDynamics, you get 100% visibility into your
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics
> Pro!
>
> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk_______________________________________________
> Nexml-discuss mailing list
> Nex...@li...
> https://lists.sourceforge.net/lists/listinfo/nexml-discuss
>
>
> --
> ===========================================================
> : Hilmar Lapp  -:- Durham, NC -:- informatics.nescent.org :
> ===========================================================
>
>
>
>


-- 
Carl Boettiger
UC Santa Cruz
http://carlboettiger.info/

Like Hilmar, I find it off-putting to modify the genealogy to express
the character state transitions.

I like the approach that Hilmar advocated in the "Adding extra
structured data to NeXML files" thread [1]. Basically this came down
to embedding specific XML elements into an appropriate meta element.
An example are the phen: namespace elements in [2]

I don't have specific advice on the syntax, but I think that designing
a simple syntax for this can be terse and transparent. To me, if it
uses the nexml element IDs to refer to states, characters, and trees
then it is very nexml-friendly. Even if all of the annotation is in a
child of meta rather than in the attributes of meta.

Something like the following (apologies for not really using xml, and
just adding a nex: prefix to indicate a part of nexml) seems
reasonable to me:

#########################################################
nex:characters id=mat1
  nex:format
    nex:states id=states1 ...
      nex:state id=s1 ...
      nex:state id=s2 ...
    nex:char id=pos1
...
nex:trees
 nex:tree
  nex:node id=node1 root=true
  nex:node id=node2 otu=o1
  nex:edge id=edge1 source=node1 target=node2
    nex:meta
      reconstructions [this could hold info on how the mappings were done]
        reconstruction character=pos1 [one per mapping]
           stateassignment id=sa1 state=s1 node=node1
           statechange id=sc1 edge=edge1 height=0.4 state=s2
           statechange id=sc2 edge=edge1 height=0.5 state=s1
#####################################################


where height is the distance along the edge from the source node.
In the meta  that is the parent of reconstructions, you can just add
some attribute that points to a web page documenting your schema for
the following elements.



best,
mark


[1] http://sourceforge.net/mailarchive/message.php?msg_id=31344501

[2] https://github.com/phenoscape/phenoscape-data/blob/master/Curation%20Files/completed-phenex-files/Characiformes/Buckup_1998.xml

On Mon, Dec 2, 2013 at 11:53 AM, Carl Boettiger <cbo...@gm...> wrote:
> Hilmar, Rutger, list,
>
> Thanks for the replies -- I see the merits of both perspectives, though I'm
> not quite sure how I would implement Hilmar's case.
>
> On one hand, as Hilmar says the 'stochastic character map' really is an
> annotation ('painting') of the existing phylogeny, so it feels wrong to edit
> the topology merely to accommodate an annotation. From the user perspective,
> an R user should be able to write R's ape::phylo object out as NeXML with or
> without the annotation, and read back in the same phylo object.  I'm open to
> suggestions on how to construct such an annotation though.
>
> Perhaps an edge that changed from state 1 to state 2 might be annotated as:
>
> ```xml
> <states>
>   <state id="s1" label="description of state">
>   <state id="s2" label="description of alternative state">
>   ...
>   <edge id="e1" source="n1" target="n2" about="#e1" length="6.4">
>     <meta property="x:order" content="1"  xsi:type="nex:LiteralMeta" id =
> "m1" about="#m1">
>       <meta property="x:length" content="3.4" xsi:type="nex:LiteralMeta" id
> = "m2" />
>       <meta property="x:hasState" content="s1" xsi:type="nex:LiteralMeta" id
> = "m3" />
>     </meta>
>    <meta property="x:order" content="2"  xsi:type="nex:LiteralMeta" id =
> "m4"  about="#m4">
>       <meta property="x:length" content="3.0" xsi:type="nex:LiteralMeta" id
> = "m5"/>
>       <meta property="x:hasState" content="s2" xsi:type="nex:LiteralMeta" id
> = "m6"/>
>     </meta>
>   </edge>
> ```
>
> Obviously I have just made up the properties `x:`.  How would I go about
> establishing a formal namespace for such properties?
>
> Clearly several alternative annotations could be proposed here.  For
> instance, could either declare `start`, `stop`, and `state` times for each
> section, instead?
>
> Also, not sure if my nesting of meta elements is appropriate. Perhaps they
> should all be wrapped in a `meta` declaring something like
> `hasStochasticCharacterMapping`.
>
>
>
> Alternatively, after introducing the nodes, the annotation is more straight
> forward.  I might suggest something like:
>
> ```xml
> <states>
>   <state id="s1" label="description of state">
>   ...
>   <edge id="e1" source="n1" target="n2" about="#e1" length="3.4">
>     <meta property="x:hasState" content="s1" xsi:type="nex:LiteralMeta" id =
> "m1"/>
>   </edge>
> ```
>
> needing only a better property and a real namespace for the concept "has
> state"
>
> there is a possible use-case in introducing new nodes, in that there are R
> functions that can deal with these paintings but only when they change at
> nodes.  Still, I suppose. such a case should be dealt with at the R end, not
> be a side-effect of trying to serialize the data.
>
>
>
> Anyway, sorry for the long reply. Any input on which alternative to use and
> how the annotation might best be constructed would be great.  Hopefully my
> quick examples provide some starting point to critique and modify.
>
>
>
>
> On Mon, Dec 2, 2013 at 8:47 AM, Hilmar Lapp <hl...@ne...> wrote:
>>
>> Adding non-branching nodes is certainly a possibility but sounds like a
>> hack to me. While there's plenty of room for hacks in NeXML due to its
>> built-in flexibility, one of its benefits should be to obviate the need for
>> hacks, in contrast to formats like Newick. It seems to me that unlike
>> annotations such as a traditional branch length which apply to the branch
>> (edge) as a whole, here we have annotations that apply to an edge only for a
>> certain length (amount of time). So rather than a simple scalar it seems to
>> me we have a structured annotation value here, which NeXML metas are
>> perfectly capable of expressing. Why not do it that way rather than invent
>> an unnecessary hack as a convention?
>>
>> -hilmar
>>
>> On Dec 2, 2013, at 8:16 AM, Rutger Vos wrote:
>>
>> Hi Carl,
>>
>> just typed the same response to your #48 before reading this email. I
>> guess the best way would be as you say: by introducing an unbranched
>> internal node for each stretch of mapped state. The other way might be to
>> have multiple meta annotations on a single "edge" element, but then you
>> might have to have some sort of convention to specify in which order the
>> stretches need to be applied to the edge (=ugly).
>>
>> Rutger
>>
>>
>> On Sat, Nov 30, 2013 at 10:27 PM, Carl Boettiger <cbo...@gm...>
>> wrote:
>>>
>>> Hi list,
>>>
>>> I am wondering if anyone has either an example or recommendation on how
>>> to express a simmap / stochastic character map on a phylogeny in nexml?
>>> (e.g. see http://www.simmap.com/pgs/docs.html for background).
>>>
>>> Briefly, this would involve for each edge, specifying the state the edge
>>> was in.  Perhaps the most logical thing would be to add non-branching nodes
>>> wherever the character changes state, and then we would need an appropriate
>>> meta tag indicating the branch has state id xxx (referencing the `states`
>>> element in `characters` element perhaps).
>>>
>>> (This issue arises in working out use cases for our R parser,
>>> https://github.com/ropensci/RNeXML/issues/48)
>>>
>>> Thanks for any ideas or suggestions!
>>>
>>> Carl
>>>
>>> --
>>> Carl Boettiger
>>> UC Santa Cruz
>>> http://carlboettiger.info/
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Rapidly troubleshoot problems before they affect your business. Most IT
>>> organizations don't have a clear picture of how application performance
>>> affects their revenue. With AppDynamics, you get 100% visibility into
>>> your
>>> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics
>>> Pro!
>>>
>>> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> Nexml-discuss mailing list
>>> Nex...@li...
>>> https://lists.sourceforge.net/lists/listinfo/nexml-discuss
>>>
>>
>>
>>
>> --
>>
>> Dr. Rutger A. Vos
>> Bioinformaticist
>> Naturalis Biodiversity Center
>> Visiting address: Office A109, Einsteinweg 2, 2333 CC, Leiden, the
>> Netherlands
>> Mailing address: Postbus 9517, 2300 RA, Leiden, the Netherlands
>> http://rutgervos.blogspot.com
>>
>> ------------------------------------------------------------------------------
>> Rapidly troubleshoot problems before they affect your business. Most IT
>> organizations don't have a clear picture of how application performance
>> affects their revenue. With AppDynamics, you get 100% visibility into your
>> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics
>> Pro!
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk_______________________________________________
>> Nexml-discuss mailing list
>> Nex...@li...
>> https://lists.sourceforge.net/lists/listinfo/nexml-discuss
>>
>>
>> --
>> ===========================================================
>> : Hilmar Lapp  -:- Durham, NC -:- informatics.nescent.org :
>> ===========================================================
>>
>>
>>
>
>
>
> --
> Carl Boettiger
> UC Santa Cruz
> http://carlboettiger.info/
>
> ------------------------------------------------------------------------------
> Rapidly troubleshoot problems before they affect your business. Most IT
> organizations don't have a clear picture of how application performance
> affects their revenue. With AppDynamics, you get 100% visibility into your
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics
> Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk
> _______________________________________________
> Nexml-discuss mailing list
> Nex...@li...
> https://lists.sourceforge.net/lists/listinfo/nexml-discuss
>



-- 
Mark Holder

mth...@gm...
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
==============================================

Nice examples. A few comments:

- There is already has_State in CDAO (http://purl.obolibrary.org/obo/CDAO_0000184).
- The properties you made up and that don't exist yet would either go into CDAO, or, if they are too application-specific (i.e., arguably chiefly useful for annotating phylogenetic analysis inputs and outputs), to MIAPA.
- I have no objections to, in fact am in favor of representing the data in memory so it's most amenable to analysis methods in the corresponding environment. However, when you serialize the data for exchange, it can and should be as devoid of application and analysis-specific hacks as possible.

Also, great suggestion from Mark, that's certainly one way to do the structured annotation in a straightforward way. Structured annotation need not mirror or resemble RDF, but adding artificial structure to the data just as a crutch for structured annotation to stand on is hopefully something that NeXML does away with.

	-hilmar

On Dec 2, 2013, at 12:53 PM, Carl Boettiger wrote:

> Hilmar, Rutger, list,
> 
> Thanks for the replies -- I see the merits of both perspectives, though I'm not quite sure how I would implement Hilmar's case.
> 
> On one hand, as Hilmar says the 'stochastic character map' really is an annotation ('painting') of the existing phylogeny, so it feels wrong to edit the topology merely to accommodate an annotation. From the user perspective, an R user should be able to write R's ape::phylo object out as NeXML with or without the annotation, and read back in the same phylo object.  I'm open to suggestions on how to construct such an annotation though.  
> 
> Perhaps an edge that changed from state 1 to state 2 might be annotated as:  
> 
> ```xml
> <states>
>   <state id="s1" label="description of state">
>   <state id="s2" label="description of alternative state">
>   ...
>   <edge id="e1" source="n1" target="n2" about="#e1" length="6.4">
>     <meta property="x:order" content="1"  xsi:type="nex:LiteralMeta" id = "m1" about="#m1">
>       <meta property="x:length" content="3.4" xsi:type="nex:LiteralMeta" id = "m2" />
>       <meta property="x:hasState" content="s1" xsi:type="nex:LiteralMeta" id = "m3" />
>     </meta>
>    <meta property="x:order" content="2"  xsi:type="nex:LiteralMeta" id = "m4"  about="#m4">
>       <meta property="x:length" content="3.0" xsi:type="nex:LiteralMeta" id = "m5"/>
>       <meta property="x:hasState" content="s2" xsi:type="nex:LiteralMeta" id = "m6"/>
>     </meta>
>   </edge>
> ```
> 
> Obviously I have just made up the properties `x:`.  How would I go about establishing a formal namespace for such properties? 
> 
> Clearly several alternative annotations could be proposed here.  For instance, could either declare `start`, `stop`, and `state` times for each section, instead?    
> 
> Also, not sure if my nesting of meta elements is appropriate. Perhaps they should all be wrapped in a `meta` declaring something like `hasStochasticCharacterMapping`.  
> 
> 
> 
> Alternatively, after introducing the nodes, the annotation is more straight forward.  I might suggest something like:
> 
> ```xml
> <states>
>   <state id="s1" label="description of state">
>   ...
>   <edge id="e1" source="n1" target="n2" about="#e1" length="3.4">
>     <meta property="x:hasState" content="s1" xsi:type="nex:LiteralMeta" id = "m1"/>
>   </edge>
> ```
> 
> needing only a better property and a real namespace for the concept "has state"
> 
> there is a possible use-case in introducing new nodes, in that there are R functions that can deal with these paintings but only when they change at nodes.  Still, I suppose. such a case should be dealt with at the R end, not be a side-effect of trying to serialize the data.  
> 
> 
> 
> Anyway, sorry for the long reply. Any input on which alternative to use and how the annotation might best be constructed would be great.  Hopefully my quick examples provide some starting point to critique and modify.  
> 
> 
> 
> 
> On Mon, Dec 2, 2013 at 8:47 AM, Hilmar Lapp <hl...@ne...> wrote:
> Adding non-branching nodes is certainly a possibility but sounds like a hack to me. While there's plenty of room for hacks in NeXML due to its built-in flexibility, one of its benefits should be to obviate the need for hacks, in contrast to formats like Newick. It seems to me that unlike annotations such as a traditional branch length which apply to the branch (edge) as a whole, here we have annotations that apply to an edge only for a certain length (amount of time). So rather than a simple scalar it seems to me we have a structured annotation value here, which NeXML metas are perfectly capable of expressing. Why not do it that way rather than invent an unnecessary hack as a convention?
> 
> 	-hilmar
> 
> On Dec 2, 2013, at 8:16 AM, Rutger Vos wrote:
> 
>> Hi Carl,
>> 
>> just typed the same response to your #48 before reading this email. I guess the best way would be as you say: by introducing an unbranched internal node for each stretch of mapped state. The other way might be to have multiple meta annotations on a single "edge" element, but then you might have to have some sort of convention to specify in which order the stretches need to be applied to the edge (=ugly).
>> 
>> Rutger
>> 
>> 
>> On Sat, Nov 30, 2013 at 10:27 PM, Carl Boettiger <cbo...@gm...> wrote:
>> Hi list,
>> 
>> I am wondering if anyone has either an example or recommendation on how to express a simmap / stochastic character map on a phylogeny in nexml? (e.g. see http://www.simmap.com/pgs/docs.html for background).  
>> 
>> Briefly, this would involve for each edge, specifying the state the edge was in.  Perhaps the most logical thing would be to add non-branching nodes wherever the character changes state, and then we would need an appropriate meta tag indicating the branch has state id xxx (referencing the `states` element in `characters` element perhaps).  
>> 
>> (This issue arises in working out use cases for our R parser, https://github.com/ropensci/RNeXML/issues/48)
>> 
>> Thanks for any ideas or suggestions!
>> 
>> Carl
>> 
>> -- 
>> Carl Boettiger
>> UC Santa Cruz
>> http://carlboettiger.info/
>> 
>> ------------------------------------------------------------------------------
>> Rapidly troubleshoot problems before they affect your business. Most IT
>> organizations don't have a clear picture of how application performance
>> affects their revenue. With AppDynamics, you get 100% visibility into your
>> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
>> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Nexml-discuss mailing list
>> Nex...@li...
>> https://lists.sourceforge.net/lists/listinfo/nexml-discuss
>> 
>> 
>> 
>> 
>> -- 
>> 
>> Dr. Rutger A. Vos
>> Bioinformaticist
>> Naturalis Biodiversity Center
>> Visiting address: Office A109, Einsteinweg 2, 2333 CC, Leiden, the Netherlands
>> Mailing address: Postbus 9517, 2300 RA, Leiden, the Netherlands
>> http://rutgervos.blogspot.com
>> ------------------------------------------------------------------------------
>> Rapidly troubleshoot problems before they affect your business. Most IT 
>> organizations don't have a clear picture of how application performance 
>> affects their revenue. With AppDynamics, you get 100% visibility into your 
>> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
>> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk_______________________________________________
>> Nexml-discuss mailing list
>> Nex...@li...
>> https://lists.sourceforge.net/lists/listinfo/nexml-discuss
> 
> -- 
> ===========================================================
> : Hilmar Lapp  -:- Durham, NC -:- informatics.nescent.org :
> ===========================================================
> 
> 
> 
> 
> 
> 
> -- 
> Carl Boettiger
> UC Santa Cruz
> http://carlboettiger.info/

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