Re: What is a WebID?

On 11/9/23 8:26 PM, Sebastian Hellmann wrote:
> 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.


Yes, make URIs for URLs by just tacking on a "#".


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


We SHOULD encourage the use of HTTPS, but not force it on users. Most 
WebID's generated by way of SSEO are HTTPS based anyway, since Google 
has signaled their HTTPS preference to the SEO community etc..

Today, only older WebIDs are HTTP based.


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


"#" usage is just an option, that carries low costs that's all. 
Fundamentally, its "#" is you want to leverage resolution by way of 
implicit indirection of "/" if you want to use explicit indirection via 
content negotiation. Disambiguation is always the core objective.


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


It is so much easier to speak about these matters in terms of entities 
and entity description documents. Entities are uniquely identifiable 
things that comprise perceived structured represented in 
machine-computable form using an entity relationship graph.

These fundamental concepts date back to the beginning of computing i.e., 
we can't compute without this kind of baseline clarity.

If name something using a "#" based HTTP URI the denotation->connotation 
indirection just happens without any work. If circumstances lead to 
using "/" then content negotiation is part of the cost inherited re 
denotation->connotation indirection. There are no ways around these 
fundamental matters -- when it comes to the matter of unambiguous entity 
naming.

Another analogy I used to use years ago is as follows:

The projector provides a surface for perceiving what's projected. If 
that distinction doesn't exist, how to do we perceive anything bar the 
projector itself?


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


You can have a collection of documents comprising entities named using 
indefinite pronouns (blank nodes), but the onus of disambiguation is 
then pushed to apps, thereby handing everything off to silo vectors etc..


TimBL though a lot of this through eons ago, but getting it through en 
masse has clearly been a big challenge.


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


That's a great point! The challenge is getting the right audience to 
understand the story being told. In my experience, I've found that the 
story and the audience are typically out of sync. For instance, 
developers just want to parse stuff and implement algorithms, while 
architects, on the other hand, typically think more conceptually, 
lending themselves to matters of abstraction.

Kingsley

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

-- 
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 13:33:43 UTC