Re: Attributes vs. Relationships

[Edward K. Ream]

On Wed, Feb 17, 2016 at 9:08 AM, 'Terry Brown' via leo-editor <
leo-editor@googlegroups.com> wrote:


> the easiest way to
> ​ [associate icons with attributes] might be the (unfortunately named)
> "tree declutter patterns"
>

​Thanks for the reminder.  I had forgotten​

​all about this.​ The code looks like an excellent start.

Edward

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Attributes vs. Relationships

['Terry Brown' via leo-editor]

From: Edward K. Ream <edream...@gmail.com>
 To: leo-editor <leo-editor@googlegroups.com> 
 Sent: Wednesday, February 17, 2016 8:31 AM
 Subject: Re: Attributes vs. Relationships
   

​​[snip]


I would like to see a general user interface that would associate icons with 
attributes/predicate/relation. That way the user can see all the nodes with a 
given attribute. Stay tuned.

Edward

I think the easiest way to get that done might be the (unfortunately named) 
"tree declutter patterns" 
D:\local\leo-editor\leo\config\leoSettings.leo#@settings-->Tree 
operation-->@bool tree-declutter = False
D:\local\leo-editor\leo\config\leoSettings.leo#@settings-->Tree 
operation-->@data tree-declutter-patterns

docs. in the latter node.  Currently they add icons (and otherwise fiddle with 
appearance) based on regex matches of headline text, seems like it would be 
straight forward to add matches to uA content as well. Of course I don't really 
know to what uA content, seems that would be user use case dependent.  Although 
the presence of tags from Jacob's tagging plugin would be an obvious target. 
The could also add icons for ToDo status, but the todo.py plugin already does 
that.
Cheers -Terry

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Attributes vs. Relationships

[Edward K. Ream]

​​
​​On Tue, Feb 16, 2016 at 2:35 PM, Largo84  wrote:

>
> It would be really cool to better expose the uA's and make them truly
> useful. However, I see them as merely metadata (like tags in media files).
> What would also be useful is to describe in some meaningful way the
> *nature* of a data relationship between elements (objects or 'nodes' in
> the Leo sense)
> ​.
>

​My present opinion is that uA's are simply a background implementation
detail.

In mathematics, a relation is just a set of tuples. Imo, we should define
the following two important terms:

A *Leo predicate* is a function/method taking a position
argument that returns True or False (or equivalent).

Predicates are typically implied by the conversation.  We say p.parent() ==
x rather than pedantically giving the actual predicate function.

A *Leo relation* (on an outline) is the (unordered) set of positions
for which the associated Leo predicate returns True.

Again, we can simply refer to relations by the associated predicate. That
is, predicates instantly give rise to relations: the set of positions for
which the predicate is True.

It's best to define relations on positions rather than vnodes.  This allows
us to define relations such as p.parent() == x. If outline structure is not
important, we can define the relation on the underlying vnode:  p.v.u == x,
for instance.

These definitions are clearly the most general possible. In particular, we
can easily define Leo relations such as "p has a given
attribute/uA/icon/whatever" The resulting predicates and relations are
unconstrained by outline structure. They would work in multi-trees. They
work in general graphs.

I am going to be writing next at length about the "relationships" between
Leo predicates, relations, views, attributes, work flow and (perhaps most
important) gui.

I would like to see a general user interface that would associate icons
with attributes/predicate/relation. That way the user can see all the nodes
with a given attribute. Stay tuned.

Edward

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Attributes vs. Relationships

[Largo84]

Got it (I used backlinks.py instead of backlink.py). Now, just need to 
decipher how to use it; not initially obvious (nothing in the plugin 
docstring by way of direction that I can find).

Rob

On Tuesday, February 16, 2016 at 11:40:30 PM UTC-5, Terry Brown wrote:
>
> On Tue, 16 Feb 2016 20:32:03 -0800 (PST) 
> Largo84 <lar...@gmail.com > wrote: 
>
> > Maybe a stupid question, but where do I find the plugin? It doesn't 
> > load from the standard GitHub repo. 
>
> They're in the standard repo. - let me check the names... 
>
> backlink.py 
> graphcanvas.py 
>
> from my settings @enabled-plugins, superseding any other spellings I 
> may have offered. 
>
> Not sure about Python 3 compatibility though... 
>
> Cheers -Terry 
>
> > Rob... 
> > 
> > 
> > On Tuesday, February 16, 2016 at 6:04:54 PM UTC-5, Terry Brown wrote: 
> > > 
> > > Hmm, well, at risk of sounding like a broken record, you could use 
> > > the backlinks plugin, the attached image shows A and B in their 
> > > "native" or "outline" relationship (or lack thereof) in the tree, 
> > > then in backlinks (middle pane) with a link via a node 
> > > "blocking_dependency" which is a rich relationship description with 
> > > "severity" and "description" components, and in the bottom pane in 
> > > graphcanvas plugin, which uses backlinks for its relationships 
> > > (they're two interfaces to the same info.). Sorry about the colors, 
> > > but the white arrow is the parent->child relationship of Nodes Y 
> > > and B, and the black arrows run through the "blocking_dependency" 
> > > relationship node as described. 
> > > 
> > > You could use the same approach in place of clones for gathering 
> > > nodes relevant to a particular bug or something, just link all the 
> > > nodes of interest to one otherwise unrelated "issue" node, which 
> > > perhaps resides in a list of such issues.  I'd tend to use 
> > > bookmarks plugin instead, although I'm realizing how much 
> > > redundancy there is between backlinks and bookmarks... hmm, they're 
> > > not really the same, phew ;-) 
> > > 
> > > I'm not sure how tractable the API is for using backlinks in 
> > > scripts, there's some support I think, and of course more can be 
> > > added if there's demand. 
> > > 
> > > Cheers -Terry 
> > > 
> > > -- 
> > > *From:* Largo84 <lar...@gmail.com > 
> > > *To:* leo-editor <leo-e...@googlegroups.com > 
> > > *Cc:* terry_...@yahoo.com  
> > > *Sent:* Tuesday, February 16, 2016 3:36 PM 
> > > *Subject:* Re: Attributes vs. Relationships 
> > > 
> > > Yes, Terry, that's a good description of what I envision. Is that 
> > > possible now? If so, I don't see the mechanism. How (where) would 
> > > you create that link? 
> > > 
> > > Rob. 
> > > 
> > > On Tuesday, February 16, 2016 at 4:25:13 PM UTC-5, Terry Brown 
> > > wrote: 
> > > 
> > > Something I think you run into here is nodes vs. edges 
> > > (connections) carrying information.  So two nodes are related: 
> > > 
> > > A -> B 
> > > 
> > > now you want to describe the relationship, "implements" (the 
> > > "source order" view) or "documents" or "todo_item" (issue / 
> > > ticket), whatever. 
> > > 
> > > Ok, so somehow you store those different flavors of relationship. 
> > > But now maybe you want to record priority, percent complete etc. on 
> > > the "todo_item" relation, or build documentation for different 
> > > contexts into the "documents" relationship.  Suddenly describing a 
> > > relationship needs a complex data structure..., maybe some 
> > > hierarchy... 
> > > 
> > > So you end up in a situation where you could effectively use a node 
> > > to describe the relationship: 
> > > 
> > > A -> x -> B 
> > > 
> > > where if x is a node with its own children etc., there's no 
> > > restriction on how complex the description of the relationship 
> > > between A and B can be. 
> > > 
> > > And maybe you also have 
> > > 
> > > M -> x -> N and S -> x -> T where the relationships between A and 
> > > B, M and N, and S and T are all the same and described 

Re: Attributes vs. Relationships

['Terry Brown' via leo-editor]

On Tue, 16 Feb 2016 20:32:03 -0800 (PST)
Largo84 <larg...@gmail.com> wrote:

> Maybe a stupid question, but where do I find the plugin? It doesn't
> load from the standard GitHub repo.

They're in the standard repo. - let me check the names...

backlink.py
graphcanvas.py

from my settings @enabled-plugins, superseding any other spellings I
may have offered.

Not sure about Python 3 compatibility though...

Cheers -Terry

> Rob...
> 
> 
> On Tuesday, February 16, 2016 at 6:04:54 PM UTC-5, Terry Brown wrote:
> >
> > Hmm, well, at risk of sounding like a broken record, you could use
> > the backlinks plugin, the attached image shows A and B in their
> > "native" or "outline" relationship (or lack thereof) in the tree,
> > then in backlinks (middle pane) with a link via a node
> > "blocking_dependency" which is a rich relationship description with
> > "severity" and "description" components, and in the bottom pane in
> > graphcanvas plugin, which uses backlinks for its relationships
> > (they're two interfaces to the same info.). Sorry about the colors,
> > but the white arrow is the parent->child relationship of Nodes Y
> > and B, and the black arrows run through the "blocking_dependency"
> > relationship node as described.
> >
> > You could use the same approach in place of clones for gathering
> > nodes relevant to a particular bug or something, just link all the
> > nodes of interest to one otherwise unrelated "issue" node, which
> > perhaps resides in a list of such issues.  I'd tend to use
> > bookmarks plugin instead, although I'm realizing how much
> > redundancy there is between backlinks and bookmarks... hmm, they're
> > not really the same, phew ;-)
> >
> > I'm not sure how tractable the API is for using backlinks in
> > scripts, there's some support I think, and of course more can be
> > added if there's demand.
> >
> > Cheers -Terry
> >
> > --
> > *From:* Largo84 <lar...@gmail.com >
> > *To:* leo-editor <leo-e...@googlegroups.com > 
> > *Cc:* terry_...@yahoo.com 
> > *Sent:* Tuesday, February 16, 2016 3:36 PM
> > *Subject:* Re: Attributes vs. Relationships
> >
> > Yes, Terry, that's a good description of what I envision. Is that
> > possible now? If so, I don't see the mechanism. How (where) would
> > you create that link?
> >
> > Rob.
> >
> > On Tuesday, February 16, 2016 at 4:25:13 PM UTC-5, Terry Brown
> > wrote:
> >
> > Something I think you run into here is nodes vs. edges
> > (connections) carrying information.  So two nodes are related:
> >
> > A -> B
> >
> > now you want to describe the relationship, "implements" (the
> > "source order" view) or "documents" or "todo_item" (issue /
> > ticket), whatever.
> >
> > Ok, so somehow you store those different flavors of relationship.
> > But now maybe you want to record priority, percent complete etc. on
> > the "todo_item" relation, or build documentation for different
> > contexts into the "documents" relationship.  Suddenly describing a
> > relationship needs a complex data structure..., maybe some
> > hierarchy... 
> >
> > So you end up in a situation where you could effectively use a node
> > to describe the relationship:
> >
> > A -> x -> B
> >
> > where if x is a node with its own children etc., there's no
> > restriction on how complex the description of the relationship
> > between A and B can be.
> >
> > And maybe you also have
> >
> > M -> x -> N and S -> x -> T where the relationships between A and
> > B, M and N, and S and T are all the same and described by the same
> > node 'x', so 'x' is a collecting point for nodes related in a
> > particular way.
> >
> > So Rob I'm not disagreeing with you or even perhaps responding to
> > what you're saying directly, just saying that I've seen "adding
> > descriptive elements to connections / edges / relationships" evolve
> > into "using nodes to describe connections" in the past.
> >
> > Cheers -Terry
> >
> >
> > --
> > *From:* Largo84 <lar...@gmail.com>
> > *To:* leo-editor <leo-e...@googlegroups.com> 
> > *Sent:* Tuesday, February 16, 2016 2:35 PM
> > *Subject:* Attributes vs. Relationships
> >
> > I'm following with much interest the recent discussio

Re: Attributes vs. Relationships

[Largo84]

Maybe a stupid question, but where do I find the plugin? It doesn't load 
from the standard GitHub repo.

Rob...


On Tuesday, February 16, 2016 at 6:04:54 PM UTC-5, Terry Brown wrote:
>
> Hmm, well, at risk of sounding like a broken record, you could use the 
> backlinks plugin, the attached image shows A and B in their "native" or 
> "outline" relationship (or lack thereof) in the tree, then in backlinks 
> (middle pane) with a link via a node "blocking_dependency" which is a rich 
> relationship description with "severity" and "description" components, and 
> in the bottom pane in graphcanvas plugin, which uses backlinks for its 
> relationships (they're two interfaces to the same info.). Sorry about the 
> colors, but the white arrow is the parent->child relationship of Nodes Y 
> and B, and the black arrows run through the "blocking_dependency" 
> relationship node as described.
>
> You could use the same approach in place of clones for gathering nodes 
> relevant to a particular bug or something, just link all the nodes of 
> interest to one otherwise unrelated "issue" node, which perhaps resides in 
> a list of such issues.  I'd tend to use bookmarks plugin instead, although 
> I'm realizing how much redundancy there is between backlinks and 
> bookmarks... hmm, they're not really the same, phew ;-)
>
> I'm not sure how tractable the API is for using backlinks in scripts, 
> there's some support I think, and of course more can be added if there's 
> demand.
>
> Cheers -Terry
>
> --
> *From:* Largo84 <lar...@gmail.com >
> *To:* leo-editor <leo-e...@googlegroups.com > 
> *Cc:* terry_...@yahoo.com 
> *Sent:* Tuesday, February 16, 2016 3:36 PM
> *Subject:* Re: Attributes vs. Relationships
>
> Yes, Terry, that's a good description of what I envision. Is that possible 
> now? If so, I don't see the mechanism. How (where) would you create that 
> link?
>
> Rob.
>
> On Tuesday, February 16, 2016 at 4:25:13 PM UTC-5, Terry Brown wrote:
>
> Something I think you run into here is nodes vs. edges (connections) 
> carrying information.  So two nodes are related:
>
> A -> B
>
> now you want to describe the relationship, "implements" (the "source 
> order" view) or "documents" or "todo_item" (issue / ticket), whatever.
>
> Ok, so somehow you store those different flavors of relationship. But now 
> maybe you want to record priority, percent complete etc. on the "todo_item" 
> relation, or build documentation for different contexts into the 
> "documents" relationship.  Suddenly describing a relationship needs a 
> complex data structure..., maybe some hierarchy... 
>
> So you end up in a situation where you could effectively use a node to 
> describe the relationship:
>
> A -> x -> B
>
> where if x is a node with its own children etc., there's no restriction on 
> how complex the description of the relationship between A and B can be.
>
> And maybe you also have
>
> M -> x -> N and S -> x -> T where the relationships between A and B, M and 
> N, and S and T are all the same and described by the same node 'x', so 'x' 
> is a collecting point for nodes related in a particular way.
>
> So Rob I'm not disagreeing with you or even perhaps responding to what 
> you're saying directly, just saying that I've seen "adding descriptive 
> elements to connections / edges / relationships" evolve into "using nodes 
> to describe connections" in the past.
>
> Cheers -Terry
>
>
> --
> *From:* Largo84 <lar...@gmail.com>
> *To:* leo-editor <leo-e...@googlegroups.com> 
> *Sent:* Tuesday, February 16, 2016 2:35 PM
> *Subject:* Attributes vs. Relationships
>
> I'm following with much interest the recent discussions on data structures 
> and possible new directions for Leo. Sorry in advance if this new post 
> hashes old ground, but it seemed to be somewhat of a different approach (or 
> question).
>
> It would be really cool to better expose the uA's and make them truly 
> useful. However, I see them as merely metadata (like tags in media files). 
> What would also be useful is to describe in some meaningful way the 
> *nature* of a data relationship between elements (objects or 'nodes' in 
> the Leo sense). Looking at the wikipedia article on DAGs 
> <https://en.wikipedia.org/wiki/Directed_acyclic_graph>, I see the 
> directed vectors (arrows), but don't see how those describe what the 
> 'nature' of the relationship is between objects, just a direction (of 

Re: Attributes vs. Relationships

['Terry Brown' via leo-editor]

Hmm, well, at risk of sounding like a broken record, you could use the 
backlinks plugin, the attached image shows A and B in their "native" or 
"outline" relationship (or lack thereof) in the tree, then in backlinks (middle 
pane) with a link via a node "blocking_dependency" which is a rich relationship 
description with "severity" and "description" components, and in the bottom 
pane in graphcanvas plugin, which uses backlinks for its relationships (they're 
two interfaces to the same info.). Sorry about the colors, but the white arrow 
is the parent->child relationship of Nodes Y and B, and the black arrows run 
through the "blocking_dependency" relationship node as described.
You could use the same approach in place of clones for gathering nodes relevant 
to a particular bug or something, just link all the nodes of interest to one 
otherwise unrelated "issue" node, which perhaps resides in a list of such 
issues.  I'd tend to use bookmarks plugin instead, although I'm realizing how 
much redundancy there is between backlinks and bookmarks... hmm, they're not 
really the same, phew ;-)
I'm not sure how tractable the API is for using backlinks in scripts, there's 
some support I think, and of course more can be added if there's demand.
Cheers -Terry
 
  From: Largo84 <larg...@gmail.com>
 To: leo-editor <leo-editor@googlegroups.com> 
Cc: terry_n_br...@yahoo.com
 Sent: Tuesday, February 16, 2016 3:36 PM
 Subject: Re: Attributes vs. Relationships
   
Yes, Terry, that's a good description of what I envision. Is that possible now? 
If so, I don't see the mechanism. How (where) would you create that link?
Rob.

On Tuesday, February 16, 2016 at 4:25:13 PM UTC-5, Terry Brown wrote:
Something I think you run into here is nodes vs. edges (connections) carrying 
information.  So two nodes are related:
    A -> B
now you want to describe the relationship, "implements" (the "source order" 
view) or "documents" or "todo_item" (issue / ticket), whatever.
Ok, so somehow you store those different flavors of relationship. But now maybe 
you want to record priority, percent complete etc. on the "todo_item" relation, 
or build documentation for different contexts into the "documents" 
relationship.  Suddenly describing a relationship needs a complex data 
structure..., maybe some hierarchy... 
So you end up in a situation where you could effectively use a node to describe 
the relationship:
A -> x -> B
where if x is a node with its own children etc., there's no restriction on how 
complex the description of the relationship between A and B can be.
And maybe you also have
M -> x -> N and S -> x -> T where the relationships between A and B, M and N, 
and S and T are all the same and described by the same node 'x', so 'x' is a 
collecting point for nodes related in a particular way.
So Rob I'm not disagreeing with you or even perhaps responding to what you're 
saying directly, just saying that I've seen "adding descriptive elements to 
connections / edges / relationships" evolve into "using nodes to describe 
connections" in the past.
Cheers -Terry

 
  From: Largo84 <lar...@gmail.com>
 To: leo-editor <leo-e...@googlegroups.com> 
 Sent: Tuesday, February 16, 2016 2:35 PM
 Subject: Attributes vs. Relationships
  
I'm following with much interest the recent discussions on data structures and 
possible new directions for Leo. Sorry in advance if this new post hashes old 
ground, but it seemed to be somewhat of a different approach (or question).
It would be really cool to better expose the uA's and make them truly useful. 
However, I see them as merely metadata (like tags in media files). What would 
also be useful is to describe in some meaningful way the nature of a data 
relationship between elements (objects or 'nodes' in the Leo sense). Looking at 
the wikipedia article on DAGs, I see the directed vectors (arrows), but don't 
see how those describe what the 'nature' of the relationship is between 
objects, just a direction (of course, I may be missing something obvious).
As an example, consider how MusicBrainz describes advanced relationships (ARs). 
A music track (like on a CD) may have a relationship with a composition (work) 
and that relationship is described in a somewhat 'symmetrical' way, such that 
the given work is 'related' to multiple recordings and the track may be related 
to multiple compositions (eg. medleys). These relationship 'descriptors' are 
directional which prevents recursion problems.
It seems to me that the only relationship inherent in the Leo data model is one 
of Parent/Child (and maybe Sibling). I suppose that's what makes it a DAG. Is 
it possible to describe other arbitrary types of relationships between objects 
(nodes) that goes beyond simply assigning a uA (tag) to a node. 

Re: Attributes vs. Relationships

[Largo84]

Yes, Terry, that's a good description of what I envision. Is that possible 
now? If so, I don't see the mechanism. How (where) would you create that 
link?

Rob.

On Tuesday, February 16, 2016 at 4:25:13 PM UTC-5, Terry Brown wrote:
>
> Something I think you run into here is nodes vs. edges (connections) 
> carrying information.  So two nodes are related:
>
> A -> B
>
> now you want to describe the relationship, "implements" (the "source 
> order" view) or "documents" or "todo_item" (issue / ticket), whatever.
>
> Ok, so somehow you store those different flavors of relationship. But now 
> maybe you want to record priority, percent complete etc. on the "todo_item" 
> relation, or build documentation for different contexts into the 
> "documents" relationship.  Suddenly describing a relationship needs a 
> complex data structure..., maybe some hierarchy... 
>
> So you end up in a situation where you could effectively use a node to 
> describe the relationship:
>
> A -> x -> B
>
> where if x is a node with its own children etc., there's no restriction on 
> how complex the description of the relationship between A and B can be.
>
> And maybe you also have
>
> M -> x -> N and S -> x -> T where the relationships between A and B, M and 
> N, and S and T are all the same and described by the same node 'x', so 'x' 
> is a collecting point for nodes related in a particular way.
>
> So Rob I'm not disagreeing with you or even perhaps responding to what 
> you're saying directly, just saying that I've seen "adding descriptive 
> elements to connections / edges / relationships" evolve into "using nodes 
> to describe connections" in the past.
>
> Cheers -Terry
>
>
> --
> *From:* Largo84 <lar...@gmail.com >
> *To:* leo-editor <leo-e...@googlegroups.com > 
> *Sent:* Tuesday, February 16, 2016 2:35 PM
> *Subject:* Attributes vs. Relationships
>
> I'm following with much interest the recent discussions on data structures 
> and possible new directions for Leo. Sorry in advance if this new post 
> hashes old ground, but it seemed to be somewhat of a different approach (or 
> question).
>
> It would be really cool to better expose the uA's and make them truly 
> useful. However, I see them as merely metadata (like tags in media files). 
> What would also be useful is to describe in some meaningful way the 
> *nature* of a data relationship between elements (objects or 'nodes' in 
> the Leo sense). Looking at the wikipedia article on DAGs 
> <https://en.wikipedia.org/wiki/Directed_acyclic_graph>, I see the 
> directed vectors (arrows), but don't see how those describe what the 
> 'nature' of the relationship is between objects, just a direction (of 
> course, I may be missing something obvious).
>
> As an example, consider how MusicBrainz <https://musicbrainz.org/doc/Work> 
> describes advanced relationships (ARs). A music track (like on a CD) may 
> have a relationship with a composition (work) and that relationship is 
> described in a somewhat 'symmetrical' way, such that the given work is 
> 'related' to multiple recordings and the track may be related to multiple 
> compositions (eg. medleys). These relationship 'descriptors' are 
> directional which prevents recursion problems.
>
> It seems to me that the only relationship inherent in the Leo data model 
> is one of Parent/Child (and maybe Sibling). I suppose that's what makes it 
> a DAG. Is it possible to describe other arbitrary types of relationships 
> between objects (nodes) that goes beyond simply assigning a uA (tag) to a 
> node. Maybe that uA may also be a relationship 'type' that creates a 'link' 
> between two or more nodes. Maybe this also creates opportunities to create 
> multiple 'views' based on relationship types other than the native 
> Parent/Child.
>
> Rob..
> -- 
> You received this message because you are subscribed to the Google Groups 
> "leo-editor" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to leo-editor+...@googlegroups.com .
> To post to this group, send email to leo-e...@googlegroups.com 
> .
> Visit this group at https://groups.google.com/group/leo-editor.
> For more options, visit https://groups.google.com/d/optout.
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Attributes vs. Relationships

['Terry Brown' via leo-editor]

Something I think you run into here is nodes vs. edges (connections) carrying 
information.  So two nodes are related:
    A -> B
now you want to describe the relationship, "implements" (the "source order" 
view) or "documents" or "todo_item" (issue / ticket), whatever.
Ok, so somehow you store those different flavors of relationship. But now maybe 
you want to record priority, percent complete etc. on the "todo_item" relation, 
or build documentation for different contexts into the "documents" 
relationship.  Suddenly describing a relationship needs a complex data 
structure..., maybe some hierarchy... 
So you end up in a situation where you could effectively use a node to describe 
the relationship:
A -> x -> B
where if x is a node with its own children etc., there's no restriction on how 
complex the description of the relationship between A and B can be.
And maybe you also have
M -> x -> N and S -> x -> T where the relationships between A and B, M and N, 
and S and T are all the same and described by the same node 'x', so 'x' is a 
collecting point for nodes related in a particular way.
So Rob I'm not disagreeing with you or even perhaps responding to what you're 
saying directly, just saying that I've seen "adding descriptive elements to 
connections / edges / relationships" evolve into "using nodes to describe 
connections" in the past.
Cheers -Terry

 
  From: Largo84 <larg...@gmail.com>
 To: leo-editor <leo-editor@googlegroups.com> 
 Sent: Tuesday, February 16, 2016 2:35 PM
 Subject: Attributes vs. Relationships
   
I'm following with much interest the recent discussions on data structures and 
possible new directions for Leo. Sorry in advance if this new post hashes old 
ground, but it seemed to be somewhat of a different approach (or question).
It would be really cool to better expose the uA's and make them truly useful. 
However, I see them as merely metadata (like tags in media files). What would 
also be useful is to describe in some meaningful way the nature of a data 
relationship between elements (objects or 'nodes' in the Leo sense). Looking at 
the wikipedia article on DAGs, I see the directed vectors (arrows), but don't 
see how those describe what the 'nature' of the relationship is between 
objects, just a direction (of course, I may be missing something obvious).
As an example, consider how MusicBrainz describes advanced relationships (ARs). 
A music track (like on a CD) may have a relationship with a composition (work) 
and that relationship is described in a somewhat 'symmetrical' way, such that 
the given work is 'related' to multiple recordings and the track may be related 
to multiple compositions (eg. medleys). These relationship 'descriptors' are 
directional which prevents recursion problems.
It seems to me that the only relationship inherent in the Leo data model is one 
of Parent/Child (and maybe Sibling). I suppose that's what makes it a DAG. Is 
it possible to describe other arbitrary types of relationships between objects 
(nodes) that goes beyond simply assigning a uA (tag) to a node. Maybe that uA 
may also be a relationship 'type' that creates a 'link' between two or more 
nodes. Maybe this also creates opportunities to create multiple 'views' based 
on relationship types other than the native Parent/Child.
Rob..-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.


   

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Attributes vs. Relationships

[Largo84]

I'm following with much interest the recent discussions on data structures 
and possible new directions for Leo. Sorry in advance if this new post 
hashes old ground, but it seemed to be somewhat of a different approach (or 
question).

It would be really cool to better expose the uA's and make them truly 
useful. However, I see them as merely metadata (like tags in media files). 
What would also be useful is to describe in some meaningful way the *nature* 
of a data relationship between elements (objects or 'nodes' in the Leo 
sense). Looking at the wikipedia article on DAGs 
, I see the directed 
vectors (arrows), but don't see how those describe what the 'nature' of the 
relationship is between objects, just a direction (of course, I may be 
missing something obvious).

As an example, consider how MusicBrainz  
describes advanced relationships (ARs). A music track (like on a CD) may 
have a relationship with a composition (work) and that relationship is 
described in a somewhat 'symmetrical' way, such that the given work is 
'related' to multiple recordings and the track may be related to multiple 
compositions (eg. medleys). These relationship 'descriptors' are 
directional which prevents recursion problems.

It seems to me that the only relationship inherent in the Leo data model is 
one of Parent/Child (and maybe Sibling). I suppose that's what makes it a 
DAG. Is it possible to describe other arbitrary types of relationships 
between objects (nodes) that goes beyond simply assigning a uA (tag) to a 
node. Maybe that uA may also be a relationship 'type' that creates a 'link' 
between two or more nodes. Maybe this also creates opportunities to create 
multiple 'views' based on relationship types other than the native 
Parent/Child.

Rob..

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.