Scoped contexts

[davidlehn]

While designing contexts to make writing and processing JSON-LD easier there is an issue of polluting the global context namespace with term definitions. It may be beneficial to support scoped contexts or similar functionality. This could make an "enum" pattern much easier to handle.

For instance, if you have a property http://example.com/foo with possible values http://example.com/Bar and http://example.com/Baz you currently could use JSON-LD such as:

{
  "@context": {
    "ex": "http://example.com/",
    "foo": {
      "@id": "ex:foo",
      "@type": "@vocab"
    },
    "Bar": "ex:Bar",
    "Baz": "ex:Baz"
  },
  "foo": "Bar"
}

However, this has now put Bar and Baz in the "global" namespace when perhaps they are only used as values for foo.

A possible scoped context structure could limit how terms are resolved based on current processing state:

{
  "@context": {
    "ex": "http://example.com/",
    "foo": {
      "@id": "ex:foo",
      "@type": "@vocab"
      "@context": {
        "Bar": "ex:Bar",
        "Baz": "ex:Baz"
      }
    }
  },
  "foo": "Bar"
}

The above would limit the Bar and Baz expansion to only happen when used as a value for the foo property. In addition, other properties, such as bif could redefine Bar and Baz to other local values without conflicting with the terms names that foo uses.

This feature wouldn't stop anyone from using data however they want, it would just add clarity to contexts without referring to a fully defined schema. Data still needs to be validated by some other means. There is a potential issue for confusion if you have multiple terms with similar names, but I suspect the ease of use benefits would out weight the problems. The alternate less easy to use method is to define top-level terms such as FooBar and BifBar to avoid conflicts.

Current examples of where this might be of use:

https://github.com/web-payments/payswarm.com/blob/master/contexts/payswarm-v1.jsonld

PaySwarm, as of early 2013, uses a credit card schema and has a context with cardBrand with some common brand terms defined such as Visa, MasterCard, and others. Those values are not used elsewhere. Similar with bankAccountType, currency, and various other "enum" style properties.

https://developers.google.com/gmail/schemas/reference/rsvp-action

Google, as of May 2013, started using JSON-LD for email actions. In their new RsvpAction type they have an attendance property that can take on http://schema.org/RsvpAttendance/Yes|No|Maybe. Such properties would be a prime candidate for a scoped context since it's likely the schema used restricts the valid value to those three URIs.

[dlongley]

This is an interesting idea. You could think of it as if you were injecting the scoped @context into the data whenever its related term is found without having to do it in the data itself. This could also be helpful with the zero-edit design goal.

[lanthaler]

This pretty much goes in the direction I tried with previous work (before JSON-LD). The conclusion I came to by talking to developers was that it is very powerful but unfortunately also very complex and difficult to evaluate as a human. (maybe it was also just the case the way I designed it back then..) Anyway, thanks for raising this.. depending on how people and up using JSON-LD this is definitely something to look into.

[davidlehn]

In addition to the examples above it would be nice to have property scoped @vocab support as well. Similar to that being discussed in #262.

[ceefour]

👍 for this..

@ihervin eh PaySwarm (and Google) uses JSON-LD as well, can be an inspiration for future payment API

[ariutta]

This is a difficult challenge to implement well, but if it could be done, I'd love to use it.

[ceefour]

As it stands now, a property must be created which "encompasses" (i.e. sameAs) all other properties, even though they're semantically different :(

[davidlehn]

@ceefour I assume you are talking about the issue of keys with the same names but should have different associated properties depending on where they are used? That is a use case that this idea could address. For now you just have to deal with the limitation and use different key names.

[ceefour]

@davidlehn Yes. But since we're JSON first, we're doing it the other way around by using the same key names anyway. When we control the vocabulary we try to make it unique but not always possible.

E.g.

Product has status which is (enumeration) property with range ProductStatus

Order has status which is (enumeration) property with range OrderStatus

Using key names productStatus and orderStatus would feel unnatural to the JSON user.

[serialseb]

+100. We're being beaten by this a lot in our current format, and that restriction really flies in the face of json-first. It's making our like unnecessary complex. We end up injecting a context in a term with a vocab, which makes the json less than easy to deal with.

[mitar]

Related: #415