Folder hierarchy

[Yotam Leibovici]

Hi, is it possible to store files for annotation in a folder hierarchy within the application?

Thanks

[Richard Eckart de Castilho]

Hi,

> On 17. Jul 2025, at 11:01, Yotam Leibovici <yotam.l...@gmail.com> wrote:
>
> Hi, is it possible to store files for annotation in a folder hierarchy within the application?

The concept for organizing documents / work in INCEpTION is the project.
There is currently no level below (or above) the project wrt. organizing things.

What would you like to use folders for?

-- Richard

[Yotam Leibovici]

When working with a large number of documents (even just a few dozen), a hierarchical organization can make project management easier compared to a flat view—just like a hierarchical structure in regular file systems makes navigation easier. I would use folders to organize the documents logically, for example by characteristics such as document type, format, content, or even differences in the version of the annotation schema used to create or annotate them. This is useful when the documents share the same overall annotation schema and therefore need to remain in the same project, but their different characteristics affect who annotates the document or how it is further processed. Additionally, it can help in understanding how many documents there are of each type or format, based on segmentation by characteristics.

ב-יום שבת, 19 ביולי 2025 בשעה 14:59:21 UTC+3, Richard Eckart de Castilho כתב/ה:

[Richard Eckart de Castilho]

Hi,

> On 19. Jul 2025, at 14:38, Yotam Leibovici <yotam.l...@gmail.com> wrote:
>
> I would use folders to organize the documents logically, for example by characteristics such as document type, format, content, or even differences in the version of the annotation schema used to create or annotate them. This is useful when the documents share the same overall annotation schema and therefore need to remain in the same project, but their different characteristics affect who annotates the document or how it is further processed. Additionally, it can help in understanding how many documents there are of each type or format, based on segmentation by characteristics.

Why wouldn't you use projects to the same effect?

If you have different versions of an annotation scheme, having at least one project per version seems reasonable - if not even necessary.

You can assign annotators to projects quite easily. If you wanted to assign them based on folders, it would introduce additional complexity below the project wrt. workload management.

-- Richard

[Yotam Leibovici]

Sometimes the changes between versions are minor, and the differences between the various documents are also small or numerous in a way that, in my view, doesn’t justify managing multiple nearly-identical projects in parallel. In the current setup, in order to distinguish between documents that belong to different characteristics, I need to rely on their filenames, which becomes cumbersome, hard to change, and requires managing the differences externally (for example, through a list of documents of a certain type). I believe such a feature could make the system more complete, though I of course understand the complexity involved. I appreciate your attention to this.

ב-יום שבת, 19 ביולי 2025 בשעה 16:24:11 UTC+3, Richard Eckart de Castilho כתב/ה:

[Richard Eckart de Castilho]

Hi,

> On 19. Jul 2025, at 15:40, Yotam Leibovici <yotam.l...@gmail.com> wrote:
>
> I need to rely on their filenames, which becomes cumbersome, hard to change, and requires managing the differences externally (for example, through a list of documents of a certain type). I believe such a feature could make the system more complete, though I of course understand the complexity involved. I appreciate your attention to this.

I am looking into adding the ability to rename documents. A good part of it is already implemented, UI still missing... and testing...
Since document names had never been changeable, I'm not entirely sure what negative side-effects the change of a document name might
have. But we'll see.

-- Richard