- From: Melvin Carvalho <melvincarvalho@gmail.com>
- Date: Thu, 23 Mar 2023 21:56:12 +0100
- To: Bob Wyman <bob@wyman.us>
- Cc: Jacky Alcine <yo@jacky.wtf>, public-swicg@w3.org
- Message-ID: <CAKaEYhJ+osqt+2uh5ktgabG9MHB+FBk1n7EovNu=_31x9pTCNA@mail.gmail.com>
čt 23. 3. 2023 v 21:18 odesílatel Bob Wyman <bob@wyman.us> napsal: > Melvin wrote: > > JSON-LD already had built in extension mechanisms that could be used, > and that seemed to be a satisfactory response > > Yes. JSON-LD usefully provides a mechanism for identifying which namespace > identifies each element of an object, but that just shifts the focus of the > problem to that of defining standard extensions and describing common > understandings of how the various extensions work together and with the > core specification. > > Today, I can add ODRL or Annotations to any JSON-LD object because they > each have defined namespaces. But, this mechanism won't help much if > Mastodon, Pleroma, and others all define their own extensions for either > Rights Expression Language or Annotations. Thus, I think we should be > identifying commonly useful extensions and, when there are competing > implementations, we should be seeking to define consensus versions that can > replace the implementation-specific extensions. > This is a good way But actually namespacing is overkill for a lot of use cases 1. If plemora and mastodon want to have common terms, in JSON, that's good 2. IF they want to have common terms in an HTTP vocabulary that will be maintained by them, or a third party that's also fine Both approaches have trade-offs. If you view these two approaches are types of variable scope, then many of the problems go away. There's also some tricks to enable this to work with global tool chains. > > > bob wyman > >
Received on Thursday, 23 March 2023 20:56:36 UTC