Re: What is a WebID?

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/" 
for dcat:distribution:

"distribution": [
"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.

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