- From: Melvin Carvalho <melvincarvalho@gmail.com>
- Date: Mon, 26 Jul 2021 16:38:50 +0200
- To: Kingsley Idehen <kidehen@openlinksw.com>
- Cc: public-rww <public-rww@w3.org>
- Message-ID: <CAKaEYh+TEMOKqbQrneCcpVZG7qapHckyggfGxdFq0zip7BUi+A@mail.gmail.com>
On Mon, 26 Jul 2021 at 16:09, Kingsley Idehen <kidehen@openlinksw.com> wrote: > On 7/26/21 2:39 AM, Melvin Carvalho wrote: > > > > On Mon, 26 Jul 2021 at 03:57, Kingsley Idehen <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, 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 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. > It doesnt solve the issue, it just makes it a bit easier JSON-LD 1.2 may solve it though, but there's no reason to wait for that > 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 > >
Received on Monday, 26 July 2021 14:39:15 UTC