Skip to content

Session 2: Chapter 1 Introduction

Jump to bottom
msesboue edited this page Feb 10, 2022 · 2 revisions

Questions

Session Minutes

During this session, we answer the following questions (see issues for the detailed session time):

  • Data warehouse/lake approach, but with a KG
  • Could you describe how data management changes with knowledge graphs? + Expectations
  • Given that most legacy RDBMS data has the problems noted in Chapter 1, is it possible -- or advisable -- to build a partial Knowledge Graph with just the elements for which the semantics are relatively clear?
  • Do you have some examples of inference use case?

During this session we also had some great discussions/comments in the chat:

Does that mean that we can't have semantics if there isn't any data?

  • We always operate on something.
  • perhaps, but if the semantics aren't grounded, we can't use it. Like an electrical circuit without grounding is...suspect.
  • This is certainly true for almost all the engagements I have been involved in. But I occasionally encounter a project where the ontology itself is the product. But not like FIBO (which eventually gets down to data, in the way Juan talks about), but the ontology almost seems to be data in its own right.

any ideas/suggestions on how can I get experience in KG work (RDF, OWL)?

  • I think the 3rd edition of his SWWO book is a great practical intro to RDF, OWL, etc.

Are there good tools for graphically drawing KG's? Would be really helpful to go from a sketch (of an ontology) to something you can query as a demonstration of the power of KG's to others in an enterprise. Does such a thing exist?

  • Gra.fo, we have a thing called gra.fo that lets you visually build ontologies
  • I often use Keynote
  • Another tool that let you define things graphically: metaphactory
  • Works with Neptune

Other remarks:

  • I think I understand the connection between "semantics" and the application of mappings/queries. In the Query approach, the Data is stable, whereas the Semantics are ad hoc, unshared, and possibly inconsistent from query to query, even for a given analyst.
  • I think I see how a data warehouse is not a KG because a warehouse houses products, in boxes, that you ultimately want to access and ship, so some operational efficiency (or at least low response time) is implied. Whereas a term like "data mesh" better communicates the idea that you're probably not going to interact with it directly (you don't go "in" a mesh loke you go "in" a warehouse).

Clone this wiki locally