The definition seems faulty to me, since the pair (E: subset(N × N), f: E → L) does not admit of multiple edges with different labels, connecting the same ordered pair of nodes. Of course this is most often allowed in practical KG's.
An Introduction to Knowledge Graphs
11–20 of 76 posts
Re: An Introduction to Knowledge Graphs
#12SQL 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
Graph databases likely are more optimized for this sort of data storage, but you've hit it on the head that SQL databases can be used to represent node/edge style data.
Re: An Introduction to Knowledge Graphs
#13Re: An Introduction to Knowledge Graphs
#14On a side note, I love the idea of researchers writing “articles” in this format. No paywall, no complex two-column format, no PDFs. As a researcher myself, I wish this is what my “productivity” was judged upon, I’d probably have a lot more fun and motivation to work and produce!
Re: An Introduction to Knowledge Graphs
#15SQL 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 discuss…
> it does fall down for graphy tasks like multihop joins, connect the dots, and supernodes.
These can always be accomplished via recursive SQL queries. Of course any given implementation might be unoptimized for such tasks. But in practice, this kind of network analytics tends to be quite rare anyway.
One should note that even inference tasks, that are often thought of as exclusive to the "semantic" or "knowledge" based paradigm, can be expressed very simply via SQL VIEW's. Of course this kind of inference often turns out to be infeasible in practice, or to introduce unwanted noise in the 'inferred' data, but this has nothing to do with SQL per se and is just as true of the "knowledge base" or "semantic" approach.
Re: An Introduction to Knowledge Graphs
#16The definition seems faulty to me, since the pair (E: subset(N × N), f: E → L) does not admit of multiple edges with different labels, connecting the same ordered pair of nodes. Of course this is most often allowed in practical KG's.
Indeed multiple edges (with different labels) are quite useful, particularly when you want to represent RDF graphs. But since there is no restriction on the form of L, you can still represent those by, e.g., letting L be a set of sets of IRIs, and thus labelling your edges with sets of IRIs, which you then interpret as a set of RDF triples (i.e., as a set of edges).
Re: An Introduction to Knowledge Graphs
#17I wish all of you not to fall in the trap of ontologies. I worked very hard in this domain my conclusion is that all ontologies fail to scale eventually. I would recommend people in the field to go towards "perspectivism".
Re: An Introduction to Knowledge Graphs
#18I wish all of you not to fall in the trap of ontologies. I worked very hard in this domain my conclusion is that all ontologies fail to scale eventually. I would recommend people in the field to go towards "perspectivism".
I’d like to read more about what you worked on specifically if you’re willing to share!
Re: An Introduction to Knowledge Graphs
#19SQL 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
yes, you can always map most structures into tables, or even excel.
but it think "good fit" is a stretch. when designing systems you generally want to look at data access patterns, and pick a data exec approach that aligns to that.
in tech, unfortunately, RDBMS are the "hammer" in "if your only tool is a hammer then every problem looks like a nail."
Re: An Introduction to Knowledge Graphs
#20I wish all of you not to fall in the trap of ontologies. I worked very hard in this domain my conclusion is that all ontologies fail to scale eventually. I would recommend people in the field to go towards "perspectivism".
Is this just a way of saying that no relations are absolute?