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

Re: Protein representation with a Bioschemas context ()

From: Franck Michel <franck.michel@cnrs.fr>
Date: Wed, 15 Nov 2017 09:47:07 +0100
To: public-bioschemas@w3.org
Message-ID: <f3ae17aa-efc0-38ed-4a79-ab3ea1d0ae62@cnrs.fr>
 > overriding requires specifying a nested context like the second one 
for "name"

Actually I feel like this is unclear, in the specification, whether this 
is the only way of overriding:

    "Multiple contexts may be combined using an array, which is
    processed in order. The set of contexts defined within a specific
    JSON object are referred to as local contexts. The active context
    refers to the accumulation of local contexts that are in scope at a
    specific point within the document."

I understand that this "accumulation" will apply overriding given the 
order in the array, but this is not clearly stated.

Franck.

Le 14/11/2017 à 23:09, Anders Riutta a écrit :
> 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 
> <mailto: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
>     <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/Protein/examples/ProteinEntity-with-context.json
>>         <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 <http://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
>>         <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
>>     <http://semanticscience.org/resource/SIO_010081>".
>
>
Received on Wednesday, 15 November 2017 08:47:31 UTC

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