Re: webid serializations consensus 2023

Hi all,


> On 16 Jun 2023, at 18:37, Martynas Jusevičius <martynas@atomgraph.com> wrote:
> 
> There clear principles in how the specs should be structured, and one one them is orthogonality which I already brought up 1.5 years ago:
> https://www.w3.org/TR/webarch/#orthogonal-specs
> 
> […]
> 
> Yet in this group, most seem inclined to ignore this principle. Can someone explain to me why? In my personal opinion, it is detrimental to the WebID specification effort.

@Martynas: I can’t speak for others but my own explanation is that, while we are all familiar with the principle of orthogonality, some of us believe that a “perfect” application of such principle would lead to a spec too onerous / difficult to implement / support. I might not share such perspective right now but I sure did when I first started looking into WebID. In fact, to this day I still see significant advantages in having a few MUST(s), although I have also come to believe that they would bring even more significant disadvantages.

> On 21 Jun 2023, at 00:25, Sebastian Hellmann <hellmann@informatik.uni-leipzig.de> wrote:
> 
> * personally, I would like to see a client specification, i.e. specifying what a WebID reader MUST accept and be able to parse. I see it more helpful for adoption, if the publishers are unburdened and MAY choose the format they like the most. This would also improve validation, i.e. a standardized client can give a definite yes or no.

@Sebastian: defining the set of serialization formats that clients MUST support is not trivial, however, and past discussion have brought forward good arguments for and against all of the most common serialization formats. Ultimately, and here lies the biggest problem IMHO, there is nothing that covers all of the following:

- simplicity, also in terms of the computational cost of parsing / serializing
- self-containment, not having to retrieve other documents for the sole purpose of parsing
- embeddability within HTML
- compatibility with static hosting
- compatibility with Solid
- ease of adoption for non-LD professionals

> * JSON-LD can be made to look like plain JSON with the right context. This ideally means 1. no datatypes, 2. no `vocab:`, 3. no full URIs in keys. See example below. I consider this a great plus for schema.org, although some providers put "@context" : "https://schema.org" instead of "https://schema.org/" , which I read as "we never tested this with a json-ld parser". Otherwise, there is the flattened form with "@graph" .

@Sebastian: I think this is super-important and, for reference, has been previously proposed by @acoburn, for example in https://github.com/w3c/WebID/issues/3#issuecomment-1051274578 .

> On 21 Jun 2023, at 02:02, Nathan Rixham <nathan@webr3.org> wrote:
> 
> Related issue: https://github.com/w3c/WebID/issues/17

@Nathan: thanks for mentioning that discussion, it’s often hard to track things across both this list and GitHub.

Received on Wednesday, 5 July 2023 11:20:45 UTC