Re: webid serializations consensus 2023

st 5. 7. 2023 v 13:21 odesílatel Jacopo Scazzosi <jacopo@scazzosi.com>
napsal:

> 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 1.1 accomplishes most if not all of the mentioned tasks. See
example 144 for reference:
https://www.w3.org/TR/json-ld11/#example-144-embedding-json-ld-in-html.
This approach has been employed successfully by Schema.org, Openlink, and
on my own static web page. It's extensively deployed across billions of
pages and millions of sites, significantly more than Solid.

There's near unanimous agreement in our group on JSON-LD. Our goal should
be to incorporate it into the spec, avoiding prolonged delays, which has
been a common occurrence for the past decade.

>
> > * 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.
>
>
>