odd CHEBI identifier

[balhoff]

Is this CHEBI identifier a mistake? (doesn't use standard CHEBI IRI structure)

biolink-model/biolink-model.ttl

Line 637 in ad0cb85

skos:mappingRelation <https://w3id.org/biolink/vocab/CHEBI:23888>,

[mbrush]

This does look strange to me as well. Guessing @hsolbrig or @cmungall can provide an answer.

[deepakunni3]

@hsolbrig It looks like while generating the TTL, it does not use CURIE prefix to IRI mapping provided via context.jsonld. Instead, it is using https://w3id.org/biolink/vocab/.

Although I don't see a pattern. Some CURIEs are expanded to their proper IRI while others are not.

[cmungall]

yeh this is odd... can you investigate further?

[hsolbrig]

The issue is a bug (feature) in the JSON-LD 1.0 specification, where prefix aliases had to end with "/" or "#" to be considered prefixes. See: http://tinyurl.com/ru6aygk for an example.

In JSON-LD 1.1, the solution is to add "@prefix": true to prefixes that end in "_" or other characters. Since we're still waiting for a 1.1 Python implementation, the solution will have to be to expand the CURIE's of non-"standard" prefixes for the immediate turn.

[balhoff]

I never knew about that restriction. I feel like we have been using underscore-terminated prefixes in our contexts (e.g. in GO) for quite a while without issue. Maybe it's a difference in the implementation we're using; I mostly have experience with json-ld-java (this is used in ROBOT).

[hsolbrig]

We've raised the following question:

Just to double check - in JSON-LD 1.0, there is no way to make the following work:

    {   "@context": {
          "CHEBI": "http://example.org/CHEBI_"
        },
       "CHEBI:item1": true
   }

On w3c/json-ld-syntax#329

It appears that there was an addendum to the JSON-LD 1.0 spec that caused the above item

[cmungall]

This is worrying, it goes beyond biolinkml and prefixcommons..

[hsolbrig]

Yup -- at this point we need to be sure that we address it thoroughly in the JSON-LD 1.1 spec. Note that it works fine if you're just parsing the context as a plain old JSON file, but rdflib won't see it as a prefix. For the short term (~3 months) we are planning to publish a fork of rdflib-jsonld that addresses this (although we do need to keep an eye out for the issue that caused it to be implemented in the first place). Be interested on your take on the:

{
    "@context": {
        "@prefix" : {
           "CHEBI" : "http://exampl.org/CHEBI_"
           ...
       }
   }
}

proposal for the longer term

[balhoff]

It doesn't seem like we can wait for the JSON-LD spec to change in order to fix this incorrect prefix expansion (which is a fairly urgent problem to me). I think we should manage prefixes in a basic YAML file (which is not a JSON-LD context), and then have a separate build step that generates a more verbose JSON-LD context that will produce the correct expansions. If anyone supports this idea, we could close this ticket and open a ticket do that instead.

[TomConlin]

+1 for a stand alone yaml file of :

• common cure-prefix
  to
• owl/ontology/KG/machine preferred base-uri

[hsolbrig]

As a follow up, the RDFLIB JSON-LD library fix did not work -- without the URI pattern match, a lot of things that weren't intended be prefixes ended up being interpreted as such. The patch has been withdrawn.

+1 on the stand-alone yaml file as the default. We can generate an automatic transformation to the JSON-LD context for those who use it directly, although it will be interesting to see what 1.0 processors do with it...

[balhoff]

@hsolbrig thanks! Maybe we need to generate two JSON-LD contexts. 😉

[hsolbrig]

Should we consider shifting this discussion to https://github.com/prefixcommons or https://github.com/prefixcommons/biocontext ? I think the only way to find out is to run unit tests and see what breaks, but I'd assume that the majority of them are on prefixcommons side

[balhoff]

I'm closing this issue in favor of the proposal in #397.