W3C home > Mailing lists > Public > public-bioschemas@w3.org > November 2017

Re: Protein representation with a Bioschemas context ()

From: Melanie Courtot <mcourtot@ebi.ac.uk>
Date: Fri, 10 Nov 2017 17:39:52 +0000
To: public-bioschemas@w3.org
Message-ID: <042a3b28-e873-af87-082c-5643e11c2eee@ebi.ac.uk>
Is data integration really a use case for Bioschemas?  The stated goal 
of Bioschemas is to extend schema.org to provide markup for pages, and 
IIRC the use cases discussed at the last meeting were about discovery 
and retrieval.

Cheers,
Melanie


On 10/11/2017 16:30, Justin Clark-Casey wrote:
>
>
> On 10/11/17 14:21, ljgarcia wrote:
>> Hi,
>>
>>>> I thought we did not want to impose any IRI. Is there any reason why
>>>> we should?
>>>
>>> But then we sacrifice the interoperability and understanding that we
>>> are striving for. If you look at the n-quads for the two examples
>>> (included at the end of this email) then you will see a different set
>>> of triples.
>>
>> If there are mappings between the terms, that interoperability we 
>> want to achieve could still be achieved, could not it? With mappings, 
>> we still can transform any n-quads to the, let's say, canonical 
>> Bioschemas defined form. Would this not be a way? If a mapping cannot 
>> be found, then validation fails. Bioschemas should then use mapping 
>> tools and clearly state what the use mappings tool is.
>
> If consuming applications have to use term mappings then this will 
> make them much harder to write, and in some cases might make it 
> impossible to integrate some information.  This might only be a 
> problem for code that is trying to integrate data across websites, but 
> this is an important use case.
>
> At least for mandatory properties and types, and major profiles (gene, 
> protein, etc.), I would like to see pre-agreed IRIs, rather than free 
> choice or emerging consensus.  In some ways, I don't think this is so 
> different from what we are doing with DataCatalog, Sample, 
> TrainingMaterial, etc.
>
>>
>> Regards,
>>
>> On 2017-11-10 14:07, Gray, Alasdair J G wrote:
>>>> On 10 Nov 2017, at 13:28, Leyla Garcia <ljgarcia@ebi.ac.uk> wrote:
>>>> I was under the same impression than Melanie. We agree on aliases
>>>> but providers can decide what is their preferred IRI for any of
>>>> them. A Bioschemas Protein context would just provide a default
>>>> context that can also be used as a template where IRIs (but not
>>>> aliases) can be modified. And of course, anyone could add more
>>>> aliases, Bioschemas will just not parse those outside the
>>>> default/template provided context.
>>>>
>>>> I thought we did not want to impose any IRI. Is there any reason why
>>>> we should?
>>>
>>> But then we sacrifice the interoperability and understanding that we
>>> are striving for. If you look at the n-quads for the two examples
>>> (included at the end of this email) then you will see a different set
>>> of triples. Aliases are only defined within the document. When you
>>> interpret them they give you different meanings. If we go down this
>>> route, we would need to make our tooling with knowledge of either all
>>> possible terms that will be used or mapping aware.
>>>
>>> Alasdair
>>>
>>> http://tinyurl.com/y9mu423y
>>>
>>> <http://identifiers.org/ncbigene/25> <http://schema.org/name> "ABL1" .
>>>
>>> <http://identifiers.org/ncbigene/25>
>>> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type>
>>> <http://purl.obolibrary.org/obo/SO_0000704> .
>>> <http://identifiers.org/ncbigene/25>
>>> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type>
>>> <http://schema.org/BioChemEntity> .
>>> <http://identifiers.org/uniprot/P00519>
>>> <http://schema.org/alternateName> "ABL" .
>>> <http://identifiers.org/uniprot/P00519>
>>> <http://schema.org/alternateName> "JTK7" .
>>> <http://identifiers.org/uniprot/P00519>
>>> <http://schema.org/description> "Non-receptor tyrosine-protein kinase
>>> that plays a role..." .
>>> <http://identifiers.org/uniprot/P00519> <http://schema.org/name>
>>> "ABL1" .
>>> <http://identifiers.org/uniprot/P00519>
>>> <http://semanticscience.org/resource/SIO_000001>
>>> <http://pfam.xfam.org/clan/CL0001> .
>>> <http://identifiers.org/uniprot/P00519>
>>> <http://semanticscience.org/resource/SIO_010081>
>>> <http://identifiers.org/ncbigene/25> .
>>> <http://identifiers.org/uniprot/P00519>
>>> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type>
>>> <http://purl.obolibrary.org/obo/PR_000000001> .
>>> <http://identifiers.org/uniprot/P00519>
>>> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type>
>>> <http://schema.org/BioChemEntity> .
>>>
>>> http://tinyurl.com/yd5snze2
>>>
>>> <http://identifiers.org/ncbigene/25> <http://schema.org/name> "ABL1" .
>>>
>>> <http://identifiers.org/ncbigene/25>
>>> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type>
>>> <http://purl.obolibrary.org/obo/OGI_0000004> .
>>> <http://identifiers.org/ncbigene/25>
>>> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type>
>>> <http://schema.org/BioChemEntity> .
>>> <http://identifiers.org/uniprot/P00519>
>>> <http://purl.obolibrary.org/obo/RO_0002510>
>>> <http://identifiers.org/ncbigene/25> .
>>> <http://identifiers.org/uniprot/P00519>
>>> <http://schema.org/alternateName> "ABL" .
>>> <http://identifiers.org/uniprot/P00519>
>>> <http://schema.org/alternateName> "JTK7" .
>>> <http://identifiers.org/uniprot/P00519>
>>> <http://schema.org/description> "Non-receptor tyrosine-protein kinase
>>> that plays a role..." .
>>> <http://identifiers.org/uniprot/P00519> <http://schema.org/name>
>>> "ABL1" .
>>> <http://identifiers.org/uniprot/P00519>
>>> <http://semanticscience.org/resource/SIO_000001>
>>> <http://pfam.xfam.org/clan/CL0001> .
>>> <http://identifiers.org/uniprot/P00519>
>>> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type>
>>> <http://purl.obolibrary.org/obo/NCIT_C17021> .
>>> <http://identifiers.org/uniprot/P00519>
>>> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type>
>>> <http://schema.org/BioChemEntity> .
>>>
>>> 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 .fsize { font-family: Arial, Helvetica Neue,
>>> Helvetica, sans-serif; font-size: 10px; }
>>>
>>> -------------------------
>>>
>>> _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:
>>>
>>>      * 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.
>>
>
Received on Friday, 10 November 2017 17:40:20 UTC

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