(image created by https://beta.dreamstudio.ai/dream).
Knowledge Futures Group, eLife, Cold spring harbour press, and EMBO are collaborating on the development of https://docmaps.knowledgefutures.org.
In one place they talk about it as being
a community-endorsed framework for representing research object-level review/editorial processes in a machine-readable, interoperable, and extensible format.
And in another they talk about it as being
a framework for describing the processes used to create a document in a machine-readable way. The framework is designed to be interpreted in multiple formats depending on the use-case of the consumer of the DocMap
I think the most comprehensible description is the following
At its core, the DocMaps framework is a set of agreed-upon conventions for aligning editorial processes against the Publishing Status Ontology (PSO), Publishing Workflow Ontology (PWO) and for expressing these events in a domain-specific language that can be easily interpreted by machines and humans alike
So if you have multiple parties that are creating document in the scholarly space -- preprint services, publishers, funders, then they could use this as a way to share the history of how a document was created, and what kinds of editorial or review steps were taken in the creation of that document.
Where this might be useful - if there are a network of collaborating services that have a high level of interchange between them, then this could reduce the friction in moving a document through a process involving these multiple systems. E.g. a publisher taking up a paper from a preprint service, and brining it through peer review.
In contrast to decorating DOIs for the document with this extra metadata, these DocMaps would stand as a kind of sidecar file with information about the process, rather than information about the document.
Where this could face difficulty - I think you need to have that close group of collaborating entities to make this work well, and if you have document creation happening outside of that network the cost of adoption of the system is going to be a barrier to participation.
I wonder how this relates to MECA - https://www.niso.org/standards-committees/meca, and whether the MECA standard is flexible enough to accommodate the representation in Docmaps.
If you are creating new systems or integrations, and you have developers who are working on your system, then Docmaps seems like a reasonable way to interface with other systems, but if you have existing systems then I don't see how you can get to an adoption of this without there being a significant proof of value.