Re: WebID default serialization for WebID 2.x

On 1/24/22 2:15 PM, Jacopo Scazzosi wrote:
> Hi all,
>
>> A NetID is a resolvable identifier that denotes and entity unambiguously.
>> This identifier can resolve to JSON, JSON-LD, RDF-Turtle, etc profile
>> documents as preferred by an Identity Provider  -- leaving the agnostic
>> nature of RDF to handle the inevitable and natural data messiness.
>> Keep JSON(-LD) as a SHOULD, have no serialisation as a MUST, this gives the
>> feel of a NetID type spec.
> Am I correct if I state that the implication, here, is that NetID clients must
> be able to work with all RDF serialization formats?


Hi Jacopo,

No.


>   If so, how do you make this
> future-proof so that clients do not break when new formats arise?


New formats will always arise in regards to representing entity 
relationships using graphic or linear notations. The trick is to look to 
a RDF as being totally abstract in nature with loose-coupling to various 
notations and serialization formats.

It is unlikely that entity relationship graphs (be it EAV or RDF) are 
going anywhere soon :)

>> 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)
> IMHO, b) or c) limited to JSON.


No matter how it is worded, a MUST for any serialization format (or 
content-type) is a problem. Jonas explained this nicely in an earlier 
response.

If you start with JSON it is highly likely that your effort will be 
groked by many a "Web Developer" out there i.e., your work will attract 
collaborators and users quite rapidly. Achieving that trumps any MUST in 
a spec, IMHO.

For instance, look at where all the MUST and SHOULDs took WebID:

A great piece of work (leveraging core Web Architecture) that addresses 
a important problem, but is barely used and rarely understood circa 2022.


> On top of the above, I fear a) would lead to
> *huge*, less maintainable clients. Which is not an issue in some cases but can
> be a significant one in others.


Not if you look through NetID lenses :)

>
> Best regards,
> Jacopo
>
>

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