search

w3c / json-ld-syntax

JSON-LD 1.1 Specification
https://w3c.github.io/json-ld-syntax/
Other
112 stars 22 forks source link

Suggestion about `@prefix` #329

Open hsolbrig opened 4 years ago

hsolbrig commented 4 years ago

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 commented 4 years ago

This issue was discussed in a meeting.

hsolbrig commented 4 years ago

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 commented 4 years ago

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

http://tinyurl.com/wwl2yk2

gkellogg commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

@hsolbrig would the form suggested in https://github.com/w3c/json-ld-api/issues/76#issuecomment-582650517 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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

hsolbrig commented 4 years ago

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 commented 4 years ago

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.

pchampin commented 4 years ago

That's right, simple term definitions and expanded term definitions behave differently regarding @prefix:

IIRC, the feeling of the WG was that the default value of @prefix should have always been false (hence the default for expanded term definitions). But on the other hand, JSON-LD 1.0 has set the expectation that simple term definitions could be used to define prefixes, hence the special case for simple term definitions.

Standardization is about compromise :)

wdduncan commented 4 years ago

@pchampin Thanks for the feed back! Setting the @prefix to true in an expanded term definitions allows use of the underscore ("_") at the end IRIs, which is very important for the OBO community.

For example:

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

yields:

_:b0 <http://ex.com/bar_456> "blah" .
_:b0 <http://ex.com/foo#123> "baz" .

It would be nice to have a global way to set @prefix to true, rather than having to use expanded term definitions for all OBO IRIs. Any plans to make this possible?

iherman commented 4 years ago

This issue was discussed in a meeting.

wdduncan commented 4 years ago

@iherman Thanks for the info!

iherman commented 4 years ago

This issue was discussed in a meeting.

matentzn commented 1 year ago

Are there any updates on this issue?

gkellogg commented 1 year ago

The little activity in the recommendations is mostly directed at errata and test issues. This feature may be considered for the next release cycle, depending on what the Maintenance Group prioritizes.