[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [O] Graph not hierarchical?

From: Nick Dokos
Subject: Re: [O] Graph not hierarchical?
Date: Tue, 18 Feb 2014 13:00:22 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux)

Brett Viren <address@hidden> writes:

> Lawrence Bottorff <address@hidden> 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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]