Specify WebID #17
Comments
|
Initially we used the foaf ontology. The agent we meant was The whole point of WebId was to tie it to an authentication procedure: WebID-TLS, which did require the cert ontology, <#> a foaf:Agent;
cert:key <#k> .But that was 14 years ago, and since then, we have the The webid-profile group is looking into what vocabulary to use in the profile document. |
|
If the WebID specification only: And https://github.com/solid/webid-profile will define a (solid compatible?) WebID Profile Document, and what vocab to use to describe People (or Agents) What exactly can any WebID specification, specify?
Something like that? would that not be a one liner definition in the Solid WebID Profile spec? |
|
The WebID spec is a micro spec. :-) |
|
I can't see any specification, would be my overriding point here, all that the spec actually specifies in any implementable way, is that an HTTP URI is a WebID Profile if it dereferences to literally any text/turtle response. |
|
I would tend to agree. "Web Identity and Discovery" just declares Resource aliases, and the rest of the text is informative. It could go away in principle. "WebID Authentication over TLS" is the core spec to me in the WebID suite. It actually contains a novel method. |
The reason the WebID spec was created and separated from the WebID-TLS spec is to reduce the surface of disagreement and to define something that many other specs would have in common. WebID-TLS was never going to be the only way to authenticate. Other methods, such as OpenID, existed at the time (see I am now working on HttpSig and have put up a demo and explanation of how it works here: |
|
Yes but if you would replace "WebID" with simply "URI" in those specs, they would still work? :) I think that's what this issue is about. |
|
It's a bit more. It's a URI that refers to an agent via a description on the HTTP Web. That's why it is important to Solid, as that is an HTTP based protocol. There may well be more things to add to this spec, but I think we should leave that to the the upcoming Solid WG to resolve. solid/solid-wg-charter#40 |
Given the the group has not been able to produce a 1.0 in many years, I think this is the most sensible option. That said, I think the current formulation covers enough ground to be considered a spec, albeit a micro one as per @bblfish 's comment. Quoting from the spec's
|
|
Two observations
It would be much easier if we had 2 chairs. But as @jacoscaz as editor, and I think the whole group is behind him, it may be possible to make a bit of progress, if he has time |
|
For additional context, a few term definitions: A WebID is an HTTP based identifier that unambiguously names an Agent. The only things specified are:
Note: |
A specification must be implementable, an agreement between parties which facilitates interoperability. What you outline above is an abstract idea, it cannot be implemented. |
|
On Sat, 11 Nov 2023 at 07.07, webr3 ***@***.***> wrote:
For additional context, a few term definitions:
A WebID is an HTTP based identifier that unambiguously names an Agent. A
WebID-Profile Document describes an Agent named by a WebID using an Entity
Relationship Graph.
The only things specified are:
1. Use of an HTTP based identifier
2. Entity Relationship Graph
Note: There's no mention of RDF, RDF-Turtle, JSON-LD, JSON, SPARQL, TLS,
OAuth, or any other implementation detail.
A specification must be implementable, an agreement between parties which
facilitates interoperability. What you outline above is an abstract idea,
it cannot be implemented.
+1
—
… Reply to this email directly, view it on GitHub
<#17 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAGPM5W7THO2QDDU2EAMHRLYD4IYTAVCNFSM6AAAAAAZJIYNKCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMBWG4YDQOJZGQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
I provided a definition of terms that do not need to be compromised in the name of implementation. You can write a specification for an HTML-based WebID Profile document comprising and entity relationship graph expressed in a JSON-LD structured data island (a/k/a rich metadata). Nothing about that requires terminology confusion. A WebID is one thing. A Profile Document is another. They shouldn't be conflated, which is my prime concern when providing terminology definitions. As for what can or cannot be implemented, here is a simple example of what I've described that's already being implemented by companies publishing content to the Web. Structured Data Island Excerpt. {
"@context": "https://schema.org",
"@graph": [
{
"@type": "WebPage",
"@id": "https://devblogs.microsoft.com/semantic-kernel/autogen-agents-meet-semantic-kernel/",
"url": "https://devblogs.microsoft.com/semantic-kernel/autogen-agents-meet-semantic-kernel/",
"name": "AutoGen Agents Meet Semantic Kernel | Semantic Kernel",
"isPartOf": {
"@id": "https://devblogs.microsoft.com/semantic-kernel/#website"
},
"primaryImageOfPage": {
"@id": "https://devblogs.microsoft.com/semantic-kernel/autogen-agents-meet-semantic-kernel/#primaryimage"
},
"image": {
"@id": "https://devblogs.microsoft.com/semantic-kernel/autogen-agents-meet-semantic-kernel/#primaryimage"
},
"thumbnailUrl": "https://devblogs.microsoft.com/semantic-kernel/wp-content/uploads/sites/78/2023/11/sk-blog.006.jpeg",
"datePublished": "2023-11-02T22:31:42+00:00",
"dateModified": "2023-11-03T01:24:06+00:00",
"author": {
"@id": "https://devblogs.microsoft.com/semantic-kernel/#/schema/person/5e0c53e0d7c106911583b8455530f366"
},
"breadcrumb": {
"@id": "https://devblogs.microsoft.com/semantic-kernel/autogen-agents-meet-semantic-kernel/#breadcrumb"
},
"inLanguage": "en-US",
"potentialAction": [
{
"@type": "ReadAction",
"target": [
"https://devblogs.microsoft.com/semantic-kernel/autogen-agents-meet-semantic-kernel/"
]
}
]
},
{
"@type": "ImageObject",
"inLanguage": "en-US",
"@id": "https://devblogs.microsoft.com/semantic-kernel/autogen-agents-meet-semantic-kernel/#primaryimage",
"url": "https://devblogs.microsoft.com/semantic-kernel/wp-content/uploads/sites/78/2023/11/sk-blog.006.jpeg",
"contentUrl": "https://devblogs.microsoft.com/semantic-kernel/wp-content/uploads/sites/78/2023/11/sk-blog.006.jpeg",
"width": 1920,
"height": 1080,
"caption": "Image sk blog 006"
},
{
"@type": "BreadcrumbList",
"@id": "https://devblogs.microsoft.com/semantic-kernel/autogen-agents-meet-semantic-kernel/#breadcrumb",
"itemListElement": [
{
"@type": "ListItem",
"position": 1,
"name": "Home",
"item": "https://devblogs.microsoft.com/semantic-kernel/"
},
{
"@type": "ListItem",
"position": 2,
"name": "AutoGen Agents Meet Semantic Kernel"
}
]
},
{
"@type": "WebSite",
"@id": "https://devblogs.microsoft.com/semantic-kernel/#website",
"url": "https://devblogs.microsoft.com/semantic-kernel/",
"name": "Semantic Kernel",
"description": "The latest news from the Semantic Kernel team for developers",
"potentialAction": [
{
"@type": "SearchAction",
"target": {
"@type": "EntryPoint",
"urlTemplate": "https://devblogs.microsoft.com/semantic-kernel/?s={search_term_string}"
},
"query-input": "required name=search_term_string"
}
],
"inLanguage": "en-US"
},
{
"@type": "Person",
"@id": "https://devblogs.microsoft.com/semantic-kernel/#/schema/person/5e0c53e0d7c106911583b8455530f366",
"name": "John Maeda",
"image": {
"@type": "ImageObject",
"inLanguage": "en-US",
"@id": "https://devblogs.microsoft.com/semantic-kernel/#/schema/person/image/",
"url": "https://devblogs.microsoft.com/semantic-kernel/wp-content/uploads/sites/78/2023/02/John-Maeda-96x96.jpg",
"contentUrl": "https://devblogs.microsoft.com/semantic-kernel/wp-content/uploads/sites/78/2023/02/John-Maeda-96x96.jpg",
"caption": "John Maeda"
},
"description": "American technologist and product experience leader. Currently VP of design and artificial intelligence at Microsoft. Author of five books including a gentle intro to AI/ML \"How to Speak Machine (Penguin)\" and the \"Laws of Simplicity (MIT Press).\" Represented in the permanent collections of the Museum of Modern Art, NYC and the Cartier Foundation, Paris.",
"sameAs": [
"https://twitter.com/https://twitter.com/semantic_kernel"
],
"jobTitle": "VP Design & AI",
"url": "https://devblogs.microsoft.com/semantic-kernel/author/johnmaeda/"
}
]
} Chunk that uses WebID exactly how I've describe it. {
"@type": "Person",
"@id": "https://devblogs.microsoft.com/semantic-kernel/#/schema/person/5e0c53e0d7c106911583b8455530f366",
"name": "John Maeda",
"image": {
"@type": "ImageObject",
"inLanguage": "en-US",
"@id": "https://devblogs.microsoft.com/semantic-kernel/#/schema/person/image/",
"url": "https://devblogs.microsoft.com/semantic-kernel/wp-content/uploads/sites/78/2023/02/John-Maeda-96x96.jpg",
"contentUrl": "https://devblogs.microsoft.com/semantic-kernel/wp-content/uploads/sites/78/2023/02/John-Maeda-96x96.jpg",
"caption": "John Maeda"
} |
|
Let me try to understand better. Are some folks proposing that since, for example, there is no requirement for How certain are some folks about not being able to improve unclarity or underspecified parts of the WebID 1.0? Will they also promise not get in the way of those that can demonstrate that the spec can be improved? A few words on quality assurance: "Testing" does not strictly entail automated scripting and verification. In fact, W3C Evaluation and Report Language (EARL) 1.0 Schema, which is one of the key outputs of the W3C QA Activity, provides a set of Test Modes, including: "automatic", "manual", "semiAuto", "undisclosed", "unknownMode". So, conformance in a specification can be written in different ways towards what would qualify as a product to be interoperable. In practise, not every notion or requirement is necessarily tested or applicable or only testable with a single test case. That said, of course being testable strengthens the legitimacy of implementation's conformance through reports. But even then EARL for example acknowledges possible Outcomes Value such as "cantTell", "inapplicable", "untested". Certain notions or intentions of a specification may not be practical to test. Take for example the notion of URI Ownership as per Web Architecture. If the owner of a URI says that it is allocated to represent today's weather, or an agent's profile (document) - and that can be stated in many ways - it does not entail that there must be specific wording/statement in a given representation with a specific testing. If there were to be the case, it would be generally infeasible or impractical to test. That's just an example. When I say https://csarven.ca/#i is my WebID, it is so, first and foremost, because I said so (even just with this sentence). As the URI owner ( one of the intended audience: #29 ), I also have the responsibility to manage its representations. To quote a AWWW principle: "Reference does not imply dereference". So, when the WebID spec defines WebID (the identifier) using an existing URI scheme (HTTP), there are limits to what can be tested. (It certainly does not entail coming up with several specs.) I've shared quite a bit of considerations in #21 (comment) essentially about expressing conformance requirements and interoperable product classes, categories of the specification, and weighing actual complexity / fragmentation of alternatives. If a particular Class, media types, and other things are so desired, I'm all ears about why this can't be done in the current WebID 1.0 ED. If the "title" of the specification has been a show starter or prevented uptake, I'd love to get some data behind those claims as opposed to perceptions. Or any other random thing that's being put forward that somehow justifies a new spec instead of improving the current. Aside: Noting that the title of the specification is "WebID 1.0", and subtitle "Web Identity and Discovery". If it helps to contrast, see "Decentralized Identifiers (DIDs) v1.0" with subtitle "Core architecture, data model, and representations"). If an adjustment to the subtitle is desired, it could be along the lines of DID's. In fact, the DID spec, from the perspective of conformance and scope is not entirely different from the WebID spec. All that said, if folks still want to pursue an alternative one or two or five specs, then go ahead as a new work item ( #31 ) but leave the current work alone. There are existing dependencies and social expectations out there. It would be inappropriate to break them as I see it. There is at least one WG charter that's interested in carrying that particular WebID (or thereabouts) forward in a WG. Reminder to us all that the current WebID 1.0 has a track record of "working" irrespective to the level of pedantry of a handful of people (i.e., us) may express about the spec. There is data behind that claim whereas all alternative proposals... ? |
Yes and no. There were volumes of discussion about many details, mainly centered on which media types should or should not be in the specification (add json-ld, remove turtle, require multiple, require conneg, require none). As per the top of this issue, if you remove the media type (turtle) from the current ED, you are left with precisely nothing, no MUSTs. I position that:
So the notion of a super and sub spec setup, was entirely to "unlock" an unresolvable status and a decade of arguing about media types, whilst allowing a webid specification to at least specify something useful and implementable, and ensuring that different pockets of work (projects using turtle, projects using json-ld, others) could all agree on a superset of constraints (a,b) above. Hence, super and sub. To reiterate:
Only one of those things can be addressed (or so I thought). |
|
Allow me to reiterate that if there isn't one (which would be the lowest barrier for actual interop, i.e., actual products enabling user features) or more (at increasing complexity) media type, there is no strong interop at the end of the day. I've tried to communicate that at least a couple of times in recent memory: #21 (comment) and #3 (comment) . On one end there is the hypothetical interop, and on other the end the real and more complicated. (The current spec is on the easy end but people have opinions..) Yes, it is quite feasible to have a test suite that has all the RDF parsers under the sun, and be able to check whether an implementation can express a particular data model and get a pass with flying colours, but that doesn't actually say anything since in the wild, one particular implementation may only speak Turtle, and another JSON-LD, and yet another something else. No interop. Splitting whatever into several specs makes zero difference at the end of the day because the fundamental / actually useful interop (or not) will remain the same. Majority of the arguments about media types that are being raised AFAICT is essentially within a year. Which is after the fact of the WebID spec, as we know it, based on Turtle, despite with all the "flaws" and staleness, {insert concern}, has some notable update. It using only Turtle as MUST (single requirement that guarantees interop) was sufficient for all sorts of uptake. It is misleading to think that it was a show-stopper. I want to be clear that I'm not arguing for a particular concrete RDF syntax here but the idea that one of them "did the job". But of course that doesn't (and didn't) stop anyone from +1'ing one or two, and -1'ing one or two. That's a common thing to observe in the standards space. That said, not everyone is on board with RDF stuff or even JSON-LD/schema.org in HTML either. If we had a few very vocal people that said the media type should be PDF or EXE, then what? So, of course who shows up here matters but let's not conflate that with anyone speaking on behalf of the developers out there. Evidence is welcome. Do you think that all those developers publishing JSON-LD/schema.org in HTML about persons/agents/orgs or what have you are going to add As for what is a WebID (the identifier), that cuts into core definitions and language gymnastics involving URI ownership. That's relatively the easy part as I see it. Agreeing on the media type(s) is harder, and I agree with you. That said, if there is strong reason to change WebID 1.0, we can do that. If a new set of specifications are desired, call it something else and keep it along the currently adopted specification. Let the market decide? |
How about https://www2.deloitte.com/us/en/profiles/beena-ammanath.html#this approach? You can apply that to a .json or .jsonld document too. A "#" indexical is a powerful solution for these issues.
It didn't need to do that. This is simply a consequence of conflating identity (WebID, and HTTP URI for unambiguous agent naming) and identification (WebID-Profile Doc) with authentication in mind (TLS). Possible solution:
Are 1&2 possible? |
Define the difference between WebID and HTTP URI please |
@webr3 this is a personal and subjective view which is out of place here. Conneg is part of the AWWW: https://www.w3.org/TR/webarch/#frag-coneg |
In prose: Why is this specific use of an HTTP URI required? What are the distinguishing, machine-computable, characteristics of an Agent? |
|
Turtle is a MUST in the Solid version of WebID, and it's anticipated to remain so at least until 2026 (when it goes to 1.0). Barring any unforeseen developments, Turtle's status as a MUST is unlikely to change in ED 2014. That being said, there's room for a JSON-LD version of WebID to coexist alongside the Turtle specification. This approach seems particularly suitable for deployments planned c. 2024. The key is ensuring that both specifications maintain a common framework for defining a WebID. As currently stated:
This definition is a solid starting point, though its breadth might raise questions about whether it's "intentionally vague". Our current approach has been to include various examples in the text. However, this leads us to an important consideration: how to develop a test suite for conformance if the specifications are not explicitly detailed. |
This is a good start, but this doesnt answer the questions:
We need to be able to specify it enough so that a test suite can be written, and these questions can be answered. |
A WebID is a kind of URI.
As I've stated repeatedly, this spec effort isn't going to solve the longstanding problems associated with using HTTP URIs as names. A name is a kind of identifier that comprises both denotation and connotation by way of realm-specific indirection. In the realm provided by the HTTP protocol based Web, that's achieved implicitly by tacking on an "#" indexical on to an HTTP URL or explicitly via 303 redirection. The notion of an HTTP URI as a Name is a matter for AWWW docs and specs (e.g., this one).
That is a vague question that isn't precisely answerable due to the current state of affairs. That said, OpenLink has implementations that will pass any tests based on the current broken spec -- FWIW.
By implementation, as we've done for eons. The fundamental issue here is that the current spec is Turtle and WebID-TLS bound (covertly). Basically, What we are trying to fix right now via PRs or nuclear options. |
|
On Fri, 5 Jan 2024, 15:54 Kingsley Idehen, ***@***.***> wrote:
- Is a URI a WebID?
A WebID is a kind of URI
This is the fundamental difference in understanding.
A URI cannot be classified as a WebID until it's confirmed to unambiguously
refer to an Agent.
It's not a WebID until this has been established.
The unambiguously bit is that it refers to an Agent, not a pipe.
This is what's leading to the mass confusion.
If it's a "kind of uri" as per your understanding, what's the bit that
differs it from other kind of dereferenceable http uris.
Message ID: ***@***.***>
… |
Again, you are discounting the role of natural language rose. The current WebID specification isn't specifically about machine computation. Your point, as I continue to see it, is primarily from the perspective of writing code which works better if we are talking about a machine-computable (or readable) Profile Document rather than one of its components (i.e., a moniker for an HTTP URI used in a specific way).
Why didn't we simply stick with the Linked Data Principles angle? Because the spec was derived from FOAF+SSL, retrospectively. TimBL has already got the "Get Yourself a Personal URI" meme peculating just before FOAF+SSL (which is actually partly based on said meme), and we desperately wanted to negate all the distracting debates swirling around Linked Data and the need (or lack thereof) for content-negotiation etc.. JSON-LD didn't exist then, and when it initially emerged: it did so without support for "#" based relative HTTP URIs. I really don't want to belabor these points, but there's a little more to this problem than meets the eye. You have branding mangled with technical specification etc.. I think we can fix this problem if we put all of these issues into context:
|
Again, disagree, it is a facilitator of things which do require computation, such as auth*. One does not need a specification to say my web page is this and have some agent visit it and determine that it is indeed about them. That, is not something that needs specified. |
Not saying or inferring any such thing. I am saying: Dereference functionality is an affordance inherited from the host operating environment i.e., a HTTP based network. |
But until you dereference and establish it names an Agent, it doesn't name an agent unambiguously. |
It does, when defined as part of a WebID-Profile Document specification. Your sticky point arises when its done outside a WebID-Profile Document specification. 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. The sole purpose what to have a simply moniker that encapsulated what was introduced in this TimBL post. A WebID is an HTTP URI for naming an entity, unambiguously. It inherits its disambiguation prowess by being derived from an HTTP URL which is part of the operating network provided by HTTP. Note, TimBL never said anything about FOAF. He simply outlined the following sequence:
We discussed our way into using "WebID" to replace "Get yourself a URI" long before FOAF+SSL came into being, because the focus was entity naming that provided a conduit to all your existing social-media content. Related
|
We cannot proceed with this conversation until you decide which of those you want to say it is. Cannot be both. |
A passport number is a citizen identifier that names a passport holder unambiguously. Possibly it is an invalid identifier. Only by dereferencing the passport number - i.e. looking up the number in a governmental database and seeing that data for that passport number appears - is it known that the number functionally works. Possibly it is an unacceptable identifier. Only by authenticating the passport number - i.e. comparing the dereferenced data with physical traits of the holder of the passport (and whatever other rules might be imposed - e.g. "disregard if holder presents themself as on a business trip if data lack business information and vice versa") - is it known if the passport is acceptable as proof of the identity of the passport holder. Passport number dereferencing and authentication may also potentially be loosely coupled, in that it is at least theoretically possible for an authentication scheme to not consult the data and therefore not require access to it. Hope that helps. |
Agent! ("entity" gotta be simply a typo) |
|
A WebID is an HTTP URI for naming an Agent, unambiguously. That's my preference, if it helps move matters forward. |
|
Tis an important point here Jonas Passport Number is to Number, as Agent is to Entity, as WebID is to URI. You don't know if a number is a passport number till you confirm it on a passport or db lookup You don't know an Entity is an Agent until you dereference and find that out You don't know a URI is a WebID until you establish that via the previous step, or again some statement in a dB lookup. That is, that it's a URI identifying an Agent, not a pipe. It's a key point, is a number a passport number, is an entity an agent, is a uri a WebID. That's the basic test I position were trying to specify the answer to. Let's ground this in an example, given 3 URIs: how do we establish that one is a WebID, and the other two are not.
Such that this can be determined. (thanks for confirming @kidehen ) |
It is an identifier.
You lookup the passport number (an identifier) via the passport system which is just another network.
The passport number lookup leads you to the credentials in the passport. I use this analogy to once again attempt to orient the spec toward the Passport rather that its Passport Number. Passport Number, as identifiers, are a feature of the Passport Network. "Passport Number" doesn't imply "Cannot be an Identifier" . Finally, you can't find a definition of Passport Number in the Marriam Webster Dictionary, but you will find one for Passport. Naturally, you will find a definition for Identifier -- point here being loose-coupling of related concepts that make up a system. |
|
@kidehen apologies mate, I posted an edit at the same time you posted a new comment! |
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. In machine-readable form, specifically via a WebID Profile Document Specification, you can achieve that objective by qualifying triples from a chosen vocabulary. In relation to the latest Editor's Draft by @jacoscaz, this problem could be solved by fixing the draft spec's title i.e., changing "Web 1.0" to "WebID Identity and Discovery [WebID] 1.0" (where WebID functions as a recursive acronym that can be used to refer to more than one thing). I don't like it per se., but I can live with it. |
Works for me too, also don't like it per se, as I'm not sure what would go in a WebID specification other than perhaps no requirements just a text introduction describing what WebID is (note, WebID as opposed to a WebID) so that it can cover "it's a system" and "it's an identifier". But I can also live with both. Ultimately all I care about is that there's one document with any name that provides a base which allows this test to be passed, as mentioned in #33 (comment)
edit: @kidehen if you 're going to follow with all the http stuff, 303 and #hash goes in the WebID base spec, and only that w/ description, that's golden by me - it'd be like having a base linked data spec outlining good practice. |
|
"Good Practice" or "Suggested Practice" or even "Best Practice" guides all sit well with me too! Things I am wary of:
1&2 ultimately lead to wasting lots of time that people simply don't have i.e., you're darned when you do attempt an implementation and you are equally darned when you don't. |
|
Well now, I do believe that all the elements of this particular set of recipes are already well defined, specified even, so perhaps it's more a case of aggregate, describe, and defer/point to that which is already set in rec. |
|
My suggestion at this point, is simply a title change with regards to the draft put out earlier by @jacoscaz. Alternatively, by way of PR, it should be possible to merge the latest draft with the current spec en route to a solution. I am happy with either approach, as I really want this matter resolved. |
|
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 |
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 |
|
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. |
|
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. |
|
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. |
|
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. |
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. |
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. |
|
Closed by #60. |
I've reduced the WebID specification to it's MUSTs, and swapped two terms to BBB and CCC:
Even if we prefix it with the (loose) definition:
At best, the only specification I can pull from this is:
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
<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.
The text was updated successfully, but these errors were encountered: