Re: Protein representation with and without BioChemEntity

Hello all,

@Alasdair, you managed to have a conversation with Dan that I was hoping 
to have during our October Bioschemas meeting. Using third party terms 
seems a cleaner and easier approach to me.

@Melanie, using RO or SIO or any other is not necessarily a step 
further. All of them are well know and valid ontologies. You would like 
to use RO, UniProt would probably like to use the Protein Ontology 
(PRO), Wikidata would probably like to use Wikidata ontology and so on, 
some other groups would like to use SIO, we also have the Sequence 
Ontology (SO) and so on. Furthermore, there are mappings between them so 
using one or the other could be equally acceptable. For instace 
SIO:010035 (gene) is mapped to SO:0000704 (gene).

@Alasdair, @Dan. Would not be even cleaner adding a second context to 
the mark up where we define aliases for the third party terms and types? 
If we do so, then, as far as the same aliases are used, maybe what third 
party ontology is used becomes not that relevant anymore? Then people 
could use either one. And, just in case, Bioschemas would collate 
somewhere what ontologies are in used for each profile and corresponding 
properties. Aliases of course would be defined by the profile itself, at 
least those minimum and recommended ones which will be used for 
validation. It is always possible to add more properties but then would 
not be parsed for Bioschemas (or schema.org I suppose).

If you think adding a second context makes things easier, I could work 
on some examples. They would look similar to 
https://github.com/BioSchemas/specifications/blob/master/PhysicalEntity/examples/BioChemEntityAlt-min+rec.jsonld 
but with aliases defined in the second context for 
"http://semanticscience.org/resource/is-transcribed-from" and so on.

Regards,


On 02/11/2017 12:04, Gray, Alasdair J G wrote:
> Hi Melanie,
>
> I think we are talking at cross purposes. The three examples show 
> different ways of representing a protein.
>
> My original motivation was to compare the BioChemEntity wrapper 
> approach using additionProperty with an approach that would involve 
> the Bioschemas community proposing multiple new types to schema.org 
> <http://schema.org>*. When I discussed these two examples with Dan, he 
> pointed out that we don’t need to use additionalProperty, we can just 
> use the ontology terms directly. In the first and third example, i was 
> just using the ontology terms that were proposed by the Protein Group 
> in the Protein Profile. In the second example, I was playing with the 
> idea that we create these properties in schema.org <http://schema.org>.
>
> The markup in the first example, BioChemEntity with 
> additionalProperty, is complex and increases the complexity of the 
> tools needed for creating and consuming that markup. The third set of 
> examples, using the ontology terms directly, gives us a simplified 
> markup and therefore simplifies our tooling. It will also make 
> adoption more straightforward. It would be up to the profiles to 
> decide which are the appropriate ontology terms to use.
>
> I hope this clears things up
>
> Alasdair
>
> *This approach was ruled out in the May meeting, but I felt that it 
> was important to do a comparison of the two approaches with a concrete 
> example
>
>> On 2 Nov 2017, at 10:34, Melanie Courtot <mcourtot@ebi.ac.uk 
>> <mailto:mcourtot@ebi.ac.uk>> wrote:
>>
>> Hi Alastair,
>>
>> I'm not sure I understand, are you talking about validating profiles? 
>> For validation purpose wouldn't it be equivalent to look for a string 
>> such as "isContainedIn" or a URI such as 
>> http://purl.obolibrary.org/obo/RO_0001018, where the latter has the 
>> advantage to not duplicate existing terms as well as offering 
>> dereferencing, hierarchy and flexibility?
>>
>> I'll admit being a bit confused between the 3 examples, so I may be 
>> overlooking something.
>>
>> Cheers,
>> Melanie
>
> 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 <mailto:A.J.G.Gray@hw.ac.uk>
> Web: http://www.macs.hw.ac.uk/~ajg33 <http://www.macs.hw.ac.uk/%7Eajg33>
> ORCID: http://orcid.org/0000-0002-5711-4872
> Office: Earl Mountbatten Building 1.39
> Twitter: @gray_alasdair
>
> Untitled Document
> ------------------------------------------------------------------------
>
> */Heriot-Watt University is The Times & The Sunday Times International 
> University of the Year 2018/*
>
> 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:
>
>  1. Heriot-Watt University, a Scottish charity registered under number
>     SC000278
>  2. 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
>  3. 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.
>

Received on Friday, 3 November 2017 10:14:53 UTC