Re: WebID default serialization for WebID 2.x

On 1/25/22 3:36 AM, Jacopo Scazzosi wrote:
> Hi all,
>
>> 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.


You are expressing a common concern, but there's a little issue with 
said concern:

RDF is fundamentally a formalization (by the W3C) of an age-old pattern 
for structured data representation. That pattern is known as the 
Entity-Attribute-Value (EAV) approach to structured data representation.

The great thing about EAV is that it's everywhere, and has been so for 
eons.

Take any JSON document out there, and if you look closer you will find 
this pattern.

The ubiquity of said pattern is why Web Developers gravitate so easily 
to JSON en route to exploding projects aligned with their motivations.

RDF was an attempt to formalize EAV, but adding IRIs, but it got lost in 
confusion (much of which lingers to this very day).

Long story short, if you want resolvable identifiers to be adopted by 
Web Developers, while also leveraging the underlying ingenuity of core 
Web Infrastructure, simply operate on the following basis re structured 
data:

1. Logic is the schema -- everything is related to something else, in a 
variety of ways

2. The above is expressed using an Entity Relationship Graph

3. Use Resolvable Identifiers to craft Entity Relationship Graphs, where 
possible

Generally, JSON doc creators have little or no interest in #3, which is 
where the ingenuity of a "#" indexical come into play i.e., an client 
that's identity-aware can simply tack "#", "#this", or "#{whatever}" to 
the end of a URL and arrive at a URI that adheres to Linked Data 
Principles -- it just so happens that resolution isn't necessarily to an 
RDF document type (e.g., RDF-Turtle, RDF-XML, JSON-LD etc.); typically, 
it would be to a pure JSON or HTML doc.

The point here is that there is not breakage on the client side if Logic 
is the Schema and structured data is understood to be represented as an 
Entity Relationship Graph :)


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


You standards are:

1. Logic for the Schema

2. Entity Relationship Graph for expression

3. JSON, HTML, and others for representation

All you have to do as a developer is make that your working foundation. 
That's what we (OpenLink) have done for eons, and it has saved our tails 
from many potential disasters in this volatile world of technology and 
politics.


> Hardware should not break and become unusable
> when the manifacturer ceases to exist.


That's never happened to us.


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


Nope!

Conflating data representation syntax and data expression semantics 
will, as it has done re both WebID and RDF to date!

>
> I do feel that I might be missing something but I don't want to monopolize this
> thread.


These are good questions :)


> I would be grateful if you could point me to any resources that might
> help me understand your approach, also privately.


I published a presentation titled "Understanding Data" years ago, in 
relation to these matters [1].

> 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.
>
> Best regards,
> Jacopo.


[1] https://www.slideshare.net/kidehen/understanding-29894555 -- 
Understanding Data

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