Re: WebID default serialization for WebID 2.x

Am 25.01.22 um 11:32 schrieb Jonas Smedegaard:
> 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
> 

I agree with that argument. Besides the time dimension, the scope 
dimension mentioned here [1] supports that approach. IoT may have 
different requirements than the average Web use case. If we try to 
enforce a serialization, some use cases may have requirements 
incompatible with the spec. How high is the chance somebody will fork 
the spec and only change the serialization? Identifiers for agents is a 
very broad field. We can expect other specs to show up. A more open 
defined WebID spec would allow other specs compatible on the RDF level 
based on the WebID spec.

[1] https://lists.w3.org/Archives/Public/public-webid/2022Jan/0035.html

Received on Tuesday, 25 January 2022 21:53:29 UTC