Re: WebID default serialization for WebID 2.x

On 1/25/22 5:32 AM, Jonas Smedegaard wrote:
> 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.


Yep!


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


Amen!


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


Yep!


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

-- 
Regards,

Kingsley Idehen 
Founder & CEO
OpenLink Software
Home Page: http://www.openlinksw.com
Community Support: https://community.openlinksw.com
Weblogs (Blogs):
Company Blog: https://medium.com/openlink-software-blog
Virtuoso Blog: https://medium.com/virtuoso-blog
Data Access Drivers Blog: https://medium.com/openlink-odbc-jdbc-ado-net-data-access-drivers

Personal Weblogs (Blogs):
Medium Blog: https://medium.com/@kidehen
Legacy Blogs: http://www.openlinksw.com/blog/~kidehen/
               http://kidehen.blogspot.com

Profile Pages:
Pinterest: https://www.pinterest.com/kidehen/
Quora: https://www.quora.com/profile/Kingsley-Uyi-Idehen
Twitter: https://twitter.com/kidehen
Google+: https://plus.google.com/+KingsleyIdehen/about
LinkedIn: http://www.linkedin.com/in/kidehen

Web Identities (WebID):
Personal: http://kingsley.idehen.net/public_home/kidehen/profile.ttl#i
         : http://id.myopenlink.net/DAV/home/KingsleyUyiIdehen/Public/kingsley.ttl#this