Re: Protein representation with a Bioschemas context ()

Hi,

Nice to get that many comments!

So, it looks like we are talking about something like 
https://github.com/BioSchemas/specifications/blob/master/Protein/examples/ProteinEntity-with-context.json 
where the context containing Gene and so will become the Bioschemas 
context and the IRIs will be agreed and then fixed. That example 
includes a third-party property which is always possible whenever 
schema.org or Bioschemas do not provide a better option.

Regards


On 14/11/2017 12:41, Justin Clark-Casey wrote:
> I agree.  As Alasdair and Franck say, I feel that a major benefit of 
> schema.org is in providing agreed upon minimal terms that aid 
> findability.
>
> Pragmatically, data sources would always be free to use their own 
> terms and additionalTypes (I don't think that bioschemas can or should 
> forbid this), but they should be aware that there are agreed upon 
> terms that will make their data findable/usable by a distributed 
> community, rather than only by a few applications that are especially 
> aware of their markup.
>
> I also agree with Stephen that relying on a central collator is too 
> much overhead.  To me, this introduces a single point of failure that 
> conflicts with the spirit of the web.
>
> -- Justin Clark-Casey
>
> On 14/11/17 12:02, Gray, Alasdair J G wrote:
>> Dear All,
>>
>> I think Franck’s email clearly explains the situation here.
>>
>> Schema.org <http://schema.org> is about everyone buying in to use a 
>> common set of terms to markup their content. If they buy-in to that 
>> then they get the benefit. Otherwise you are just on the linked data 
>> web.
>>
>> Bioschemas is about making Schema.org <http://schema.org> relevant 
>> for the life sciences. We have agreed as a community that we prefer 
>> to reuse an existing ontology term than mint our own. However, to me, 
>> it means that we do need to select a single ontology term. It is 
>> through this agreement that we will see benefit whilst also keeping 
>> the route to adoption straightforward.
>>
>> Alasdair
>>
>>> On 14 Nov 2017, at 10:21, Franck Michel <franck.michel@cnrs.fr 
>>> <mailto:franck.michel@cnrs.fr>> wrote:
>>>
>>> Dear all,
>>>
>>> I'd like to bring a few elements into the discussion wrt. aliases.
>>>
>>> In JSON-LD, aliases are just a handy short-cut notation with a local 
>>> scope: an alias just applies within the scope of the context where 
>>> it is defined. And more importantly, an alias should not bear any 
>>> meaning. The first thing a consumer app does with JSON-LD is to 
>>> expand all terms, which immediately removes all aliases.
>>>
>>> Hence, if I use theBioschemas.org <http://bioschemas.org/>default 
>>> context:
>>> @context {  "Gene": { 
>>> "@id":"http://purl.obolibrary.org/obo/SO_0000704"} ... }
>>> I will typically write:  "@type": [ "BioChemEntity", "Gene" ]
>>>
>>> But I may well write a document with a custom alias:
>>> @context {  "GeneAlias": { 
>>> "@id":"http://purl.obolibrary.org/obo/SO_0000704"} ... }
>>> and write:   "@type": [ "BioChemEntity", "GeneAlias" ]
>>> With:
>>> @context {  "obo": {  "@id":"http://purl.obolibrary.org/obo/"} ... }
>>> I would write:   "@type": [ "BioChemEntity", "obo:SO_0000704" ]
>>> Or I could even not use any alias:   "@type": [ 
>>> "BioChemEntity","http://purl.obolibrary.org/obo/SO_0000704"]
>>>
>>> These are all equivalent from the point of view of a data consumer.
>>>
>>> In my view, the default context should be a useful guide for those 
>>> annotating data withBioschemas.org <http://bioschemas.org/>markup, 
>>> but alias names should not matter at all. What matters is the URIs 
>>> to which aliases resolve.
>>>
>>> I feel like the solution of agreed pre-defined URIs, whatever the 
>>> aliases used, is more sustainable. After all,schema.org 
>>> <http://schema.org/>advocates for the use of specific agreed-upton 
>>> terms. If one uses them, their pages are more likely to be 
>>> discoverable. They can chose to use other terms if this is 
>>> convenient for them, but then there is not guarantee that the pages 
>>> will be discovered as easily.
>>>
>>> Franck.
>>
>> 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
>> 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 Tuesday, 14 November 2017 13:57:48 UTC