Actions

Ontolog Forum

Session KGSQL
Duration 1 hour
Date/Time 07 July 2021 16:00 GMT
9:00am PDT/12:00pm EDT
5:00pm BST/6:00pm CEST
Convener KenBaclawski

The Knowledge Graph System Query Language

KGSQL is a new language for accessing and managing knowledge graphs. This language addresses some of the shortcomings of existing languages for knowledge graphs. KGSQL is based on the definition of a knowledge graph in the Ontology Summit 2020 Communiqué. However, non-graph structures can also be represented, such as arrays, trees and JSON data.

One of the most important distinctions between KGSQL and existing knowledge graph query languages is that in KGSQL essentially all of the statements are reified. In particular, this means that KGSQL statements can be annotated with provenance and other properties, and that the annotations can themselves be annotated. In spite of this, a KGSQL knowledge graph can be efficiently implemented using existing triple stores.

Agenda

Conference Call Information

  • Date: Wednesday, 07 July 2021
  • Start Time: 9:00am PDT / 12:00pm EDT / 6:00pm CEST / 5:00pm BST / 1600 UTC
  • Expected Call Duration: 1 hour
  • The Video Conference URL is https://bit.ly/3i1uPRl
    • iPhone one-tap :
      • +16465588656,,83077436914#,,,,,,0#,,822275# US (New York)
      • +13017158592,,83077436914#,,,,,,0#,,822275# US (Germantown)
    • Telephone:
  • Chat Room: https://bit.ly/39PzQJW
    • If the chat room is not available, then use the Zoom chat room.

Attendees

Proceedings

[12:11] RaviSharma: Hello everyone, specially Ken the speaker today

[12:12] RaviSharma: Why can we not specify quantity in shipment type?

[12:15] Douglas R. Miles1: @Ravi it is that RDF only allows arity 2 relations

[12:15] RaviSharma: So a named graph is a collection but it can be other things?

[12:17] RaviSharma: Reification is like fixing a broken link yes it is problematic

[12:17] RaviSharma: I also suggested this name KGSQL to Ken

[12:21] RaviSharma: It is ok we forget sometimes, janet and I both congratulated and named in that session as KG SQL.ken great modifications and enrichments in KGSQL.

[12:23] RaviSharma: What happens to resulting KG after FRED deletion, dangling edge loss graph?

[12:25] RaviSharma: Ken I even identified that arrow directions were to be counterclockwise?

[12:25] RaviSharma: Nice compared with SPARQL

[12:28] RaviSharma: could you thus relate pooled orders from different buyers who use this technique to exploit economy of scale?

[12:28] RaviSharma: Are you defining a new graphic notation for drawing KG?

[12:29] RaviSharma: I meant from counter to clockwise?

[12:30] anonymous: why the attribute -- "quantity" -- is linked with predicate "shipment", and not with the object "part34"

[12:30] RaviSharma: Mike, please chime in to leave Qs for Ken or anyone else?

[12:32] anonymous: I see that the object "part34" is linked with attribute "weighs", etc. which is understandable.. in the same sense, why not the "quantity"

[12:33] RaviSharma: Ken for provenance you have to have delimiters for each set of statements (KGSQL) that belong to an era in sense of provenance?

[12:36] RaviSharma: Please give example of a property for Liked List?

[12:37] RaviSharma: What happens when due to deleting some edges the whole KGSQL becomes unusable? just critically examining what if scenarios?

[12:38] RaviSharma: nice to see comparison with CLIF

[12:40] NancyWiegand: Why do lines come off the middle in your linked list diagrams?

[12:41] RaviSharma: Congrats, let it be recorded that with your effort we are seeing a great breakthrough in semantic or cognitive or logic embedded queries for KGs and it is next real progress beyond RDBMS SQL> Congrats Ken!

[12:42] RaviSharma: very statement therefore has a UNIQUE ID? e.g. running list or something else so even by mistake it can not be repeated as namespace can not be duplicate?

[12:46] RaviSharma: Could there be conflict between linked list and provenance or context Queries logically?

[12:46] MikeBennett: If certain things are not needed in RDF files for KGSQL, do the RDF files intended for use with KGSQL all need to be different to RDF files intended for use in other ways? OR can KGSQL simply ignore the un-needed stuff (domain, range etc.)?

[12:48] MikeBennett: Can you have an OWL ontology, as already designed, and use it in the KGSQL arrangements?

[12:49] RaviSharma: Ken with this we should use KGSQL to construct KGs themselves

[12:50] RaviSharma: once you define how each KGSQL statement implies a pattern, this can be done?

[12:53] BobbinTeegarden: Could you use the LISP notation of () within () to show nesting of statements and named graphs (and a type of composition)?

[12:56] janet singer: To clarify the origin of the name KGSQL, Ravi was the first to suggest the KGSQL in relation to SQL. I suggested the S be taken to stand for Systems rather than Structured.

[12:56] BobbinTeegarden: Why not take it to OMG so it becomes a 'controlled' standard...?

[12:59] RaviSharma: Janet thanks, Mike sorry I saw your hand later!

[12:59] RaviSharma: Janet Thanks

[12:59] RaviSharma: Mike sorry I saw your raised hand later

[13:00] RaviSharma: Bobbin yes OMG would also be great because it has two namely ODM linking OWL and MOF UML etc.

[13:01] BobbinTeegarden: ... and DOL ...

[13:01] Douglas R. Miles1: Ken have you considered making a Protege plugin for KGSQL or a TopBraid-Composer Plugin?

[13:02] RaviSharma: YES inference is definitely a higher level

[13:02] Douglas R. Miles1: *KGSQL

[13:02] RaviSharma: Ram's comment is great I kind of implied that in my comment, standardization is required.

[13:05] RaviSharma: CL version control from Jacob Friedman.

[13:06] RaviSharma: also asked about self describing type of KGSQL, great Q Jacob.

[13:10] RaviSharma: Janet and Gary, I am toying with the idea of asking Ken some more Qs in next wed sessions to make progress that help him in open source goals?

[13:13] RaviSharma: Jacob on SPARQL, what is comparison?

[13:14] RaviSharma: Ken Says bracket notation,

[13:15] RaviSharma: Janet - denotational (compositional) semantics, Ken said he wanted to use semantic notation.

[13:16] RaviSharma: I think what Ken is doing, Janet you are right it is denotational semantics!

[13:16] Douglas R. Miles1: > re: @BobbinTeegarden: Could you use the LISP notation of () within () to show nesting of statements and named graphs (and a type of composition)?

[13:17] Douglas R. Miles1: in the past when RDF was not expressive or complete enough people start writing their common logic statement sunder RDF with ((()))s

[13:17] RaviSharma: Category theory - Ken and Janet conversation.

[13:19] RaviSharma: Ravi mentioned CL and First order Logic, and Ken described how to come around it? There needs to be deeper discussion, if semantics is deeper, it will need to address logic, uncertainty and Query rules?

[13:21] Douglas R. Miles1: RDF easily translates to IKL.. but the other way around is not possible in most cases

[13:24] NancyWiegand: Just a high level statement that last week you indicated the demise of database as a field, ah you're just mentioning this now, that this new language is still trying to improve on the old problems of modeling, storing, and accessing/querying real world data in a manner that people (and machines) can understand. It still isn't solved. But, I like your new ideas. Thank you!

[13:24] Douglas R. Miles1: If we expect KGSQL to always round trip to RDF that would be a limit to KGSQL?

[13:26] Douglas R. Miles1: whatever doesn't round trip would be the enhancements that KGSQL gives us

[13:28] RaviSharma: Sapna will you please put your Q here as well?

[13:29] RaviSharma: Thanks Ken

[13:29] Cassiopeia Miles: Great Stuff, Thank you Ken!

[13:29] Andrew Dougherty: Thanks!

Resources

Retrieved from "https://ontologforum.com/index.php?title=ConferenceCall_2021_07_07&oldid=3945"