relationType to link Dataset processed/transformed by Software

[KellyStathis]

What is the problem that your suggestion solves?

From an email exchange:

[Has DataCite considered] relationtypes to represent semantic relationships between resourceTypes such as code and data? For instance, code processes data, code transforms data, and vice versa… Or maybe the scope is limited to processes that generate a different resourceType, rather than the process/action itself...

At the moment there doesn’t seem to be much to represent the relationships between the relevant resourceTypes, such as: [ComputationalNotebook, Workflow, or Software] and inputs [e.g. Dataset] or outputs [a Model, or a derived Dataset]. A common example would be a ComputationalNotebook that processes raw sequence data from an machine into the RNA or DNA sequence data that is published in an NCBI database.

What solution might meet your needs?

A new relationType pair, potentially one of:

• Process/IsProcessedBy
• Transforms/IsTransformedBy

Your name

Kelly Stathis

Your organization

DataCite

What alternatives have you tried or considered?

The relationType IsDerivedFrom would link original data and transformed data, but doesn't work to link to the software.

Compiles is closer, but may have a more specific meaning in software (compilation).

The scenario is similar to that between and Instrument and a Dataset, where we have the relationType pair IsCollectedBy/Collects—but this doesn't imply any processing, just collection of (raw?) data.

Is there anything else you would like to share?

Front conversation (link for DataCite staff)

What group(s) would benefit from your suggestion?

• DataCite members registering DOIs and metadata and administering accounts
• Developers building integrations with DataCite services
• Harvesters who index DataCite DOIs and metadata
• Individuals or institutions analyzing DataCite DOIs and metadata
• DataCite staff
• Other

If other group(s), please describe.

No response

[bwestra]

I could use this kind of relationType whenever I add a link to software that was used to process, transform, or analyze the data, and conversely, in Zenodo or our institutional repository, when authors want to link from code to a corresponding dataset. This would seem to be aligned with reproducibility goals too. Is a more granular representation needed to differentiate between data analysis and computational pipelines that process or transform data?

[rebeccaringuette]

Speaking from my role in the NASA Heliophysics science data repositories, I also support this addition as a critically needed option to connect data and software. To echo the relationship in Schema.org that is used to connect data and software (see the last paragraph of this section), I suggest the relation type be called "IsGeneratedBy" / "Generated" with the change in tense (from 'was' to 'is') to match existing relation types in DataCite. This would result in connections between data and software, notebooks, and similar resource types being possible. We are beginning to be blocked by the lack of such a relation type when indicating that a dataset was produced by a certain version of modeling, analysis, or mission software, which is critical for the transparency of our research publications and for a proper impact analysis of the data and software funded by NASA Heliophysics. Here are two simple examples representative of the most common ways we intend to use this.

Example 1: A software is used to generate a dataset without any input data, such as a modeling software or the original production of a dataset.
dataset A isGeneratedBy software B
software B generated dataset A

Example 2: A software is used to generate a dataset with at least one input dataset, such as in the combined analysis of multiple datasets to produce a new dataset. Let's call the input datasets 'dataset inA' and 'dataset inB', the output 'dataset outA', and the software 'software C'. Then, the provenance between the four resources would be represented with:
dataset outA IsGeneratedBy software C
software C Generated dataset outA
dataset outA IsDerivedfrom dataset inA
dataset inA IsSourceOf dataset outA
dataset outA IsDerivedfrom dataset inB
dataset inB IsSourceOf dataset outA
software C Requires dataset inA
dataset inA IsRequiredBy software C
software C Requires dataset inB
dataset inB IsRequiredby software C
The relationships between the software and the input datasets (last four lines above) should be considered optional since the software can likely accept multiple input datasets other that those used to generate dataset outA. However the other relation types used are critical to indicate what resources were used to generate the output dataset, dataset outA, so that others can understand and either potentially attempt to reproduce it or consider additional funding for the indicated software.

@dgarijo What is the conversation in CodeMeta / software for representing these provenance relationships in DataCite?
@clnsmith What is the conversation about this on the dataset side for representing this in DataCite?
@kvrouwenvelder Have you also come across this challenge?
@jibarnum

[mbjones]

@rebeccaringuette 👍 I would love it if the DataCite extensions for these provenance relationships followed the well-established W3C PROV-O vocabulary, as described in the SOSO provenance section that you linked. I wrote that section and am happy to chat with anyone thinking of implementing this. We had many community conversations in SOSO and ESIP around it before it made it into the recommendation. Plus its just nice to not start over when others (e.g., the W3C PROV working group) established such a clear solution 12 years ago (see PROV-O).

[dgarijo]

+1 to use prov for these cases. It is the intended use El sáb., 8 nov. 2025 8:48 a. m., Matt Jones ***@***.***> escribió:

…

@rebeccaringuette <https://github.com/rebeccaringuette> 👍 I would love it if the DataCite extensions for these provenance relationships followed the well-established W3C PROV-O vocabulary, as described in the SOSO provenance section <https://github.com/ESIPFed/science-on-schema.org/blob/main/guides/Dataset.md#provenance-relationships> that you linked. I wrote that section and am happy to chat with anyone thinking of implementing this. We had many community conversations in SOSO and ESIP around it before it made it into the recommendation. Plus its just nice to not start over when others (e.g., the W3C PROV working group) established such a clear solution 12 years ago (see PROV-O <https://www.w3.org/TR/prov-o/>). — Reply to this email directly, view it on GitHub <#198 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AALTIGX34ICKZBOCEKAEB7L33UVWDAVCNFSM6AAAAACH2SEW2OVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTIOJQG44DAOI> . You are receiving this because you were mentioned.Message ID: <datacite/datacite-suggestions/repo-discussions/198/comments/14907809@ github.com>

[rebeccaringuette]

@KellyStathis Is there any way to get these two relation types into the next version (4.7) of DataCite? The drafts for the needed pieces are below:
"IsGeneratedBy"
Definition: indicates that A is generated by B
Example and Usage Notes: The envisioned example is to indicate the registered resource is generated by another resource, such as when an dataset is generated by an instance of software or other computational resource.

<relatedIdentifier relatedIdentifierType="DOI" relationType="IsGeneratedBy" resourceTypeGeneral="Software">10.5281/zenodo.14919949</relatedIdentifier>

"Generated"
Definition: indicates that A generated B
Example and Usage Notes: The envisioned example is to indicate the registered resource generated another resource, such as when an instance of software or other computational resource generates a dataset.

<relatedIdentifier relatedIdentifierType="DOI" relationType="IsGeneratedBy" resourceTypeGeneral="Dataset">10.48322/1fgf-zm82</relatedIdentifier>

[KellyStathis]

Thanks for this proposal, @rebeccaringuette! We're working through this idea and some similar use cases. One question I have for you at this stage: would a more generic option like "HasOutput" and "IsOutputOf" suffice? Or is the specificity of generation needed for your use case?

[rebeccaringuette]

Fine with me, as long as the mapping to schema.org (presumably to prov:wasGeneratedBy and its inverse) holds true for all use cases. If the mapping to schema.org is not acceptable for all the use cases to be supported, then a split is needed.

[mbjones]

I think the key there, then, is to ensure that the definition in DataCite makes it clear that the DataCite properties are complete synonyms of the PROV properties (e.g., datacite:isOutputOf is synonymous with prov:wasGeneratedBy). Which then begs the question of why not use the PROV terms, just to reduce complexity and use the already well-known PROV terms, rather than making up new ones that can introduce confusion? To me it would be more obvious if datacite:wasGeneratedBy is a synonym of prov:wasGeneratedBy. One way to express this formally as a triple is:

• datacite:wasGeneratedBy owl:equivalentProperty prov:wasGeneratedBy.

[KellyStathis]

Thanks @rebeccaringuette and @mbjones! We discussed IsOutputOf further this week, and the consensus is that it's less specific than wasGeneratedBy. Therefore, we need some more time to review the use cases for software relationships and explore how we might incorporate the PROV terms into the DataCite relationType vocabulary. I'll keep you updated as we move forward!

[dgarijo]

Looking at this more closely, the right prov relationship to map to is prov:wasAttributedTo. Was generated by links an output to an activity (like the execution process of a tool), while attribution links the output to the agent (or tool) that in this case generated it. If what you aim to represent is something like "this tool generates this type of dataset" then you may want to have a look at p-plan: http://purl.org/net/p-plan#isOutputVarOf Was generated by is quite broad in scope. El sáb., 15 nov. 2025 3:33 a. m., Kelly Stathis ***@***.***> escribió:

…

Thanks @rebeccaringuette <https://github.com/rebeccaringuette> and @mbjones <https://github.com/mbjones>! We discussed IsOutputOf further this week, and the consensus is that it's less specific than wasGeneratedBy. Therefore, we need some more time to review the use cases for software relationships and explore how we might incorporate the PROV terms into the DataCite relationType vocabulary. I'll keep you updated as we move forward! — Reply to this email directly, view it on GitHub <#198 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AALTIGWFFTEKPNLOZ46SAWD34YN7FAVCNFSM6AAAAACH2SEW2OVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTIOJXGI2DAMQ> . You are receiving this because you were mentioned.Message ID: <datacite/datacite-suggestions/repo-discussions/198/comments/14972402@ github.com>

[rebeccaringuette]

I think the broadness of scope for the 'generatedby' prov terms works in our favor so that it applies to more relationships between items and be more useful to everyone. However, if the 'wasOutputOf' and its inverse are being incorporated into the next version of DataCite as an even more general option, and renaming to the prov term is not on the table, then I suggest that those new terms are sufficient (but not ideal). The mapping to schema.org will likely still be to the prov 'generatedBy' pair of terms and the schema.org 'isBasedOn' and its inverse, but the owl mapping will not be exact. This would still be a win for both software and data. Any other thoughts?
@KellyStathis What is the status of the other term pair?

[KellyStathis]

That makes sense! With "IsGeneratedBy", we'd already be using it differently than in the PROV-O Ontology. This is because we'd be describing datasets to software (entity-entity) links, not dataset to specific software executions (entity-activity) links. Does this still make sense for you?

For IsOutputOf/HasOutput, we're still scoping this. Here are the use cases we are trying to address:

• Connecting awards/grants to their associated outputs, such as papers, datasets, and software—and vice versa.
• Connecting research projects to their associated outputs, such as papers, datasets, and software—and vice versa.
• Connecting events (such as conferences) to their associated outputs, such as presentations and posters—and vice versa.
• Connecting software to its associated output, e.g. when data is produced by a simulation or transformed by software—and vice versa.

However, for events, the Metadata Working Group is thinking that IsPartOf/HasPart would be more suitable (see #138 (comment)).

[rebeccaringuette]

I think it could work. From a metadata mapping perspective for data, it still could map loosely into prov:wasGeneratedBy or the p-plan "isOutputVarOf" / "HasOutputVar" pair Daniel mentioned earlier. Given the more generic way this will be used, that p-plan option may be the better choice. For relations between data and software specifically, we could also pull in the prov:wasGeneratedBy structure without including the execution id field.
Once the output pair of terms is implemented, which it sounds like will happen in the next version anyway, users will not wait to begin using it, including for data generated by software. So, we will have links between data and software using that term pair that will need to be mapped.
@dgarijo @mbjones It seems worth it to be flexible here, make use of the output pairs proposed, and do the best we can with mapping it to schema.org and codemeta. We could meet on the side and work out some drafts on where the pieces would go in the mappings for data and software if you like.
@KellyStathis would it be acceptable to the API developers to have an (if objectA=dataset and if objectB=software) + similar conditions in the software to include a more specific mapping to/from schema.org for cases relevant to data and software?

[KellyStathis]

@rebeccaringuette Great! We'd have to work out the implementation details for the Schema.org mapping, but we could certainly look at applying logic along those lines. Since the interpretation of "IsOutputOf" and "HasOutput" is going to be dependent on the resource types on either end of the relationship, it would make sense to do so.

[rebeccaringuette]

Okay great! Please let us know if you need anything else to make this easier. Thanks, @KellyStathis, and hoping to see this in the next DataCite release.