Re: Protein representation with a Bioschemas context ()

I like this option. Data providers who use it will just need to be careful
if the Bioschemas context and the data provider's context share IRIs but
use different terms. See this issue
<https://github.com/digitalbazaar/jsonld.js/issues/75> for more details.
Note also that it doesn't appear possible to override a term if the data
provider makes the context available only via an HTTP Link Header
<https://json-ld.org/spec/latest/json-ld/#interpreting-json-as-json-ld>,
because overriding requires specifying a nested context like the second one
for "name" in the following example:

{
  "@context": {
    "name": "http://example.com/person#name",
    "details": "http://example.com/person#details"
  },
  "name": "Markus Lanthaler",
  ...
  "details": {
    "@context": {
      "name": "http://example.com/organization#name"
    },
    "name": "Graz University of Technology"
  }
}


On Tue, Nov 14, 2017 at 1:51 PM, Franck Michel <franck.michel@cnrs.fr>
wrote:

> An option between 3A and 3B may consist in importing the Bioschemas
> context and extend it with an additional custom terms:
>
>   "@context": [
>     "http://bioschemas.org/context.jsonld" <http://bioschemas.org/context.jsonld>,
>     {
>       "comesFromGene": "...",
>     }
>   ]
>
> According to the specification it is even possible to override a term
> defined in a previously loaded context: https://json-ld.org/spec/
> latest/json-ld/#advanced-context-usage
>
> Franck.
>
>
> Le 14/11/2017 à 20:31, Anders Riutta a écrit :
>
> So, it looks like we are talking about something like
>> https://github.com/BioSchemas/specifications/blob/master/Pro
>> tein/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.
>
>
> To clarify, here's a list of what I'm hearing we'll have:
>
>    1. Context published by Bioschemas, e.g., "http://bioschemas.org/
>    context.jsonld"
>    2. Data published by each data provider, e.g.,
>    http://rest.ensembl.org/...
>    <http://rest.ensembl.org/lookup/id/ENSG00000157764?content-type=application/json>
>    3. Context published by each data provider, e.g., "
>    http://ensembl.org/context.jsonld <http://ensembl.org/context.jsonld>"
>       - Option A: Data provider can re-use Bioschemas context: {"@context":
>       "http://bioschemas.org/"}
>       - Option B: Data provider can create their own context, but,
>       whenever possible, will use the IRIs from the Bioschemas context
>
> 3A will probably only be possible if the data provider is creating a new
> API.
>
> Most data providers will need to use 3B, because their terms will not
> match the terms from the Bioschemas context, e.g., "transcribedFrom" vs.
> "comesFromGene". By re-using IRIs from the Bioschemas context, they will
> make it possible for Bioschemas-compliant tools to work despite term
> differences, because the data provider context and the Bioschemas context
> will together make it clear that "comesFromGene" and "transcribedFrom" both
> mean "http://semanticscience.org/resource/SIO_010081".
>
>
>