Graph not hierarchical?

Graph not hierarchical?

[Lawrence Bottorff]

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

Re: Graph not hierarchical?

[Eric S Fraga]

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

Re: Graph not hierarchical?

[Lawrence Bottorff]

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

Re: Graph not hierarchical?

[Eric S Fraga]

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

Re: Graph not hierarchical?

[Brett Viren]

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

Re: Graph not hierarchical?

[Nick Dokos]

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

Re: Graph not hierarchical?

[Samuel Wales]

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.

Re: Graph not hierarchical?

[Samuel Wales]

s/more than one other place in/more than one other place from/

Re: Graph not hierarchical?

[Samuel Wales]

there is also <<this syntax>>.

Re: Graph not hierarchical?

[Lawrence Bottorff]

[-- Attachment #1: Type: text/plain, Size: 233 bytes --]

Is this ID spoken of? http://orgmode.org/worg/org-api/org-id-api.html

So far it's just a field in Property, correct?


On Tue, Feb 18, 2014 at 12:46 PM, Samuel Wales <samologist@gmail.com> wrote:

> there is also <<this syntax>>.
>

[-- Attachment #2: Type: text/html, Size: 638 bytes --]

Re: Graph not hierarchical?

[Bastien]

Hi Lawrence,

Lawrence Bottorff <borgauf@gmail.com> writes:

> Is this ID spoken
> of? http://orgmode.org/worg/org-api/org-id-api.html

Yes, but this API documentation is old and should be removed.

> So far it's just a field in Property, correct?

Correct.

-- 
 Bastien