Re: Is scalability the key property of knowlege graph?

Thank you for your response. I think the KG term is spread by GOOGLE, while I don’t how google implement it.  I used to think the semantic network  is the key technology of KG,but google has never statement that.
> 在 2019年6月13日,下午2:46,Paola Di Maio <paola.dimaio@gmail.com> 写道:
> 
> Thank you for asking this, 
> 
> I  ll leave the experts to reply to scalability and other questions
> 
> In general, much depends on the language one uses, which in turn
> depends on the domain (which planet you come from)
> 
> When I first studied knowledge engineering, the expression knowledge graph
> was not in use at all. I was doing an MSc and studied the body of knowledge
> from ESPRIT project (some folks on this list worked on it)
> https://pdfs.semanticscholar.org/193e/b66909b0c87d5dbcdbd6b20d78ed93fc95a7.pdf <https://pdfs.semanticscholar.org/193e/b66909b0c87d5dbcdbd6b20d78ed93fc95a7.pdf>  
> 
>  I d be curious to learn when such term knowledge graph came in use and who coined it 
> 
> I then heard it in relation to the SW and this list, and always tried to figure out what exactly 
> a KG is (in relation the wider Knowledge Representation domain I was studying)
> 
> Knowledge graphs are a type of knowledge representation, and they can be visualized
> graphically, or represented using algebra (again, depends on what planet you are on)
> Engineers tend to use diagrams, others tend to use algebra
> 
> But more importantly, is that they enable machine readability querying and computational manipulation of complex (combined) data sets, assuming knowledge is some kind of data in context, as some say.
> I dont use the term knowledge graph much either.  Let's see if the KG folks can offer more info
> 
> PDM
> Knowledge Graph Representation
> Knowledge graphs provide a unified format for representing knowledge about relationships between entities. A knowledge graph is a collection of triples, with each triple (h,t,r) denoting the fact that relation r exists between head entity h and tail en- tity t. http://ceur-ws.org/Vol-2322/dsi4-6.pdf <http://ceur-ws.org/Vol-2322/dsi4-6.pdf> 
> 
>  
> 
> 
> 
> 
> On Thu, Jun 13, 2019 at 1:40 PM 我 <1047571207@qq.com <mailto:1047571207@qq.com>> wrote:
> Dear all:
> 
> When I first touch knowledge graph, I'm very confused. Different from the other AI theory,  it is not an pattern recognization algorithm which will  give some "output" given some "input"(such as classify algorithms) ,but a program language(such as owl,rdf) and database(such as neo4j) instead. So in my opinion, knowledge graph is more like a problem of engineering than mathematic theory.  
> 
> Then I realized that different from the pattern recognization algorithm, the knowledge graph is created aimed at making the computes all over the world to  communicate with each other with a common language, and I have a question: Is scalability the key property of knowledge graph?
> 
> There are many knowledge vaults edited by different language(such as owl,rdf ),but is it always hard to merge them and there is not a standard knowledge vault  on which  we can do advanced  development. So is it necessary to open a scalable  and standard knowledge vault so that everyone can keep extended it and make it more perfect just like linux kernel or  wiki pedia? What kind of knowledge should be contained in the standard knowledge vault so that it can be universal?  I imagine that the standard knowledge vault is an originator, and all of the other application copy the originator, then all of the other application can communicate under the same common sense, for example when a application decelerate ''night", all of the other application will know it's dark. 
> 
> As I know, the knowlege graph is implement as a query service, but is it possible to implement it  as a program language,just like c++,java? In this way ,the compute can directly know nature language, and human can communicate with compute with nature language, also a compute can communicate with another compute with nature language.
> 
> 
> 
> 
> 
> 
> 
> 
> 

Received on Thursday, 13 June 2019 09:18:56 UTC