際際滷

際際滷Share a Scribd company logo

Capturing and Using Knowledge about Visualization Toolkits

Download as PPTX, PDF
Nicholas Del Rio
Nicholas Del Rio

This document proposes a method for automated discovery of visualization services through a conceptual model and knowledge base. It summarizes previous work on visualization pipelines and models. The proposed approach classifies services, represents visualization queries, and uses the knowledge base to answer queries by constructing pipelines that match format and type requirements. This enables automated sharing of visualizations in a way that empowers recipients.

1 of 20
Download to read offline
Capturing and Using Knowledge about Visualization Toolkits Nicholas Del Rio Paulo Pinheiro - PNNL 1
Outline Discovery through Visualization Diversity Background on Generating Visualizations Visualization Conceptual Model Visualization Knowledge Base A Practical Application Conclusion 2
Service Discovery for Visualization There are many ways to visualize a single dataset Near neighbor vs. surface 3D views: gridding techniques isosurfaces vs. point plot In many cases, it is up to the users to understand the different views and know how to generate them 3
Service Discovery for Visualization There are many ways to visualize a single dataset Near neighbor vs. surface 3D views: gridding techniques isosurfaces vs. point plot How can we support the seamless automated discovery of visualization services to support visualization diversity? 4
Goal Enable automated discovery and integration of visualization services VISUALIZE http://cs.utep.edu/dataX.xyz AS isosurfaces IN firefox Objectives: WHERE AND FORMAT TYPE = csv = gravity AND interval =5 AND xRotation = 10 Abstract visualization pipelines in 1 the form of declarative requests (visualization queries) Construct a knowledge base of 2 visualization services Develop methods for translating 3 the abstractions into pipelines (query answering) 5
Proposed Usage Pattern Users may also generate other visualizations of the same dataset from a variety of sources 6
Background Users typically employ visualization toolkits to construct visualizations Sequence of visualization operators known as a pipeline 7
Visualization Pipeline Structure Op1: vtkDataObjectToDataSetFilter Op Data Gathering 1 1 Op Op2: vtkShepardMethod 2 Mapping 2 Op Op 3: vtkExtractVOI 3 Op 4: vtkContourFilter Op Visualization Abstraction 3 4 specified in the query Op Op 5: vtkPolyDataMapper 5 Rendering 4 Data Flow Model Haber and McNabb 90 1 2 4 Data State Model Chi 98 2 3 8
Building From Existing Work Habers work paved the way for modular visualization environments popular in the 90s: Visualization Data Explorer (OpenDX) and IRIS A Visualization System (AVS) and Visualization Toolkit (VTK) Users still have to manually compose pipelines Chis work provided a data centric perspective from which to compare and taxonomize techniques These models have not been used to drive automatic composition of visualization pipelines 9
Building From Existing Work (2) Past efforts to automate visualization generation have had great success in restricted domains: A Presentation Tool (APT) Jock Mackinlay 86 Tableau Stolte 2012 Both operate on relational data to drive visualizations: Nominal or ordinal These tools were not designed to operate on Functionally dependent general kinds of data and are were more focused towards information visualization 10
Our Enhancements: Format [Type] One way we expand on existing visualization models is by considering type and format requirements of modules. We call these modules transformers CSV [Gravity] OBSERVATION 1 Op 1 Format is not enough, some can XML [vtkPolyData] encode a variety of types Op 2 OBSERVATION 2 XML [vtkImageData3D] Dimension reduction is not explicitly Op 3 specified but inferred through the type requirements XML [vtkImageData2D] Op 4 OBSERVATION 3 XML [vtkPolyData] These formats and types should be defined in ontologies and shared to Op 5 foster interoperability JPEG [owl:Thing] 11
Our Enhancements: Viewer We also consider the viewer that presents the visualization Op 1 Op After the mapping, there may be a number of transformations 2 before the geometry can be presented by a viewer Op 3 These additional transformations may JPEG [owl:Thing] PDF [owl:Thing] be viewed as an expansion of the Op rendering phase 4 Op Op 5 6 PDF Viewer (Type Agnostic) 12
Our Overall Model 1. Marries Data Flow (Haber) with Data State (Chi) concept of Visualization Abstraction 2. Incorporates service composition concerns (i.e., format [type]) into data gathering phase 3. Incorporates concept of a Viewer 4. Expands rendering phase to consist of a sub pipeline of further transformations 5. Is encoded in OWL 13
Constructing the Knowledge Base We can classify visualization services using the concepts in our ontology: Transformer Mapper (generates visualization abstractions) Viewer Services are combined based on our model constraints: Format[type] match-ups Must include a mapper Must terminate at a viewer Transformer Mapper Viewer 14
A Data Centric View 15
Answering Visualization Queries VISUALIZE http://somedata.csv Visualization Queries Specify: AS 3d-point-plot IN firefox Source format[type] WHERE FORMAT = csv AND Target Visualization Abstraction TYPE = gravity-data Target Viewer Transformer Mapper Viewer 16
Sharing Visualizations Recipient may be unable to adjust any properties such as contour interval, color tables, projection and labels 1. Send image (contents or by URL) Recipient may not have tools, capabilities, and expertise to regenerate visualization from data 2. Send data These solutions have been implemented only for specific domains , for example OGC 3. Send URL of visualization embedded in viewer VisKo queries address the limitations above 4. Send a VisKo Query specifying the visualization 17
Conclusion Visualization queries abstract away the complexities of visualization pipelines. We can automate pipeline construction provided: A visualization query A service knowledge base structured using our model We can use queries to share visualizations in a way that empowers visualization recipients. 18
Future Work Automated Parameter Settings Color functions driven from formula identification Data driven vs. visualization driven Weighted graphs Add information about performance Add information about quality degradation Task driven generation Map task descriptions (Shneiderman 96) to the right set of parameters and visualization abstractions 19
Play With Our System! http://trust.utep.edu/visko http://iw.cs.utep.edu/visko-web: VisKo Server 20

More Related Content

Capturing and Using Knowledge about Visualization Toolkits

  • 1. Capturing and Using Knowledge about Visualization Toolkits Nicholas Del Rio Paulo Pinheiro - PNNL 1
  • 2. Outline Discovery through Visualization Diversity Background on Generating Visualizations Visualization Conceptual Model Visualization Knowledge Base A Practical Application Conclusion 2
  • 3. Service Discovery for Visualization There are many ways to visualize a single dataset Near neighbor vs. surface 3D views: gridding techniques isosurfaces vs. point plot In many cases, it is up to the users to understand the different views and know how to generate them 3
  • 4. Service Discovery for Visualization There are many ways to visualize a single dataset Near neighbor vs. surface 3D views: gridding techniques isosurfaces vs. point plot How can we support the seamless automated discovery of visualization services to support visualization diversity? 4
  • 5. Goal Enable automated discovery and integration of visualization services VISUALIZE http://cs.utep.edu/dataX.xyz AS isosurfaces IN firefox Objectives: WHERE AND FORMAT TYPE = csv = gravity AND interval =5 AND xRotation = 10 Abstract visualization pipelines in 1 the form of declarative requests (visualization queries) Construct a knowledge base of 2 visualization services Develop methods for translating 3 the abstractions into pipelines (query answering) 5
  • 6. Proposed Usage Pattern Users may also generate other visualizations of the same dataset from a variety of sources 6
  • 7. Background Users typically employ visualization toolkits to construct visualizations Sequence of visualization operators known as a pipeline 7
  • 8. Visualization Pipeline Structure Op1: vtkDataObjectToDataSetFilter Op Data Gathering 1 1 Op Op2: vtkShepardMethod 2 Mapping 2 Op Op 3: vtkExtractVOI 3 Op 4: vtkContourFilter Op Visualization Abstraction 3 4 specified in the query Op Op 5: vtkPolyDataMapper 5 Rendering 4 Data Flow Model Haber and McNabb 90 1 2 4 Data State Model Chi 98 2 3 8
  • 9. Building From Existing Work Habers work paved the way for modular visualization environments popular in the 90s: Visualization Data Explorer (OpenDX) and IRIS A Visualization System (AVS) and Visualization Toolkit (VTK) Users still have to manually compose pipelines Chis work provided a data centric perspective from which to compare and taxonomize techniques These models have not been used to drive automatic composition of visualization pipelines 9
  • 10. Building From Existing Work (2) Past efforts to automate visualization generation have had great success in restricted domains: A Presentation Tool (APT) Jock Mackinlay 86 Tableau Stolte 2012 Both operate on relational data to drive visualizations: Nominal or ordinal These tools were not designed to operate on Functionally dependent general kinds of data and are were more focused towards information visualization 10
  • 11. Our Enhancements: Format [Type] One way we expand on existing visualization models is by considering type and format requirements of modules. We call these modules transformers CSV [Gravity] OBSERVATION 1 Op 1 Format is not enough, some can XML [vtkPolyData] encode a variety of types Op 2 OBSERVATION 2 XML [vtkImageData3D] Dimension reduction is not explicitly Op 3 specified but inferred through the type requirements XML [vtkImageData2D] Op 4 OBSERVATION 3 XML [vtkPolyData] These formats and types should be defined in ontologies and shared to Op 5 foster interoperability JPEG [owl:Thing] 11
  • 12. Our Enhancements: Viewer We also consider the viewer that presents the visualization Op 1 Op After the mapping, there may be a number of transformations 2 before the geometry can be presented by a viewer Op 3 These additional transformations may JPEG [owl:Thing] PDF [owl:Thing] be viewed as an expansion of the Op rendering phase 4 Op Op 5 6 PDF Viewer (Type Agnostic) 12
  • 13. Our Overall Model 1. Marries Data Flow (Haber) with Data State (Chi) concept of Visualization Abstraction 2. Incorporates service composition concerns (i.e., format [type]) into data gathering phase 3. Incorporates concept of a Viewer 4. Expands rendering phase to consist of a sub pipeline of further transformations 5. Is encoded in OWL 13
  • 14. Constructing the Knowledge Base We can classify visualization services using the concepts in our ontology: Transformer Mapper (generates visualization abstractions) Viewer Services are combined based on our model constraints: Format[type] match-ups Must include a mapper Must terminate at a viewer Transformer Mapper Viewer 14
  • 15. A Data Centric View 15
  • 16. Answering Visualization Queries VISUALIZE http://somedata.csv Visualization Queries Specify: AS 3d-point-plot IN firefox Source format[type] WHERE FORMAT = csv AND Target Visualization Abstraction TYPE = gravity-data Target Viewer Transformer Mapper Viewer 16
  • 17. Sharing Visualizations Recipient may be unable to adjust any properties such as contour interval, color tables, projection and labels 1. Send image (contents or by URL) Recipient may not have tools, capabilities, and expertise to regenerate visualization from data 2. Send data These solutions have been implemented only for specific domains , for example OGC 3. Send URL of visualization embedded in viewer VisKo queries address the limitations above 4. Send a VisKo Query specifying the visualization 17
  • 18. Conclusion Visualization queries abstract away the complexities of visualization pipelines. We can automate pipeline construction provided: A visualization query A service knowledge base structured using our model We can use queries to share visualizations in a way that empowers visualization recipients. 18
  • 19. Future Work Automated Parameter Settings Color functions driven from formula identification Data driven vs. visualization driven Weighted graphs Add information about performance Add information about quality degradation Task driven generation Map task descriptions (Shneiderman 96) to the right set of parameters and visualization abstractions 19
  • 20. Play With Our System! http://trust.utep.edu/visko http://iw.cs.utep.edu/visko-web: VisKo Server 20