- From: Melvin Carvalho <melvincarvalho@gmail.com>
- Date: Fri, 10 Nov 2023 10:24:28 +0100
- To: Sebastian Hellmann <hellmann@informatik.uni-leipzig.de>
- Cc: Kingsley Idehen <kidehen@openlinksw.com>, Nathan Rixham <nathan@webr3.org>, public-webid@w3.org
- Message-ID: <CAKaEYhKxBYzvYSz=TNGLosXXwM62FL8MKNXGXRs_JdGC3ZJRhg@mail.gmail.com>
pá 10. 11. 2023 v 10:16 odesílatel Sebastian Hellmann < hellmann@informatik.uni-leipzig.de> napsal: > Hi all, > > Then to define a subspec (webid-json(-ld)) that can be liberated of the > the requirement for tutle - even if some other subspec like webid-rdf > requires conneg & at least tutle, say in SOLID) > > > What's wrong with establishing the following: > > 1. WebID -- an identifier for unambiguously naming an Agent > > 2. WebID-Profile Document -- a document that describes an Agent named > using a WebID > > 3. WebID-TLS -- an authentication protocol for verifying credentials > expressed in an WebID-Profile Document > > 4. WebID-OpenIDConnect+OAuth -- an authentication protocol for verifying > credentials expressed in an WebID-Profile Document > > That then gels nicely with Solid where the following are loosely coupled: > > 1. Identity -- via an identifier, in the form of a WebID that > unambiguously names an Agent. > > 2. Identification -- via a credentials expressed in profile document that > coalesce around a WebID via an entity relationship graph. > > 3. Authentication -- verification of credentials in a profile document > that coalesce around a WebID. > > 4. Authorization -- access controls tested against a verified WebID > > > I think, we can and should do much more. The main point here is that > mixing '#' and '/' results in much "cooler" URIs. We are already using that > in the Databus: curl -H "Accept: application/ld+json" > "https://databus.dbpedia.org/dbpedia/generic/infobox-properties/2022.03.01/" > <https://databus.dbpedia.org/dbpedia/generic/infobox-properties/2022.03.01/> > for dcat:distribution: > > "distribution": [ > > "https://databus.dbpedia.org/dbpedia/generic/infobox-properties/2022.03.01#infobox-properties_lang=cs.ttl.bzip2" > <https://databus.dbpedia.org/dbpedia/generic/infobox-properties/2022.03.01#infobox-properties_lang=cs.ttl.bzip2> > , > > basically re-routing LD requests to the databus:Version=dcat:Dataset to > get a nice & useful graph without additional requests. > > I was thinking that 'curl -H "Accept: application/ld+json" > https://blogs.microsoft.com/blog/2023/11/02/new-study-validates-the-business-value-and-opportunity-of-ai/' > could also return 200 with content-type application/json+ld as a service to > de-wrap the structured data islands. I would see this as a seamless > mechanisms to allow coexistence of RDF and HTML and all other > representations. > Could develop out something like getj (which is just a proof of concept): https://github.com/spux/getj#readme Demo http://spux.org/getj/test.html There is need of a consistent documentation in this area, clear parsing instructions, what to do with id= in a script tag, possibly how to reference JSON(-LD) from a script tag. Unsure if this is taking on too much for the group right now, as we are thinly spread. But it will be needed one day after WebID-JSON-LD > Mixing hash and slash allows for a "Need another Node?" paradigm and could > potentially solve a lot of Linked Data issues, pitfalls and nuissance: > > - over/underfetching & CBD > > - blank nodes > > - additional metadata > > - annoying redirects and the need to explain 303. We need to drastically > reduce the amount of URIs that we use in Linked Data. > https://dbpedia.org/page/Berlin has a total of 16 URIs with 2 > non-information resources due to http/https and then 7 main formats each > with http/https > > - signatures > > - seamless integration of Linked Data into REST APIs / swagger: > databus.dbpedia.org/{sparql|search|{account}/{group} > <http://databus.dbpedia.org/%7Bsparql%7Csearch%7C%7Baccount%7D/%7Bgroup%7D>) > so there is a huge potential to add a whole metadata layer on top. > > I would be on board with chairing, if we were to start drafting a "cooler" > URIs document, then go downwards into superspecs and then subspecs. > > -- Sebastian > > BTW -- everything I've outlined above has been implemented in our Virtuoso > platform for longer tham I even care to remember these days. > > -- > 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 Friday, 10 November 2023 09:24:48 UTC