> On 5. Jun 2021, at 21:11, Gregg Kellogg <gregg@greggkellogg.net> wrote: > > The charter does mention various RDF serialization formats, and calls out the role of a JSON-LD Context, in particular. I think we should make it clear that the basis of the work is on the RDF Abstract Syntax, with serializations used as examples. Typically, these are written in Turtle/TriG as a well-understood representation, but it’s entirely appropriate to have some written in other serialization formats, or even allow a choice to view examples in different formats, or in non-normative sections on concrete syntaxes. > > Securing a JSON-LD context should not be a direct focus of this group, but it does point to work needed elsewhere. At the time, in the JSON-LD WG, the proposed hashlink URL scheme [1] looked like it would address this generically, and could be used to solve the issue of referencing quite specific versions of remote resources such as JSON-LD contexts and frames, which is part of the reason the group deferred action on adding anything explicitly for context integrity. I guess that with a method to sign canonicalized RDF data as the LDS group proposes to do, then such hash link URLs could be a lot more stable. > > The Linked Data Security Vocabulary, of necessity, does focus on vocabulary definitions in concrete syntaxes, and JSON-LD Contexts are commonly considered to be part of such vocabulary definitions. > > Otherwise, I would say that format-specific considerations should be left to non-normative notes and best practice documents. Of course, other groups may create their own normative documents, based on recommendations emerging from this group, that define some format-specific requirements, is is done with VCs, for example. > > If we can restrict the focus of the group, as much as possible, to dealing with abstract RDF datasets, we may be able to narrow the discussion sufficiently to find common ground. > > Gregg > > [1] https://datatracker.ietf.org/doc/html/draft-sporny-hashlink-07 > >Received on Sunday, 6 June 2021 06:30:49 UTC
This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 08:46:08 UTC