# Interactive 3D Exploration of RDF Graphs through Semantic Planes
Unfortunately, this solution scales very poorly. In fact, even with a few dozen triples, dominating the content becomes almost impossible. An alternative is represented by a (possibly very large) set of tables where every property is mapped into a relation. Even though relational tables have been widely used to optimize data storage and retrieval [5], this may not be the best choice for an effective visualization of RDF data. In fact, data visualization should provide an expressive and clear representation to easily grasp complex concepts and identify recurring structures (e.g, subgraphs characterized by a similar topology as in networks of hundreds of sensors semantically mapped in a graph). One of the most natural (and diffused) ways to represent an RDF KB is a graph, as it directly maps with the RDF data model: RDF data can be, as previously mentioned, represented as a directed and labeled graph where the subject and the object of each statement are linked by an edge whose label is the predicate of the statement. As this graph can be very complex (i.e., composed by many nodes and many edges), a tool for its visualization should address a set of issues and requirements that can be summarized as:  
* **Pre-Filtering**: When dealing with RDF knowledge bases, the amount of triples contained in the data store may be really high (e.g., DBpedia contains more than 6.6 M triples). Representing in a graphical way such a large amount of data is usually both ineffective (it is hard for the user to retrieve the information he looks for) and inefficient (it is heavy from the point of view of memory occupation and computational resources). Then, a pre-filtering mechanism is required to extract the subgraph that is really relevant for the user from the full knowledge base. * **Node placement**: Node positioning should be smart enough to avoid overlapping with other graphical elements such as edges or labels. The complexity of this task grows with the size of the KB. If possible, linked resources should be placed close to each other to easily gather as much information information as possible in a glimpse. * **Incremental approach**: Often, only a small portion of a large KB needs to be inspected. Creating the visualization that fits the user needs may require a series of steps (e.g., to specify the information that must be represented and how it should be done). Thus, the incremental building of the view should be supported. * **Filtering**: Filtering must be as flexible as possible to focus on the parts considered relevant for a task by hiding/showing information. Providing powerful filtering features in a user-friendly way is often a difficult task. It is, nevertheless, very important because of the close relationship to one of the techniques that are usually used in designing and debugging queries. According to an incremental progressive method, every step consists in applying a new condition to the previous query: in that way, a less error-prone coding technique, while at every step a new filter is applied to results, until the required level of precision is reached in the request. * **Support for RDFS and OWL**: Both RDFS and OWL must be supported. The user should be able to select and filter the graph content by means of concepts such as class, domain and range of properties, datatype and object properties distinction. * **Support for a high number of scenarios**: Semantic Web and Linked Data technologies may be applied to totally different and heterogeneous domains even within the same application. The datasets in the Linked Open Data cloud mainly belong to seven domains (cross-domain,geographic, media, life sciences, government, user-generated content, and publications) [6], while in the Internet of Things (IoT) where SW technologies are often applied, the application domains are more than 50 [7]. Depending on the specific use case, the end user may be interested in completely custom visualization perspectives.