Re: A New HTTP Request Header for Specifying Task Contexts

Ryan,

Hello. As considered, these context data could come from clients.

To answer your question, we can consider a thought experiment where users have software applications, "task management" applications, which would load and display diagrams for tasks (e.g., BPMN). These task diagrams would each have starting nodes and users would be able to click upon, or otherwise select, the components in these diagrams as they progressed through the visually depicted tasks.

Further, these "task management" applications might have multiple tabs, each tab displaying its own task diagram, to support multitasking scenarios.

Next, we can consider that users would soon want their AI assistants to be able to handle the chore of interacting with these "task management" applications so that the users could focus their attentions entirely on completing their tasks using their other software tools. Users might want their AI assistants to be able to manually or automatically load task models (e.g., BPMN) and to be able to mark progressions through these tasks using combinations of natural-language dialogue and observations of users’ interactions with their other software tools.

It is presently theoretical that AI assistants could interoperate with the envisioned "task management" applications (which are, today, a thought experiment) or otherwise interoperate with business process models in all of these ways simultaneously. These ideas occurred recently while researching the fast-developing intersection of AI and business processes using Google Scholar.

In summary, as envisioned, client-side context data could be obtained from users manually making use of interoperable "task management” applications, today, and AI assistants could be increasingly useful with respect to context management, into the future.


Best regards,
Adam

________________________________
From: Ryan Hamilton <rch@google.com>
Sent: Saturday, November 23, 2024 1:38 AM
To: Adam Sobieski <adamsobieski@hotmail.com>
Cc: ietf-http-wg@w3.org <ietf-http-wg@w3.org>
Subject: Re: A New HTTP Request Header for Specifying Task Contexts

How does the user-agent know what value to send in this Context field? Is this a value provided by the server previously? If so, I wonder if it would be simpler for the server to just use a cookie to convey this information. If it's not a value previously provided by the server, it would be good to explain where this comes from.

On Fri, Nov 22, 2024 at 7:34 PM Adam Sobieski <adamsobieski@hotmail.com<mailto:adamsobieski@hotmail.com>> wrote:
IETF HTTP Working Group,

Hello. I recently thought of and would like to share with the group some ideas involving a new HTTP request header, "Context", for providing users’ task contexts to trusted context-aware services, e.g., search engines, Q&A systems, recommender systems, and AI assistants.

As far as I know, it is a new idea to represent task contexts using URLs. In these regards, URLs could refer to business process model diagrams (which task that a user was doing):

https://en.wikiprocess.org/wiki/process12345678.bpmn


and URLs’ fragment identifiers could refer to components in those diagrams (where a user was in that task):

https://en.wikiprocess.org/wiki/process12345678.bpmn#component


Next, these ideas involve using a new HTTP request header, "Context", in a manner resembling:

Context: https://en.wikiprocess.org/wiki/process12345678.bpmn#component


to share URLs both representing and referring to users’ task contexts with trusted context-aware services.

I recently wrote about these ideas in greater detail in a new GitHub issue: https://github.com/WICG/proposals/issues/188 . I would like to invite anyone interested in commenting upon, discussing, and improving upon these ideas to reply either in this mailing list or, preferably, in that GitHub issue.

Thank you for reading and considering these ideas. I am looking forward to discussing them with you.


Best regards,
Adam Sobieski
http://www.phoster.com