|
| 1 | +# Installation |
| 2 | + |
| 3 | +## Service Snapshot |
| 4 | + |
| 5 | +Cratey Validator is a web service that checks whether RO-Crates follow the |
| 6 | +expected structure and metadata rules. It can validate a complete RO-Crate |
| 7 | +stored in MinIO-compatible object storage, or it can validate the contents |
| 8 | +of an `ro-crate-metadata.json` file directly. |
| 9 | + |
| 10 | +At a high level, a client sends a validation request, the service runs the |
| 11 | +RO-Crate validation checks, and the result is either returned directly or |
| 12 | +saved so it can be retrieved later. |
| 13 | + |
| 14 | +## What You Can Validate |
| 15 | + |
| 16 | +### Stored RO-Crates |
| 17 | + |
| 18 | +Use this option when the RO-Crate already exists in MinIO-compatible object |
| 19 | +storage. The service reads the crate from the configured bucket, runs the |
| 20 | +validation checks, and saves the validation result back to object storage. |
| 21 | + |
| 22 | +This is useful for validating complete crates as part of an upload, review, |
| 23 | +or publication workflow. |
| 24 | + |
| 25 | + |
| 26 | +### Metadata Files |
| 27 | + |
| 28 | +Use this option when you only need to check the contents of |
| 29 | +`ro-crate-metadata.json`. Instead of asking the service to download a full |
| 30 | +crate, you submit the metadata JSON directly and receive the validation result |
| 31 | +in the response. |
| 32 | + |
| 33 | +This is useful for quick checks while editing metadata or before a complete |
| 34 | +crate has been assembled. |
| 35 | + |
| 36 | + |
| 37 | +### Saved Validation Results |
| 38 | + |
| 39 | +After a stored RO-Crate has been validated, the saved validation result can be |
| 40 | +retrieved later. This lets another application or user interface show the most |
| 41 | +recent validation status without rerunning the checks. |
| 42 | + |
| 43 | + |
| 44 | +## Before You Start |
| 45 | + |
| 46 | +For stored RO-Crate validation, you need: |
| 47 | + |
| 48 | +- A MinIO-compatible object store. |
| 49 | +- A bucket containing the RO-Crate. |
| 50 | +- Access credentials for that bucket. |
| 51 | +- The crate identifier used by the object store. |
| 52 | + |
| 53 | +For metadata-only validation, you only need the contents of |
| 54 | +`ro-crate-metadata.json`. |
| 55 | + |
| 56 | + |
| 57 | +## Running The Service |
| 58 | + |
| 59 | +The service can be started with Docker Compose: |
| 60 | + |
| 61 | +```bash |
| 62 | +docker compose up --build |
| 63 | +``` |
| 64 | + |
| 65 | +For local container development, use: |
| 66 | + |
| 67 | +```bash |
| 68 | +docker compose --file docker-compose-develop.yml up --build |
| 69 | +``` |
| 70 | + |
| 71 | +Expected local services: |
| 72 | + |
| 73 | +- Flask API: `http://localhost:5001` |
| 74 | +- MinIO API: `http://localhost:9000` |
| 75 | +- MinIO console: `http://localhost:9001` |
| 76 | +- Redis: `localhost:6379` |
| 77 | + |
| 78 | +MinIO needs a bucket for RO-Crates, normally `ro-crates`. Bucket versioning |
| 79 | +should be enabled so uploaded crate objects can be tracked reliably. |
| 80 | + |
| 81 | + |
| 82 | +## Configuration |
| 83 | + |
| 84 | +The main environment variables are: |
| 85 | + |
| 86 | +- `FLASK_APP`: Flask entrypoint, normally `cratey.py`. |
| 87 | +- `FLASK_ENV`: selects development or production config. |
| 88 | +- `CELERY_BROKER_URL`: Redis broker URL. |
| 89 | +- `CELERY_RESULT_BACKEND`: Redis result backend URL. |
| 90 | +- `PROFILES_PATH`: optional path to custom RO-Crate validator profile |
| 91 | +definitions. |
| 92 | +- `MINIO_ENDPOINT`: default MinIO endpoint used by Docker examples. |
| 93 | +- `MINIO_ROOT_USER`: MinIO root username for local development. |
| 94 | +- `MINIO_ROOT_PASSWORD`: MinIO root password. |
| 95 | +- `MINIO_BUCKET_NAME`: default bucket name used by local setup. |
| 96 | + |
| 97 | +API calls also pass MinIO access details in `minio_config`, so the service can validate crates in a specified object store and bucket. |
| 98 | + |
| 99 | +## More Information |
| 100 | + |
| 101 | +- For endpoint paths, request bodies, response codes, validation profiles, and |
| 102 | +result storage paths, see the [REST API documentation](./rest_api). |
| 103 | +- For implementation details, service components, runtime flow, and test |
| 104 | +coverage, see the [Architecture documentation](./architecture). |
| 105 | +- For deployment context and the architecture diagram, see |
| 106 | +[Deployment](./deployment). |
0 commit comments