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]>
To: leo-editor <[email protected]>
Cc: [email protected]
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, 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+...@ googlegroups.com.
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.
--
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.
--
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.
