Repository navigation
Request for Feedback for the BioSample 0.2-Draft Type #723
Description
Activity
- changed the title
[-]Request for Feedback for the BioSample 0.2-Draft[/-][+]Request for Feedback for the BioSample 0.2-Draft Type[/+]on May 27, 2026 I am new to all this but a few things to consider for the bioschema that I did not see at a glance:
For full reanalysis many datatypes would need further technical information:
- experiment unit
- batch within experiment unit
- information if sample was acquired on a plate and position in the plate
- the collector field may need to be replicated to include various levels of complexity: (collector, processor/extractor/sample preparator, etc) - is there any flexibilty to add these potential sources of variation?
- the isControl should have further ramifications to indicate the type of control (postiive, negative, pooled, etc)
- is there a way of logging the weight/volume of the sample - it may be important for normalisation
- Other biologically relevant information is not quite there - how does one log mutants, co-morbidities, or other relevant variables -- is there a minimum subset
There were elements that were not clear to me. I understand (hopefully correctly) that this information is at the sample level. If I think omics, there will be many chemical entities in a sample. Thus, I was confused to see the properties hasBioChemEntityPart, hasMolecularFunction, etc.
additional comment - licence/access?
Dear @EvaCaamano,
Thank you for the valuable feedback, and your interest in these types. Broadly, Bioschemas ‘types and profiles’ target the identification and representation of the key properties to aid in discoverability of suitable records, allowing users to more practically use our profiles; largely our profiles have a very limited and community-tailored set of key properties (in comparison to schema.org) to allow users to identify appropriate resources. Hence, it is not possible in the Bioschemas context to provide all possible properties.
- The batch, experimental unit, plate position, run information, etc. can be added using the ‘additionalProperty’ inherited from ‘Sample’.
- After surveying multiple different repositories, we included the most commonly seen roles. If additional roles were involved the ‘contributor’ property can be flexibly used to accommodate them.
- Very good point about the ‘isControl’ property. The current expected type is Boolean which would only indicate if it is a control or not. We can add an expected type of schema.org/Enumeration to allow for additional flexibility.
- The weight/volume of the sample can be added using the sampleQuantity which expects a schema.org/QuantitativeValue.
- Mutants, comorbidities, etc could be recorded using the properties ‘associatedPhenotype’ or ‘associatedDisease’ (inherited from BioChemEntity). Other relevant variables could be captured using ‘additionalProperty’ inherited from Sample
- Good point about license, but ‘access’ would be conveyed with the
conditionsOfAccessproperty
Hi all, we just mentioned this in the monthly call. I've just minor notes:
-
Looking at the draft for the
BioSampleandSampletypes, do I get correct that there is distinction between a aample and a biosample, where the latter is biomaterial, while the former is more generic (eg, a cohort, a set of questionnaires). If that's the case, I think it's a useful distinction, which should be clarified in the definitions. Moreover, the general type, the sample, might not necessarily be material (questionnaires are creative works). -
Moreover, it's strange that schema.org hasn't a type for something that it's even more general, eg, a sample of pieces in an industrial production, a product sample, a statistical sample. But maybe these are quite different cases where sample is part of their name
-
In the page for the BioSample type draft, there seem to be a glitch in the 'Schema.org hierarchy' section: [Thing] > Sample > BioSample > BioSample
-
Thank you for taking the time to provide your feedback. Nick, Sara, and I discussed your comments and drew the following conclusions.
Looking at the draft for the BioSample and Sample types, do I get correct that there is distinction between a aample and a biosample, where the latter is biomaterial, while the former is more generic (eg, a cohort, a set of questionnaires). If that's the case, I think it's a useful distinction, which should be clarified in the definitions. Moreover, the general type, the sample, might not necessarily be material (questionnaires are creative works).
Yes - These are two distinct types of Things. Based on the definition of Sample, these are physical / tangible samples, so the cohort or questionnaire you mentioned would NOT be included as a Sample type, and would be better off modeled as some sort of Intangible or CreativeWork.
Moreover, it's strange that schema.org hasn't a type for something that it's even more general, eg, a sample of pieces in an industrial production, a product sample, a statistical sample. But maybe these are quite different cases where sample is part of their name
For statistical samples, there are classes nested under schema.org/Intangible which are a better fit. Agree that it is strange that schema.org doesn’t have this; however, from an internet search perspective, it makes sense. Product samples are more likely to be shared business-to-business and made available upon request, rather than be made searchable to the general populace; hence, the general lack of need (from a search perspective). In the research space--where Samples/BioSamples can be stored, shared, processed, and used--the need for this type exists.
In the page for the BioSample type draft, there seem to be a glitch in the 'Schema.org hierarchy' section: [Thing] > Sample > BioSample > BioSample
Thank you for catching that error. It should have inherited from Sample and BioChemEntity. We will work on fixing that on the page.
Hi @gtsueng,
Sorry for my late reply, I took a few days off.
Based on the definition of Sample, these are physical / tangible samples, so the cohort or questionnaire you mentioned would NOT be included as a Sample type, and would be better off modeled as some sort of Intangible or CreativeWork.
I understand. There are records about "sample, somehow" that one wants to qualify as related to (bio)samples, not just
CreativeWork. I deal with cases like this by addingdc:type(see the discussion in #538). We could go on like this; maybe it's worth mentioning it in the profile or type pages.Hi @marco-brandizi --
I understand. There are records about "sample, somehow" that one wants to qualify as related to (bio)samples, not just CreativeWork. I deal with cases like this by adding dc:type (see the discussion in #538). We could go on like this; maybe it's worth mentioning it in the profile or type pages.
Your approach makes sense to me. IMO, rather than having each profile contain a note with potentially different recommendations on handling additional properties, it would be better to have this discussion at the community call level and having a general recommendation that can be applied broadly to similar cases across the different profiles. I would also love to hear how other groups are handling these issues and see if we can't coalesce around a common recommended approach. Then have these guidelines formalized as separate additional recommendations on the bioschemas website.
Reacted by Marco BrandiziI agree with that, I hope to discuss it in a future call.
Dear Bioschemas community,
We are pleased to announce that the draft type for Biosample are now available on the Bioschemas website.
In line with our governance, both drafts are open to community review for a period of 2 weeks (close of business (GMT) - 15th June 2026). Comments and feedback on properties should be provided through the relevant form here: Biosample.
Additionally, you may comment through this issue.
Please refrain from other means of feedback (e.g. email or direct messages) which may cause a delay in processing, and are more difficult to track.
We will endeavour to incorporate all relevant feedback prior to full release, but note that some feedback (e.g. descriptions of properties) may be more appropriate to accommodate in the profile creation stage.
Furthermore, in anticipation of a full release, we are also soliciting feedback on key properties for developing a profile against each draft type.
We will summarise our actions in a follow-up correspondence. For further information on this and other matters, please feel free to attend our regular Community Call.
Finally, We would like to thank the Bioschemas Samples Group for bringing this work together, ELIXIR and ELIXIR-DE for hosting hackathon projects, BGE and BioDT for targeted contributions, and most importantly the broader community for all their input.
sincerely,
Nick, Ginger, and Sara (Bioschemas Sample Working Group)