Add Profile Crates for 0.5-DRAFT

[stain]

One Profile Crate for each of process/workflow/provenance, assuming Profile Crate updates in ResearchObject/ro-crate#296 and ResearchObject/ro-crate#262

To view what this PR looks like, see https://stain.github.io/workflow-run-crate/profiles/0.5-DRAFT/ :

• Process Run Profile Crate
• Workflow Run Profile Crate
• Provenance Run Profile Crate

This is in a way also a test of the Profile Crate mechanism.

Note the need to rename workflow_run_crate.md to workflow_run_crate/index.md etc to add the neighbouring crate files.

If we settle for this style I can do similar crates for the older versions and set up the w3id content negotiation so that the permalinks can give both JSON-LD and HTML.

I extracted out the JSON-LD example to actual crates, so it can be linked to from the Profile Crate.

Link to the common JSON-LD context using the @id at w3id -- this requires context negotiation as permitted by https://www.researchobject.org/ro-crate/1.2-DRAFT/profiles.html#json-ld-context but I also added url to the direct json -- should this not have jsonld filename to get the correct Content-Type?

To discuss:

• Where do we define the ro-terms (see #69 -- could split this in two/four) -- for now I defined the full DefinedTermSet including domain/range of each term, all in the Process Crate profile, even though some of these terms are only used later. @dgarijo may have views..
• Should the DefinedTermSet be included and/or fully listed in each of the profiles? Remember from recent https://github.com/ResearchObject/ro-crate/pull/262 there is no longer inheritance across profile crates (and also we have SHOULD on conformsTo requirements) -- however conformsTo do pull in the term definitions as long as implementations always declare conformsTo Process Crate.
• Where do we define the Workflow Run RO-Crate community? I've now copied all the ORCIDs into each profile. Perhaps we need a DataCatalog crate we can keep in the root as https://www.researchobject.org/workflow-run-crate/ro-crata-metadata.json ? (This can also list all the profile versions etc). See also https://github.com/ResearchObject/ro-crate/issues/283
• Here the machine readable listing of the profile is a bit limited as there is no schemas/shapes or similar. For the WRROC paper do we also need to link to or copy out the RDF shapes as i https://github.com/ResearchObject/runcrate/tree/shex/src/runcrate/shex ? Note that these are flaky but we could test them on our examples.
• Should the Profile Crates list software in addition to runcrate -- e.g. corresponding to WRROC table of implemenations ? It would necessarily always be out of date as profiles are newer than implementations
• Should the Profile Crates also list real examples from Zenodo? These would again also be out of date. (Note that the current in-line example said 0.1 conformance, so this may not be big issue)

[stain]

I added links to prov mapping to each, but it lives outside in the ro-crate for the paper, referenced from this crate

[stain]

Merging the profile crates as I think we agreed this approach on 2024-05-21

[simleo]

@stain now we have the docs/ontology/wfrun.* files, the DefinedTermSet in the Process Run Crate profile crate and the csv and jsonld files in the ro-terms repository (unless I'm missing something). I'm wondering, how does one add a new term now, especially someone that does not speak all those languages? Before this you had to add a line to the csv in ro-terms and run the Python script to update the jsonld, but what is going to be the procedure now?

[dgarijo]

Thanks Stian. Having a defined set with domains and ranges makes sense to me. As long as we produce a machine readable specification it should be ok. It may confuse people that the specification itself is a RO-Crate, since we could just return JSON-LD with the terms.

[dgarijo]

@stain I enabled content negotiation on the profiles for the crates (in the draft version only for now). The terms we should probably define in https://github.com/ResearchObject/ro-terms/tree/master/workflow-run, because that's the repo on terminology, no?

[stain]

I think if the terms are defined now properly in the roterms namespace (incl. HTML!) we no longer need to define them individually in the profile crates, just refer to the DefinedTermSet alone. Will raise as new issue for 0.6, that's just housekeeping, no harm in the current way except duplication.