Use Case: Indicate profile of RO-Crate

[stain]

As a specializer of RO-Crate, I want to indicate a particular RO-Crate profile so that consumers can make programmatic assumptions.

For instance, an RO-Crate might follow the profile https://about.workflowhub.eu/Workflow-RO-Crate/ but at the moment this can only be inferred by the right elements being present. Ideally one could also be explicit about which profile the crate intends to follow.

Given such a statement a programmatic consumer of RO-Crates can assume certain duck typing as recommended by the profile - for instance that all Persons should have an affiliation to an Organization with a url property.

Formally such profiles might even include RDF shapes or similar to do such validation, but as a base case, as discussed in @marc-portier's RO-Crate Profiles and community call 2021-05-13 we want to just indicate the profile by URI.

[marc-portier]

1/
Like the new idea where the formal-profile-description ends up being a crate itself - might be useful to hint towards an example showing that off ? --> i.e. showing the proper encoding-format, hinting further towards a possible organization of additional stuff going into the profile?

2/
Reminding that we did also raise the topic of multiple json-ld contexts --> in issue #150 as a side effect of the profile discussion, I think it would be useful to have the resulting two additions to the spec refer to each other (when they land) ?

3/
Finally: some expressed use cases for having profiles in the first place (content structuring, validation, ...) have not been addressed yet - is the idea to:
a/ address those in separate issues, and have this issue strictly focused on the basics (purl, conforms-to, ...)
b/ go as far as even introducing a 'ro-crate-profile-profile' leaving some template and additional semantics that structures, orders and covers all those (optional) elements
c/ not cover these aspects as part of the spec, but providing it as examples of profile-use?
d/ entirely leave it as an exercise to the reader, just provide a managed link-base of existing profiles?

(not trying to look too far into the future here: things always change at some point, no way we can predict any of that -- I'm more questioning what our current ambitions are / should be)

[stain]

#154 was merged - see https://www.researchobject.org/ro-crate/1.2-DRAFT/profiles.html

A few outstanding issues:

• A figure showing how a crate conforms to a PID that goes to a Profile Crate that gathers other stuff.
• Some hyperlinks are broken from Markdown, e.g. [Semantic Versioning][semver] (I think fixed by f8b1f35)
• Review the text for language/consistency/understandability
• Add how it can use workExample as in https://about.workflowhub.eu/Workflow-RO-Crate/ro-crate-preview.html#example/ to link to an example of an conforming RO-Crate

[ptsefton]

Re the draft: https://github.com/ResearchObject/ro-crate/blob/10439ad3abd8a70a6f25609bca3e8de6d98c4ebd/docs/1.2-DRAFT/profiles.md#declaring-conformance-of-an-ro-crate-profile

At the University of Queensland we are developing a profile for language resources and it would be best to describe an entire data model in one document with # URIs pointing to different levels of a heirarchy.

The proposed data model is:

• Language Corpus (based on pcdm:Collection AKA RepositoryCollection)
  • Collection (based on pcdm:Collection) - OPTIONAL & Recursive
    • Language Item (pcdm:Object AKA RepositoryObject)
      • File(s) (can be Member of Corpus or Collection
        • Optional Raw text: Plain-text (UTF-8)
        • Optional Original
        • Audio / video etc (TODO)
        • Documents (TEI XML, PDF, whatever)
        • Transcriptions / annotations using software such as ELAN

It would be good to be able to put a conforms to property on ANY ELEMENT so that we can ship an entire corpus (dataset) as one crate or break it into smaller ones that might contain a collection or an item. (Ie not jsut on the descriptor as per the draft).

[jmfernandez]

Maybe a bit offtopic, as audio and video files can use combinations of audio/video containers and codecs, the annotation of them could go to the practical side, and point out to an open implementation (i.e. a known program or software library) and version which is able to reproduce the file

[ptsefton]

As discussed at the latest call - we should move the conformsTo to the root Dataset - this will make it (a) easier for developers to code with and (b) make it possible to nest RO-Crates.

[stain]

We reiterated in RO-Crate Call 2022-01-27 that we will move conformsTo to the root Dataset to indicate profiles.

See also #182

[stain]

Investigate if https://www.w3.org/TR/dx-prof/ can be appropriate to support profile nesting.

Also a profile resource can be wrapped as an prof:ResourceDescriptor wrapper to indicate a profile role including constraints, example, guidance, mapping, schema, validation vocabulary.

Alternatively use only the roles through hasPart using schema.org role similar to this way of expanding on contributor roles

[stain]

Agreed in 2022-09-08 to leave conformsTo of RO-Crate itself on metadata file descriptor, all other profiles on the Dataset (and possibly other entities).

[ptsefton]

@stain is this work done?