Live data from Hacker News

An Introduction to Knowledge Graphs

ai.stanford.edu

61–70 of 76 posts

Re: An Introduction to Knowledge Graphs

#61
post #43
post #5

Earlier quoted context omitted.

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 an…

The size of Wikidata knowledge base / relevant graph (as well as Linked Open Data Cloud KBs and other large KBs) certainly presents some challenges. However, I think that the largest challenge and, in fact, the main obstacle, for practical programmatic solutions is the use of essentially meaningless alphanumeric identifiers assigned to entities and properties. All corresponding identifiers need to be discovered first…

Why manually, when you have APIs to find Wikidata items and properties based on their labels, descriptions, aliases, data, metadata and use?

If you mean autocomplete UI or tooltips, look no further than the query editor and its Ctrl+Space at https://query.wikidata.org/

Re: An Introduction to Knowledge Graphs

#62
I couldn't stress how important Wikidata (and its predecessor DBpedia) is as a public example of a huge knowledge graph (versus the ones hidden at big tech companies) but also as a Wikipedia-like collaborative project to organise all the knowledge among existing semantic web / linked data publishers, government open data, libraries, galleries, archives...

Also remember that Wikidata is open source and you can fire up your own knowledge graph as docker containers on your laptop: https://wikiba.se/

If you have been disappointed by RDF-based technologies before, I would say Wikidata/Wikibase have significantly innovated on top of them. For example, they allow each statement to have qualifiers, references, depreciation/preferredness attached to them in a user-friendly way while also keeping simple queries simple.

Re: An Introduction to Knowledge Graphs

#63

Earlier quoted context omitted.

There's no such thing in practice as "California is in the US." What you can get in reality is "Alice told the computer in 2008 that Bob wrote in his 1999 book that California was in the US in 1470BC." Perspectivism is the understanding that it's impossible to interpret semantic "knowledge" without knowing the limitations and implicit context carried with the fallible, partial transcription of the truth (set in a wor…

> partial transcription of the truth (set in a world that obeys quantum mechanics, for one thing) Quantum mechanics actually says there's less information needed to describe X area of space than classical physics implies there is. https://en.wikipedia.org/wiki/Bekenstein_bound

Both limits are unimaginably far above the amount of text you could reasonably write to describe something.

Re: An Introduction to Knowledge Graphs

#64

On 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!

Didn't you hear? Having two columns makes it twice as sciencey.

Re: An Introduction to Knowledge Graphs

#65

On 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!

>no complex two-column format, Two columns is for the reader's benefit - your eyes can keep their place on the page much more easily when jumping half the distance to the beginning of the next line

Two columns makes inappropriate assumptions about the reader's choice of media. The aging publisher assumes everyone prefers paper. A reader attempting to scroll through the article on a tablet suffers.

We blew it, making a global effort to perfect fixed format technical typesetting rather than flowable text. Technical flowable text is just now becoming viable, and it is certainly not the norm for journal articles.

Re: An Introduction to Knowledge Graphs

#66
post #2

KG 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.

... there's a whole bunch of Datomic-likes these days:

https://github.com/simongray/clojure-graph-resources#datalog

Re: An Introduction to Knowledge Graphs

#67
post #44

So this is the ‘semantic web’ from ~15 years ago?

Think of this as a programming language? The semantic web is another choice.

Programming languages are valued both when they reveal inevitable design, and when they enjoy widespread adoption. We continue to have many programming languages, because there is no consensus on inevitable design.

The design of "this" reveals no deep secrets about the nature of the universe; the only parts that seem inevitable are the parts that seem obvious. And all of what one sees seems obvious; the choices involve what one doesn't see, what is left out of the system.

The value here is in widespread adoption. The system is good enough that people can agree to use it.

Re: An Introduction to Knowledge Graphs

#68

Knowledge 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 environme…

Recent work suggests it's possible to generate knowledge graphs from large corpi of text encoded with a language model: https://arxiv.org/abs/2010.11967

I wouldn't recommend using this work to generate knowledge graphs, as it requires a lot of rule based filtering. I suspect it wouldn't be any better than generating from a constituency parse tree. Disclaimer, I implemented this work a while ago and reach my current conclusion, still waiting for the official code to release.

Re: An Introduction to Knowledge Graphs

#69

Earlier quoted context omitted.

Honestly I think people's assumption that graph databases must be better in representing binary relations might be a bit optimistic. After all there's no reason relational databases (named after the n-ary relationships that tables represent) couldn't handle binary relations. The one thing that's definite is that SQL is a bad choice for particular kinds of queries, though most graph databases don't seem to go much fur…

Modern SQL can express arbitrary queries (including transitive closure ofc.) since it allows for recursive table expressions.

That's still some ways of from what I'd call "arbitrary" but yeah you can go quite far.

Re: An Introduction to Knowledge Graphs

#70

I 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".

As Clay Shirky said,"Ontology is Overrated" https://oc.ac.ge/file.php/16/_1_Shirky_2005_Ontology_is_Over... See also his talk https://www.youtube.com/watch?v=ujMgQqp8YSY

Seconding the wisdom shared by u/julienreszka and you.

Stuff like schemas and data dictionaries and reuse are chinese finger traps for us geeks. Exquisite problems we can't look away from.

I eventually decided to treat most data ingestion (ETL) as screen scraping. Honoring Postel's Law. Pull out the interesting relevant bits as needed. Ignore the rest.

There's still an internal model, natch. But it's the smallest, most obvious model to support my immediate use cases. Nothing more.

Post reply on HN