Goal

Capture enough descriptive and process context to support interpretation, reuse, and stewardship by maintaining both object-level metadata and project-level registry metadata throughout the workflow.

1) Metadata workflow and handoff

2) Minimum fields plus high-value technical context

Core descriptive fields

  • object_id, title, creator, and physical_object
  • rights, access_level, and doi
  • preservation_master and access_files

Often missed but critical

  • capture_device and scan or photo conditions
  • scale_units and coordinate_system
  • linked_files and expected folder structure
  • software_environment and version numbers

Paradata you should not skip

  • Registration or alignment notes
  • Cleanup, smoothing, or decimation choices
  • Export parameters and validation checks

3) Simulated metadata files

These examples mimic the kind of document or control file a small repository can actually maintain. Hover or click highlighted fields to see why they matter.

Interactive metadata preview

Object metadata note

CoopersHawk_001

Prepared for repository handoff

CoopersHawk_001
structured_light
Artec Eva, turntable setup
local object coordinates; millimeters
OBJ + MTL + TIFF textures stored in geometry/, materials/, textures/
Artec Studio 18; Blender 4.2
CoopersHawk_001_master_v03_pres.obj
Global registration, hole filling on base, light smoothing, no decimation on master
Package reopened in Blender after moving folder; textures resolved correctly

object_id

This is the anchor connecting the object across files, folders, logs, and repository systems. If it drifts, traceability drifts with it.

capture_method

Photogrammetry, LiDAR, and structured light create different data types, file sizes, and preservation dependencies. The method helps future users interpret the dataset.

capture_device

Device or scanner details explain precision limits, workflow expectations, and any vendor-specific risks that came with capture.

coordinate_system

Units and coordinate assumptions are essential for scale, alignment, and reuse. Without them, later measurement or assembly work can become unreliable.

linked_files

3D assets often depend on sidecars such as MTL files and textures. This field documents what belongs together and how the package is expected to be organized.

software_environment

Version numbers help manage software drift and vendor lock-in. If a file later behaves differently, this field gives people a starting point.

preservation_master

Call out the authoritative high-fidelity file set explicitly so it is not confused with lighter access or print derivatives.

paradata

Paradata records interpretation and intervention: registration, smoothing, decimation, filtering, and export choices that shape what the model means.

validation_note

A quick note that the package was reopened after transfer makes hidden failures easier to catch before long-term storage.

{
  "": "1.1",
  "": "2026-03-25",
  "": [
    {
      "": "TREC_CoopersHawk_2026",
      "title": "Coopers Hawk specimen scan",
      "owner": "Sustain 3D",
      "": "Documentation/workflow_standards.txt",
      "": "Metadata/object_profile_v1.txt",
      "": {
        "access_level": "public",
        "rights": "institution-owned",
        "license": "CC BY-NC 4.0"
      },
      "": {
        "doi_status": "published",
        "doi_value": "10.xxxx/example"
      }
    }
  ]
}

registry_version

A schema or profile version helps you change the registry over time without losing track of which structure older records used.

updated

This gives you a quick signal that the registry is being maintained and not drifting out of sync with actual preservation activity.

projects

The registry works at project level so you can manage many objects while keeping shared ownership, workflow, and publication context together.

project_id

This is the project anchor for workspace folders, preservation packages, and public deposit records.

workflow_doc

Linking the workflow standard makes repository expectations explicit instead of assuming future users know the local process.

metadata_schema

This is where you point to a shared schema, profile, or controlled vocabulary so metadata remains consistent across projects.

policy

Access, rights, and license statements belong here because reuse is shaped by governance as much as by file quality.

publication

Tracking DOI status here helps connect local stewardship work to publication, discovery, and long-term citation.

4) Empty templates

Keep these closed until you need to copy them into your own repository.

Project registry template

Shared control file for the whole project

Use this for project identity, workflow references, policy values, and publication status.

 
{
  "registry_version": "1.1",
  "updated": "",
  "projects": [
    {
      "project_id": "",
      "title": "",
      "owner": "",
      "date_start": "",
      "date_end": null,
      "workflow_doc": "Documentation/workflow_standards.txt",
      "metadata_schema": "",
      "policy_doc": "",
      "policy": {
        "access_level": "",
        "rights": "",
        "license": "",
        "attribution": ""
      },
      "publication": {
        "doi_status": "none",
        "doi_value": null,
        "landing_page": null
      },
      "notes": ""
    }
  ]
}

Object metadata template

Field list for one object package

Use this when you need a quick object-level note that still captures technical context.

 
object_id:
title:
creator:
date_created:
physical_object:
capture_method:
capture_device:
scale_units:
coordinate_system:
linked_files:
software_environment:
preservation_master:
access_files:
rights:
access_level:
doi:
paradata:
validation_note: