Edges between sub-nodes inside nodes
RangerMauve opened this issue · 27 comments
An application that I'm working on involves having nodes that are essentially graphs with input nodes and output nodes. Edges then connect an output from one node to the input of another node. Any ides of how I should use the json-graph-specification with this use case?
Right now I'm currently storing the name of the input and output within the metadata of the edge, but it feels like there should be a better way to do this.
Can you share an example of what you are currently doing?
On Aug 7, 2015, at 9:55 PM, RangerMauve notifications@github.com wrote:
An application that I'm working on involves having nodes that are essentially graphs with input nodes and output nodes. Edges then connect an output from one node to the input of another node. Any ides of how I should use the json-graph-specification with this use case?
Right now I'm currently storing the name of the input and output within the metadata of the edge, but it feels like there should be a better way to do this.
—
Reply to this email directly or view it on GitHub #22.
Yeah, here's the project I'm working on: event-graph
And here's an example graph that I'm using.
This feels different than a directed, undirected, or mixed graph. GraphML defines hyperedges where a single edge connects multiple vertices. Hyperedges are part of a hypergraph.
I've never worked with hypergraphs, but maybe you could define the Value/Console node, Input, and Output as single set of vertices connected by a hyperedge.
Well, my main purpose was to have something like noflo at the end of this. Where I'm connecting nodes together via sockets that they expose. I'm not sure if the hyperedge would be what I want since I really want a flow from output to input between nodes
You are using the specification in your example exactly the way you should
be. It's what we put metadata in there for.
However, since source and target are strings, you can actually represent
multiple sources and targets with a delimiter within the string; then your
implementation would have to split the values. This would prevent your JGF
file from being rendered by a generic visualizer as it would not be
expecting a string array as a valid value. (We are not implementing JGF at
this point) That being said, a general JGF visualizer wouldn't be able to
render what you need it to do anyway. This is just an out-side-the-box way
of thinking.
On Fri, Aug 7, 2015 at 4:44 PM RangerMauve notifications@github.com wrote:
Well, my main purpose was to have something like noflo
http://noflojs.org/example/ at the end of this. Where I'm connecting
nodes together via sockets that they expose. I'm not sure if the hyperedge
would be what I want since I really want a flow from output to input
between nodes—
Reply to this email directly or view it on GitHub
#22 (comment)
.
Well, if the source/target don't have to directly match ids in nodes, then I was thinking that it'd be useful to use something like
{
"source": "node1/output/output_namet",
"target": "node2/input/input_name"
}That way it would work with the event-based stuff I'm working on for the project pretty nicely and would make the engine that wires it all up together even more simple.
Alternately I was thinking of maybe forking the spec to add fields for input and output names.
In terms of rendering, if I stick with the metadata method, I could probably give the edges labels that describe the input and output that are being connected.
Another thing that I'd like to bring up is that some of the nodes in my graph actually represent entire graphs of their own. I was wondering if the spec was interested in supporting something like that on the spec level. Maybe nodes themselves could have graph properties that contain entire graph definitions within them
Anselmo has proposed that we all (Robert, you, Anselmo, Tony, Nick, Dexter Pratt and I - and anyone else interested) get together sometime in the next few weeks virtually online to discuss the future of JGF, revise the goals and plan out changes. We initially proposed it to keep the basic JGF graph simple and understandable while layering on complexity in the child graph. That suggested keeping the basic elements, graph, node, edge limited. We need to revisit that core element in the design now that there are a lot more use cases available to review the design against. I think getting together is also a really good idea.
I've not thought through the impact of changing "additionalProperties" to true on graph, node, edges.
I do really like the idea of nodes representing graphs in a recursive fashion, but it complicates the code parsing the data structure - not a lot, but I've seen simple formats succeed even though they aren't complex enough for many purposes (JSON vs XML for example).
This all comes down to balancing versatility against complexity and what are we trying to achieve with this. This of course also has to be balanced against large enough value to get a reasonable eco-system of tools and technologies using the spec. Are you up for getting together online to discuss this?
Nice to see the jgf-dot implementation!
I'm definitely up. This week is pretty full for me but I'll be free evenings around 10 PM EST or during lunch between 12 and 1 PM EST. Also I'm pretty sure I have the entire weekend available
Great thought summary William;
RangerMauve (sorry not sure of your real name) it is great to see you
making yourself available to this as well.
Let's push it out a bit... lets say Wed. Sept 2nd or around there. This
would give us time to put together an itinerary of talking points and to
potentially get other high profile industry players involved. I may have
to make a trip up to the Boston area for this meeting :)
How does Sept 2nd work?
On Wed, Aug 12, 2015 at 7:52 AM RangerMauve notifications@github.com
wrote:
I'm definitely up. This week is pretty full for me but I'll be free
evenings around 10 PM EST or during lunch between 12 and 1 PM EST. Also I'm
pretty sure I have the entire weekend available—
Reply to this email directly or view it on GitHub
#22 (comment)
.
I'm Georgiy :D
Sept 2nd sounds good to me as long as it's after 6 EST so I can attend after work.
https://github.com/jsongraph/json-graph-specification/wiki -- Has the link to the document to plan the meeting (time, who, agenda) - the Google Doc for it is fully public - anyone can edit, comment
Thanks William. We should host/record a Google Hangout as well.
My views on additionalProperties:
The JSON Graph Format was designed to represent a directed, undirected, or mixed graph containing a set of vertices (i.e. our nodes) and edges. The schema provides a fixed schema for graph objects to set expectations for processing a graph. It also provides for dynamic schema and extension through the use of metadata. It is worth noting we recently set additionalProperties to false in #16.
Now if we introduce nested graphs, within nodes, we could augment the node to allow for a graph. We may want to do approach it this way since it affects the graph structure, not metadata about a graph object.
My thought on this approach is that we're introducing complexity into the graph structure that tooling may not support. To support nested graphs I would argue for a new schema (exclusive of JGF) that implements basic graphs and nested graphs within nodes. This would allow tooling to say they support http://jsongraphformat.info/schema.json and / or http://jsongraphformat.info/schema-nested-graph.json. The tooling can then make the support decision at the media type level and not have to crack open the data.
Would it be just an extension of the regular graph schema sort of like the BEL JSON Graph format?
I could see that being useful. A question would be, could edges in a graph connect to nodes within nested graphs. That's really a use case that'd be important for me to have, but I'm still not sure about a simple way to enable such functionality, especially while making it simple and backwards compatible.
To extend the JSON Graph Format base schema to support including a graph within a node this we would need additionalProperties set to true on node. I would rather duplicate the schema in the nested graph scenario to ensure we have a clean separation.
We should be drawing a line in the sand and saying, use this schema if you need a basic graph, use this other schema if you need nested graph support, and so on...I believe support for a graph structure at the media type level is really valuable.
I'm not sure I entirely agree with having completely different schemas, I see a real use in being able to reuse existing definitions and extending them via json schema. It would be nice if there was a way to reuse chunks of the main definition but without having the limitation of not allowing additional properties. I agree with potentially having different media types for formats that are very different.
I do see the value of building upon schemas. If the base JSON Graph Format defined node as:
{
"node": {
"type": "object",
"additionalProperties": true,
"properties": {
"id": {
"type": "string"
},
"label": {
"type": "string"
},
"metadata": {
"type": [
"object",
"null"
],
"additionalProperties": true
}
},
"required": [
"id"
]
}
}Setting it to true would allow for node extensions without explicitly supporting them within the base JSON Graph Format schema. For example, a nested graph within node:
{
"node": {
"id": 0,
"label": "Neo",
"graph": {
"nodes": [
...
],
"edges": [
...
]
}
}
}MAY be supported by the JSON Graph Format schema but MUST be supported by the nested graph extension schema.
I think if we communicate the requirements within the schema and its documentation then the tooling can decide how to process different schemas in the scenario that unknown properties are provided.
Yes, I agree that that would be a good way of approaching it.This would simplify the schema that specifies the nested graph support because it'd just need to define the graph property, which could probably just use a $ref to point to the root to make it recursive.
👍
I think you would have to extend (i.e. allOf keyword) the definition of node and graph within the sub specification. If you $ref the base schema's graph object you will not be able to nest more than one level deep.
Another thought on nested graphs to accomplish @RangerMauve's original use case.
Could you represent input and output as attributes within a node and use directed edges for the dataflow? In this way you provide a type abstraction (e.g. TerminalNode, MappingNode, FanOutNode, SyncNode, etc.) within a nested graph model.
For example,
Terminal Node (no output)
{
"node": {
"id": "terminal0",
"graph": {
"nodes": [
{
"id": "terminal0",
// copied into the nested level
},
{
"id": "input0",
"value": "...some data..."
}
],
"edges": [
{
"source": "terminal0",
"relation": "hasInput",
"target": "input0"
}
]
}
}
}
Some more theoretical thoughts on nested-graph for type abstraction can be found in A Nested-Graph Model for the Representation and Manipulation of Complex Objects.
Currently an important part of my design is to have multiple named inputs and outputs for each node. The way I have that scaling to nested graphs is that nodes of a type GraphInput and GraphOutput get treated specially and are used to connect the internals of the graph to the external world.Within the graph, GraphInput nodes contain one output called input, and GraphOutput nodes contain one input called output. This means that in the context of the graph they just look like nodes that only accept or generated data to and from the ether. But when the graph is used as a node in a bigger graph, it populates its output and input name lists by looking at the types of nodes it has, and they relaying events to the child nodes that are connected to those nodes. I guess one thing to not is that I'm more focused on individual nodes and consider the graph to be just a special type of node. All my nodes are required to define a static list of inputs and outputs based on their type. This is then used for wiring up data flows between them.
Nested graphs might be a useful way to present complex BEL statements, where the target node is itself a statement with a source and target - see http://wiki.openbel.org/display/BLVD/Nested+Statement+Example
Another use case I have for this is modeling the Audio Graph for the Web Audio API. Nodes can be connected directly to each other, but you can also connect nodes to params within another Audio node. For instance, attaching an LFO to a Gain node in order to make the volume oscillate.
Isn't that effectively creating a new edge between the nodes? The
relationship of the edge can help dictate the property of the node to use
found in its metadata
On Tue, Sep 22, 2015 at 10:42 AM RangerMauve notifications@github.com
wrote:
Another use case I have for this is modeling the Audio Graph for the Web
Audio API. Nodes can be connected directly to each other, but you can also
connect nodes to params within another Audio node. For instance, attaching
an LFO to a Gain node in order to make the volume oscillate.—
Reply to this email directly or view it on GitHub
#22 (comment)
.Anselmo Di Fabio, CTO | O +732.764.8844 x124 | M +732.993.8182
ADS (Applied Dynamic Solutions, LLC)
Innovative People. Innovative Technology. Innovative Solutions.
www.ads-llc.com | LinkedIn
http://www.linkedin.com/company/applied-dynamic-solutions-llc
The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential and/or privileged
material. Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by persons or
entities other than the intended recipient is prohibited. If you received
this in error, please contact the sender and delete the material from any
computer.
That's exactly what it's doing. So metadata is the way to go in the long run, I suppose?
Yup. Sounds like a fun project you have over there
On Tue, Sep 22, 2015 at 11:00 AM RangerMauve notifications@github.com
wrote:
That's exactly what it's doing. So metadata is the way to go in the long
run, I suppose?—
Reply to this email directly or view it on GitHub
#22 (comment)
.Anselmo Di Fabio, CTO | O +732.764.8844 x124 | M +732.993.8182
ADS (Applied Dynamic Solutions, LLC)
Innovative People. Innovative Technology. Innovative Solutions.
www.ads-llc.com | LinkedIn
http://www.linkedin.com/company/applied-dynamic-solutions-llc
The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential and/or privileged
material. Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by persons or
entities other than the intended recipient is prohibited. If you received
this in error, please contact the sender and delete the material from any
computer.
Closing due to inactivity.