Re: A New HTTP Request Header for Specifying Task Contexts

Martin,
All,

A server providing a context-aware service could recognize a received URL, "https://en.wikiprocess.org/wiki/conducting-scholarly-research.bpmn#searching-for-papers" , e.g., from a lookup table, or, instead, retrieve the URL-addressed resource, in this case a BPMN diagram, "https://en.wikiprocess.org/wiki/conducting-scholarly-research.bpmn" , and utilize the URL's fragment identifier, "#searching-for-papers", to inspect the users' precise position or step in the modelled process.

To your first question, a server could query business process model diagrams in a number of ways, perhaps using knowledge-graph representations (see also: [1]), perhaps using foundation models or generative AI (e.g., [2]). One could also explore obtaining embedding vectors for users' precise positions or steps in modelled business processes [3][4] to use in a variety of ways.

To your second question, considering the search engine use case, a search engine might return different varieties of results to users' queries depending upon whether they were conducting research, shopping, or looking for recipes. If I understand your question correctly, then, yes, there could be: https://scholar.search.com<https://scholar.search.com/> , https://shop.search.com<https://shop.search.com/> , and https://recipes.search.com<https://recipes.search.com/> , providing different varieties of search results for different client states or contexts. One advantage of the proposed approach would be that service endpoints, e.g., https://www.search.com , could serve context-aware results in an extensible and open-ended manner.


Best regards,
Adam

[1] https://www.irit.fr/recherches/MELODI/ontologies/BBO/index-en.html

[2] Dolha, Damaris Naomi, and Robert Andrei Buchmann. "Generative AI for BPMN Process Analysis: Experiments with Multi-modal Process Representations." In International Conference on Business Informatics Research, pp. 19-35. Cham: Springer Nature Switzerland, 2024.

[3] De Koninck, Pieter, Seppe vanden Broucke, and Jochen De Weerdt. "act2vec, trace2vec, log2vec, and model2vec: Representation Learning for Business Processes." In Business Process Management: 16th International Conference, BPM 2018, Sydney, NSW, Australia, September 9–14, 2018, Proceedings 16, pp. 305-321. Springer International Publishing, 2018.

[4] Neubauer, Thais Rodrigues, Jari Peeperkorn, Sarajane Marques Peres, Jochen De Weerdt, and Marcelo Fantinato. "Vector Representation for Business Process: Graph Embedding for Domain Knowledge Integration." In 2023 International Conference on Machine Learning and Applications (ICMLA), pp. 588-594. IEEE, 2023.

---------------------------

What would a server do in response to this?

How would this differ from having a different resource for each stage of a process?  That is, if the client has different state, why can it not request a different resource according to a map (state -> resource).

On Sat, Nov 23, 2024, at 14:30, Adam Sobieski 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