Re: WebID default serialization for WebID 2.x

On Mon, 24 Jan 2022 at 19:03, Jonas Smedegaard <jonas@jones.dk> wrote:

> Quoting Kingsley Idehen (2022-01-24 17:32:55)
> > A WebID was supposed to be as follows:
> >
> > A resovable identifier that denotes an Agent, unambiguously.
>
> [...]
>
> > A NetID is a resolvable identifier that denotes and entity
> > unambiguously.
>
> Right.
>
> Subject of this email thread is tied to wether WebID should be...:
>
>  a) the W3C spec generally for Agent IDs - i.e. exact same as NetID
>  b) the W3C spec for Agent IDs usable only where Turtle is spoken
>     (others can call their Agent IDs NetID or BingoCards or whatever)
>  c) the W3C spec for Agent IDs usable only where JSON(-LD) is spoken
>     (others can call their Agent IDs NetID or BingoCards or whatever)
>
> In other words, do we want WebID simple or easy?
>
>  * simple enough to be broadly usable
>
> or
>
>  * easy usable by constraining scope
>

There could be a compromise solution, that keeps most people happy.  And
that is:

Keep JSON(-LD) as a SHOULD, have no serialisation as a MUST, this gives the
feel of a NetID type spec.  Allow content negotiation to be supported, for
those that use it

Have the examples in the text in JSON(-LD), such that a casual developer
can deploy via copy and paste, can deploy to github.io, a static server,
jekyll etc.

Have a @context to make the examples look easy and attractive, that works
with User, Agents, IoT etc.

Have a few selected examples that show how to deploy WebIDs for different
use cases


>
>
> > It was never supposed to be complicated i.e., it's all about
> > "deceptively simple" design where simple things provide building
> > blocks for solving complex problems e.g., identity authenticity,
> > disparate data integration using data source names, and other
> > challenges.
>
> Amen.
>
>  - Jonas
>
> --
>  * Jonas Smedegaard - idealist & Internet-arkitekt
>  * Tlf.: +45 40843136  Website: http://dr.jones.dk/
>
>  [x] quote me freely  [ ] ask before reusing  [ ] keep private

Received on Monday, 24 January 2022 19:01:47 UTC