There will be incentives in the future to allow users to store some objects in the ARC, that can be referenced in the ISA-XLSX components and make their way into the compiled RO-Crate. This might solve issues regarding representation of complex objects, where ontological design is not applicable (e.g. complex, variable nesting).
The highest gain for the community would be the case, in which these objects seamlessly integrate into the RO-Crate, instead of being free-formatted strings.
For this, we would need some rules:
The referenced objects MUST follow the json-ld specification
The objects are referenced in specific places from the ISA-XLSX components, defined in extensions of the ISA-XLSX specification
e.g. A Component REF column could be introduced, which does point to a Component being applied in a process (e.g. Microscope or Tractor)
e.g. A Input/Output [Sample Name] column may point to a json-ld file describing a complex, domain specific sample (e.g. a crop)
The objects MUST be of an RDF type, which fits the range of the property it is referenced by
e.g. Samples referenced by a Sample Name column MUST be of type BioChemEntity
There will be incentives in the future to allow users to store some objects in the ARC, that can be referenced in the ISA-XLSX components and make their way into the compiled RO-Crate. This might solve issues regarding representation of complex objects, where ontological design is not applicable (e.g. complex, variable nesting).
The highest gain for the community would be the case, in which these objects seamlessly integrate into the RO-Crate, instead of being free-formatted strings.
For this, we would need some rules:
json-ld
specificationComponent REF
column could be introduced, which does point to a Component being applied in a process (e.g. Microscope or Tractor)Input/Output [Sample Name]
column may point to ajson-ld
file describing a complex, domain specific sample (e.g. a crop)Sample Name
column MUST be of type BioChemEntity