On Tue, 16 Feb 2016 20:32:03 -0800 (PST) Largo84 <[email protected]> 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 <[email protected] <javascript:>> > > *To:* leo-editor <[email protected] <javascript:>> > > *Cc:* [email protected] <javascript:> > > *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 <[email protected]> > > *To:* leo-editor <[email protected]> > > *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 [email protected]. > > > > Visit this group at https://groups.google.com/ group/leo-editor > > <https://groups.google.com/group/leo-editor>. > > For more options, visit https://groups.google.com/d/ optout > > <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 [email protected] <javascript:>. > > To post to this group, send email to [email protected] > > <javascript:>. > > 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
