Idea for storing trusted timestamps in Noark 5

Petter Reinholdtsen pere at hungry.com
Fri Jun 9 17:24:59 CEST 2017


Hi Kent Inge.  Very nice to see you here. :)

[Kent Inge Fagerland Simonsen]
> Although the noark 5 specification sems to be unavailable at the
> moment, I dont think that storing trusted timestamps as documenc
> objects are in the spirit of Noark 5 (if that is, at all, a
> thing). The reason is that these objects are meant to contain
> variations (i.e. different formats) and versions of archiived
> documents.

I definitely understand this viewpoint.  I am not quite convinced this
is against the spirit of Noark 5, given that a perfectly valid
'variantion' of a document would be a PDF with a completely blacked out
content, and the document trusted timestamp could be seen as equally
derived from the original as such variant.

> A timestamp, trusted or not, is more like metadata and, in my oppinion
> should be treated as such.

Note, a trusted timestamp is not really a timestamp, it is a binary
blob.  This is the reason I found dokumentobjekt to be a good candiate
for storing it.  If we store it in a text field, we would have to base64
encode it or something.

And the trusted timestamp is closely connected to a specific file (or at
least a specific check sum), so it should be stored close to or
associated with the file it is stamping.

> The Noark specification, afaik, allows implementations to add
> aditional metadata, so this could be another way to go here.

Sure.  But another term for 'implementation specific metadata' is
'vendor lock-in' and I do not want to propose something that only work
on some implementations.  One of my goals is to make sure the data we
store can be migrated without data loss to any Noark 5 compliant system.

> Also: Hi everybody, my name is Kent Inge and I hope to help.

Welcome.  Great to see you here.  What bring you to our nice project? :)

-- 
Happy hacking
Petter Reinholdtsen


More information about the nikita-noark mailing list