Schemaless Directory Structure

example1.sh

# Schemaless Directory Structure

A schemaless directory structure can be achieved in two stages.

1. Encapsulation
2. Metadata

### Stage 1 - Encapsulation

Encapsulation is to minimise the amount of duplicated information within a hierarchy.

```
/project
  /models
    /Hero
      /hero_model_v01
  /rigs
    /Hero
      /hero_rig_v01
```

Contains an identical amount of information as this.

```
/project
  /assets
    /Hero
      /model
        /v01
      /rig
        /v01
```

Yet one duplicates information - multiple directories named `Hero` and duplicate metadata
in filenames `hero_model` = `/Hero` and `/model` - whereas the other adds *new* information
at each level of the hierarchy.

In addition, `/Hero` now encapsulates everything related to itself which facilitates reuse.

example2.sh

Working within a schemaless directory structure could look like this.

```
/project
  /assets
    /Hero
      /model
        /private
        /public
```

**public** members of *any* directory - not just `/Hero` and not just "assets" - are *exposed*
members that are accessible to others. Also known as published data. Whereas **private** members
are created and managed by a single user.

Considering the fact that content is often produced in a variety of different software packages,
an additional layer is added.

```
/private
  /marcus
    /maya
    /nuke
    /houdini
```

Each directory can be automatically generated based on data derived without user intervention;
such as querying the currently logged in user and the software package about to be launched.

For published material.

```
/public
  /v01
  /v02
  /v03
```

The idea is that versions are versions, regardless of where they come from.

```
/public
  /v01
    /maya
    /nuke
    /houdini
```

In reality there would most often only ever be one software package related to any one asset.

```
/Hero/model/public/v01/maya
```

Maintaining the separation keeps it aligned with shot data.

```
/project
  /film
    /seq01
      /shot100
        /animation
        /creaturefx
        /lighting
```

In which `public` and `private` serves the same roles.

```
/shot100
  /animation
    /private
    /public
```

A version of animation for a shot may look like this.

```
/shot100
  /animation
    /public
      /Hero
        /v001
        /v002
```

In which each version, much like assets, may have multiple **representations**

```
/v001
  /alembic
  /atom
  /obj
```

example3.sh

### Stage 2 - Metadata

The second stage to a schemaless directory structure is querying information.

In a nutshell, when you are here.

```
/project/assets/Hero/model
```

We need something that answers the questions.

- What am I?
- What is my Asset?
- What is my Project?

Here is how something like that could look.

```
$ cd /project/asset/Hero/model
$ identify .Asset
/project/asset/Hero
$ idenfity .Project
/project
```

This queries the parenthood of a directory. Descendants are equally important, and
could look like this.

```
$ cd /project/asset/Hero/model
$ search .Version
/project/asset/Hero/model/public/v001
/project/asset/Hero/model/public/v002
/project/asset/Hero/model/public/v003
...
$ cd /project
$ search .Asset
/project/asset/Hero
/project/asset/Villain
...
```

cQuery is an implementation of the above.

- http://cquery.readthedocs.org/en/latest/overview.html

There is an example of a schemaless directory structure, along with a few Pyblish plug-ins that make use of it, in the Napoleon repository /examples directory.

• https://github.com/pyblish/pyblish-napoleon