# Understand Jina Recursive Document Representation¶

In Jina, each Document is represented as a recursive representation (tree).

A rooted recursive representation has a root node and every node has X children. In Jina, the root node is the document itself, while the left & right children are referred to as chunks and matches respectively.

The above image illustrates a basic document structure: A document (root node) and the two possible child nodes: chunks and matches. chunks are a sequence of documents which is attached to the root document with a higher `granularity` degree. `matches` is a sequence of documents which are semantically related to the root document. We’ll dive into these concepts in this chapter:

## Chunks¶

Each Jina Document (potentially) consists of a list of chunks. A `chunk` is a small semantic unit of a Document, like a sentence or a 64x64 pixel image patch.

Think about these use cases: you want to search a document at a specific `granularity` level, e.g. a sentence or a paragraph. Or your query consists of multiple modalities, such as a piece of text together with an image. `chunk` makes it feasible!

In Jina primitive data types, `chunk` is defined as a `property` of a Document:

```from jina import Document

with Document() as root:
root.text = 'What is love? Oh baby do not hurt me.'
# Initialised a document as root with 0 chunks.
print(len(root.chunks))
>>> 0
# Initialise two documents and add as chunks to root.
with Document() as chunk1:
chunk1.text = 'What is love?'
with Document() as chunk2:
chunk1.text = 'Oh baby do not hurt me.'
# Now the document has 2 chunks
print(len(root.chunks))
>>> 2
```

What happened by adding `chunk` to `root`?

```print(root.granularity)
>>> 0
print(root.chunks[0].granularity)
>>> 1
root.id == root.chunks[0].parent_id
>>> True
```

This can be seen in the image below:

The code sample and graph above demonstrates the basic idea of a `chunk` in a Document. In the beginning, we initialized a Document with `granularity=0` (by default). We then initialized two chunks and add them to the `root` document. Two things happened when adding the `chunk` to `root`:

1. The granularity of the chunk has been increased by 1 (default 0).

2. The `chunk` has been referenced to its parent: `root`.

This allows Jina (and you) to query chunks and reference back to its root document at any `granularity` level.

## Matches¶

In a neural search system (and traditional retrieval system), matches are the expected documents returned from the system given the user query. In Jina, `matches` could happen at the `root` level or any `chunk` level.

To fully understand the concept of `matches`, we introduce a new term, named `adjacency` (short for `a` in the diagram), which reflects the level of the document it is connected to.

NOTE: granularity and adjacency apply to both chunks and matches.

```from jina import Document

with Document() as root:
root.text = 'What is love? Oh baby do not hurt me.'
>>> 0
# Initialise two documents and add as chunks to root.
with Document() as chunk1:
chunk1.text = 'What is love?'
with Document() as chunk2:
chunk1.text = 'Oh baby do not hurt me.'
with Document() as match:
# a match document semantically related to our root
match.text = 'What is love? Oh please do not hurt me.'
print(len(root.matches))
>>> 1
print(root.matches[0].granularity)
>>> 0
>>> 1
```

In the code snippet and diagram above, we initialized a Document as `root` with the text: What is love? Oh, baby do not hurt me.. And a Document with text What is love? Oh please do not hurt me was added as a match to the `root`. The matched document `match` is a document without any parents, so it stays at the same level as `root` with a granularity value of 0. Meanwhile, since `match` is the retrieved result from `root`, so the `adjacency` increased to 1.

By default, the `root` node has an `adjacency` of 0, and the value increases by 1 when it hits a `match`.

## Let’s go deeper: Recursive Document Representation¶

Till now, we’ve introduced chunks and `matches` with a depth of 1. While in a real-world scenario, things could be much more complicated than this. For instance, a `chunk` could be further divided into small chunks, and a chunk at any level might have it’s own `matches` at that level.

Jina has defined a recursive structure with arbitrary width and depth instead of a trivial bi-level structure. Roughly speaking, chunks can have the next level chunks and the same level matches; and so do matches. This could go on and on. The following figure illustrates this structure Ref: New Features in Jina v0.5 You Should Know About.

This recursive structure provides Jina the flexibility to cover any complex use case that may require search at different semantic units. Besides, the recursive structure enables Jina rankers to accumulate scores from lower granularities to upper granularities, such as `Chunk2DocRankers`. For example, in NLP a long document is composed of semantic chapters; each chapter consists of multiple paragraphs, which can be further segmented into sentences. In CV, a video is composed of one or more scenes, including one or more shots (i.e. a sequence of frames taken by a single camera over a continuous period of time). Each shot includes one or more frames. Such hierarchical structures can be very well represented with the recursive representation.

If we look from a tree view (with a depth of 3):

## Document Traversal with traversal paths¶

As you already learned from Jina 101, you needs to apply transformation (i.e. a `callback`) on a different level of documents. Given the tree structure, how could we achieve that? The answer is `traversal`.

Jina has defined a method called `traversal` within the class of Document, which looks like this:

```def traverse(self, traversal_path: str, callback_fn: Callable, *args, **kwargs) -> None
"""Traversal apply `:meth:callback_fn` on the recursive tree representation."""
...
```

This allows you to apply `callback_fn` based on `traversal_path`. The `traversal_path` is defined as below:

With these pre-defined node names, you’re able to apply any callbacks (defined as `_apply_all` in the `driver`) to a specific node. In the below YAML configuration, the `VectorSearchDriver` was applied to node `c`, `KVSearchDriver` was applied to node `cm` (matches of chunks).

```!CompoundIndexer
...
requests:
on:
SearchRequest:
- !VectorSearchDriver
with:
traversal_path: ['c']
- !KVSearchDriver
with:
traversal_path: ['cm']
```