You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Request for Feedback for the BioSample 0.2-Draft Type #723
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)
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.
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 conditionsOfAccess property
Hi all, we just mentioned this in the monthly call. I've just minor notes:
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).
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.
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 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.
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.
Hi @marco-brandizi--Looking at BioSchemas/bioschemas.github.io#924, I think the next community call might be a good opportunity to discuss the recommendations surrounding the additionalType property. I can definitely see the need for using either this property or dc:type especially for things that are multiple types. For example, BioSamples that are made-to-order reagents and can be purchased as Products.
Activity
[-]Request for Feedback for the BioSample 0.2-Draft[/-][+]Request for Feedback for the BioSample 0.2-Draft Type[/+]EvaCaamano commentedon Jun 5, 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:
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?
gtsueng commentedon Jul 28, 2026
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.
conditionsOfAccesspropertymarco-brandizi commentedon Aug 17, 2026
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
gtsueng commentedon Aug 19, 2026
Hi @marco-brandizi
Thank you for taking the time to provide your feedback. Nick, Sara, and I discussed your comments and drew the following conclusions.
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.
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.
Thank you for catching that error. It should have inherited from Sample and BioChemEntity. We will work on fixing that on the page.
marco-brandizi commentedon Aug 24, 2026
Hi @gtsueng,
Sorry for my late reply, I took a few days off.
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.gtsueng commentedon Aug 24, 2026
Hi @marco-brandizi --
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.
marco-brandizi commentedon Aug 24, 2026
I agree with that, I hope to discuss it in a future call.
gtsueng commentedon Nov 2, 2026
Hi @marco-brandizi--Looking at BioSchemas/bioschemas.github.io#924, I think the next community call might be a good opportunity to discuss the recommendations surrounding the
additionalTypeproperty. I can definitely see the need for using either this property or dc:type especially for things that are multiple types. For example, BioSamples that are made-to-order reagents and can be purchased as Products.