You are viewing archived messages.
Go here to search the history.

Alex North 2024-12-20 08:48:53

Does anyone know of any DSLs or similar that are specific to graph/chart drawing? I.e. a language that defines a function from data to image, specialised toward visualising data?

If not, what’s the closest thing? E.g. is there a JS chart-drawing library with an API that feels close to a DSL?

Mariano Guerra 2024-12-20 08:56:56

vega.github.io and vega.github.io/vega-lite count?

📝 Vega: A Visualization Grammar

Vega is a declarative format for creating, saving, and sharing visualization designs. With Vega, visualizations are described in JSON, and generate interactive views using either HTML5 Canvas or SVG.

📝 A High-Level Grammar of Interactive Graphics

Vega-Lite - a high-level grammar for statistical graphics. Vega-Lite provides a higher-level grammar for visual analysis, comparable to ggplot or Tableau, that generates complete Vega specifications. Vega-Lite specifications consist of simple mappings of variables in a data set to visual encoding channels such as x, y, color, and size. These mappings are then translated into detailed visualization specifications in the form of Vega specification language. Vega-Lite produces default values for visualization components (e.g., scales, axes, and legends) in the output Vega specification using a rule-based approach, but users can explicit specify these properties to override default values.

misha 2024-12-20 10:03:11

vega has json-schemas for its configs, but those are huge

vega.github.io/schema/vega-lite/v4.json

so if you fancy some clojure, I got draft lib github.com/akovantsev/json-schema-to-clojure-spec

specifically to explore those schemas in repl

(I don't remember if it handled schemas of such size though :))

Tom Larkworthy 2024-12-20 12:03:54

vega, plot, ggplot, all based off "grammar of graphics" which defines a conceptual toolbox for data -> pixel space.

Konrad Hinsen 2024-12-20 17:17:57

Graphviz and Penrose are two graph DSLs that are quite different from Vega.

📝 Graphviz

Please join the Graphviz forum to ask questions and discuss Graphviz. What is Graphviz? Graphviz is open source graph visualization software. Graph visualization is a way of representing structural information as diagrams of abstract graphs and networks. It has important applications in networking, bioinformatics, software engineering, database and web design, machine learning, and in visual interfaces for other technical domains.

📝 Penrose

Create beautiful diagrams just by typing math notation in plain text.

Tomas Petricek 2024-12-21 00:13:18

I've done a thing some time ago that may be relevant: compostjs.github.io/compost

It is fairly small composable DSL for composing visualizations - unlike grammar of graphics libraries (vega), it is more low-level and you construct graphical primitives yourself - but it handles mapping of units from "domain units" to pixels (where domain units can be continuous or categorical) - so the idea is to have something that is a sweet spot between low level drawing and high-level (Vega, D3, etc) libraries...

📝 Compost.js: Composable data visualization library

Compost is a data visualization library that lets you compose rich interactive data visualizations from a small number of basic primitives. The library is based on the functional programming idea of composable domain-specific languages. Compost is simple (implemented in just 700 lines of code) and easy to understand. Compost is a plain JavaScript library. You use it by writing JavaScript code that generates a chart using some 15 basic Compost primitives.

Alex North 2024-12-21 08:28:50

Thank you, Vega does look pretty close to what I’m describing, if one considers that giant JSON schemas like this are standing in for what could probably be a nice and tidy special-purpose language. I will investigate further.

misha 2024-12-21 08:36:47

schemas are "grammar of a language", not a "message written in a language".

Jason Morris 2024-12-20 16:53:08

I have been working with large-ish knowledge graphs on and off over the course of the year, and I keep running into the same problem... my intuition for what I have done when I modify the graph and how it will effect everything else is just dismally bad. I make what seems like will be an incremental change, and it doesn't do what I expected, or if it does, it breaks all my algorithms. This happens with other data structures, too, obviously. But with graph data it happens far more often, as in nearly always, and the time between "it isn't working" and "oh, I know how I broke it" is much longer. So I'm wondering, assuming that my experience is not unique, is there something about graphs that makes them harder to grok? The absence of a clear serialization, the absence of order, complexity of structure? Or is it a UI problem, and if I could just see what I was doing it wouldn't be so bad... Often, when I come to a particularly hard problem, I sample and visualize the graph, and learn that the previous three problems were not correctly solved. So visualization helps, but is that enough? Or is there something fundamentally inhuman about large, dense graphs?

Oleksandr Kryvonos 2024-12-20 22:39:20

can you give an example of issue you encountered?

Jason Morris 2024-12-20 23:03:04

In general, maybe? Like I have at least twice added edges of a different type to reflect a different relationship, and failed to appreciate the need to exclude those edges from how other algorithms in the system work, because the new edges represent relationships of a different type. And that mess-up has been invisible to me until I was investigating why steps far after that algorithm was applied were broken. But that's just one example, and it's not about the specifics. It's a pattern I'm beginning to see, and I wonder if it represents something, or if it's just the effects of a leaning curve, or what.

Tom Lieber 2024-12-21 00:26:54

In my experience, even linked lists are hard like that. It doesn’t seem like the problem goes away until you eliminate edges entirely and have arrays.

Tom Lieber 2024-12-21 00:34:12

In trees whose shape mirrors the shape of the recursive computation exactly, things can be simple. Thinking locally works.

misha 2024-12-21 07:50:39

"working with knowledge graphs" makes it sound like you are clicking away in some notetaking™ UI, and not programmatically modifying particular data structure.

if "mistakes while programmatically modifying" is the case – it is similar to working with dynamic (python/clojure) vs static (java/haskel) lang codebase: you know the general rules "how to call method on thing/get attribute of thing", but dynamic-lang env (generally) hits you with "that thing has no such method/attribute" at runtime, static (generally) – at compile/IDE time.

maybe it can be generalized as: there are rules either 1) you are unaware of, or 2) are not enforced "in time"

(whatever "enforced" and "in time" mean for you, eg. red squiggly line in IDE, or absence of method in autocomplete dropdown, etc.)