We describe and demonstrate a method of automated creation of refined visualizations of Linked data endpoint schemas, based on their pre-computed structure information. The visualization uses UML class diagram style structure with classes, associations, and attributes, as well as subclass structure. Due to the pre-computed nature of the data schemas, visualization can avoid repeating the subclass properties and links at a superclass level and present parts of larger data schemas in a compact and conceivable way.
Visual presentation of a knowledge graph or a Linked data endpoint schema can be expected to
help a user to comprehend the graph/endpoint structure and, therefore, use more efficiently the
data contained therein. There are several tools allowing visualization of existing Linked data
endpoint schemas, such as LD-VOWL [
The actual data schema information, important both for visual characterization of the data set contents and for technical assistance in handling the models based on such a data schema (e.g., by providing context-aware model auto-completion) is, however, much richer than the class-toproperty correspondence alone. Such a schema can distinguish between more relevant and less relevant classes as property sources and targets (as described further on in the paper), it also can involve e.g., property domain/range information (in the ontological sense), and cardinalities.
The means for knowledge graph schema description are provided also by RDF data shape
languages SHACL [
Due to the richness of the information the data schemas may contain, it might not (and typically would not) be possible to obtain their full information on-the-fly, with the user waiting behind the computer screen. In this demonstration we work in the setting of creating a data schema first and further on providing its visualization in the form of an extended UML class diagram, paying attention to the features we find necessary for the successful schema presentation.
The primary use case for the data schemas we consider here is serving the context-aware
autocompletion in building visual queries over RDF data in the ViziQuer tool [
There exists a wealth of tools for visual presentation of OWL ontologies, including VOWL [
In the context of RDF data summarization (cf. [
In the rest of the paper Section 2 provides a motivational example and the data schema concept description, Section 3 describes the visualization of the data schemas and Section 4 provides brief conclusions and outlines directions for future work.
We consider data schemas that are based on property availability at classes and connections of classes by properties, including the situations when a property can link multiple pairs of classes. Should it be typical for an instance in a data set to belong to multiple classes (including, but not limited to, the case of a subclass and a superclass), a direct class-to-property mapping may exhibit a set of links that is overly large for characterizing the actual connections of instances in the data set. This would show up immediately in the schema diagram visualization, where the extra links both overload the schema and may even obscure the actual connections.
As a simple example, consider the data set of Nobel Prizes2 (we work with a copy3 made for easier connection reasons). Figure 1 shows a (manually drawn) fragment of the data set schema, regarding Awards, Laureate Awards and Nobel Prizes; similar structure of links is obtained also in the LD-VOWL visualization4. Here only the two direct links between nobel:LaureateAward5 and nobel:NobelPrize would be explicitly relevant; all links involving the dbo:Award class would actually obscure the data set presentation.
If the data schema is used to support a modeling environment (e.g., in context-dependent data query completion, either in SPARQL form, or possibly in visual form, as in ViziQuer tool6), the full list of source and target classes for a property would need to be collected. However, the markers for the class importance in the context of a property would be essential also in the modeling environment. For instance, if a class were the property domain or range (the smallest domain/range, if there are several ones), this would allow to consider all other source/target classes for the property to be less relevant and even auto complete the property domain/range information. Still, the data schemas need to also cover the cases where there are more than one relevant class designated as a source or target class for a property (intuitively, the union of all “relevant” classes would need to cover the entire set of subjects or objects in the property triples).
3 http://85.254.199.72:8890/sparql, Named graph: http://nobelprizes.local 4 http://vowl.visualdataweb.org/ldvowl/#/graph?endpointURL=http:%2F%2F85.254.199.72:8890%2Fsparql 5 Here and further on the used namespace prefixes stand for their usual URIs. The prefix nobel: stands for http://data.nobelprize.org/terms/ and ncat: stands for http://data.nobelprize.org/resource/category/. 6 http://viziquer.lumii.lv/. https://viziquer.app
Figure 2 outlines the structure of (an essential fragment of) the data schema used for storing the class-to-property correspondence, together with the described relevance markers (cover_set_index in the cp_rels table that relates the classes and properties) also stating the relation type_id (1 for incoming and 2 for outgoing property), cardinalities and property domain/range class information. The schema contains also further information that is used in the setting of auto-completing visual queries over RDF data in the ViziQuer tool, although the schema structure and its data can be used also independently of the visual tool.
We offer the data schema filling by running first the open-source OBIS Schema Extractor tool7 that issues a (possibly, large) series of SPARQL queries over a data set and creates a JSON-encoded structure of the data set schema (there are options to specify the level of granularity of the information to be retrieved from the data set at the schema extractor interface). The created JSON file is then stored into the database of the described schema by the data shape import service tool8, followed by some manual editing of the namespace prefix abbreviations (e.g., for namespaces not found on prefix.cc site).
The data schemas described in Section 2 assist query auto-completion in the ViziQuer tool (with possible independent usage). The work demonstrated here shows the possibility to visualize the corresponding schema in form of extended UML class diagram thereby providing the visual schema presentation in addition to the visual ViziQuer query creation tool environment.
The idea of the schema visualization is to ascribe the properties only to those source and target classes that are relevant in the sense described in Section 2, so not ascribing a property link source/target to a superclass, if all property subjects/objects belong to a subclass, and not ascribing a property link source/target to a subclass if it is ascribed to a superclass.
Figure 3 shows a visualization of the Nobel Prizes data set schema in accordance with these principles. We note the single appearance of the properties dct:hasPart and dct:isPartOf connecting the nobel:LaureateAward and nobel:NobelPrize classes, in contrast to the naïve visual schema presentation in Figure 1.
Should only the object properties connecting the classes and the data properties at classes been visualized, an important property nobel:category would have been missing from the schema, as it connects (in the actual dataset) the instances of nobel:LaureateAward and nobel:NobelPrize classes to resources that do not have their class assertions specified. Therefore, a design is suggested to show an object property (nobel:category in the example) at a source class as an attribute, if some of its object instances are classless.
The created data schema is further on enriched by the property triple statistics (optional) showing the property triple count in the context (source class or source and target class combination) and total property triple count, property domain (D) and (local) range (R) information (in the ontological sense) and property max cardinality (1 or *).
To offer a further compactified data schema presentation, abstract superclasses (as dbo:City
or dbo:Country in the example) can be introduced into the data schema, based on the shared
properties for which the classes are sources or targets. An abstract class is introduced based on
shared incoming and outgoing object properties, however, when introduced, it lists the data
properties common to all its subclasses, as well9. The ontological range information for properties
incoming into the abstract superclass is not shown in the example schema, however, it can be
computed (approximated) from the information that is collected in the data schema (Figure 2).
dbo:Award (1.60K)
nobel:category (1596/1596) [
rdfs:label (4788/10021) [*]
nobel:NobelPrize (612)
nobel:categoryOrder (612/612) [
The data schema shown in Figure 2 (in Section 2) admits a possibility to specify a classification
property (classification_property field in table classes) used for identifying a class in the data. The
typical classification property is rdf:type, however, there are endpoints that use different
classification properties (e.g., Wikidata10). In the considered Nobel Prizes data set example the
classes in Figure 3 are created each with the rdf:type property, however, it would be possible to
9 Since the abstract superclasses currently are not reflected in the data schema (Figure 2), the statistics information
for the properties at an abstract superclass may be higher than the actual numbers, if there are individuals shared by
the subclasses. A remedy for this would be either introducing the abstract superclasses in the data schema, or
consulting the actual data set during the schema creation process.
10 https://query.wikidata.org/
dct:isPartOf (984/
984) [
nobel:LaureateAward (984)
nobel:share (984/984) [
In the example the classifier values corresponding to the nobel:category property are marked with the prefix (ct), and are shown using a simplified notation (list of multiple class names/classifier values in a single visual container) since none of them have any incoming or outgoing property characteristics that would be different from their container superclass.
Note that the categories for Nobel prizes and Laureate in the actual data set, although have the same local names, are different resources that belong to different namespaces (and therefore are to be listed separately in the extended data schema).
nobel:Laureate (976)
foaf:name (1024/1025) [*] nobel:laureateAward
owl:sameAs (976/1947) [
foaf:Organization (27)
dct:created (26/26) [
foaf:Person (949)
dbp:dateOfBirth (949/949) [
nobel:LaureateAward (984)
dct:hasPart (982/982) [*] DR nobel:share (984/984) [
nobel:sortOrder (984/984) [
The visualization module is freely available11, together with its usage instructions in the ViziQuer tool context. The visualization starts from an existing ViziQuer project, from which the data to be loaded into the visualization tool are generated (an independent use of the visual schema presentation module would require generating this information in some other way).
The technical implementation of the visualization is currently performed within the desktop
based GrTP/TDA platform [
The visualization module repository also provides links to the information on the currently visualized schemata. The current schemata list involves schemas over Nobel Prizes, Mondial13 and ISWC 2017 metadata14, and is kept growing. 11 https://github.com/LUMII-Syslab/dss-schema-explorer 12 http://owlgred.lumii.lv 13 http://servolis.irisa.fr:3232/mondial/sparql 14 http://servolis.irisa.fr/iswc2017/sparql In this work we have demonstrated that a saved data schema, in particular the one used by the ViziQuer tool environment, may contain useful information for the data schema visualization that would typically not appear in the simple class-to-property mappings that could be retrieved onthe-fly from the suitably sized data endpoints.
The concept of a data schema expansion to introduce non-standard classifiers on the level of the data schema and its visual presentation has been introduced, as well.
The principal directions of the future work include a fine-tuning of the visualization concept
(e.g., by dealing with properties whose triple subjects or objects are classless). The concepts and
algorithms from RDF graph summarization area (cf. [
Regarding the use of the visualization in the ViziQuer tool the principal future work avenues include integrating the visualization solution into the web/based tool environment, developing the options for schema fragment presentation and navigation, as well as enabling the data query creation over the data schema backbone presentation (since both the data schema presentation and a developed visual query would have similar UML-style diagram structure).
This work has been partially supported by a Latvian Science Council Grant lzp-2021/1-0389 “Visual Queries in Distributed Knowledge Graphs”.