Diagrams for RDF data - Overview

RDF data naturally represent graphs, and visualizing them is straightforward with diagramming tools like Graphviz. A generic mapping can turn each triple into a link between a node for the subject and a node for the object. For example: 


            
        



        
But such diagrams quickly become messy for non-trivial data, unless we can tweak them a little bit.

        

            To have decent-looking diagrams, we inevitably have to cope with long URIs, possibly keeping them as
            tooltips but using something else for labels.
            To have fewer edges, some properties may be ignored, and others may be embedded in the label for their
            subject.
            Edge labels may be omitted and colors may help to at least distinguish those that represent different
            predicates.
            Node shapes and colors may represent the type, some other property, or even a combination.
        

        

            But even if we can settle on a good default set of visualization rules like these, it is important to be
            able to cherry pick rules and to add more specific ones on a diagram-by-diagram basis.
            The approach proposed here (which is not new) provides the
            needed flexibility to tailor graph diagrams of RDF data.


        
Diagramming Vocabulary

        

            Using a small vocabulary of basic diagramming terms (node, edge, label, shape, color, tooltip...) we can
            express a diagram in RDF.
            It's not difficult to convert such diagram descriptions from RDF to some diagramming DSL.
        

        
With our vocabulary, based on the dot language,
            we can describe a more compact version of the above graph:

        

            

            
        


        
The label for the <urn:ann> node is the name instead of the URI. The shape for the city node is
            rectangular,
            and its label is the last part of the URI. The label of the edge is also customized,
            but the full predicate URI is available as a tooltip over the arrow.
        

        

            Thus we can construct a customized diagram for our little dataset. But if we were to create the diagram
            description manually, it would be better to use directly the dot language which is designed for
            that purpose.
        


        
The missing step is how to get from the original data to the description of its diagram.
            We need rules to tranform RDF data into diagram descriptions. Some rules may be more general (the
                tooltip of an arrow is the predicate URI),
            others a bit more specific (city nodes are rectangular).

        

        
Since it's a matter of transforming an RDF dataset into another RDF dataset,
            one option is to use SPARQL and run a CONSTRUCT query to transform the original RDF data into the desired
            description of its diagram.
        

        
But here, as in the original idea, we leverage Notation 3
            and its  eye reasoner implementation now available also in the browser.


        
Notation 3

        
The following N3 rules are used to obtain the last diagram from the initial data:


        

            

            

            

        


        
There are three rules, expressed with the implication symbol =>. 

        
  • 
            The first one states that for every instance of city, we extract the last part of its URI
            (using a so-called built-in named log:localName) and derive a node with such a label and having
            rectangular shape.
        
    • 
        
  • 
            The next rule handles triples with a string literal value for the urn:name predicate.
            The subject of such a triple becomes a node labelled with the literal value
            (the text part of the literal term is parsed by the log:dtlit built-in).
        
    • 
        
  • 
            The last rule creates edges for the urn:livesIn property, with a customized label
            and the tooltip obtained from the URI (converted to string by the log:uri built-in).
        
    • 
        
    
            The above rules are quite specific and tailored to the vocabulary used in the input data.
            Any additional data not covered by the rules would be ignored.
            It is possible to create more general rules, such that all input data would somehow be mapped to a
            diagrammatic
            representation. In fact, the very first diagram was obtained with a simple general-purpose rule:
        
    
        
    
            
    
        
    
        
        
    
            It is possible to create and compose both general and specific rules.
            General rules may require extra-care, for example the log:notEqualTo clauses above are needed
            to
            avoid loops (otherwise the rule would be applied also to the derived triples).
            A sufficient understanding of Notation 3 logic is needed, but it allows to create interesting diagrams.
        
    
        
    
            Here, you can create diagrams using default rules, with the option to provide
            your own.
            See also the examples page.