NAMASTE file

[ross-spencer]

I caught the excellent FIAF presentation, and the section about the relation.db triggered a thought about NAMASTE which I recently learned about working on OCFL.

NAMASTE: https://web.archive.org/web/20211103114106/https://confluence.ucop.edu/download/attachments/14254149/NamasteSpec.pdf

The way the file is used is to use key-value pairs in a directory to describe:

E.g. 0=ocfl_1.1 ← tells us what
1=who
2=what
3=when
4=where

Each namaste file exists in a top-level directory, e.g.

• File 1: 0=ocfl_1.1
• File 2: 1=university_of_minnesota
• File 3: and so on...

I didn't know about it, and wondered if it might be better if it used one naming convention with all key-value pairs, e.g. a namaste file like Makefile but I think there's a question about Disk I/O.

One thought that connects it to the FIAF presentation you did was whether NAMASTE's goal could be met with a relation.db like file.

Another might be, whether naming conventions could also be used interestingly, e.g. a top-level file for relation.db in a directory called MERCS would be a flag and a signal for users to read more into that file and others. That being said, it's largely a thought, and works for directories with a specific purpose, but not buckets with multiple uses.

[pjotrek-b]

Supercool. Very interesting!
I must read both specs first: NAMASTE and OCFL to really understand your suggestions.

However, I'm indeed pretty sure some naming conventions to structure "related data objects" will come in handy.

Especially since I do want to use the filesystem to support related-object structures as common "normal file formats". 😉

Imagine...: instead of having a video container format: we can store the individual "streams" as standalone, yet related "data objects". And digital film (dpx+wav+xml+folders) would not be awkward anymore, and merely "huge" - but technically as common as a "normal video object structure".

And the relationships described are by metadata:
And that's where OCFL/NAMASTE may indeed be very interesting.
But I have to read more on them first...