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 <javascript:>> > *To:* leo-editor <leo-e...@googlegroups.com <javascript:>> > *Cc:* terry_...@yahoo.com <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 <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 > <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 leo-editor+...@googlegroups.com <javascript:>. > To post to this group, send email to leo-e...@googlegroups.com > <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 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.
