search

w3c / json-ld-api

JSON-LD 1.1 Processing Algorithms and API Specification
https://w3c.github.io/json-ld-api/
Other
76 stars 29 forks source link

More compact @prefix #76

Open rubensworks opened 5 years ago

rubensworks commented 5 years ago

Currently, @prefix has boolean as range, and can be used as follows:

{
  "@context": {
    "@version": 1.1,
    "compact-iris": { "@id": "http://example.com/compact-iris-", "@prefix": true }
  },
}

In most cases, @prefix will probably be used together with @id. For this reason, it might be beneficial to also allow the following as equivalent representation:

{
  "@context": {
    "@version": 1.1,
    "compact-iris": { "@prefix": "http://example.com/compact-iris-" }
  },
}

As far as I can see, this should not cause conflicts or major performance issues when processing.

BigBlueHat commented 5 years ago

See PR #77 for more.

dlongley commented 5 years ago

PROPOSAL: If @prefix is present in a term definition, and its value is a string, then the term may only be used as a prefix. Additionally, including @id in the same term definition is an error.

Note that this adds additional complexity to processing as we would now have a new class of term that has no @id. I'm not sure how complex it would be.

To be clear, this would be different from treating @prefix: <string> as just syntactic sugar for @id: <string>, @prefix: true as I believe was originally proposed in this issue. Instead, this syntax would be a way to define a prefix that cannot be used on its own as a term.

dlongley commented 5 years ago

@pchampin -- Does the above sound like what we meant on the call?

rubensworks commented 5 years ago

PROPOSAL: If @prefix is present in a term definition, and its value is a string, then the term may only be used as a prefix. Additionally, including @id in the same term definition is an error.

So this would mean that if @id and @prefix: true would be used, that the term can be used as both a prefix and a property, right?

This would only be useful for some exotic use cases, but indeed important for backwards-compatibility with 1.0 behaviour. (We may want to clarify that this kind of usage is discouraged)

dlongley commented 5 years ago

@rubensworks,

So this would mean that if @id and @prefix: true would be used, that the term can be used as both a prefix and a property, right?

Yes.

This would only be useful for some exotic use cases, but indeed important for backwards-compatibility with 1.0 behaviour. (We may want to clarify that this kind of usage is discouraged)

And yes. +1

pchampin commented 5 years ago

@dlongley yes, that's how I understand the outcome of our discussion. and +1 as well to @rubensworks comment above.

iherman commented 5 years ago

This issue was discussed in a meeting.

davidlehn commented 5 years ago

This may be mixing topics, but another potential @prefix feature would be to use it to limit the scope of prefixes to the current context. We've had the issue of wanting a local prefix alias within a context, but didn't want the prefix to leak out and pollute the outer scope namespace. One of many possible syntaxes for this would be a flag like "@prefix": "@context" which may need consideration while discussing string values of @prefix.

iherman commented 5 years ago

This issue was discussed in a meeting.

niklasl commented 4 years ago

If this is eventually revisited (POST 1.1 I presume), I strongly recommend that another form is considered:

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

This should be the way to declare "prefix-only" prefixes, and keep them cleanly separated from regular term declarations (and the latter should never be considered as prefixes if a @prefix map is defined within the context).