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 [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.
