Menu
▾
▴
cdao-discuss
|
From: Ben M. <be...@be...> - 2013-06-29 23:00:25
|
A few of us discussed this briefly at iEvoBio; it would be great to have a concept similar to "has_Root", but for unrooted trees. Some tree formats, such as Newick, represent rooted and unrooted trees identically - an unrooted tree has a "pseudo-root" and is represented the same way as a rooted tree. The position of this pseudo-root is completely arbitrary. If a Newick tree is converted to CDAO and then back to Newick, the resulting tree may appear to be "rooted" differently than the original. While this is technically fine (since it's unrooted, it shouldn't matter where the "pseudo-root" is placed), it may be confusing or irritating to users. Having a property cdao:has_PseudoRoot would ensure that the tree could be retrieved from a triple store and converted back to a Newick tree without changing the position of the pseudo-root - so users would get back a tree that they could easily verify was identical to what they started with. Currently I'm using has_Root for unrooted trees; this is certainly incorrect, as the pseudo-root is not a root. It's important to distinguish between a true root and what's merely a starting point for convenience but has no real meaning. Ben Morris PhD student, Ecology/Evolutionary Biology University of North Carolina, Chapel Hill, NC Mail: be...@be... | Twitter: @bendmorris Web: www.bendmorris.com |
|
From: Matt Y. <dia...@gm...> - 2013-07-01 01:58:43
|
It sounds like this concept is specifically (only?) used for rendering? How about making it specific and calling it a "render anchor" or some such? Cheers, Matt On Sat, Jun 29, 2013 at 5:03 PM, Ben Morris <be...@be...> wrote: > A few of us discussed this briefly at iEvoBio; it would be great to > have a concept similar to "has_Root", but for unrooted trees. Some > tree formats, such as Newick, represent rooted and unrooted trees > identically - an unrooted tree has a "pseudo-root" and is represented > the same way as a rooted tree. The position of this pseudo-root is > completely arbitrary. If a Newick tree is converted to CDAO and then > back to Newick, the resulting tree may appear to be "rooted" > differently than the original. While this is technically fine (since > it's unrooted, it shouldn't matter where the "pseudo-root" is placed), > it may be confusing or irritating to users. Having a property > cdao:has_PseudoRoot would ensure that the tree could be retrieved from > a triple store and converted back to a Newick tree without changing > the position of the pseudo-root - so users would get back a tree that > they could easily verify was identical to what they started with. > > Currently I'm using has_Root for unrooted trees; this is certainly > incorrect, as the pseudo-root is not a root. It's important to > distinguish between a true root and what's merely a starting point for > convenience but has no real meaning. > > > Ben Morris > PhD student, Ecology/Evolutionary Biology > University of North Carolina, Chapel Hill, NC > Mail: be...@be... | Twitter: @bendmorris > Web: www.bendmorris.com > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Windows: > > Build for Windows Store. > > http://p.sf.net/sfu/windows-dev2dev > _______________________________________________ > CDAO-discuss mailing list > CDA...@li... > https://lists.sourceforge.net/lists/listinfo/cdao-discuss |
|
From: Hilmar L. <hl...@ne...> - 2013-07-01 14:25:24
|
Another alternative I was thinking about is capturing the semantics through type rather than property.(*)
For example, we could create a class 'pseudo root' ("a node in an unrooted tree that is designated as a root node solely for the purposes of maintaining consistent appearance when rendering the tree graphically or in parenthetical formats, such as Newick, that do not allow distinction of rooted from unrooted trees"), rdf:type the respective node that way (in addition to rdf:type cdao:Node), and then associate the node to the tree with something as neutral as "bfo:has part", or "cdao:has". A SPARQL query would then extract the node using the rdf:type triple.
-hilmar
(*) It's worth keeping in mind that while there is a natural-language temptation to put lots of differentiation into the property, reasoners can do very little with properties, beyond inferring other properties based on subproperty, property chains, inverse etc assertions. Type hierarchies typically yield a lot more in terms of richness of reasoning than a proliferation of properties does.
On Jun 30, 2013, at 9:58 PM, Matt Yoder wrote:
> It sounds like this concept is specifically (only?) used for
> rendering? How about making it specific and calling it a "render
> anchor" or some such?
>
> Cheers,
> Matt
>
> On Sat, Jun 29, 2013 at 5:03 PM, Ben Morris <be...@be...> wrote:
>> A few of us discussed this briefly at iEvoBio; it would be great to
>> have a concept similar to "has_Root", but for unrooted trees. Some
>> tree formats, such as Newick, represent rooted and unrooted trees
>> identically - an unrooted tree has a "pseudo-root" and is represented
>> the same way as a rooted tree. The position of this pseudo-root is
>> completely arbitrary. If a Newick tree is converted to CDAO and then
>> back to Newick, the resulting tree may appear to be "rooted"
>> differently than the original. While this is technically fine (since
>> it's unrooted, it shouldn't matter where the "pseudo-root" is placed),
>> it may be confusing or irritating to users. Having a property
>> cdao:has_PseudoRoot would ensure that the tree could be retrieved from
>> a triple store and converted back to a Newick tree without changing
>> the position of the pseudo-root - so users would get back a tree that
>> they could easily verify was identical to what they started with.
>>
>> Currently I'm using has_Root for unrooted trees; this is certainly
>> incorrect, as the pseudo-root is not a root. It's important to
>> distinguish between a true root and what's merely a starting point for
>> convenience but has no real meaning.
>>
>>
>> Ben Morris
>> PhD student, Ecology/Evolutionary Biology
>> University of North Carolina, Chapel Hill, NC
>> Mail: be...@be... | Twitter: @bendmorris
>> Web: www.bendmorris.com
>>
>> ------------------------------------------------------------------------------
>> This SF.net email is sponsored by Windows:
>>
>> Build for Windows Store.
>>
>> http://p.sf.net/sfu/windows-dev2dev
>> _______________________________________________
>> CDAO-discuss mailing list
>> CDA...@li...
>> https://lists.sourceforge.net/lists/listinfo/cdao-discuss
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> _______________________________________________
> CDAO-discuss mailing list
> CDA...@li...
> https://lists.sourceforge.net/lists/listinfo/cdao-discuss
--
===========================================================
: Hilmar Lapp -:- Durham, NC -:- informatics.nescent.org :
===========================================================
|
|
From: Arlin S. <ar...@um...> - 2013-07-02 19:04:19
|
I think "render anchor" captures the needed concept more clearly. Another option is to allow node A is_root_of tree B but assign it 0 confidence. It is important to note that the issue Ben raises has existed for decades. It would be great to solve this problem in a way that is consistent with current practices and expectations, but I'm not sure exactly what they are. My impression is that systematists tend to be more careful about designating outgroups, whereas molecular evolutionists and others produce unrooted trees and depict them as rooted trees without thinking about it too much (most molecular phylogenies are inferred using time-symmetric models, so they are not rooted). Some software uses a 3-way basal polytomy as a cryptic signal that the tree is unrooted. Alas, this cryptically unrooted tree is indistinguishable from a rooted tree with a 3-way basal polytomy. Other software may use [&U] and [&R]. Arlin On Jun 30, 2013, at 9:58 PM, Matt Yoder wrote: > It sounds like this concept is specifically (only?) used for > rendering? How about making it specific and calling it a "render > anchor" or some such? > > Cheers, > Matt > > On Sat, Jun 29, 2013 at 5:03 PM, Ben Morris <be...@be...> wrote: >> A few of us discussed this briefly at iEvoBio; it would be great to >> have a concept similar to "has_Root", but for unrooted trees. Some >> tree formats, such as Newick, represent rooted and unrooted trees >> identically - an unrooted tree has a "pseudo-root" and is represented >> the same way as a rooted tree. The position of this pseudo-root is >> completely arbitrary. If a Newick tree is converted to CDAO and then >> back to Newick, the resulting tree may appear to be "rooted" >> differently than the original. While this is technically fine (since >> it's unrooted, it shouldn't matter where the "pseudo-root" is placed), >> it may be confusing or irritating to users. Having a property >> cdao:has_PseudoRoot would ensure that the tree could be retrieved from >> a triple store and converted back to a Newick tree without changing >> the position of the pseudo-root - so users would get back a tree that >> they could easily verify was identical to what they started with. >> >> Currently I'm using has_Root for unrooted trees; this is certainly >> incorrect, as the pseudo-root is not a root. It's important to >> distinguish between a true root and what's merely a starting point for >> convenience but has no real meaning. >> >> >> Ben Morris >> PhD student, Ecology/Evolutionary Biology >> University of North Carolina, Chapel Hill, NC >> Mail: be...@be... | Twitter: @bendmorris >> Web: www.bendmorris.com >> >> ------------------------------------------------------------------------------ >> This SF.net email is sponsored by Windows: >> >> Build for Windows Store. >> >> http://p.sf.net/sfu/windows-dev2dev >> _______________________________________________ >> CDAO-discuss mailing list >> CDA...@li... >> https://lists.sourceforge.net/lists/listinfo/cdao-discuss > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Windows: > > Build for Windows Store. > > http://p.sf.net/sfu/windows-dev2dev > _______________________________________________ > CDAO-discuss mailing list > CDA...@li... > https://lists.sourceforge.net/lists/listinfo/cdao-discuss ------- Arlin Stoltzfus (ar...@um...) Fellow, IBBR; Adj. Assoc. Prof., UMCP; Research Biologist, NIST IBBR, 9600 Gudelsky Drive, Rockville, MD, 20850 tel: 240 314 6208; web: www.molevol.org |
Thanks for helping keep SourceForge clean.
X