Specify WebID

[webr3]

I've reduced the WebID specification to it's MUSTs, and swapped two terms to BBB and CCC:

A BBB is a Web resource that MUST be available as text/turtle. The server MUST provide a text/turtle representation of the requested BBB. CCC (ambiguous, possibly specification) requires that servers MUST at least be able to provide Turtle representation of BBB The Agent requesting the BBB MUST be able to parse documents in Turtle

Even if we prefix it with the (loose) definition:

A CCC is an HTTP URI which refers to an Agent (Person, Organization, Group, Device, etc.). A description of the CCC can be found in the BBB.

At best, the only specification I can pull from this is:

• A CCC is an HTTP URI which refers to an Agent
• A BBB is a text/turtle representation of the CCC.

Note, Agent is a loosely defined term, not a specific rdf:Type of thing from a specific ontology.

Note, WebID Profile is also loosely defined, to be a text/turtle document, no specific ontology must be used.

Thus, to conform to the current WebID specification, I need to publish a text/turtle document via http, which contains a description using any ontology of a thing which can in some manner be determined to be an Agent of some kind.

Or, a WebID is an HTTP URI which dereferences to a text/turtle document.

So if I publish the following at http://example.org/webid

@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
<> a rdfs:Resource .
<#x> a rdfs:Resource .

<http://example.org/webid#x> is a conforming WebID?

Note, I'm being gracious here, there's no BBB MUST describe CCC, so technically it would appear that only the first triple is required to conform.

[webr3]

Likewise

This comes with the territory, the term lives at two layers, and when we apply separation of concerns, we find it at both levels - I believe at this point we both and all understand well enough, and it seems inescapable that there is a fixed concept, a fixed for unknown period of time base layer at both sides of http, and then some more fluid components.

If we tightly couple the three together there just always will be issues, most of which will be a symptom of time passing, as with json and turtle.

So I guess we are left with a living single entity of a specification, or a good for a decade or so base

[melvincarvalho]

A passport number is a citizen identifier that names a passport holder unambiguously.

I appreciate the effort to draw an analogy here, but I feel it might be leading to some confusion, as it's not quite a like-for-like comparison. Consider this: a passport number scribbled on a napkin loses its context – it could be a passport number or perhaps a phone number. However, a WebID inscribed on that same napkin retains its identity as a WebID, thanks to the inherent universality of URIs.

The beauty of using URIs to name things, unlike mere numbers, is that WebID plays a pivotal role in unifying the social web. A passport number is only valid in the context of the passport it's associated with, and particularly your passport. In contrast, if you place a URI in someone else’s document, it contributes to the fabric of the web rather than causing ambiguity.

Moreover, for a direct comparison with a WebID, the passport itself would need to serve as an identifier. A WebID is remarkable because, even when noted in the most informal manner like on a napkin, it allows us to retrieve the entire identity document. This capability is what sets it apart – it’s not just a number. It’s special because it can reside in any document, weaving a network of identifiers. It's special because of its ability to be dereferenced, revealing not just the identity document but also its place within that document, and crucially confirming its nature as a WebID, denoting an Agent or a Person. This goes beyond a mere conceptual analogy and enters the realm of practical, machine-testable functionality.

Edit: so as not to bloat potential RFCs, I've elaborated on this distinction in this mailing list post

[jonassmedegaard]

Thanks for sharing your view on how much of the WebID+WebID-Profile+WebID-Auth-* trinity lies with the WebID component.

If we choose to not loosely couple the trinity of WebID+WebID-Profile+WebID-Auth-*, then it is reasonable to shift from comparing WebID to a passport. Otherwise it is reasonable to compare WebID to a passport number, and compare WebID+WebID-Profile to a passport.

WebID is link between passport content and authentication of passport content - both of which relating to an agent.

Certainly WebID is not equal to a passport number, because an IRI is richer on information and more stable in interpretation. a closer analogy is "danish passport: 62991411-1" scribbled on a napkin. With only that napkin you can resolve further information by contacting the issuers of danish passports - danish authorities by way of police or embassies - to (maybe, if permitted) retrieve my eye color from them. Analogous with only a WebID you can (if my webserver permits you) retriece my eye color as an RDF graph from the issuer of my WebID - me by way of my website.

The analogy was brought up in a discussion wether we MUST require a WebID to be resolvable as an RDF graph. I argue that a WebID is a WebID if loosely declared that it is - analogous to writing on a napkin not only "62991411-1" but "danish passport: 62991411-1". That statement may turn out to be bogus, but it is not the purpose of a WebID to ensure its own validity as data, only to ensure its own validity as syntax: an IRI structure.

[melvincarvalho]

I respect your perspective, but I must emphasize a pivotal aspect of WebIDs that differentiates them from passport numbers: a WebID inherently denotes an Agent. This isn't just syntactic but a fundamental semantic distinction. It defines the WebID as an active, engaging entity within the web, capable of interaction and not just a static identifier.

Without recognizing a WebID as an Agent, we lose the essence of its role in the semantic web—facilitating a web of trust and interactivity, not merely data reference. Thus, a WebID is intrinsically more than a number; it's a representation of agency and function in the digital ecosystem.

[jonassmedegaard]

I agree that it is more than a number (as in what needs scribbled onto a napkin for comparison).

It seems to me that my position is that a WebID is an URI linking to an agent which is capable of dereferencing agent profile and by various means to authenticate said agent".

It seems to me that your position is that a WebID is an URI linking to an agent which must then dereference agent profile and by various means to authenticate said agent".

I fail to see how keeping a loose relationship fails the ability for the trinity of WebID+WebID-Profile+WebID-auth-* to facilitate a web of trust and interactivity, as in my view for both approaches a WebID is a representation of agency - the difference is (but perhaps this is where my understanding of the words using in this conversation fails short) that with loose coupling the function is not in the WebID but in the combination of WebID with other parts of the trinity.

[melvincarvalho]

Thank you for keeping the dialogue alive and vibrant on this matter.

Let's simplify the equation a bit, in light of Henry's succinct observation that the WebID spec is indeed a "micro spec." This indicates a lean and focused approach, steering us away from the notion of a trinity and more towards a binary or dual structure, with authentication being a separate, orthogonal aspect.

The distinction you're drawing between "capable" and "must" in terms of dereferencing a WebID is intriguing. How do we indeed ascertain if a URI is a WebID? The answer lies in the action of dereferencing it. This is more than a syntactical exercise; it's the gateway to understanding the nature of the URI.

Take, for example, the URI 'https://example.org/alice#me?type=Agent'. Does the query string define it as an Agent? Not necessarily. The true test of its identity and function as an Agent comes from dereferencing this URI. It's in this process that we uncover the real semantics encoded within, not just in the URI's structure but in the interconnected data it leads us to.

This approach underscores the unique strength of WebID. It's not confined within the strict boundaries of syntax; instead, it dynamically interacts with the web's rich tapestry of data. Authentication, while crucial, runs parallel to this. It's a distinct process, ensuring that while a WebID points us to an Agent, the authentication mechanisms validate and secure the interactions with this Agent.

[melvincarvalho]

Once again, you can determine that it names an Agent by saying so informatively in prose -- using natural language. You can put that in a document solely focused on a particular use of an HTTP URI.

Thanks for the suggestion on specifying WebID via natural language. However, reliance on prose alone doesn't meet the need for precision and testability across implementations. Natural language, while useful for clarification, carries inherent ambiguities. Our goal is to ensure WebID's functionality is clearly testable and interoperable, avoiding the pitfalls of misinterpretation that can arise without concrete, testable criteria.

For WebID to serve its purpose effectively across the web, it's crucial that specifications are not just informative but also objectively verifiable. This ensures consistent implementation and interoperability. Let’s focus on integrating testable specifications alongside natural language descriptions to balance clarity with rigor.

[melvincarvalho]

I am telling you this because I know how "WebID" came to be the short for "Personal URI" . I was the one that suggested the play on OpenID to WebID with the sole focus of making the idea more palatable to the general Web User.

Unfortunately, I just can't find the IRC chat logs where that conversation occurred.

For accuracy, it’s important to clarify the origin of 'WebID' within our discussions. The transition from 'FOAF+SSL' to 'WebID' was initiated on the foaf-protocols mailing list in 2008, a suggestion credited to Toby Inkster following the acquisition of the domain foafssl.org by Henry. The change aimed to address the unwieldiness of the term 'FOAF+SSL'. At that time, @kidehen expressed a preference for 'Secure Web Identity (SWI)' or 'Secure Web Identity via FOAF (SWIF)', rather than 'WebID'.

Given this historical preference for SWI/SWIF over 'WebID', claims of suggesting 'WebID' to parallel 'OpenID' for broader appeal appear incongruent with documented discussions. The name 'WebID' ultimately prevailed, as detailed in this discussion.

While using URIs to name things is useful in itself, and that is inherited from awww, as @timbl points out. It's not a WebID until it is an Agent, and this is a vital distinction. Otherwise it's just anyURI, and NOT a WebID.

[jacoscaz]

Closed by #60.