An Introduction to Knowledge Graphs
ai.stanford.edu
An Introduction to Knowledge Graphs
1–10 of 76 posts
Re: An Introduction to Knowledge Graphs
#2KG are cool, but I haven't find a practical framework of combining simple logical predicates with temporal facts (things that are true at a certain moment in time) and information provenance (the truthiness of information given the origin). There might be ways to encode this information in a hyper graph but they are far from practical.
Re: An Introduction to Knowledge Graphs
#3KG are cool, but I haven't find a practical framework of combining simple logical predicates with temporal facts (things that are true at a certain moment in time) and information provenance (the truthiness of information given the origin). There might be ways to encode this information in a hyper graph but they are far from practical.
Checkout Datomic. It’s a temporal database that uses datalog as it’s query language. There’s also Datascript, which does the same thing.
Re: An Introduction to Knowledge Graphs
#4SQL might be a good fit to model Knowledge Graphs, since FOREIGN KEYs can be named, using the CONSTRAINT constraint_name FOREIGN KEY … syntax. We thus have support to label edges.
Nodes = Tables
Edges = Foreign keys
Edge labels = Foreign key constraint names
Re: An Introduction to Knowledge Graphs
#5KG are cool, but I haven't find a practical framework of combining simple logical predicates with temporal facts (things that are true at a certain moment in time) and information provenance (the truthiness of information given the origin). There might be ways to encode this information in a hyper graph but they are far from practical.
Wikidata statements (which roughly correspond to the edges in the Knowledge Graph) have quite a bit of Metadata associated with them: they can have refer to sources that state this particular bit of knowledge, they have a so-called rank that allows distinguishing preferred and deprecated statements, and the can be qualified by another statement in the graph. Temporal validity is encoded using a combination of rank and qualifiers, as for, e.g., Pluto[0], where the instance-of statement saying that “Pluto is a planet” is deprecated and has an “end time” qualifier, and the preferred statement says “Pluto is a dwarf planet,” with a corresponding “start time” qualifier.
In principle, all of this information is available through the SPARQL endpoint or as an RDF export (there is also the simplified export that contains only “simple” statements lacking all of that metadata), so reasoning over this data is not entirely out of reach, but the sheer size (the full RDF dump is a few hundred GBs) is also not particularly practical to deal with.
Re: An Introduction to Knowledge Graphs
#6KG are cool, but I haven't find a practical framework of combining simple logical predicates with temporal facts (things that are true at a certain moment in time) and information provenance (the truthiness of information given the origin). There might be ways to encode this information in a hyper graph but they are far from practical.
Might be worth looking at Sowa's Conceptual Graphs. E.g., [1], talks about time, and links to his book.
Re: An Introduction to Knowledge Graphs
#7Knowledge graphs for text (the focus of the article) seem narrowly-scoped since they require "objective" facts and relations to be practical. Capturing the subjective and transient perspective of observations made by multiple observers (which is what we actually have access to) is more complicated.
For example, asking the same person the same question may yield different answers based on their mood or other environmental or situational factors. Who's asking the question can also matter, as does the specific phrasing of the question.
Re: An Introduction to Knowledge Graphs
#8KG are cool, but I haven't find a practical framework of combining simple logical predicates with temporal facts (things that are true at a certain moment in time) and information provenance (the truthiness of information given the origin). There might be ways to encode this information in a hyper graph but they are far from practical.
Checkout Datomic. It’s a temporal database that uses datalog as it’s query language. There’s also Datascript, which does the same thing.
Unfortunate name for a product, I can't find anything called Dynamic on DDG, only dynamic things with a lowercase d. Do you have a link to the project?
Re: An Introduction to Knowledge Graphs
#9Earlier quoted context omitted.
Checkout Datomic. It’s a temporal database that uses datalog as it’s query language. There’s also Datascript, which does the same thing.
Unfortunate name for a product, I can't find anything called Dynamic on DDG, only dynamic things with a lowercase d. Do you have a link to the project?
not dynamic but Datomic
Re: An Introduction to Knowledge Graphs
#10SQL might be a good fit to model Knowledge Graphs, since FOREIGN KEYs can be named, using the CONSTRAINT constraint_name FOREIGN KEY … syntax. We thus have support to label edges. Nodes = Tables Edges = Foreign keys Edge labels = Foreign key constraint names
This kind of approach is pretty common, including in compute engines like Spark's graphx. I suspect a lot of teams using graph DBs would be better off realizing this: it's good for simple and small problems
it does fall down for graphy tasks like multihop joins, connect the dots, and supernodes. So for GB/TBs of that, either you should do those outside the DB, or with an optimized DB. Likewise, not explicitly discussed in the article, modern knowledge graphs are often really about embedding vectors, not entity UUIDs, and few/no databases straddle relational queries, graph queries, and vector queries