Re: A New HTTP Request Header for Specifying Task Contexts

Glenn,
All,

Thank you. I didn't know about those caveats with respect to URI's fragment identifiers in HTTP headers.

Brainstorming, other possibilities for discussion do include:

  1.
Using two HTTP request headers. One could be a URL (without a fragment identifier) which refers to a business process model diagram and the other could represent a path through it or a node within it.
  2.
Using a JSON string as the value of an HTTP request header. In this way, one HTTP request header's value could simultaneously reference a diagram, provide a path through it or a node within it, and provide any other useful data or parameters.

Best regards,
Adam

________________________________
From: Glenn Strauss <gs-lists-ietf-http-wg@gluelogic.com>
Sent: Monday, November 25, 2024 2:24 PM
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

On Mon, Nov 25, 2024 at 07:20:33AM +0000, Adam Sobieski wrote:
> 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.

Adam, your example appears to conflict with
https://www.rfc-editor.org/rfc/rfc9110#name-determining-the-target-reso
second paragraph:
"A URI reference is resolved to its absolute form in order to obtain the "target URI". The target URI excludes the reference's fragment component, if any, since fragment identifiers are reserved for client-side processing ([URI], Section 3.5)."

Some servers discard fragment, if present, early in HTTP request
processing.  Fragments have been used in the past in various attacks
to trick or bypass configurable server-side HTTP processing (string
searching and regexes matching).

Expecting fragment to be passed through by proxies or
to server-side applications is not portable.

Cheers, Glenn


> 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://scholar.search.com<https://scholar.search.com/> , [https://shop.search.com<https://shop.search.com/>]https://shop.search.com<https://shop.search.com/> , and [https://recipes.search.com<https://recipes.search.com/>]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