Re: A Quick Note on WebID history - Re: All the Agents Challenge (ATAC) at ISWC 2021

On 7/26/21 2:39 AM, Melvin Carvalho wrote:
>
>
> On Mon, 26 Jul 2021 at 03:57, Kingsley Idehen <kidehen@openlinksw.com
> <mailto:kidehen@openlinksw.com>> wrote:
>
>     On 7/25/21 4:48 PM, Melvin Carvalho wrote:
>>
>>
>>         Yes, but parties on both sides are at fault re trying to
>>         impose a default document content-type for serialization and
>>         persistence of credentials.
>>
>>
>>     The default document type of the web is html
>
>
>     Yes it is, which is why "RDF deployed via HTML" is a growing
>     deployment pattern [1]
>
>
>>      
>>
>>         I continue to encourage the pursuit of verifiable identity
>>         solutions that aren't distracted by content-type conflicts.
>>
>>         The ultimate beauty of RDF lies in its abstract nature i.e.,
>>         it is fundamentally data representation format agnostic.
>>
>>
>>     RDF does have a lot of baggage.
>
>
>     No, the problems it solve are both complex and *scary* to those
>     who wish said problems were simple.
>
>     You can wish simple solutions for complex problems. That's what
>     Web 2.0 folks have done, and look at how nicely that's played out
>     for the world right now.
>
>
>>     Forcing predicates as URIs, language tags, bnodes, data types,
>>     content negotiation, XML format from 2002, SPARQL, RDF*,
>>     difficulty with arrays, forcing everything to be a Set etc. etc.
>
>
>     I don't understand the point you are making above.
>
>     RDF simply requires the use of IRIs for identifying entities and
>     entity relationship types (relations) . What's wrong with that?
>
>
>>
>>     Where one might see beauty, others might see complexity.  Even as
>>     an abstract format, it is opinionated
>
>
>     It isn't.
>
>     What's opinionated, is all the thinking and money that went into
>     imposing Web 2.0 on the world. That effort is the root of most
>     misconceptions associated with RDF.
>
>
> I would say the main hurdle for developers is that when they create an
> object every attribute MUST be a URI.  That makes for a poor developer
> experience.  That's what I think is opinionated.
>  
>
>
>>      
>>
>>         JSON-LD is good for engaging the so-called "Web Developer"
>>         due to the ubiquity of JSON. That developer-profile dominates
>>         the application development landscape in today's digital world.
>>
>>                                              
>>
>>>         It's too much of a heavy-lift for the average developer and
>>>         they'll choose JSON.  The name RDF is poison to web developers
>>
>>
>>         Correction:
>>
>>         RDF (formaized EAV i.e., EAV plus formalized Identifiers in
>>         the form of IRIs) cannot be poison since Web Developers
>>         generally understand EAV and work with it courtesy of
>>         structured data delivered via JSON docs :)
>>
>>
>>>
>>>         IMHO we need a JSON based version of WebID, perhaps an
>>>         extension of schema.org <http://schema.org>, as a basis to
>>>         create a modern read-write web
>>
>>
>>         You need a Resolvable Identifier (e.g., and HTTP IRI) that
>>         resolves to a variety of documents types. If the target
>>         audience is Web Developers, JSON-LD or pure JSON will suffice
>>         as the default.
>>
>>
>>     Yes, JSON with URis.
>
>
>     But you stated above that URI requirement in abstract RDF was
>     problematic? I can't reconcile both of those thoughts.
>
>
> Again, we're talking about MUST vs SHOULD.  JSON doesnt reqiure you to
> use URIs as predicates, but when you use schema.org
> <http://schema.org> they show you how to do that. 


It isn't about using IRIs as predicates. It is about denoting predicates
using IRIs.

IRIs simply offer an effect denotation mechanism.

JSON-LD solves the predicate denotation issue for JSON-LD developers.

For pure JSON developers, it is solved by relative IRIs generated by
agents operating on the data i.e., they don't have to anything on the
predicate denotation front, if so desired.

Just take a look at how we handle JSON in our Structured Data Sniffer.
We specifically added JSON and CSV support to demonstrate how these
matters are handled. 

Links:

[1]
https://chrome.google.com/webstore/detail/openlink-structured-data/egdaiaihbdoiibopledjahjaihbmjhdj?hl=en
-- for Chromium compliant browsers

[2]
https://addons.mozilla.org/en-US/firefox/addon/openlink-structured-data-sniff/
-- Mozilla

[3]
https://twitter.com/search?q=%40datasniff%20%23JSON&src=typed_query&f=live
-- JSON handling examples

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