Add explainer for Semantic Web Tools using Well-known Destinations #326
Conversation
There was a problem hiding this comment.
This is a well-structured argument that shows how WKD could assist agentic systems in future.
It also contains some more general primer-style material on agentic AI, and MCP, which echoes work going on around W3C and the world. I think some of the material could find a more appropriate home in other W3C documents (and would like to help to facilitate that).
I'm concerned about the idea of adding any destination values to the WKD spec for machines specifically. By definition, everything we do is for people, and if it helps people, and is semantic, then it'll be easier for machines to reach it, so I don't think there's a conflict here - just that we should focus on the end-user's needs.
Also we have some duplication across this and the main explainer (e.g. alternatives considered, specifically linksets).
So a few actions I suggest:
- I left some comments in the review, and some suggestions to consider.
- We should figure out if the end goal here is to include this, or some of this, into the WKD explainer. Maybe some of it would go in the explainer, and some become part of a primer (here or in another group).
- We should keep in mind all of @abhina-kumar's well-reasoned points here whilst we prototype and seek implementations. But let's focus on the end-user cases, and see where that takes us.
- As you mentioned in the text, we need to figure out some sort of process for adding destinations (technically, anyone can as they'll be
relvalues, but we'd like to at least try to reduce duplication etc.) - Perhaps now/soon is the time to rename WKD to stop it being easily confused with Well-known URIs, which it no longer is.
Thanks very much @abhina-kumar for your work on this, which has made several key points much clearer to me, and I'm sure will to others.
|
|
||
| ### The Brittle Fallback Reality | ||
|
|
||
| When APIs aren't available, AI agents become digital archaeologists, excavating information through: |
There was a problem hiding this comment.
How much of the co-ordination part of an agentic approach (if there's a typical one) would be done heuristically, or 'transparently algorithmically', like this (these seem like steps humans would come up with)? Is the coordination like that, or is what you are saying here more like 'we can observe LLMs using info such as this, because no semantics exist'?
There was a problem hiding this comment.
With new approach - The coordination is primarily LLM-driven using semantic destinations as tools rather than pre-programmed heuristics.
Currently, agents need to rely on HTML, CSS etc. as there are no semantics.
| Well-known Destinations offer an elegant solution to this challenge. Instead of websites needing to build full APIs, they can provide semantic signposts that AI agents can follow reliably. | ||
|
|
||
| **How It Works:** | ||
| Rather than an AI agent hunting for contact information using fragile selectors like `document.querySelector('.contact-page-link')`, it simply looks for the semantic marker: `rel="contact"`. This approach transforms brittle technical navigation into reliable semantic discovery. |
There was a problem hiding this comment.
Again, a question based on my lack of experience, but are we saying here that agents could use the semantics, so they would? Or that we actually have to prod them to doing so, somehow?
If it's more like: 'we expect they'll use this info' - where would that come in the training data? Would it perhaps mean that we'd have to get this pretty widely adopted before agents would start picking it up?
There was a problem hiding this comment.
AI agents use semantic destinations through explicit tool integration, not through any training data. The agents use natural language reasoning to decide when those tools are appropriate for the task at hand, based on the tools description.
| </head> | ||
| ``` | ||
|
|
||
| #### Centralized Linkset Discovery (Well-known Destinations Alternative) |
There was a problem hiding this comment.
I understand the linkset approach is dear to us, and promises to be more efficient, but we aren't including it in the MVP, or '1.0' of the WKD proposal, so it shouldn't be here either.
Our most vital goal right now is to propose a simple approach that people can easily take up. When they do start adopting it, and feel the benefits (including those that would come to semantic/agentic tools), then we could make the case for using linksets.
You may disagree on this - but even if so: we have a section in the 'root' WKD explainer to talk about the alternatives considered (which will talk about linksets). I don't see how discussing linksets is needed in this document, because it already states that it's based on the WKD approach.
There was a problem hiding this comment.
I changed this section to remove content which is already there in WKD explainer.
|
|
||
| #### Future Extensions | ||
|
|
||
| While building on the Well-known Destinations foundation, future extensions could define additional discovery mechanisms specifically optimized for automated tools: |
There was a problem hiding this comment.
We can't use Well-known URIs because of the multi-tenant sites that exist. The Well-known URI corresponds to a domain, but a 'site' can correspond to a subfolder of the content hosted at that domain.
Even setting that aside: would this really be necessary?
If I'm an automated tool, and I want to discover the destinations for a site, I would either:
- Fetch the root page, look in the
<head>for WKD<link>s; OR - Fetch the root page, look in the
<head>for a<link>to the linkset document for the site.
So I think we don't need this anyway.
There was a problem hiding this comment.
- Removed this section
- But this can be alternative to LinkSet
|
|
||
| This would return a standardized JSON format describing available destinations and any additional metadata needed for automated processing. | ||
|
|
||
| ### MCP Server Integration |
There was a problem hiding this comment.
As above, I'm not sure that this content fits in this document - it's very general. It's a good description (and actually I find it helpful) but this document is about WDK and agentic AI specifically.
I am trying to think if there are other places where we could publish this content, because it could be of help. I wonder if it could be an appendix in the document RQTF is working on about AI and accessibility, as a sort of primer for agentic AI and (in this case) MCP.
There was a problem hiding this comment.
I moved most of MCP related thing to Appendix section of this document.
|
|
||
| This division ensures that the intelligent processing of unstructured web content is handled by LLMs, which can adapt to different page layouts, content types, and extraction requirements. Protocol issues like rate limiting, authentication failures, or access restrictions are reported to the LLM, which decides how to respond (retry, use alternative destinations, request human intervention, etc.). | ||
|
|
||
| ## Extended Destination Types for AI Tools |
There was a problem hiding this comment.
I was wondering about the motivation for a separate document, and if there might be specific destinations that might be proposed to assist agents.
I think this document sets out some great justification for how WKD could be of help to agents, as people.
However, I do not think it's appropriate to add stuff to the platform just for machines to process. It's actually the case with both of the ones you proposed so far that they could help people, but my position would be that any destination must benefit people first (and then by extension, it would benefit their user agent - including AI-infused user agents).
We don't have a search destination proposed (though there is the search role but if there is a dedicated search page on the site, perhaps it might be useful to expose it.
There was a problem hiding this comment.
IMO agents are another way via which users can interact. We can discuss this during the call.
|
|
||
| This division ensures that the intelligent processing of unstructured web content is handled by LLMs, which can adapt to different page layouts, content types, and extraction requirements. Protocol issues like rate limiting, authentication failures, or access restrictions are reported to the LLM, which decides how to respond (retry, use alternative destinations, request human intervention, etc.). | ||
|
|
||
| ## Extended Destination Types for AI Tools |
There was a problem hiding this comment.
Also I had another thought that popped up a few times, but I couldn't find the right place for it: would you say that ARIA landmark roles (especially like main, via the <main> element) be helpful for agents to find which parts of the page they should be considering?
There was a problem hiding this comment.
This is nice point. While, Well-known Destinations solve the inter-page navigation problem. ARIA landmarks can solve the intra-page navigation - once on a page, finding the right content sections semantically (main content, navigation, complementary info).
There can be tools like:
discoverLandmarks
fetchContentFromLandmark
Should I enhance this document to capture it? Let's discuss about it in call.
Co-authored-by: Matthew Tylee Atkinson <[email protected]>
Co-authored-by: Matthew Tylee Atkinson <[email protected]>
…ainer for improved clarity and accessibility focus
The idea of the agent is also to help users. So directly/indirectly these destinations will help end-users. |
This PR adds the explainer document titled "Semantic Web Tools for Agentic AI Using Well-known Destinations". The document outlines how Semantic Web Tools can leverage the Well-known Destinations proposal to enable reliable and standardized website navigation for agentic AI systems. It addresses the limitations of API dependency and brittle scraping techniques, proposing a semantic approach for content discovery and navigation.
Preview Link:
View the explainer