[x ] You have a paragraph that is not really an introduction and not really an abstract.
[x] lines 2-3 just say we are building a mathematical framework ... unmotivated
[x] later 4-6 say this is because we don't have enough flexibility to support data and visualization types ... I sort of know what you are trying to say. If you mean "type" in the technical sense, that's a tool not a motivation. You would need to explain why we need more typing. Instead sounds like you are saying that other formalisms aren't expressive enough. No evidence is given for that in the paper, we never discussed that so I assume that is not what you meant to say.
[x] As I pointed out earlier, our primary motivation is that library developers need to think about the tranformation rather than the end result. That leads to a better fit with functional programming and that has a list of benefits if it can be pulled off, eg. concurrency, robustness, and reasonability. The first page of your proposal (going into the background) is again focuses on the benefits and issues for users of the library in creating visualizations. That seems to be your happy place. You are not going to be add much here so you despite your desire to hang out there, you need to instead realize that unlike Du Bois, Munzner, Tufte, Makinlay and Bertin ... YOUR audience is NOT users but library developers. They don't care as much the framing of Retinal variables marks and channels, they want something that will help them write performant code that doesn't crash and doesn't turn into spaghetti FOR data visualization. That has to take front stage, not the marks and glyphs stuff which while important, is secondary.
This sounds to me like more of an abstract. I know you are going to feel like you are being dictated to and this is your proposal and it is unfair if you have to let somebody else write it. Do NOT think of it that way. If you agree with the focus I outlined above, then you are free to propose a better abstract than the one below using some or none of it, as long as the same ideas are highlighted as well as anything you think I missed. If you do not agree that these are the important points you have the freedom to argue, and convince Tom and I to agree with your point of view. What would be a mistake is to do anything based on ego. The most important point is not whose text appears but what is the best text for the point.
Another issue you have made and want to continue to make is that this work needs to be understood by the visualization community. That is definitely an important goal. However, as stated above the audience for TAM is not how best to help users of visualization libraries best understand how to make visualizations, but how to make library builders life easier based on whatever model THEY have of their users. That means that developer jargon is as important if not more important than visualization jargon. You are not writing for Munzner. Maybe you are writing for Bostock. Anyhow take this abstract as a starting point and incorporate your ideas.
Abstract.
One approach to data visualization is to view it as primarily a transformation. This approach to focusing on the transformation data into graphical objects we argue, as a natural fit for visualization library developers. This is because we can more easily incorporate ideas of functional programming, which promises benefits such as code robustness, easier concurrency, and the ability to reason about code. To this end, we use topological fiber bundles to base a
mathematical formalism, we call the Topological Artist Model (TAM), to describe data visualizations. Prior formalism, has focused on end-users rather than developers, providing a declarative language that supports algebraic operations. While we also support algebraic operations, our formalism better articulates the constraints that a visualization library needs to preserve. We describe these constraints both in terms of implied continuity of the data along with some variables, and equivariance of the data itself. By making explicit and concrete within the framework the constraints the library must preserve we provide a better guide to visualization architecture design. We will highlight these ideas in terms of a proposal as an approach to redesigning the core of the matplotlib visualization core. We will relate along the way how the constraints of continuity have been informally described in the literature. We will also show how the mathematical concept of equivarance generalizes a number of visualization best practices. Along the way we will highlight that many aspects of the TAM have been discovered in a piecewise manner, empirically in building visualization libraries. By unifying these aspects as a coherent model the architecture approach will allow key libraries like matplotlib to provide a better basis for domain specific visualization libraries.
Introduction.
The introduction expands the ideas. It can start out a bit more leisurely in setting up the motivation. I suggest you star the introduction reiteraint that our approach is to focus as visualization as a transformation. That you then talk about how the genisis for this perspective comes from library design. Explain how MPL as an example of a core library, is one on which domain libraries are build and needs to provide some way for people to use it and know what it gaurentees. You can talk about programming in terms of contracts as was way of constraints and mention continuity and equivaraince as two things that we should preserve. Then you end the intro with a list of 3-4 novel contributions the work makes and the benefits of those contributions. No more than two should be purely technical.
Comments against #8c6e946
This sounds to me like more of an abstract. I know you are going to feel like you are being dictated to and this is your proposal and it is unfair if you have to let somebody else write it. Do NOT think of it that way. If you agree with the focus I outlined above, then you are free to propose a better abstract than the one below using some or none of it, as long as the same ideas are highlighted as well as anything you think I missed. If you do not agree that these are the important points you have the freedom to argue, and convince Tom and I to agree with your point of view. What would be a mistake is to do anything based on ego. The most important point is not whose text appears but what is the best text for the point.
Another issue you have made and want to continue to make is that this work needs to be understood by the visualization community. That is definitely an important goal. However, as stated above the audience for TAM is not how best to help users of visualization libraries best understand how to make visualizations, but how to make library builders life easier based on whatever model THEY have of their users. That means that developer jargon is as important if not more important than visualization jargon. You are not writing for Munzner. Maybe you are writing for Bostock. Anyhow take this abstract as a starting point and incorporate your ideas.
Abstract.
One approach to data visualization is to view it as primarily a transformation. This approach to focusing on the transformation data into graphical objects we argue, as a natural fit for visualization library developers. This is because we can more easily incorporate ideas of functional programming, which promises benefits such as code robustness, easier concurrency, and the ability to reason about code. To this end, we use topological fiber bundles to base a mathematical formalism, we call the Topological Artist Model (TAM), to describe data visualizations. Prior formalism, has focused on end-users rather than developers, providing a declarative language that supports algebraic operations. While we also support algebraic operations, our formalism better articulates the constraints that a visualization library needs to preserve. We describe these constraints both in terms of implied continuity of the data along with some variables, and equivariance of the data itself. By making explicit and concrete within the framework the constraints the library must preserve we provide a better guide to visualization architecture design. We will highlight these ideas in terms of a proposal as an approach to redesigning the core of the matplotlib visualization core. We will relate along the way how the constraints of continuity have been informally described in the literature. We will also show how the mathematical concept of equivarance generalizes a number of visualization best practices. Along the way we will highlight that many aspects of the TAM have been discovered in a piecewise manner, empirically in building visualization libraries. By unifying these aspects as a coherent model the architecture approach will allow key libraries like matplotlib to provide a better basis for domain specific visualization libraries.
Introduction.
The introduction expands the ideas. It can start out a bit more leisurely in setting up the motivation. I suggest you star the introduction reiteraint that our approach is to focus as visualization as a transformation. That you then talk about how the genisis for this perspective comes from library design. Explain how MPL as an example of a core library, is one on which domain libraries are build and needs to provide some way for people to use it and know what it gaurentees. You can talk about programming in terms of contracts as was way of constraints and mention continuity and equivaraince as two things that we should preserve. Then you end the intro with a list of 3-4 novel contributions the work makes and the benefits of those contributions. No more than two should be purely technical.