{"action":"created","issue":{"url":"https://api.github.com/repos/w3c/json-ld-syntax/issues/20","repository_url":"https://api.github.com/repos/w3c/json-ld-syntax","labels_url":"https://api.github.com/repos/w3c/json-ld-syntax/issues/20/labels{/name}","comments_url":"https://api.github.com/repos/w3c/json-ld-syntax/issues/20/comments","events_url":"https://api.github.com/repos/w3c/json-ld-syntax/issues/20/events","html_url":"https://github.com/w3c/json-ld-syntax/issues/20","id":337226406,"node_id":"MDU6SXNzdWUzMzcyMjY0MDY=","number":20,"title":"Introduce concept of \"sealed” contexts","user":{"login":"gkellogg","id":46296,"node_id":"MDQ6VXNlcjQ2Mjk2","avatar_url":"https://avatars0.githubusercontent.com/u/46296?v=4","gravatar_id":"","url":"https://api.github.com/users/gkellogg","html_url":"https://github.com/gkellogg","followers_url":"https://api.github.com/users/gkellogg/followers","following_url":"https://api.github.com/users/gkellogg/following{/other_user}","gists_url":"https://api.github.com/users/gkellogg/gists{/gist_id}","starred_url":"https://api.github.com/users/gkellogg/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/gkellogg/subscriptions","organizations_url":"https://api.github.com/users/gkellogg/orgs","repos_url":"https://api.github.com/users/gkellogg/repos","events_url":"https://api.github.com/users/gkellogg/events{/privacy}","received_events_url":"https://api.github.com/users/gkellogg/received_events","type":"User","site_admin":false},"labels":[{"id":965703045,"node_id":"MDU6TGFiZWw5NjU3MDMwNDU=","url":"https://api.github.com/repos/w3c/json-ld-syntax/labels/spec:enhancement","name":"spec:enhancement","color":"c11537","default":false}],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":4,"created_at":"2018-06-30T16:31:51Z","updated_at":"2018-10-27T07:02:02Z","closed_at":null,"author_association":"MEMBER","body":"A number of standards track specifications use JSON-LD for extensibility but intentionally place limitations on overriding the terms defined in a core context. For example:\r\n\r\n> Implementations may augment the provided @context with additional @context definitions but must not override or change the normative context.\r\n\r\nhttps://www.w3.org/TR/activitystreams-core/#jsonld\r\n\r\n> Implementations MUST produce an error when an extension JSON-LD Context overrides the expanded URL for a term specified in the base JSON-LD Context (https://w3id.org/credentials/v1). To avoid the possibility of accidentally overriding terms, developers are urged to scope their extensions.\r\n\r\nhttps://w3c.github.io/vc-data-model/#extensibility\r\n\r\nIt seems like it would be a nice feature to allow enforcement of this desire by JSON-LD processors. Then authors could be assured that the interpretation of a context would be proper and properly implemented JSON-LD processors would throw errors if rules were violated.\r\n\r\nIn short, I propose we add a keyword with boolean value such as `\"@sealed\": true` (that could appear in contexts) to JSON-LD 1.1 that enables processors to enforce a desire to prevent defined terms from being redefined in subsequent contexts, but allows for new terms (aka extensions) to be defined.\r\n\r\nOriginal issue: [Introduce concept of \"sealed\" contexts #656](https://github.com/json-ld/json-ld.org/issues/656)\r\n"},"comment":{"url":"https://api.github.com/repos/w3c/json-ld-syntax/issues/comments/433597223","html_url":"https://github.com/w3c/json-ld-syntax/issues/20#issuecomment-433597223","issue_url":"https://api.github.com/repos/w3c/json-ld-syntax/issues/20","id":433597223,"node_id":"MDEyOklzc3VlQ29tbWVudDQzMzU5NzIyMw==","user":{"login":"iherman","id":520723,"node_id":"MDQ6VXNlcjUyMDcyMw==","avatar_url":"https://avatars0.githubusercontent.com/u/520723?v=4","gravatar_id":"","url":"https://api.github.com/users/iherman","html_url":"https://github.com/iherman","followers_url":"https://api.github.com/users/iherman/followers","following_url":"https://api.github.com/users/iherman/following{/other_user}","gists_url":"https://api.github.com/users/iherman/gists{/gist_id}","starred_url":"https://api.github.com/users/iherman/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/iherman/subscriptions","organizations_url":"https://api.github.com/users/iherman/orgs","repos_url":"https://api.github.com/users/iherman/repos","events_url":"https://api.github.com/users/iherman/events{/privacy}","received_events_url":"https://api.github.com/users/iherman/received_events","type":"User","site_admin":false},"created_at":"2018-10-27T07:02:02Z","updated_at":"2018-10-27T07:02:02Z","author_association":"MEMBER","body":"This issue was discussed in [a meeting](https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2018/2018-10-25-json-ld#section3-5).\r\n\r\n- No actions or resolutions\r\n<details><summary><i class=\"differentiate\">View the transcript</i></summary>\r\nDave Longley: we wanted to talk about onboarding allies from the JSON world<br/>\r\n… a number of W3C specs have adopted JSON-LD, to get extensibility and interoperability<br/>\r\n… however, a number of non-RDF people are only going to use this data as plain JSON<br/>\r\n… not apply any JSON-LD algorithm<br/>\r\n… Most of those standards require that their context is the first one in the @context list;<br/>\r\n… and have the rule that terms from their context should not be overridden.<br/>\r\n… Result: plain JSON interpretation will differ from JSON-LD interpretation.<br/>\r\nRob Sanderson: if the JSON-only processor does not use the context at all, where’s the risk?<br/>\r\nDave Longley: E.g. Verifiable Credentials defines a ‘description’ field;<br/>\r\n… if someone uses an additional context redefining ‘definition’ to mean something else,<br/>\r\n… a pure-JSON tool will still interpret that as the VC description field.<br/>\r\n… The ‘sealed context’ feature is required to make JSON-LD-based formats robust,<br/>\r\n… reducing the gap btw JSON and JSON-LD.<br/>\r\n… JSON people understand how JSON-LD can help interoperability,<br/>\r\n… rather than having anyone defining their own schema,<br/>\r\n… but they don’t have an RDF background.<br/>\r\nIvan Herman: the idea of a ‘sealed context’ is to prevent people from overriding terms in the first context.<br/>\r\n… Wouldn’t it break the expectation of someone publishing their own data with their own vocabulary?<br/>\r\nDave Longley: this only applies in the case you are using a array of contexts<br/>\r\nChristopher Allen: In constructing VC examples or DID examples,<br/>\r\n… I ran in problem linked to the underlying graph model, that only Dave or Manu could explain.<br/>\r\n… In VC, I want to be able to put some metadata of my own,<br/>\r\n… something that’s not standardized or even ready for standardization,<br/>\r\n… how do we put it in a way that we are not messing up other things?<br/>\r\nDave Longley: many people don’t get that curly braces in JSON-LD mean that you are talking about a node,<br/>\r\n… and attributes are about the links in this graph;<br/>\r\n… those people tend to produce data that make no sense for people who understand those principles.<br/>\r\nBenjamin Young: I came to JSON-LD from an RDF-aware background<br/>\r\n… I want to make things clearer,<br/>\r\n… but not at the price of hiding completely the graph model from Web developers.<br/>\r\nAdam Soroka: +1 to bigbluehat<br/>\r\nBenjamin Young: Anecdote: in some plain-JSON formats, the same attribute ‘name’ does not expect the same type at different levels of the tree. You don’t have that in JSON-LD.<br/>\r\nChristopher Allen: We are at a jey point where a lot of people are using JSON-LD.<br/>\r\n… We don’t want them to decide that they will just do JSON and forget about the LD.<br/>\r\nGregg Kellogg: would the solution be a set of best practices?<br/>\r\nIvan Herman: Question: who is expected to seal a context? The author of the context or the author of the data?<br/>\r\nDave Longley: This is an open question.<br/>\r\n… The notion of sealed context is one way to hide the graph model .<br/>\r\n… Best practices, and anything that makes people aware that there is something beyond JSON, is a non-starter.<br/>\r\nBenjamin Young: for you, sealed context only apply for arrays of contexts?<br/>\r\nDave Longley: yes, in all the use cases that I know of.<br/>\r\n… If someone publishes a new context which extends another one,<br/>\r\nDave Longley: they can decide to override terms of the inherited context.<br/>\r\n… As this would be a totally differen thing from the POW of pure-JSON.<br/>\r\nIvan Herman: Would it make sense to introduce a JSON datatype?<br/>\r\n… I could put a bunch of JSON in the JSON-LD, that would be interpreted as an RDF literal with the JSON datatype.<br/>\r\nBenjamin Young: but then you would have problems for signing, because you couldn’t determine the exact value of that literal (re. new lines, spaces…).<br/>\r\nDave Longley: yes, that raises a number of other issues.<br/>\r\nBenjamin Young: One use case in VC is to be able to express an inner graph, with its own context,<br/>\r\n… without compromising the outer graph with the VC metadata.<br/>\r\n… In the old days, we would have used namespaces.<br/>\r\n… Why not use “vc:” in front of the terms you want to keep uncompromised?<br/>\r\nDave Longley: The prefix wouldn’t survive some JSON-LD applications,<br/>\r\n… and would produce something different from the POV of plain-JSON.<br/>\r\nRob Sanderson: Is it the expension that’s the issue? Or the compaction as well?<br/>\r\n… Is it only about the label or the rest of the definition (e.g. “@type”: “@list”)?<br/>\r\nDave Longley: the full term definition has to be a constant.<br/>\r\nIvan Herman: in the first round, let’s stick to sealing contexts, not individual term definitions<br/>\r\n… What we are trying to do is to add a “modifier” on the “@context” link.<br/>\r\nAdam Soroka: The notion of wrapping is important in this use case.<br/>\r\n… Is “sealing” not a special case of prioritization,<br/>\r\n… which might have more complex requirements?<br/>\r\nDave Longley: ActivityPub also have requirements for priority.<br/>\r\n… Their answer is “if you nee priorities, use full-fledged JSON-LD”<br/>\r\nDave Longley: re. WC, we could ask people to include their own @context,<br/>\r\n… but that could not work in all cases.<br/>\r\nBenjamin Young: pchampin suggested earlier to required that the sealed context be in the end,<br/>\r\n… so it will effectively not be overridden with the current rules.<br/>\r\nGregg Kellogg: yes, but putting the extension before the extended context would be odd<br/>\r\nRob Sanderson: if terms are marked sealed, and the extension redefines that term,<br/>\r\n… the overridden term will not be sealed, which can be detected by a validator<br/>\r\n… This could mitigate the problem.<br/>\r\nIvan Herman: what if we have two sealed contexts in the list?<br/>\r\nDave Longley: then we would also need order priority…<br/>\r\nPierre-Antoine Champin: seems to me we’re discussing two different things with multiple contexts<br/>\r\n… extensions<br/>\r\n… which are aware of the sealed context<br/>\r\n… and it would therefore be carefully designed to not conflict<br/>\r\n… the other scenario is a “wrapping” one<br/>\r\n… where the contained statements are expected to not match the wrapper<br/>\r\nBenjamin Young: regarding the wrapping scenario, JSON-LD has graph containers.<br/>\r\nDave Longley: VC is using that.<br/>\r\nBenjamin Young: could we solve the problem by adding some mechanism at the graph containers level.<br/>\r\nDave Longley: that would only work in named graph. That might solve my problem, but may be not others’ (activity streams).<br/>\r\nBenjamin Young: following pchampin’s idea that there are two different categories, may be two different solutions are the way to go.<br/>\r\nBenjamin Young: <a href=\"https://github.com/w3c/json-ld-syntax/issues/87\">https://github.com/w3c/json-ld-syntax/issues/87</a><br/>\r\nIvan Herman: to wrap up, the options that we considered are<br/>\r\n… 1/ modify the semantics of graph containers<br/>\r\n… 2/ having a “sealed”: true attribute in the context<br/>\r\n… 3/ having a “sealed”: true within term definitions<br/>\r\n… 4/ having the equivalent of a “rel=” attribute on the “@context” link<br/>\r\nGregg Kellogg: when you seal, are you sealing the local context or the active context?<br/>\r\nGregg Kellogg: seal and integrity should be treated separately<br/>\r\nBenjamin Young: why not just go for putting the sealed context in the end?<br/>\r\nGregg Kellogg: because the following contexts will usually rely on the definitions in the first (sealed) context.<br/>\r\n… e.g. after importing the schema.org context, I know I can use the xsd prefix.<br/>\r\nRob Sanderson: ref: <a href=\"https://iiif.io/api/presentation/3.0/#45-linked-data-context-and-extensions\">https://iiif.io/api/presentation/3.0/#45-linked-data-context-and-extensions</a><br/>\r\n</details>"}}
{"actor":{"display_login":"iherman"}}