4 ms·

This post is a good example of the initial realization that folks experience with graphs as data structures. I can see author exclaiming, "Graphs are an intuiti

This post is a good example of the initial realization that folks experience with graphs as data structures. I can see author exclaiming, "Graphs are an intuitive way to express knowledge!" Graphs as data structures can be more nuanced than is usually discussed. Hypernode graphs seem to be very applicable to knowledge graphs, though they have different names depending on the discipline -- nested state machines, statecharts [1], UML hierarchically nested states [2]. I recently participated in a lecture series on Applied Category Theory [3] that touched on the underlying math of composition. The course focused on optimization of design choices in complex decision spaces. [1] https://statecharts.github.io/ https://statecharts.github.io/ [2] https://en.wikipedia.org/wiki/UML_state_machine#Hierarchically_nested_states https://en.wikipedia.org/wiki/UML_state_machine#Hierarchical... [3] https://applied-compositional-thinking.engineering/lectures/ https://applied-compositional-thinking.engineering/lectures/

gryn 6y ago
I too have been facinated with graphs and all related systems/framworks that make use of them in one way or another, but the problem with (hyper/multi)-graphs is that they can represent almost anything, in multiple differing ways and people usually gloss over the second part. In reality it's what make or brake what you can do and express and infer with them. said in another way, saying to yourself i'm using graphs is pining down a single part of the syntax used while the semantics of what is talked about are almost orthogonal. In CT parlance the underlying can be almost anything, and changing a few rules about how you want to reason about stuff can drasticly changes the underlying category you're working with. (PS: my comment is probably biggerish incoherent mind soup)
eternalban 6y ago
The nested FSMs were likely motivated as modeling tools for GUI event graphs. Unlike the relatively obscure wiki example [2], a GUI toolkit example would drive the 'hierarchical' part home: events are delivered to the lowest level in the component graph that can handle it.
- gugagore 6y ago
  Is the obscure example that you are referring to the pocket calculator state machine at https://en.wikipedia.org/wiki/UML_state_machine#Hierarchically_nested_states https://en.wikipedia.org/wiki/UML_state_machine#Hierarchical... ? Between pocket calculators and GUI events (reactive programming), I think obscurity is probably a matter of personal experience. In any case, I think the connection to GUI events is worthwhile. Thanks! I believe there are a few important caveats to the connection: 1. The "most popular" GUI frameworks have semantics that go (way) beyond "events are delivered to the lowest level in the component graph that can handle it": https://developer.mozilla.org/en-US/docs/Learn/JavaScript/Building_blocks/Events#event_bubbling_and_capture https://developer.mozilla.org/en-US/docs/Learn/JavaScript/Bu... https://stackoverflow.com/questions/4616694/what-is-event-bubbling-and-capturing https://stackoverflow.com/questions/4616694/what-is-event-bu... 2. You can still have this hierarchical handling of events without modeling the event handling itself as a state machine. And if you do want to model it as a state machine, and if multiple levels of the hierarchy may handle the event, I suspect you must rely on some decomposition where each layer of hierarchy can only influence some components of the state, while leaving the others unchanged. It seems like UML state machines addresses this! From https://en.wikipedia.org/wiki/UML_state_machine#Orthogonal_regions https://en.wikipedia.org/wiki/UML_state_machine#Orthogonal_r... > In most real-life situations, orthogonal regions would be only approximately orthogonal (i.e. not truly independent). Therefore, UML statecharts provide a number of ways for orthogonal regions to communicate and synchronize their behaviors. Among these rich sets of (sometimes complex) mechanisms, perhaps the most important feature is that orthogonal regions can coordinate their behaviors by sending event instances to each other.
  - eternalban 6y ago
    Thanks, but note no claim was made of needing fsms to handle events [in component graphs]! /g I merely stated the [conjectured] motivation for UML's design team to introduce this level of sementics at the notational level.
flyingsilverfin 6y ago
It's always funny to see people mentioning hypergraphs in relation to knowledge graphs, this is exactly what we do at Grakn Labs (disclaimer: work there) https://grakn.ai https://grakn.ai For others: we're also starting to look into ML on knowledge graphs, check out our initial work at https://github.com/graknlabs/kglib https://github.com/graknlabs/kglib :D

gryn 6y ago

I too have been facinated with graphs and all related systems/framworks that make use of them in one way or another, but the problem with (hyper/multi)-graphs is that they can represent almost anything, in multiple differing ways and people usually gloss over the second part. In reality it's what make or brake what you can do and express and infer with them. said in another way, saying to yourself i'm using graphs is pining down a single part of the syntax used while the semantics of what is talked about are almost orthogonal. In CT parlance the underlying can be almost anything, and changing a few rules about how you want to reason about stuff can drasticly changes the underlying category you're working with. (PS: my comment is probably biggerish incoherent mind soup)

eternalban 6y ago

The nested FSMs were likely motivated as modeling tools for GUI event graphs. Unlike the relatively obscure wiki example [2], a GUI toolkit example would drive the 'hierarchical' part home: events are delivered to the lowest level in the component graph that can handle it.

gugagore 6y ago
Is the obscure example that you are referring to the pocket calculator state machine at https://en.wikipedia.org/wiki/UML_state_machine#Hierarchically_nested_states https://en.wikipedia.org/wiki/UML_state_machine#Hierarchical... ? Between pocket calculators and GUI events (reactive programming), I think obscurity is probably a matter of personal experience. In any case, I think the connection to GUI events is worthwhile. Thanks! I believe there are a few important caveats to the connection: 1. The "most popular" GUI frameworks have semantics that go (way) beyond "events are delivered to the lowest level in the component graph that can handle it": https://developer.mozilla.org/en-US/docs/Learn/JavaScript/Building_blocks/Events#event_bubbling_and_capture https://developer.mozilla.org/en-US/docs/Learn/JavaScript/Bu... https://stackoverflow.com/questions/4616694/what-is-event-bubbling-and-capturing https://stackoverflow.com/questions/4616694/what-is-event-bu... 2. You can still have this hierarchical handling of events without modeling the event handling itself as a state machine. And if you do want to model it as a state machine, and if multiple levels of the hierarchy may handle the event, I suspect you must rely on some decomposition where each layer of hierarchy can only influence some components of the state, while leaving the others unchanged. It seems like UML state machines addresses this! From https://en.wikipedia.org/wiki/UML_state_machine#Orthogonal_regions https://en.wikipedia.org/wiki/UML_state_machine#Orthogonal_r... > In most real-life situations, orthogonal regions would be only approximately orthogonal (i.e. not truly independent). Therefore, UML statecharts provide a number of ways for orthogonal regions to communicate and synchronize their behaviors. Among these rich sets of (sometimes complex) mechanisms, perhaps the most important feature is that orthogonal regions can coordinate their behaviors by sending event instances to each other.
- eternalban 6y ago
  Thanks, but note no claim was made of needing fsms to handle events [in component graphs]! /g I merely stated the [conjectured] motivation for UML's design team to introduce this level of sementics at the notational level.

flyingsilverfin 6y ago

It's always funny to see people mentioning hypergraphs in relation to knowledge graphs, this is exactly what we do at Grakn Labs (disclaimer: work there) https://grakn.ai https://grakn.ai For others: we're also starting to look into ML on knowledge graphs, check out our initial work at https://github.com/graknlabs/kglib https://github.com/graknlabs/kglib :D