Re: [xdi] XDI Grapher

[Drummond Reed <drummond.reed@xdi.org>]

What I was thinking is that the left margin of each box (I'm going to call them "cells" now because this is so much like spreadsheets) would be fixed by the contents of the cell above it (its XDI parent cell), and the right border of the widest cell in that column would become the left border for the cells below it (its XDI child cells).

If we took this approach, we'd have two options:

1) Equal width, where the longest string in any cell of any column determines the full column width, and all cells in that column have that same width. This is the way spreadsheets work.

2) Variable width, where the width of a subject determines the width of that cell alone; the width of the widest predicate on that subject determines the width of the second column for all of that subject's predicates (but not for other subject's predicates); the width of the widest object on that predicate determines the width
of the third column for all of that predicate's objects (but not for
other predicate's objects), etc.

Of these two, I prefer equal width, since it's probably both easier to graph and easier to follow. Also, in an equal width graph, it would be easy to see that the first column always represents XDI subjects, the second column XDI predicates, the third column XDI objects, the fourth column is XDI subcontext subjects, etc. We might even emphasize this by giving the borders of all cells in that column the same color, i.e., first column red, second column blue, third column green, then repeat.

In crude ASCII graphics (providing your email client is showing the below in a fixed width font), this would look like:

|=drummond|
          |+b            |
                         |+c               |
          |+email        |
                         |"dsr@example.com"|
|=markus  |
          |+nickname$l$en|
                         |"Mr. XDI"        |

If you did this, my one other suggestion would be to set a maximum length for cells containing literals, and if they exceed this length, show only the portion that fits within the maximum length (again, just like a spreadsheet). That way the column widths will be determined primarily by the length of the XRIs, and not by the length of the data values.

Whadayathink?

=Drummond

On Sat, Jan 2, 2010 at 3:55 PM, Markus Sabadello <markus.sabadello@xdi.org> wrote:

Hmm are you saying the box should grow horizontally to make the XRI fit into it? Yes that wouldn't be hard, but then subjects/predicates/etc wouldn't be directly above/below each other anymore, which I thought was one of the main ideas behind this notation.

In order words, right now each "addressing level" takes you further right by exactly 1 box size. If I start dynamically changing box sizes, that wouldn't be the case anymore.

Markus

On Sat, Jan 2, 2010 at 10:55 PM, Drummond Reed <drummond.reed@xdi.org> wrote:

Also, I found one other bug: when you input a literal it sizes the box to fit the literal, but when you input an XRI longer than will fit in the box, it doesn't "word wrap" the box size to fit the XRI.

If you can set it to adjust the box size to fit the XRI, then XDI Grapher would be able to produce a box graph of any XDI document. Killer!

Thanks,

=Drummond

On Sat, Jan 2, 2010 at 1:52 PM, Drummond Reed <drummond.reed@xdi.org> wrote:

Markus,

Amazing!!! As soon as I saw your mail I realized what you had been up to, but I had no idea how easy or fun it would be to play with XDI Grapher. This is going to be a fantastic XDI teaching tool!

RE the B4 example (which applies to the XRI [+a+b+c]), I think the problem is in the way you are implementing the associative semantics. You in fact are following exactly the path I did in originally developing the box graphing notation. I thought the box graph for +a+b+c would look just like what XDI grapher currently shows for +a+b+c. However, because of the associative semantics of $has statements, all of the XDI RDF statements listed for the B4 example should produce the same box graph.

For example, both of the following XDI addresses...

  (+a/(+b/+c))
  ((+a/+b)/+c)

...reduce to the XRI +a+b+c.

So the rule I followed was that box graph for any set of $has statements (whether expanded or contracted) was the union of the box graphs of all of the $has statements that are equivalent. The result is always a completely filled grid of x^2 boxes where x is the number of XRI subsegments.

Give me a ring on Skype when you have time and let's discuss it.

Thanks again for the fantastic New Year's present!

=Drummond

On Sat, Jan 2, 2010 at 12:29 AM, Markus Sabadello <markus.sabadello@gmail.com> wrote:

I couldn't help, there was this voice in my head that kept telling me I had to try this:
http://graceland.parityinc.net/xdi-grapher/XDIGrapher

Unfortunately the tool isn't 100% consistent with the examples in
http://www.oasis-open.org/committees/download.php/35590/xdi-rdf-box-graphs-v2.pdf

In particular, the examples in B4 don't yield the same results.
Not sure if that's a problem with the notation or with the $has semantics, or if I just didn't implement it correctly.

Anyway it should be a fun tool to experiment with.. Happy new year..

Markus