* Graph not hierarchical?
@ 2014-02-15 2:58 Lawrence Bottorff
2014-02-15 10:44 ` Eric S Fraga
0 siblings, 1 reply; 11+ messages in thread
From: Lawrence Bottorff @ 2014-02-15 2:58 UTC (permalink / raw)
To: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 1664 bytes --]
Is there any way to have org mode simulate a graph structure rather than
always a (folding) hierarchy? You could say a hierarchy is a tree graph,
and you could "link" or give a "jump" from one entry to another -- even in
another org file. It seems plausible to call an entry a "node," and a node
could have listed in its properties "edges" leading to other nodes. Has
anyone else thought of this?
Without knowing anything about how org mode is really coded under the hood,
I'm guessing (from reading the documentation) it is simply built on the
emacs folding code, i.e., there is no real underlying hierarchy
algorithm(s) that you could hack into in order to make org mode more
database-like (tree, graph, or otherwise).
Some of these thoughts came from the simple examples given in "Land of
Lisp" where a simple nodes and edges representation was given with a-lists:
(defparameter *nodes* '(living-room garden attic))
(defparameter *edges* '((living-room (garden west door)
(attic upstairs ladder))
(garden (living-room east door))
(attic (living-room downstairs ladder))))
The nodes are living-room, attic, and garden. And the edges are an a-list
keyed on the nodes, e.g., living-room has two edges, one connected to the
attic (upstairs by way of a ladder), the other to the garden (to the west
by way of a door).
I guess this is beginning to sound like a weak graph database hack, but as
I envisioned it, each node -- an org mode entry -- could be leveraging org
mode's big strengths: literate programming and loose, do-it-yourself text
data storage.
LB
North Shore MN
[-- Attachment #2: Type: text/html, Size: 1996 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Graph not hierarchical?
2014-02-15 2:58 Graph not hierarchical? Lawrence Bottorff
@ 2014-02-15 10:44 ` Eric S Fraga
2014-02-15 15:34 ` Lawrence Bottorff
0 siblings, 1 reply; 11+ messages in thread
From: Eric S Fraga @ 2014-02-15 10:44 UTC (permalink / raw)
To: Lawrence Bottorff; +Cc: emacs-orgmode
Lawrence Bottorff <borgauf@gmail.com> writes:
> Is there any way to have org mode simulate a graph structure rather than
> always a (folding) hierarchy?
Sure: you could superimpose a graph structure using headline
properties. You could define CHILDREN, PARENT, NODES, NEXT, PREVIOUS,
... types of properties entries and write emacs lisp code to process
these. Not sure what you want to do accomplish in the end, mind you...
--
: Eric S Fraga (0xFFFCF67D), Emacs 24.3.50.2, Org release_8.2.5h-608-g27a978
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Graph not hierarchical?
2014-02-15 10:44 ` Eric S Fraga
@ 2014-02-15 15:34 ` Lawrence Bottorff
2014-02-15 21:05 ` Eric S Fraga
` (2 more replies)
0 siblings, 3 replies; 11+ messages in thread
From: Lawrence Bottorff @ 2014-02-15 15:34 UTC (permalink / raw)
To: Lawrence Bottorff, emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 1083 bytes --]
Org mode seems to lack data extraction/insertion. There's agenda view, but
that's just one method. Obviously, you could use things like grep or other
command-line Unix utilities, but being able to organize and extract based
on your stuff being stored graph-aware would be nice, IMHO. Being able to
traverse a graph data structure and do an add or read or whatever would be
great, IHMO. You'd have the benefits of a database with all the good stuff
about org mode retained.
On Sat, Feb 15, 2014 at 4:44 AM, Eric S Fraga <e.fraga@ucl.ac.uk> wrote:
> Lawrence Bottorff <borgauf@gmail.com> writes:
>
> > Is there any way to have org mode simulate a graph structure rather than
> > always a (folding) hierarchy?
>
> Sure: you could superimpose a graph structure using headline
> properties. You could define CHILDREN, PARENT, NODES, NEXT, PREVIOUS,
> ... types of properties entries and write emacs lisp code to process
> these. Not sure what you want to do accomplish in the end, mind you...
>
> --
> : Eric S Fraga (0xFFFCF67D), Emacs 24.3.50.2, Org
> release_8.2.5h-608-g27a978
>
[-- Attachment #2: Type: text/html, Size: 1557 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Graph not hierarchical?
2014-02-15 15:34 ` Lawrence Bottorff
@ 2014-02-15 21:05 ` Eric S Fraga
2014-02-18 17:18 ` Brett Viren
2014-02-18 18:33 ` Samuel Wales
2 siblings, 0 replies; 11+ messages in thread
From: Eric S Fraga @ 2014-02-15 21:05 UTC (permalink / raw)
To: Lawrence Bottorff; +Cc: emacs-orgmode
Lawrence Bottorff <borgauf@gmail.com> writes:
> Org mode seems to lack data extraction/insertion.
Check out
http://orgmode.org/worg/dev/org-syntax.html
and maybe org-element.el in the org mode distribution you are using.
I've not tried the org element parser but others on this list have so
I'm sure you can get some advice from them.
--
: Eric S Fraga (0xFFFCF67D), Emacs 24.3.50.2, Org release_8.2.5h-633-gec0998
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Graph not hierarchical?
2014-02-15 15:34 ` Lawrence Bottorff
2014-02-15 21:05 ` Eric S Fraga
@ 2014-02-18 17:18 ` Brett Viren
2014-02-18 18:00 ` Nick Dokos
2014-02-18 18:33 ` Samuel Wales
2 siblings, 1 reply; 11+ messages in thread
From: Brett Viren @ 2014-02-18 17:18 UTC (permalink / raw)
To: Lawrence Bottorff; +Cc: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 492 bytes --]
Lawrence Bottorff <borgauf@gmail.com> writes:
> being able to organize and
> extract based on your stuff being stored graph-aware would be nice,
> IMHO.
I'm by no means an expert on this but I know org-element-parse-buffer
returns a data structure which is a directed-graph.
http://orgmode.org/worg/org-api/org-element-api.html
Note, each node has a :parent reference which makes the data structure
circular. Traversing it must take this feature into account.
-Brett.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Graph not hierarchical?
2014-02-18 17:18 ` Brett Viren
@ 2014-02-18 18:00 ` Nick Dokos
0 siblings, 0 replies; 11+ messages in thread
From: Nick Dokos @ 2014-02-18 18:00 UTC (permalink / raw)
To: emacs-orgmode
Brett Viren <bv@bnl.gov> writes:
> Lawrence Bottorff <borgauf@gmail.com> writes:
>
>> being able to organize and
>> extract based on your stuff being stored graph-aware would be nice,
>> IMHO.
>
> I'm by no means an expert on this but I know org-element-parse-buffer
> returns a data structure which is a directed-graph.
>
> http://orgmode.org/worg/org-api/org-element-api.html
>
> Note, each node has a :parent reference which makes the data structure
> circular. Traversing it must take this feature into account.
>
I thought Lawrence was looking for a way to *impose* a graph structure
on his data (stored in an org file, augmented with whatever is necessary
to implement his graph(s)). org-element-parse-buffer returns a graph
(actually, it's probably closer to a tree) which reflects the *internal*
structure of the org document.
In some ways, the analogy here is between a Unix file (internal structure:
sequence of bytes, operations: open/close/read/write/seek/etc) on one
hand, and a structured file: e.g. compiling a program
into some intermediate language and storing the result into a file.
The file itself doesn't know anything about the structure of its
contents: the contents are just a sequence of bytes. But there are
tools (compilers, loaders, assemblers, debuggers, etc.) that
"understand" the superimposed structure.
Similarly here, we have an ordinary org file, but it contains additional
stuff that allow other tools to do special things (e.g. cross-link
sections of the document into a directed graph). Org itself provides
certain mechanisms that *could* be used for that (properties, links)
but would not itself "understand" the additional structure. You'd need
other tools (probably built on top of org-element-*) to do that.
The challenge here is that you can impose structure in a very specific
manner, so that both the structure and the tools are only useful in a
very specific setting. Or you try to come with generic structure and
generic tools that can accommodate a variety of applications. The
balance between these two extremes (surgical scalpel vs kitchen sink) is
very much a matter of need, taste and experience.
That's my understanding - I hope I have not misrepresented the situation
too much.
--
Nick
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Graph not hierarchical?
2014-02-15 15:34 ` Lawrence Bottorff
2014-02-15 21:05 ` Eric S Fraga
2014-02-18 17:18 ` Brett Viren
@ 2014-02-18 18:33 ` Samuel Wales
2014-02-18 18:36 ` Samuel Wales
2 siblings, 1 reply; 11+ messages in thread
From: Samuel Wales @ 2014-02-18 18:33 UTC (permalink / raw)
To: Lawrence Bottorff; +Cc: emacs-orgmode
hi lawrence,
as eric and nick pointed out, you can use properties with org-id to
implement arbitrary graphs. you will have to write the code to select
the children and go to them and go back. org-id's work well.
if you want to point to any non-header object, it will not work. for
example, a word in a paragraph. you can point from a word using a
link, but only to one other place. pointing to a word is not
possible.
there is a much more general-purpose approach called id markers.
these are tokens that contain an org-id. you can place them anywhere
and point to them and from them. wherever you place them is a node.
so you can put them on a word. you can point to more than one other
place in an id marker. you can move them and everything that points
to them will still point to them. there are various options for how
to display them etc.
one thread that talks about them is "Feature request: IDs on anything".
however: id markers are vaporware, just like using properties. :)
samuel
On 2/15/14, Lawrence Bottorff <borgauf@gmail.com> wrote:
> Org mode seems to lack data extraction/insertion. There's agenda view, but
> that's just one method. Obviously, you could use things like grep or other
> command-line Unix utilities, but being able to organize and extract based
> on your stuff being stored graph-aware would be nice, IMHO. Being able to
> traverse a graph data structure and do an add or read or whatever would be
> great, IHMO. You'd have the benefits of a database with all the good stuff
> about org mode retained.
>
>
> On Sat, Feb 15, 2014 at 4:44 AM, Eric S Fraga <e.fraga@ucl.ac.uk> wrote:
>
>> Lawrence Bottorff <borgauf@gmail.com> writes:
>>
>> > Is there any way to have org mode simulate a graph structure rather
>> > than
>> > always a (folding) hierarchy?
>>
>> Sure: you could superimpose a graph structure using headline
>> properties. You could define CHILDREN, PARENT, NODES, NEXT, PREVIOUS,
>> ... types of properties entries and write emacs lisp code to process
>> these. Not sure what you want to do accomplish in the end, mind you...
>>
>> --
>> : Eric S Fraga (0xFFFCF67D), Emacs 24.3.50.2, Org
>> release_8.2.5h-608-g27a978
>>
>
--
The Kafka Pandemic: http://thekafkapandemic.blogspot.com
The disease DOES progress. MANY people have died from it. ANYBODY can get it.
Denmark: free Karina Hansen NOW.
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2014-03-01 7:27 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-02-15 2:58 Graph not hierarchical? Lawrence Bottorff
2014-02-15 10:44 ` Eric S Fraga
2014-02-15 15:34 ` Lawrence Bottorff
2014-02-15 21:05 ` Eric S Fraga
2014-02-18 17:18 ` Brett Viren
2014-02-18 18:00 ` Nick Dokos
2014-02-18 18:33 ` Samuel Wales
2014-02-18 18:36 ` Samuel Wales
2014-02-18 18:46 ` Samuel Wales
2014-02-20 3:11 ` Lawrence Bottorff
2014-03-01 7:26 ` Bastien
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.