hi
Im working on graph and im seeing depth and weight in vertex and connection on response but im not able to understand what is that.
im trying to make parent child relationship using copy_to having id of parent but im not getting proper search like at one i get 5 vertex after that i need to do spidering operation to get more result can i get all vertex at one shot.
Hi. The API docs describe as follows:
The weight attribute specifies a significance score.
The depth attribute specifies the hop-level at which the term was first encountered.
Each nesting of a connections section in the request represents a "hop" that will bring in a new set of terms with the same depth but potentially different significance scores.
Hope this helps.
hi,
thanks for the reply I need to know how to get all related documents without spidering operations means after a request I need all documents at once
The graph API is designed to discover related terms - documents are only used to give weight to the links between pairs of terms. If you need to drill-down into the details of the documents behind these connections you'll need to perform a follow-up query with the list of discovered terms.
Hi
Once again thanks for the reply im trying to get all vertex in a single request means get all vertex at once instead of doing spidering operation on the previous requests is it posibble
I'm unclear what you need - vertices (which are terms) or documents?
Means getting all matching nodes at a single request
When you nest connections clauses in your request you are asking for another "hop" into the graph of connections. Maybe some example input data and a required output result would help clarify the problem that we are trying to solve here
can i get all nodes and connections at once like
first request is giving some 10 nodes then through spidering operations i need to get further more relations so on continue...
Instead of above is there a way to get all vertex and related vertex
Is there a way to get parent child relationship for same index type means i know we cant have self reference but some thing else we can have????
Here is an example where documents queried contain an array of 2 or more IDs held in an entref_id array:
{
"query": {
"query_string": {
"query": "myseedquery"
}
},
"controls": {
"use_significance": false,
"sample_size": 2000,
"timeout": 5000
},
"vertices": [
{
"field": "entref_id",
"size": 50,
"min_doc_count": 1
}
],
"connections": {
"vertices": [
{
"field": "entref_id",
"size": 50,
"min_doc_count": 1
}
]
}
}
Note that it uses a seed query to start the exploration and retrieves up to 50 matching vertices. It then finds (independent of the seed query constraints) up to 50 more vertices that are connected to the initial vertices. Nesting more connections clauses would further the exploration achieved with this one request.
if i want more than 50 vertices lets say all vertices what should i do
Increase the number. Clearly handling a billion results in a single JSON response would not be a good thing for the server or the client to attempt. That is a limitation of trying to perform this analysis within a single request-response paradigm.
Im trying to make relation with same index type in elasticsearch but its not possible is there a way to solve means self referencing using parent child for same type
Please post example JSON for the documents you want to join
Lets say i have one person named anna who is wife of dave since both are in person type
anna belong to dave
Anna --wife--> dave
here dave is parent of anna
I need to see JSON for how these concepts are represented as documents in your index/indices.
If you haven't worked out a design for your docs yet maybe you can start by listing the entities and relationships that are part of the business problem you are trying to solve.
hi sir,
How can i know which vertex is parent in graph since i dont see any direction on connections
so which is parent vertex and which is child vertex
It is possible but needs some workarounds.
In general graph theory "parent" and "child" would be role metadata used to describe each of the nodes on an edge or in a directed graph the direction of the edge could imply the relationship (e.g. children always point to parents).
The thing to remember about the elasticsearch graph view of data is that the edges (we call them "connections") are aggregate edges - there could be ten thousand banking documents recording money transactions back and forth between A and B but we would summarise all these interactions in a single undirected connection between A and B. This is both a strength and a weakness.
If you want to capture the details of a parent/child relationship in a graph visualization you'd need to introduce the relationship as a special node/vertex term. Each node in the relationship would then need to define and edge-like document asserting that they are connected to this relationship-defining term. Here's how that would look for a grandparent -> parent ->child definition:
PUT relationships
{
"settings": {
"number_of_replicas": 0,
"number_of_shards": 1
},
"mappings": {
"relationship": {
"properties": {
"id": {
"type": "keyword"
},
"parent->child": {
"type": "keyword"
}
}
}
}
}
POST /relationships/relationship/_bulk
{ "index" : {} }
{"id": "A", "parent->child":"A is parent Of B"}
{ "index" : {} }
{"id": "B", "parent->child":"A is parent Of B"}
{ "index" : {} }
{"id": "B", "parent->child":"B is parent Of C"}
{ "index" : {} }
{"id": "C", "parent->child":"B is parent Of C"}
Thanks for the reply sir,
In the above example i can see document with id=b is created twice which is duplicate which dont require my document is like below format
My document is
relationships/relationship/_bulk
{ "id":1,"name":"a" }
{ "id":2,"name":"b","parent":1 }
{ "id":3,"name":"c","parent":2 }
{ "id":4,"name":"d","parent":3 }
{ "id":5,"name":"e","parent":4 }
{ "id":6,"name":"f","parent":5 }
{ "id":7,"name":"g","parent":6 }
{ "id":8,"name":"h","parent":7 }
{ "id":9,"name":"i","parent":8 }
{ "id":10,"name":"j","parent":9 }
{ "id":11,"name":"k","parent":11 }
....
so when i search for name=d i need to get all its parent and all its child without spidering operation means in single request get
request is name =d
output should be a,b,c,d,e,f,g,h,i,j,k.... because it all is related directly or indirectly to name=d
it should be from one request