Suggestion about `@prefix`

[hsolbrig]

How difficult would it be able to set @prefix globally? We've got quite a collection of non-standard prefixes and it kind of busies up the context document when we have to add the properties individually?

{   "@context": {
        "@prefix": true,
        "CHEBI": "http://example.org/CHEBI_",
        "CUBBY: "http://example.orrg/CUBBY_"
   }
}

[iherman]

This issue was discussed in a meeting.

• No actions or resolutions

View the transcript

Rob Sanderson: #329
Harold Solbrig: I have a number of prefixes ending with underscore,
… rather than hash or slash (so not considered as prefix by default);
… it would be nice to be able to set @prefix=true globally,
… instead of specifying per term.
Rob Sanderson: would that apply to all terms in the context?
Gregg Kellogg: this would apply to all terms except those explicitly marked with @prefix=false
… and this would be meant to be used in subcontexts.
Harold Solbrig: the ramifications are big…
Gregg Kellogg: this is actually what 1.0 was doing initially;
… there was an errata to prevent just any IRI to be used as a prefix
Gregg Kellogg: See errata mail
Gregg Kellogg: See JSON-LD 1.0 errata
Harold Solbrig: let me time to ponder on it a little more
Rob Sanderson: gkellogg any more issues we should discuss?

[hsolbrig]

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
}

See: http://tinyurl.com/tn8k2fd

While I'm thinking of it, is it expected behavior that the above emits a triple while

http://tinyurl.com/w5qdz4c

Does not?

[hsolbrig]

In general, can someone verify that ALL of the behaviors below conform to the spec?

http://tinyurl.com/wwl2yk2

[gkellogg]

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
}

Yes, in the updated JSON-LD 1.0 (after errata), CHEBI won't be usable as a prefix, so it is treated as an IRI scheme.

See: http://tinyurl.com/tn8k2fd

While I'm thinking of it, is it expected behavior that the above emits a triple while

http://tinyurl.com/w5qdz4c

Does not?

This does not emit a triple (or expand), as "item1" is not a defined property. If you used @vocab as a catch-all to define it, it would create a triple.

[gkellogg]

In general, can someone verify that ALL of the behaviors below conform to the spec?

http://tinyurl.com/wwl2yk2

Those seem correct. P1-6 all are defined using IRIs and the x:item? properties all have the form of an IRI (with scheme x).

[hsolbrig]

We definitely need this fix. The problem we face is that the prefixcommons library uses JSON-LD contexts both as raw JSON maps and in rdflib json-ld parsers. See: https://github.com/biolink/biolinkml/blob/master/notebooks/context_issue.ipynb for a description of the details.

The prefixcommons library, which has widespread use in the bioinformatics community, has a significant number of prefixes that do not end in '/' or '#'. Based on the above responses, our options using JSON-LD 1.0 are quite limited, and we will probably end up patching rdflib-jsonld to reverse https://lists.w3.org/Archives/Public/public-rdf-comments/2018Jan/0002.html with our fingers crossed that issue it fixes doesn't appear in any of our target JSON.

In the longer (JSON-LD 1.1) term, we would like to be able to import the existing contexts, adding a global "@prefix": true, as the per-prefix fix simply won't work.

[niklasl]

@hsolbrig would the form suggested in w3c/json-ld-api#76 (comment) work for you? That is, this:

{
  "@context": {
    "@prefix": {
        "dc": "http://purl.org/dc/terms/",
        "tag": "tag:example.org,2020:ns:",
        "compact-iris": "http://example.com/compact-iris-"
    }
  },
}

It'd require a slight change in usage, but that form is usable as a simple raw JSON dictionary.

[hsolbrig]

I've put a query out to the prefixcommons community -- hoping to hear back soon. I like where it is going but it does have some interesting ramifications.

[cmungall]

Hello all, I represent the Open Bio Ontologies (OBO) Foundry (http://obofoundry.org) which is the leading collection of ontologies in biomedicine and the life sciences.

All OBOs use PURLs of the form http://purl.obolibrary.org/obo/$NAMESPACE_$LOCALID, for which we have canonical CURIEs of the form $NAMESPACE:$LOCALID. A lot of our stack has been using JSON-LD contexts (which we love) with mappings of the form

 "NAMESPACE":  http://purl.obolibrary.org/obo//NAMESPACE_"

This has been largely working but I guess this is not following the standard and it is not robust to rely on this behavior?

I would be very much in favor of technical solutions that don't bake in assumptions about the syntactic structure of URIs, which should be opaque to software.

[wdduncan]

The NAMESPACE_ prefix works fine in the JSON-LD 1.0 playground. What changed?

[hsolbrig]

While I'd like to discuss the above approach as it would make some of the contexts we are generating more readable, the ideal solution for the prefixcommons community would be to have an API flag that says "treat everything as a prefix". That would allow code that reads contexts as JSON to work unchanged and would require minimal changes to the API calls once the 1.1 software is in place

[wdduncan]

Interestingly, in LD 1.1, using the "@id" designator does not always work as expected when using "#".
For example:

{
  "@context":
  {
    "foo": "http://ex.com/foo#",
    "bar": {
      "@id": "http://ex.com/bar#"
    }
  },
  "foo:123": "baz",
  "bar:456": "blah"
}

yields the following triples:

_:b0 <bar:456> "blah" . <---- expected <http://ex.com/bar#456>
_:b0 <http://ex.com/foo#123> "baz" .

But in LD 1.0, it yields:

_:b0 <http://ex.com/bar#456> "blah" . <----- works as expected
_:b0 <http://ex.com/foo#123> "baz" .

which is what you expect.