W3C home > Mailing lists > Public > public-bioschemas@w3.org > June 2018

Re: Bioschemas Taxon profile specification

From: ljgarcia <ljgarcia@ebi.ac.uk>
Date: Thu, 28 Jun 2018 16:42:30 +0100
To: Melanie Courtot <mcourtot@ebi.ac.uk>
Cc: "Gray, Alasdair J G" <A.J.G.Gray@hw.ac.uk>, Justin Clark-Casey <justinccdev@gmail.com>, fmichel@i3s.unice.fr, public-bioschemas@w3.org
Message-ID: <607b6bebdc71540a66e1235c8817c3a6@ebi.ac.uk>

What Melanie suggests is useful to describe profiles, they would become 
a DefinedTerm. That would help as well to avoid type/profile confusion. 
We would talk then about DefinedTerms. If we find a way to also 
described the properties accepted with their restrictions, that would be 
even better. That might be a good subject for a different discussion.

The question remains. How do we choose a term over others to associate 
it to a profile/DefinedTerm?


On 2018-06-28 15:45, Melanie Courtot wrote:
> Hi,
> We could consider using the defined terms,
> https://dataliberate.com/2018/06/18/schema-org-introduces-defined-terms/,
> to do that.
> So have a protein be defined as
>            "@type": "DefinedTerm",
>             "@id": "http://purl.obolibrary.org/obo/PR_000000001",
>             "name": "Protein",
>             "inDefinedTermSet": "http://bioschemas.org/terms",
>             "description": "An amino acid chain that is produced de
> novo by ribosome-mediated translation of a genetically-encoded mRNA.",
>             "sameAs": "http://purl.obolibrary.org/obo/NCIT_C17021",
>             "sameAs": "http://semanticscience.org/resource/SIO_010043"
> (Using random examples of sameAs from
> https://www.ebi.ac.uk/ols/search?q=protein)
> Cheers,
> Melanie
> ---
> Melanie Courtot, PhD
> GA4GH/BioSamples project lead
>> On 28 Jun 2018, at 15:18, ljgarcia <ljgarcia@ebi.ac.uk> wrote:
>> Hi,
>> I understood Franck's question in a different way.
>> Alasdair says
>>> I also agree that a context file should be provided which has the
>>> chosen types and terms in it, i.e. the context file would define
>>> Protein to be the URI http://purl.obolibrary.org/obo/PR_000000001.
>> I think what Franck is asking is how to choose
>> http://purl.obolibrary.org/obo/PR_000000001 over other possible
>> terms to define a Protein. For the taxon case, same as it happens
>> with proteins, there are multiple possibilities. Franck, is this
>> your question? If it is, I do not think there is any agreement on
>> how to choose, other than going for well-known ontologies broadly
>> accepted by the community of interest, even better if the term is
>> mapped to other possible ones.
>> Regards,
>> On 2018-06-28 11:50, Gray, Alasdair J G wrote:
>> On 27 Jun 2018, at 19:19, Justin Clark-Casey <justinccdev@gmail.com>
>> wrote:
>> I think we should have mandatory known @types and properties.  In
>> my view, Bioschemas should be as easy as possible to write and
>> consume.  Multiple options will increase cognitive load on writers
>> (which one do I choose?  Why are these 2 examples using these
>> different terms?) and open the door to greater inconsistency.
>> Non-mandatory types will also raise the barriers for writing
>> Bioschemas software that will have to be aware of equivalent
>> mappings.
>> I completely agree that we should have a single approved type for
>> each profile, and likewise for each property a single chosen term.
>> This is the whole point of having the profiles.
>> I would go one step further and say that Bioschemas should provide
>> an http://bioschemas.org [1] [1]context that will define types such
>> as
>> Taxon, rather than blessing particular ontology terms.
>> I also agree that a context file should be provided which has the
>> chosen types and terms in it, i.e. the context file would define
>> Protein to be the URI http://purl.obolibrary.org/obo/PR_000000001.
>> To
>> be completely explicit, we would not be defining a type in the
>> bioschemas namespace, e.g. http://bioschemas.org/Protein.
>> This context can also document equivalent terms in different
>> ontologies.
>> I like the idea that this also contains mappings to the equivalent
>> terms in other ontologies.
>> Alasdair
>> Alasdair J G Gray
>> Fellow of the Higher Education Academy
>> Assistant Professor in Computer Science,
>> School of Mathematical and Computer Sciences
>> (Athena SWAN Bronze Award)
>> Heriot-Watt University, Edinburgh UK.
>> Email: A.J.G.Gray@hw.ac.uk
>> Web: http://www.macs.hw.ac.uk/~ajg33
>> ORCID: http://orcid.org/0000-0002-5711-4872
>> Office: Earl Mountbatten Building 1.39
>> Twitter: @gray_alasdair
>> Untitled Document
>> -------------------------
>> Founded in 1821, Heriot-Watt is a leader in ideas and solutions.
>> With
>> campuses and students across the entire globe we span the world,
>> delivering innovation and educational excellence in business,
>> engineering, design and the physical, social and life sciences.
>> This email is generated from the Heriot-Watt University Group, which
>> includes:
>> * Heriot-Watt University, a Scottish charity registered under
>> number
>> SC000278
>> * Edinburgh Business School a Charity Registered in Scotland,
>> SC026900. Edinburgh Business School is a company limited by
>> guarantee,
>> registered in Scotland with registered number SC173556 and
>> registered
>> office at Heriot-Watt University Finance Office, Riccarton, Currie,
>> Midlothian, EH14 4AS
>> * Heriot- Watt Services Limited (Oriam), Scotland's national
>> performance centre for sport. Heriot-Watt Services Limited is a
>> private limited company registered is Scotland with registered
>> number
>> SC271030 and registered office at Research & Enterprise Services
>> Heriot-Watt University, Riccarton, Edinburgh, EH14 4AS.
>> The contents (including any attachments) are confidential. If you
>> are
>> not the intended recipient of this e-mail, any disclosure, copying,
>> distribution or use of its contents is strictly prohibited, and you
>> should please notify the sender immediately and then delete it
>> (including any attachments) from your system.
>> Links:
>> ------
>> [1] http://bioschemas.org/
> Links:
> ------
> [1] http://bioschemas.org/
Received on Thursday, 28 June 2018 15:43:06 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:08:05 UTC