Re: WebID default serialization for WebID 2.x

Quoting Jacopo Scazzosi (2022-01-25 09:36:31)
> > Are you really sure that you want the *IDENTIFIER* to define the 
> > rules of the game - e.g. ensure future compatibility?
> > 
> > I strongly recommend to place constraints on *extension* specs - 
> > e.g. Solid spec might say that it can only ever work with yellow 
> > identifiers.
> 
> Jonas and Kingsley, I think I understand your point but I struggle to 
> reconcile it with those scenarios in which updating software might not 
> be as easy as we'd like it to be.
> 
> I appreciate how your approach, by eliminating conneg and MUSTs, would 
> lend itself to a whole spectrum of WebID publishers, from static 
> resources to conneg-enabled multi-format WebID servers. However, I 
> can't see an easy way for WebID clients to keep up.
> 
> For example, let's assume a super-successful WebID 2.0 and let's say I 
> am working on a device with an embedded WebID client. One of my goals 
> in building such a device according to a standard such as WebID would 
> be to decouple the lifetime of the device itself from that of the 
> company that makes it, at least to the greater possible extent. 
> Hardware should not break and become unusable when the manifacturer 
> ceases to exist. In this scenario, wouldn't a WebID spec without a 
> default serialization format enforced via MUST be extremely prone to 
> shortening the lifespan of the device itself even in a world that 
> fully embraces WebID?
> 
> I do feel that I might be missing something but I don't want to 
> monopolize this thread. I would be grateful if you could point me to 
> any resources that might help me understand your approach, also 
> privately. You've probably been making these points for a long time, 
> particularly to those who prefer a single default serialization format 
> like I do, and I appreciate the effort in maintaining the kind and 
> welcoming attitude.

Looking at "identifier" as a core building block, it makes some sense to 
compare with an image.

  * 1990s best practice: encode as gif (jpeg is slow)
  * 2000s best practice: encode as jpeg (gif has limited colorspace)
  * 2020s best practice: encode as WebP (computation is cheap)

Best practices change, but does not necessarily imply that old practice 
becomes incompatible for newer tools - sometimes it means older practice 
works equally well as before but newer techniques emerge that are more 
efficient and therefore preferred.

Looking at "identification" as a core procedure to exchange and parse an 
identifier, it makes some sense to compare with providing live content 
on an otherwise static web page.

  * 1990s best practice: embed Java content
  * 2000s best practice: embed flash content
  * 2010s best practice: code as ECMAScript, 5th Edition
  * 2020s best practice: code as ECMAScript 2015 or newer

Some of those older techniques still work today but some does not.  We 
could not have written a spec in the 1990s to future-proof techniques 
available back then - requiring specific techniques would only have made 
the specs *less* attractive to adopt.

These are some draft specs we have today:

  * WebID: how to identify in a way that is resolvable
    + resolving MUST be possible using Turtle
  * WebID-TLS: how to resolve and prove a WebID using TLS
  * WebID-OIDC: how to resolve a WebID using OIDC
  * Solid-OIDC: how to resolve some identifier using OIDC
    + identifier format can be WebID, but Turtle is unused
  * Solid: how to exchange messages identified somehow
    + identifier format can be WebID, but Turtle is unused

Notice how there are two specs for how to resolve using OIDC? Difference 
is that one is supposedly generic but you MUST implement support for 
parsing Turtle - the other is supposedly specific to Solid but really is 
the more generic of those two - it was created *only* to permit not only 
WebID but also NetID-same-as-WebID-except-not-mandating-Turtle.

Creating duplicate specs is not helpful.

Modernizing the specs by repeating same mistake just replacing "Turtle" 
with "JSON" or "JSON-LD" is short-sighted: It might feel simpler for 
current adopters but is the *opposite* of future-proof same as requiring 
Turtle was in the 2000s.

What would be helpful was to *drop* the Turtle requirement (without 
replacing it with another serialization requirement), so WebID was 
flexible enought to be *the* identifier format in other specs:

  * WebID: how to identify in a way that is resolvable
  * WebID-TLS: how to resolve a WebID using TLS
  * WebID-OIDC: how to resolve a WebID using OIDC
  * Solid: how to exchange messages identified using WebID

I want WebID to be *the* identifier format for RDF, not bound by some 
best practice of some age.

Sorry if I monopolize this thread.  Please don't be polite but shout at 
me if you feel that I am wrong and this thread really is about something 
else than my pet vision of WebID.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private