Rosetta Stone and Cognitive Interoperability: Specifying Display Templates and Using a Query Builder

Table of Links

• Abstract & Introduction
• Interoperability
• Semantic interoperability and what natural languages like English can teach us
• Requirements for successfully communicating terms and statements
• Parallels between the structure of natural language statements and data schemata with implications for semantic interoperability
• What makes a term a good term and a schema a good schema?
• The need for a machine-actionable Rosetta Stone for (meta)data that acts as an interlingua for specifying reference terms and reference schemata to support cognitive and semantic interoperability
• Rosetta Stone and machine-readability: UPRIs, XML Schema datatypes, and RDF for communicating terms, datatypes, and statements
• Rosetta Stone and machine-interpretability: Wikidata and a modeling paradigm for (meta)data statements based on English
• Rosetta Stone and semantic interoperability: Specifying term mappings and schema crosswalks
• Rosetta Stone and cognitive interoperability: Specifying display templates and using a query builder
• Discussion
• Related work
• Conclusion, Acknowledgements, & References

Rosetta Stone and cognitive interoperability: Specifying display templates and using a query builder

Display templates

Humans usually do not want to see the (meta)data of a knowledge graph in the form of triples—they do not want to read them in any of the RDF serializations, nor do they want to visualize them as a graph. In order to display the content of a (meta)data statement modeled according to the Rosetta approach in a human-actionable way, a frontend application needs a display template that specifies how a rendering function can translate a given (meta)data structure into a human-readable statement. Display templates organize information from the (meta)data structure along with additional prepositions to be presented in the UI.

For example, if a weight measurement with a 95% confidence interval were stored according to an appropriate reference schema, the schema would specify four literal-object-positions (MAIN_VALUE, UPPER_VALUE, LOWER_VALUE, INTERVAL_VALUE) and one resource-object-position (UNIT). The form-based display template could specify that this information should be displayed in the frontend as ‘SUBJECT has weight (INTERVAL_VALUE% conf. interval): MAIN_VALUE (LOWER_VALUE-UPPER_VALUE) UNIT’. Another example is a travel statement where the corresponding reference schema specifies one required resource-object-position (DESTINATION_LOCATION), two optional resource-object-positions (DEPARTURE_LOCATION, TRANSPORTATION), and one optional literal-object-position (DATETIME). The corresponding display template would display a travel statement in the frontend as ‘PERSON travels by TRANSPORTATION from DEPARTURE_LOCATION to DESTINATION_LOCATION on the DATETIME‘. In other words, the subject-position and the various object-positions (i.e., the syntactic positions with their associated semantic roles) are mapped to corresponding variables within a string to form a human-readable statement (see Fig. 10, top). We call such textual display templates dynamic labels.

In addition to textual display templates, it is also possible to specify graphical display templates for a mind-map-like representation of a statement using dynamic mind-map patterns. Dynamic mind-map patterns use a label for the predicate underlying the corresponding statement type and, if there is more than one object-position, labels for relating the various objects to the predicate. As a result, the statement can be visualized as a mind-map like graph, where each subject and object is represented as a node with the label of the corresponding resource from the underlying graph of the (meta)data statement (see Fig. 10, bottom). Such graphical representations of statements can also be combined to form a mind-map of larger contexts and interrelationships that connect the dynamic mind-map patterns of multiple statements. Mind-map-like representations of complex interrelationships between different entities are easier to understand than form-based textual representations, thus increasing the human-actionability of a knowledge graph.

(Meta)data can be communicated to the presentation layer in the UI, with the templates filtering the complex data structure for the information relevant to a human user, using dynamic labels and dynamic mind-map patterns to present statements, decoupling human-readable data display from machine-actionable data storage.

A given reference schema can have multiple dynamic labels and dynamic mind-map patterns associated with it. It can be beneficial to be able to choose between different display templates depending on the context in which the (meta)data are accessed (PC vs. smartphone, expert user vs. layperson, etc.). The specifications of each display template should be associated with its corresponding reference schema and statement class, thus contributing to the easily accessible and usable Rosetta module mentioned above, moving it even closer to the concept of Knowledge Graph Building Blocks (64).

A Rosetta Query-Builder

We believe that findability is the most important aspect of any tool that stores and documents (meta)data. If relevant (meta)data cannot be found, no other operations can be performed on it, and interoperability issues become secondary. In the context of knowledge graphs, specific query endpoints have been established along with corresponding graph query languages to interact with the graph. These are SPARQL for RDF- and OWL-based knowledge graphs and Cypher for labeled property graphs such as Neo4J. Our personal experience is that most users and software developers have no experience with graph-based databases, are not familiar with graph query languages and their benefits, and therefore do not see the need to learn them. And even those who are familiar with them report that writing more complex queries can be challenging. Apparently, the need to write SPARQL or Cypher queries is a barrier to interacting with knowledge graphs and hinders their wider use (65).

The semantic unit framework introduced some-instance and every-instance resources as two new types of resources in addition to named-individuals, classes, and properties (50). This allows, besides specifying universal statements and negations without having to use blank nodes and simplifying negations and cardinality statements, modeling them as ABox expressions, also representing questions as statements in the graph (for a discussion, see (10,64)). Instead of named-individuals, one uses some-instance resources of a given class for a given slot of a reference schema to specify that the answer to the question may have any instance of that class at that position in any statement of the type to which the reference schema is associated. If you are asking about universal statements, you would use the every-instance resource instead.

The resulting statement can be stored as a question within the knowledge graph, by classifying its statement resource to instantiate the ‘question statement’ class. Since all question statements in a given knowledge graph would reflect the structure of their corresponding reference schema, and since all reference schemata have been created according to the same modeling paradigm, one could develop a Rosetta Query-Builder that converts the question into a query that returns a Boolean true/false answer if the subject and object-positions contained fully specified inputs (i.e., named-individual resources), or a list of statements as the answer that match the specifications provided by the question statement if one or more of these positions contained underspecified input (i.e., some-instance, every-instance, or class resources).

The same idea provides the basis for developing query interfaces for knowledge graph applications: users can create their own queries with the input forms for creating statements using named-individuals, some-instances, every-instances, classes, and datatypes as inputs for subject and object-positions without having to know and use any graph query languages. The Query-Builder translates the question statements into actual graph queries. The generic structure of the reference schemata greatly facilitates the development of procedures for this translation step. By using Boolean operators (AND and OR) and by reusing object resources as subject resources in another question statement, multiple question statements can be combined to form a more complex question.

Question units not only allow you to document questions in the graph, but also to make them operable. This can be used, for example, to document competency questions for a project in a readily actionable way within the knowledge graph itself. The ability to store question statements and make them operable moves the Rosetta Framework another step closer to the concept of Knowledge Graph Building Blocks (64) and further enhances its overall cognitive interoperability.