We fielded several questions as part of our recent webinar (recording and slides available here): Semantic Knowledge Graphs are the Governance Architecture of the Future

Questions from the webinar included:

Q1: How do you customize the panels in the human user interface?

Users can drag and drop panels on to the page. Panels can be arranged as desired. Users can then save the panel arrangement as a custom layout and even share it with others. Most panels have Settings menu that is used to further configure its appearance.

Q2: Can the Logical Model also be used to derive OWL schemas (‘ontologies’) that operate at a logical level?

Yes. EDG can run transformation rules, so it is possible to create a class for each logical entity. EDG uses SHACL for ontology modeling so we do talk about SHACL schemas. Semantics of SHACL are much more aligned with the traditional data modeling schema languages. With this, logical attributes and logical relations can be used to create SHACL property shapes that associate properties with classes.

One needs to be careful with using the term “OWL schemas” as OWL is really not a schema language in a traditional data modeling sense. It is a language that defines inferences as opposed to schema constraints which are typical of the data and object modeling. It also has open world semantics meaning that there is no support for “negation as failure” or “single resource – unique name”. Practically, speaking, for example, cardinalities in OWL do not mean what you would normally assume them to mean. Having said this, if you want to generate RDFS domain/range statements or OWL restrictions from logical data models described in RDF this is also possible.

Q3: How would you extend the Asset Example for Medical Enterprise to support, say, a consortium of hospitals, all with slightly differing data and technical assets, or even different glossary terminology? What’s the pattern to relate the Assets for hospital A with hospitals B, C, D, etc.?

If your question is about creating organizations, EDG will let you create a new class Consortium that has members and then you could capture members of the consortium. If your question is about aligning different glossary terms used within these organizations, EDG lets you create multiple glossaries. Even within a single organization, it is common to have multiple glossaries used by different groups. Some of these glossaries may have overlapping terms. Typically, related or similar terms are connected using the appropriate relationships.

All asset collections in EDG are separate, but at the same time connectable – they are all part of a knowledge graph. Relationships used to connect these assets will depends on the nature of the actual relationship. For example, if two terms are exactly the same, you could use a link called “exact match”. If one term is broader than another term, you could use “broader” or “broader match”. There are, of course, other options. EDG can also help you identify potential matches by suggesting them.

Q4: Could you speak briefly about the hooks between EDG and “production” databases? Is it only through GraphQL?

GraphQL is a very popular API. And JSON is a very popular data exchange format. Unlike REST endpoint, with GraphQL developers do not need to create different endpoints for different needs. A single endpoint can provide access to data with consuming application deciding the information they need and the structure of the JSON that will be delivered. The same is true for using GraphQL to update EDG.

These are some of the reasons we are excited about GraphQL, but it is not the only way to interact with EDG. For example, EDG also offers SPARQL endpoint. RESTful services can be templated/scripted based on user’s needs. Some commonly requested RESTful services come prebuilt. RESTful services can be created as query templates or scripted from pre-built data conversion modules (SPARQLMotion). EDG also connects to data sources through JDBC and can capture their metadata and profile and sample data. XML and tabular (spreadsheet) data can also be ingested. For use with unstructured content EDG can connect to content repositories and file systems and ingest information about documents in hundreds of formats. In general if there is an API EDG can connect to it.

 

Q5: Any integration with Github?

EDG uses a database, not files. It can import files. It can also export its information in files. If desired, these files can be stored in Github. The periodic export into Github can be scripted and scheduled. It is fairly uncommon to keep data such as reference datasets or data graphs or data dictionaries in Github, but it is possible.

Typically, however, EDG is deployed and operated as any database system. There are scheduled backups and recovery processes. EDG also offers high availability with server replication. Changes are audit trailed, so there is no danger of losing information.

Q6: Do you have any developer’s or trial version ?

Yes, you can sign up for an evaluation server.

Q7: One view is that data governance must be controlled by workflows.  How does that workflow centric view fit into the knowledge graph-based infrastructure you have shown?

TopBraid EDG supports workflows.  There are built-in workflows and organizations can create their own custom workflows.

 
Workflows in EDG are designed / structured in the same way as other models – they are types of knowledge graphs just like everything else.
 
The kinds of dynamic updates that we have been showing  — for instance a system outside of EDG updating a model in EDG through an API — can be performed and controlled through workflows

 

Q8: You showed preexisting models in the environment.  Do we have to use those or can we create our own?  

The models in EDG are there to help you get started — it is an advantage to have such a foundation to start with.  But you don’t have to use them all or use them as is.
 
You can extend them as we showed in the webinar.  We only demoed adding a new property, but you can also add new classes (types of assets). You can also deactivate certain aspects of the pre-built models that you don’t want to use. For example, deactivate some of the properties. You can use some of the models or none of them. Updates to the models can be done through UI or through the APIs. For example, GraphQL mutation (updated) queries can be ran against the models.
 
You can also take advantage of bringing in models from other sources — e..g. there are external knowledge graphs that define models that can be imported, etc.