How does this differ from zzstructure(hyperthogonal structure)?

Hyperthogonality is a new idea to me, and very cool. It's like a graph plus a local concept of space. Each cell can have up to four neighbors (up, down, left and right), with the constraint that if A is above B, then B must be below A, and if A is left of B, then B must be right of A.

When you use a tree to organize your data, too, there's an implicit notion of space: The directions up (toward the root), down (toward the leaves), and the two other directions (across siblings). It is up to the user to decide what those directions mean. Hyperthogonal data seems to offer a similar experience: Now your data is free to be cyclic, but still it is up to the user to decide what each direction means, and there are only so many directions to use.

In DWT, relationships are semantic, not spatial. If you want to record the fact that Barney is purple, you would enter "Barney #is purple". That would create (if they are not already present) expressions representing "Barney", "purple", the relationship template " is ", and the relationship "Barney #is purple".

The number of kinds of relationships that Barney can be involved in has no limit: "Barney #needs food", "Barney #(appears on) television", "Barney #was popular #in the early 2000s" (notice that that's a relationship with three members), "(Barney #is funny) #because (Barney #makes weird noises)" (that's a relationship between two relationships) ...

Given that expression and others, you can then ask for all the things that are purple ("/it #is purple"), or all the things Barney is ("Barney #is /it"), or every consequence of Barney being purple ("/it #because (Barney #is purple)") ...

DWT offers a flexible representation of information (the RSLT) and a language for querying that information (Hash). The representation and querying are separate concerns from how the data is displayed. Currently, query results are a simple list, but spatial display is on the to-do list -- both hierarchical (tree-like) and tabular displays.

I've closed this issue but added it to the FAQ. If you're still not satisfied, please, feel free to ask more questions.

Thanks!

Also, I have two new questions, how does RSLT compare to:

Ultragraphs
Ubergraphs

See this presentation deck for (vague, but pretty) details on both, specifically PDF pages 9 to 13:

http://www.storageconference.us/2018/Presentations/BigData-tutorial-1.pdf

This paper for (minimal) details on Ultragraphs, specifically PDF pages 5 to 6:

https://avesterra.georgetown.edu/sites/avesterra/files/avesterra_formalization.pdf

And this paper for details on (Undirected) Ubergraphs, which claims that Ubergraphs directly generalize Hypergraphs, neglecting to mention the (admittedly rather trivial) intermediate step of Ultragraphs:

https://arxiv.org/abs/1704.05547

Thanks!

Ubergraphs and RSLTs look like they're the same thing.

The authors of the Ubergraph paper have attached a lot of math to the data structure, which I don't immediately see a reason to be interested in -- what I care about is representing and querying knowledge. I think they might not be, because they don't talk about labeling the relationships. In the RSLT the templates are the relationship labels. Labels are critical -- otherwise the relationship "lion <-> gazelle" could be "lion dreams of gazelle" or "lion assembles dollhouse after gazelle shimmies down a halfpipe" or anything. Linear text with a hole corresponding to each member seems like the most natural way to label a relationship: " uses to ", or "not ", or " is a ".

They also talk about how an Ubergraph is better than an Ultragraph because Ubergraphs give you recursive relationshipss. I see no natural representation of an Ultragraph that is not an Ubergraph. The RSLT, for instance, I designed with only the intention of n-ary nested relationships, and it gave me recursion for free. I think it's the simplest possible implementation. In it relationships, relationship templates, and atoms are all elements of the same set ("nodes"), and the fields of a relationship are nodes. A relationship has nodes, and a relationship is a node, therefore recursion is possible.

It's a good thing, because recursion is a property of the universe. "Is a relationship," for instance, is a relationship that applies to all relationships, including those (unary) relationships in which it is applied to other relationships.

The AvesTerra idea seems to involve them picking a few kinds of metadata they think are important (precision of measurement, for example) and elevating them above other possible kinds of meta-information (such as authors who disagree). It's certainly possible you would want to represent some metadata differently from others. The time at which a relationship was created, for instance, might be so ubiquitous that you would prefer to add a Timestamp field to your relationships, rather than use three objects to represent "X was created at time T". But that's an implementation detail that the backend programmer should hide, I believe, from the frontend user. I prefer the RSLT (or, if indeed it's equivalent, the Ubergraph), which presents a uniform and simpler interface to the user, while allowing for the possibility of complicating it behind the scenes.

On Mon, Aug 27, 2018 at 6:01 AM no_identd notifications@github.com wrote:

Thanks!

Also, I have two new questions, how does RSLT compare to:

Ultragraphs

Ubergraphs

See this presentation deck for (vague, but pretty) details on both, specifically PDF pages 9 to 13:

http://www.storageconference.us/2018/Presentations/BigData-tutorial-1.pdf

This paper for (minimal) details on Ultragraphs, specifically PDF pages 5 to 6:

https://avesterra.georgetown.edu/sites/avesterra/files/avesterra_formalization.pdf

And this paper for details on (Undirected) Ubergraphs, which claims that Ubergraphs directly generalize Hypergraphs, neglecting to mention the (admittedly rather trivial) intermediate step of Ultragraphs:

https://arxiv.org/abs/1704.05547

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/JeffreyBenjaminBrown/digraphs-with-text/issues/11#issuecomment-416191048, or mute the thread https://github.com/notifications/unsubscribe-auth/AIfQT24PHM4ID5noCIWM2kfmzDwuuAFQks5uU9F1gaJpZM4QcScf .

-- Jeff Brown | Jeffrey Benjamin Brown Website https://msu.edu/~brown202/ | Facebook https://www.facebook.com/mejeff.younotjeff | LinkedIn https://www.linkedin.com/in/jeffreybenjaminbrown(spammy, so I often miss messages here) | Github https://github.com/jeffreybenjaminbrown

HypergraphDB, if I recall correctly (I read about it sometime this year), also seems to offer the same representative capabilities as the RSLT. It might be a big community. (Hash still hasn't caught on anywhere, to my knowledge.)

Also Grakn might do it? That was at least my sense from something I read of theirs.

Sorry, it's been a while. I do expect to get back to this stuff eventually ...

On Wed, Sep 5, 2018 at 12:02 AM Jeffrey Brown jeffbrown.the@gmail.com wrote:

Thanks!

Ubergraphs and RSLTs look like they're the same thing.

The authors of the Ubergraph paper have attached a lot of math to the data structure, which I don't immediately see a reason to be interested in -- what I care about is representing and querying knowledge. I think they might not be, because they don't talk about labeling the relationships. In the RSLT the templates are the relationship labels. Labels are critical -- otherwise the relationship "lion <-> gazelle" could be "lion dreams of gazelle" or "lion assembles dollhouse after gazelle shimmies down a halfpipe" or anything. Linear text with a hole corresponding to each member seems like the most natural way to label a relationship: " uses to ", or "not ", or " is a ".

They also talk about how an Ubergraph is better than an Ultragraph because Ubergraphs give you recursive relationshipss. I see no natural representation of an Ultragraph that is not an Ubergraph. The RSLT, for instance, I designed with only the intention of n-ary nested relationships, and it gave me recursion for free. I think it's the simplest possible implementation. In it relationships, relationship templates, and atoms are all elements of the same set ("nodes"), and the fields of a relationship are nodes. A relationship has nodes, and a relationship is a node, therefore recursion is possible.

It's a good thing, because recursion is a property of the universe. "Is a relationship," for instance, is a relationship that applies to all relationships, including those (unary) relationships in which it is applied to other relationships.

The AvesTerra idea seems to involve them picking a few kinds of metadata they think are important (precision of measurement, for example) and elevating them above other possible kinds of meta-information (such as authors who disagree). It's certainly possible you would want to represent some metadata differently from others. The time at which a relationship was created, for instance, might be so ubiquitous that you would prefer to add a Timestamp field to your relationships, rather than use three objects to represent "X was created at time T". But that's an implementation detail that the backend programmer should hide, I believe, from the frontend user. I prefer the RSLT (or, if indeed it's equivalent, the Ubergraph), which presents a uniform and simpler interface to the user, while allowing for the possibility of complicating it behind the scenes.

On Mon, Aug 27, 2018 at 6:01 AM no_identd notifications@github.com wrote:

Thanks!

Also, I have two new questions, how does RSLT compare to:

Ultragraphs

Ubergraphs

See this presentation deck for (vague, but pretty) details on both, specifically PDF pages 9 to 13:

http://www.storageconference.us/2018/Presentations/BigData-tutorial-1.pdf

This paper for (minimal) details on Ultragraphs, specifically PDF pages 5 to 6:

https://avesterra.georgetown.edu/sites/avesterra/files/avesterra_formalization.pdf

And this paper for details on (Undirected) Ubergraphs, which claims that Ubergraphs directly generalize Hypergraphs, neglecting to mention the (admittedly rather trivial) intermediate step of Ultragraphs:

https://arxiv.org/abs/1704.05547

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/JeffreyBenjaminBrown/digraphs-with-text/issues/11#issuecomment-416191048, or mute the thread https://github.com/notifications/unsubscribe-auth/AIfQT24PHM4ID5noCIWM2kfmzDwuuAFQks5uU9F1gaJpZM4QcScf .

-- Jeff Brown | Jeffrey Benjamin Brown Website https://msu.edu/~brown202/ | Facebook https://www.facebook.com/mejeff.younotjeff | LinkedIn https://www.linkedin.com/in/jeffreybenjaminbrown(spammy, so I often miss messages here) | Github https://github.com/jeffreybenjaminbrown

JeffreyBenjaminBrown / digraphs-with-text

How does this differ from zzstructure(hyperthogonal structure)? #11