Re: WebID default serialization for WebID 2.x

On 1/24/22 9:14 AM, Jacopo Scazzosi wrote:
> Hi all,
>
>> [...] you want to take a protocol that follows the
>> architecture of the WWW and implements content negotiation, and change
>> it to contain the anti-pattern of canonical representation, which will
>> impact all implementations across the board.
> As of today [1], WebID does not *require* content negotiation. In my opinion,
> this is a good thing. We disagree, and that's fine, but I hope we can agree
> that I am not the one arguing for change, here.


Correct.

Content-Negotiation SHOULD never be part of any spec.

It was never part of the original Linked Data Principles guidelines 
<https://www.w3.org/DesignIssues/LinkedData.html>.

Content-Negotiation is simply a pattern that can be implemented by an 
HTTP client or HTTP server. That's it, really.

The prevailing question that's attracted so much confusion is as follows:

*How are entities to be unambiguously denoted using a resolvable 
identifier? *

Unfortunately, that simple question has lead to unbelievable amounts of 
confusion, from a myriad of sources.

For instance, DBpedia answers that question (as a platform that adheres 
to Linked Data Principles) by using HTTP 303 redirection. That's a 
solution choice rather than a Linked Data Principles requirement or 
mandate i.e., it addresses the requirement in question using a 
particular practice that leverages content-negotiation.

Every Linked Data endeavor isn't a DBpedia rendition. Each endeavor 
simply needs to pick its preferred mechanism for unambiguous entity 
denotation.

A WebID was supposed to be as follows:

A resovable identifier that denotes an Agent, unambiguously. 
Unfortunately, it devolved into an HTTP URI that denotes an Agent and 
resolves to an RDF/XML document (FOAF SSL era); then it evolved into a 
variant where RDF-Turtle replaced RDF-XML; and then it evolved further 
re RDF-Turtle (MUST) and JSON-LD (SHOULD).

As I've already stated in earlier posts, based on absolute fatigue re 
this matter, we've opted to answer the same fundamental question 
differently:

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.

*Conclusion:*

Content-Negotiation is an implementation detail that has nothing to do with:

1. What WebID was supposed to address

2. Linked Data Principles

RDF's super power is actually all about handling messy data using entity 
relationship type semantics.

HTTP's supper power is about allowing clients and servers negotiate 
structured data representation algorithmically.

Linked Data Principles provided guidelines for harnessing the combined 
superpowers of both HTTP and RDF where the end product is a Semantic Web.

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.


>
> I may even agree on the fact that canonical representation is an anti-pattern
> but convenience and practicality often come at the expense of formal rigour.
> I think a hallmark of good engineering is to find the tradeoff that best serves
> all interested parties. I am not arrogant enough to claim that I am a good
> engineer and that my tradeoffs are the best ones, that is for others to say,
> but I do want WebID to succeed and insofar as my experience goes, hard
> requirements for conneg and/or full JSON-LD parsing would damage any chance it
> might have.
>
>> So essentially because of limitations of your programming
>> platform/language,
> Yes, of course. Specifications should never be designed in a vacuum. Working
> with a spec that can be easily implemented in only two languages is a really
> bad business decision if one is looking for long-term interoperability.
>
> [1]: Drafts or not, in the absence of anything else those documents act as the
>       current WebID spec for all practical purposes.
>
> 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