Re: What is a WebID?

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

blank nodes should be minimized, by creating simple non-nested structures


> - additional metadata
>

additional metadata is a plus


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

signatures, yes, henry had a lot to say about this in this final few
issues, and it was great work (which sadly he didnt get to complete)

https://github.com/w3c/vc-data-model/issues/1248

There's a couple of ways of doing sigs, and it can be future work, probably
now is not the time.


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

COOLer URIs sounds good, but these things are notoriously difficult to get
consensus on.  Good to try stuff, and see what sticks.


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