Question
Should TextRefs integrate with N2T (Name-to-Thing, https://n2t.net/) — e.g. become an ARK NAAN holder and/or register a resolver prefix so TextRefs IDs resolve via n2t — and if so, when?
Context
TextRefs IDs are already HTTP URIs that resolve under https://textrefs.org/id/.... related-systems.md lists ARK and PURL as neighbours. N2T integration would add a community-standard resolution path and optionally ARK identifiers alongside our UUID-based IDs.
Points to weigh
- Pro: durable, institution-independent resolution; alignment with the ARK/N2T ecosystem; hedge against domain/hosting changes.
- Cost/commitment: NAAN stewardship obligations; maintaining redirect/resolver mappings; overlap with our own
/id/* resolver already on the roadmap ("Next": Accept-Language / edition 303s).
- Model fit: would ARKs be mappings on existing records (like DOI/Handle today) or a second primary identifier? ADR-0002 fixes Reference IDs as UUID v5 from the semantic tuple — an ARK layer must not muddy that identity contract.
- Sequencing: likely after the public resolver/API milestone stabilizes.
Desired outcome
A go / not-yet / no decision with rationale, and — if pursued — whether it warrants a full ADR given the identifier-model implications.
Question
Should TextRefs integrate with N2T (Name-to-Thing, https://n2t.net/) — e.g. become an ARK NAAN holder and/or register a resolver prefix so TextRefs IDs resolve via n2t — and if so, when?
Context
TextRefs IDs are already HTTP URIs that resolve under
https://textrefs.org/id/....related-systems.mdlists ARK and PURL as neighbours. N2T integration would add a community-standard resolution path and optionally ARK identifiers alongside our UUID-based IDs.Points to weigh
/id/*resolver already on the roadmap ("Next": Accept-Language / edition 303s).Desired outcome
A go / not-yet / no decision with rationale, and — if pursued — whether it warrants a full ADR given the identifier-model implications.