Re: KG as KR as rubbish?

Totally agree with the thread and thanks for summarising the SW thread too. Here are my 2 cents:

There is gap between KR/KG because we haven’t really looked at efficient graph based KR and graph based query frameworks. Gartner putting a spin on KG as saviour for everything AI doesn’t help either - only feeds the marketing campaign of KG.

I did some work on an OWL based Query Language specifically for Protein Ontology back in 2008/9 and i think lessons need to learnt from Association Rule Mining and a  domain agnostic graph based query framework will help.

> On 19 Sep 2019, at 06:34, Amirouche Boubekki <amirouche.boubekki@gmail.com> wrote:
> 
>> Le mer. 28 août 2019 à 07:40, Paola Di Maio <paola.dimaio@gmail.com> a écrit :
>> 
>> I do not normally like to call stuff I disagree with  rubbish. I rarely do that.
>> 
>> but To propose KG as the future of KR sounds like complete rubbish to me
>> (shall try to justify this statement more scientifically)
> 
> 
> It would be best but getting into the actual analysis of all the poor
> work around it would take much time. I was teached to "be positive"
> and "show the way" instead of being not-very-diplomatic.
> 
>> I am shocked to see the cream of our research community being part of this
>> disinformation campaign
>> /aic.ai.wu.ac.at/~polleres/publications/bona-etal-DagstuhlReport18371.pdf
> 
> 
> To this I heartedly agree. For once in my life I can say "I was there"
> in the sense I was involved in graph database related work since 2011.
> And since that time a massive marketing campaign was happening when
> marketing is involved little or no Science is involved.
> 
> Here is the thing that I skimmed, if anyone else wants to shim in the
> conversation:
> 
> - http://blog.liu.se/semanticweb/2018/09/15/dagstuhl-seminar-on-knowledge-graphs/

> - https://thinklinks.wordpress.com/2018/09/18/trip-report-dagstuhl-seminar-on-knowledge-graphs/

> - http://www.juansequeda.com/blog/2018/09/18/trip-report-on-knowledge-graph-dagstuhl-seminar/

> - https://aic.ai.wu.ac.at/~polleres/presentations/20190827DEXA_keynote.pdf :(
> - https://aic.ai.wu.ac.at/~polleres/publications/bona-etal-DagstuhlReport18371.pdf

> - http://www.mkbergman.com/2244/a-common-sense-view-of-knowledge-graphs/

> - First thread in
> https://lists.w3.org/Archives/Public/semantic-web/2019Aug/thread.html

> 
> To repeat myself from a previous post, KG is mostly a marketing
> slogan. Still, it might have good ideas and (closed) implementation.
> 
> To me the primary mistake they do in the above writings is that they
> mix successful results of closed source software companies with the
> blurry view they have of it and knowledge representation (KR). They
> take the shortcut of saying that "KG is the way to go" because that is
> the marketing term those successful companies choose to use for some
> reasons. (KG is easier to spell and say that KR...)
> 
> The idea of what KG / KR is or should be is still blurry.
> 
> There is always a gap between what you want to express or represent
> and the implementation because physical limitations. Take for instance
> the relational-database-management-systems (RDBMS) which are at the
> end of the day .csv files on steroids. They draw on paper or
> blackboard using a graph. Are they graph? Yes! Everything is graph.
> Are they Knowledge Graph: Yes! They represent knowledge, rows can
> relate to each other so they are definitely graph in the common sense
> not just single dot points in vast empty space. They are graphs, but
> still we do not call them graphs or knowledge graph.
> 
> Something I note in the SW thread is that at least LinkedIn, Ebay,
> Apple, WikiData, Uber and maybe Google are relying on some software
> implementation that relates to n-tuple store (or chunks store). To me
> it means that n-tuple stores are not a mistakes in terms of
> implementation and are not a mistake in terms of representation even
> if less common sense compared to property graphs. At the end of the
> day, it is very clear to me that Ordered Key-Value Store (OKVS) are
> the future of database management. And on top of OKVS, n-tuple
> (chunks) is a very good candidate compared to other approaches because
> it is both sparse, relational and more powerful that "document store"
> approach (like mongodb). Any way all those consideration are mostly
> implementation details.
> 
> Maybe what happens to KG vs. KR is what happened to Probabilistic
> Models vs. Machine Learning (don't quote me on that :).
> 
> NB: KG as in property-graph ala neo4j is not a bullet proof solution
> to data problems modern applications are facing.
>

Received on Wednesday, 18 September 2019 21:26:09 UTC