- From: Sebastian Hellmann <hellmann@informatik.uni-leipzig.de>
- Date: Fri, 10 Nov 2023 02:26:03 +0100
- To: Kingsley Idehen <kidehen@openlinksw.com>, public-webid@w3.org
Ok, I think, this would be a good way ahead and it seems to be compatible with publishing Linked Data more in a REST like manner. It also could potentially remove the awkwardness of formats, content negotiation, the # vs / and also CBD and the necessity to aggregate small graphs with '/' uris . It might have a lot of potential to simplify LD as a whole. The main trick here is to use any URL, then make it so that you can retrieve graph data (embedded or standalone), then add # to disambiguate entities within that graph. I have amendments: 1. we really should go for HTTPS URLs here. We can add a note that HTTP URIs are the more general case, however, these are not meant here in a goal-oriented manner. Ultimately, we can not securely authenticate a WebID using HTTP, plus I can not think of a case where it would be useful to have a URI that is not an URL. 2. I wouldn't be strict about the # and the Agent (for legacy reasons, i.e. LD published as '/'). I think, it can be either: a) example.org/agent5 a Agent . example.org/agent5#doc a ProfileDoc b) example.org/agent5#agent a Agent . example.org/agent5 a ProfileDoc c) example.org/agent5#agent a Agent . example.org/agent5#doc a ProfileDoc b and c would be clearer. 3. Non-information resources can resolve directly with 200 using # entities. This would integrate well in REST APIs. I can see cases where you would want 303., so it should be acceptable to do content negotiation. 4. I am getting more an more skeptical about the "URI as names for things". Was this really the best way of realizing the GGG? Would it make a significant difference to say that "URLs as a tool to retrieve graph nodes and graphs that describe entities"? It would be more in line with the Web, that also delivers docs about entities. Semantically, most people think about data retrieval first and then interpret them as entities later. 5. Using https://www.openlinksw.com/data/pdf/Semantic_Web_and_LLM-based_Chat_Bot_Symbiosis.pdf#page=26 it would be possible to make a CSV/TSV subset spec. 6. Might be good to suggest some default strings to use after # , just as a no-brainer suggestion for implementation, so people don't struggle choosing between #me, #i, #this, etc. #organisation, #person, #agent, #website. -- Sebastian On 11/9/23 19:25, Kingsley Idehen wrote: > > On 11/9/23 10:47 AM, Sebastian Hellmann wrote: >> Hi Kingsley, >> >> do we actually still need to think in terms of documents. What if we >> removed the documents from the equation? URIs denote entities. > > > Exactly! > > URIs denote entities, and if you use an HTTP URI to denote an entity > it becomes a name. > > There's a subtly that's often overlooked across the the following > terms that's generally overlooked: > > 1. Denote -- act of denotation (signification) using a sign > > 2. Connote -- act of connotation i.e, descriptive representation > > 3. Name -- denotation -> connotation by way of indirection (however > that's achieved in a given medium) > > In the hypermedia medium of the Web, an HTTP URI is a powerful naming > mechanism that only costs tacking on a "#" fragment identifier to a URL. > > >> When you resolve them you should get a representation of the >> requested partition/entity. What does the detour over the >> document/URL/address actually add? Provenance could be added to the >> delivered representation. Versioning info is mostly not existent. >> >> I see the necessity for the WWW, but not for the GGG. > > > The magic of "#" extends to Giant Global Entity relationship Graph > comprising entities, entity types, and entity relationship types. > > Adding "#" to a URL costs zilch, while unleashing immense benefits. > > BTW -- the big boys have already figured this out and are already > using it when publishing structured data islands (enhanced metadata) > in their HTML docs, despite being motivated by SSEO and the E-A-T it > facilitates. > > Examples of docs comprising WebIDs constructed using "#" based > fragment identifier: > > 1. > https://blogs.microsoft.com/blog/2023/11/02/new-study-validates-the-business-value-and-opportunity-of-ai/ > > 2. > https://www.apple.com/newsroom/2023/11/new-iphone-photography-exhibition-debuts-in-paris-on-november-10/ > > In addition, it is important to note that "#" usage goes hand-in-hand > with relative URLs which are now an integral part of JSON-LD 1.1. > > A WebID as an HTTP URI that names Agents is something that's already > happening en masse. > > All that's left is authentication usage i.e., beyond WebID-TLS which > is already happening to e.g., Solid (via solid-auth library for JS) > which offers WebID+OpenIDConnect+OAuth implementation which we've long > supported in our products. > > Kingsley > > >> >> -- Sebastian >> >> On 11/9/23 15:16, Kingsley Idehen wrote: >>> >>> On 11/9/23 8:57 AM, Melvin Carvalho wrote: >>>> FWIW: when we defined WebID at TPAC, TimBL explicitly said no 303s. >>> >>> Because he knows what he is talking about, since he designed the >>> components that lead to the World Wide Web. >>> >>> An HTTP URI that names an Agent unambiguously simply needs a "#" >>> tacked on to it. >>> >>> You make the URI (pointer) from the Profile Doc URL (address). >>> >>> As I keep on trying to explain to you, right now the Web is full of >>> WebIDs that resolve to WebID-Profile documents using this importance >>> piece of Web magic. >>> >>> The whole thing "just works" and it's happening without or without a >>> WebID spec from anyone. >>> >>> ChatGPT and similar tools already understand this stuff too, so whom >>> exactly is some alternative spec going to bring on board? >>> >
Received on Friday, 10 November 2023 01:26:17 UTC