CASRAI Dictionary

Tag: project metadata

  • Project metadata that travels: phases, milestones and the research record

    A research project has structure. It moves through phases, it passes milestones, it produces deliverables on a schedule, and it changes status as it goes. Anyone who has managed a grant knows this structure intimately — and yet almost none of it survives into the durable research record. The phases and milestones live in a proposal document and a project-management tool, and when the project ends they are forgotten, leaving behind only a scatter of outputs. This article asks what it would take for project metadata to travel — to become part of the research record rather than ephemera in a filing cabinet. It draws on the research-lifecycle domain.

    The vocabulary of project structure

    Start with the concepts, because they are stable across funders even when the names vary. A project phase is a defined sub-period of a project with its own deliverables — the structure that lets a three-year grant be planned as a sequence rather than an undifferentiated block. A milestone is a scheduled point at which a specific outcome is achieved: a target, not a task. A deliverable is a scheduled output, often tied to a milestone. A work package is a grouped set of activities, the organising unit familiar to anyone who has worked on an EU-funded consortium. And a project status — proposed, awarded, active, suspended, completed, discontinued — captures where the whole activity currently stands.

    These are not exotic concepts. They are the ordinary furniture of project planning, and they are common to nearly every substantial research grant. What is missing is not the concepts but a shared, structured way of recording them that outlives the proposal.

    Why this structure evaporates

    The reason project structure rarely reaches the research record is that it is captured in the wrong places. Phases and milestones are written into the proposal — a PDF — to satisfy the funder at application time. They are then re-entered, in a different shape, into whatever project-management tool the team uses to run the work. Neither of these is part of the durable, identifier-anchored record. The proposal is archived and forgotten; the project-management tool is decommissioned when the project ends. The structure was real and useful throughout the project’s life, and then it simply disappears, because nothing was responsible for preserving it as data.

    The cost of this evaporation is subtle but real. When a project’s phases and milestones are lost, the record retains what was produced but not when, against what plan, or in what sequence. A reviewer assessing whether a project delivered against its objectives cannot easily compare the planned milestones with the actual outputs, because the planned milestones are gone. The narrative of how the project unfolded — which is exactly what a final report or an impact assessment needs — has to be reconstructed from memory.

    What “metadata that travels” means

    For project metadata to travel, three things have to be true. First, it has to be structured rather than locked in prose: a milestone recorded as a dated, named, status-bearing entity, not a sentence in a proposal. Second, it has to be anchored to a persistent identifier, so that it has a stable home and can be referenced from elsewhere. Third, it has to be updated through the lifecycle, so that the record reflects what actually happened — a slipped milestone, a re-scoped phase, a change of status — rather than freezing the plan as written at award.

    The natural anchor is the project’s RAiD. A Research Activity Identifier gives the project a stable identity across its lifecycle, and its structured record is the right place to hang the phases, milestones, and status that the project moves through. The deliverables link out to the outputs they produced (by DOI); the milestones carry dates and statuses; the project status updates as the work proceeds. The data-management plan, anchored by its DMP ID, is itself a kind of living project document that should evolve with the phases rather than freezing at award — the same principle applied to the data plan that a travelling project record applies to the project as a whole.

    The living-record principle

    The deepest shift here is from a frozen plan to a living record. Research administration has historically treated the proposal as the canonical statement of a project’s structure: written once, approved, and thereafter immutable. But a project is not immutable. Milestones slip, phases are reordered, scope changes, and a record that freezes the original plan becomes steadily less true as the project proceeds. The machine-actionable data-management plan community has already made this argument for DMPs, and the same logic applies to project structure generally. Metadata that travels is metadata that stays true, because it is maintained rather than archived.

    A caveat against over-formalising

    A note of restraint. The goal is not to turn every research project into a heavyweight, fully-specified work-breakdown structure policed by metadata. Research is not pure project management, and much valuable research is genuinely exploratory, with phases and milestones that are loose by design. The aim is a light shared vocabulary — enough structure to record the phases, milestones, and status that a project genuinely has, in a form that travels — not a mandate to plan research as if it were construction. A vocabulary that forced exploratory work into rigid milestones would be worse than none. The right amount of structure is the amount the project actually has, recorded so that it survives.

    Where the dictionary fits

    The concepts — phase, milestone, deliverable, work package, status — are stable and shared, but their representations are not. Every funder names them differently; every CRIS structures them locally; every project-management tool has its own model. A shared, operational vocabulary for these lifecycle concepts, with clear definitions and the status values enumerated, is what would let project metadata mean the same thing as it moves between the proposal, the CRIS, the RAiD record, and the funder’s report. Supplying that vocabulary is the convening role the CASRAI dictionary is built for.

    What to do now

    For research teams and offices: capture phases, milestones, and status as structured, dated entities anchored to the project’s RAiD, and update them as the project proceeds rather than freezing the proposal. For funders: accept and request project structure as machine-readable metadata, so that delivery against plan can be assessed without manual reconstruction. For standards work: define the lifecycle concepts lightly and federate to RAiD and the DMP standards, resisting the temptation to over-formalise.

    Related reading

  • RAiD and the research activity lifecycle: identifying projects, not just outputs

    For years the persistent-identifier ecosystem had a conspicuous hole in the middle. We could identify outputs with DOIs, people with ORCID iDs, and organisations with ROR IDs — but the thing that connects them all, the research project itself, had no standard identifier. The Research Activity Identifier (RAiD) fills that hole. It identifies the research activity, not just its outputs, and it does so across the activity’s whole lifecycle. This article explains what RAiD is and why identifying the project changes what the research record can do. It draws on the research-lifecycle domain.

    What RAiD is

    A RAiD is a persistent identifier for a research project or activity. It is governed by an international standard, ISO 23527:2022, which gives it the same kind of formal grounding that underpins the DOI and ORCID systems. RAiD is in production: the Australian Research Data Commons (ARDC) operates as a registration authority, with services also running in the European context through the FAIRCORE4EOSC project and adoption progressing in the United States. It is not a proposal or a pilot; it is operational infrastructure.

    A RAiD record is a small, structured container for the project’s identity. It holds the project’s name, its start and end dates, its current status, and — crucially — typed links to the other entities involved: the people (by ORCID iD), the institutions (by ROR ID), the funding (by grant identifier), and the outputs (by DOI). The RAiD does not duplicate all that information; it references it. The record is the hub; the spokes point out to the identifiers that already exist.

    Why identifying the project, not just the outputs, matters

    The conventional research record is output-centric. We record papers, datasets, and software, each with its own identifier, each citing its funding and listing its authors. From that scatter of outputs, anyone wanting to understand the project — what it set out to do, who was involved, what it produced in total, how it evolved — has to reconstruct it by inference, gathering up outputs that happen to share an acknowledgement or a grant number. The project exists only as a pattern in the outputs, never as a thing in itself.

    RAiD inverts this. The project becomes a first-class entity with its own identifier, and the outputs become things the project produced. This sounds like a small change of emphasis; it is not. It means a funder can point at a project and see everything it generated, without grepping acknowledgements. It means a researcher moving institutions can carry the project’s identity with them. It means the connections between people, funding, and outputs are asserted in one authoritative place rather than re-inferred by every system that needs them.

    The lifecycle dimension

    The word “activity” in Research Activity Identifier is doing real work. An output is a fixed artefact: once a paper is published, its DOI points at something that does not change. A research activity is a process that moves through stages — and RAiD is designed to identify that process as it evolves, not just to label its endpoint.

    A research lifecycle typically runs from idea, through planning, into execution, then dissemination, evaluation, and archiving. A project’s RAiD record persists across all of these. Its status changes — from proposed, to active, to completed — while its identifier stays constant. New outputs are linked as they appear. New collaborators are added as they join. The RAiD is the stable handle on a moving target, which is exactly what an output identifier cannot be, because an output does not move.

    This lifecycle persistence is why RAiD connects naturally to the other stage-aware identifiers. The data-management plan has a DMP ID; the funding has a grant ID; the outputs have DOIs; the people have ORCID iDs. The RAiD is the spine that threads through the whole lifecycle, linking the plan made at the start to the outputs produced at the end and the evaluation that follows. Without it, those stage-specific records are islands; with it, they are a connected account of a single activity over time.

    What RAiD is not

    It is worth marking the boundaries to avoid over-claiming. A RAiD is not a project-management tool: it does not run your Gantt chart, track your milestones in detail, or manage your budget. It is an identifier with enough structured metadata to locate the project in the wider research graph, not a system for executing the project. Nor does RAiD replace the institution’s CRIS; rather, the CRIS is one of the systems that can mint and reference RAiDs, using the RAiD as the shared, portable identity for a project that the CRIS otherwise holds in local form. And a RAiD is not automatically a public disclosure of everything about a project — its metadata can be managed with appropriate visibility, which matters for projects that are commercially sensitive or in early stages.

    Why this is infrastructure worth adopting

    The case for RAiD is the same case that justifies the whole persistent-identifier ecosystem: it lets a fact be asserted once, authoritatively, and read everywhere. The project’s membership — who, what funding, which outputs — is exactly the kind of fact that is currently re-derived independently by funders, institutions, and aggregators, each from incomplete evidence, each slightly differently. A standard project identifier with a structured record is the mechanism for asserting it once. As RAiD adoption grows, the research graph gains the connective tissue it has been missing, and the project stops being a ghost inferred from its outputs and becomes a thing the record can actually point at.

    What to do now

    For institutions and CRIS owners: begin minting and referencing RAiDs for projects, using them as the portable identity that links your local project records to the wider graph. For funders: reference RAiDs in award and reporting workflows so that a project’s outputs aggregate against its identifier automatically. For researchers: where your institution supports it, ensure your projects carry RAiDs and that your ORCID iD is linked, so your project work travels with you.

    Related reading