Hi Holger, First I want to tell you, we will simplify the resource action. So it will generate all the information products at once and push them to Nexus. Next we will inform the user, the service products have been generated and stored by showing them a page with a link for each product. This is actually way easier to create and bypasses the issues I had questions about. Just so you know.
To answer your questions, yes the SPARQL queries can change independently from the Modify Actions. The intermediate step is, for the end-user to decide which information product they will generate. Depending on the available data and requests from the organisation. But for now I will generate all information products for a specific dataset and look into the issue of product selection in due time. Maybe by then the selection is not needed anymore. About the focusNode, I wanted to use it since it's one of the available variables inside dash:js. Not because it's the "focusNode". The first thing I would do with the focusNode is point it to a resource in a separate graph where I keep track of the state inside the script. Thinking I could access the focusNode (since it's a supported variable inside dash:js) from within the users HTML front-end. But this would make it a really complex feature on your (EDG) side I guess. Anyway I won't use the focusNode for now. Thanks for the replies and support. Have a nice weekend, Cheers, Richard Op donderdag 15 februari 2024 om 14:19:38 UTC+1 schreef Holger Knublauch: > On 14 Feb 2024, at 1:38 pm, 'Richard Nagelmaeker' via TopBraid Suite Users > <topbrai...@googlegroups.com> wrote: > > Hi Holger, > > Yes correct, we want the user to select a query from the SPARQL Library. > The user will do this by clicking a button or using a dropdown list, > whatever is easiest to implement in an HTML Form, within EDG. The more > technical and SPARQL savvy people, will build the queries and add them to > the Library. From a separation of concerns, ease of use and re-using what > is already there, point of view. > What we need is a way for the user to select the query and then for the > script to generate an information product, based on this selection. This > information product then needs to be stored within Nexus and / or send back > to the user. We want to keep the interaction as simple as possible for the > user, keep them away from the inherit complexity of EDG. > > > Thanks for clarifying, Richard. So the SPARQL queries can change > independently from the Modify Actions? Asking because it sounds like the > alternative could be to store the queries as part of the dash:js of the > actions. Why the additional intermediate step? > > > I wondered if we could use the focusNode as a place to keep state, though > this would require the user interaction to change the focusNode. I don't > know if this is at all possible. > > > Right, changing the data itself would be unusual, certainly for Explore > operations. > > Holger > > > > Thank you for the support and the effort you put into it already. It is > well received on this side. I hope this answer clarifies the requirements a > bit. If you have any suggestions, I'm happy to receive them. > > Cheers, > > Richard > > Op woensdag 7 februari 2024 om 15:04:21 UTC+1 schreef Holger Knublauch: > >> dash:Explore/Modify/BatchActions can take parameters that are declared >> using sh:parameter. The other input they receive is the focusNode, i.e. the >> currently selected resource. >> >> This means that the dash:js script may query the values that were >> entered/selected by the user for the parameters. There is, until now, no >> further way to open another page of parameters based on values entered in >> previous steps. I wish we had that capability, but it hasn't bubbled up to >> the top in priority. >> >> In your case, is my understanding correct that you want the user to be >> able to select a query from the SPARQL Library? Off the top of my head I >> cannot think of a way to do that from a sh:Parameter, although these offer >> the same features as other property shapes, including the ability to >> specify a dash:editor. But I think we lack a dash:editor widget that would >> be populated from a SPARQL query (or any other node expression). Maybe your >> use case would be addressed if we had such a widget. >> >> Would you mind clarifying your requirements a bit more based on this? >> >> Thanks, >> Holger >> >> >> On 7 Feb 2024, at 11:01 am, 'Richard Nagelmaeker' via TopBraid Suite >> Users <topbrai...@googlegroups.com> wrote: >> >> Hi, >> >> Using EDG 7.8 is it possible to use Resource or Batch actions in >> combination with user interaction. The user interaction is needed, for the >> user to select the data product they want and receive the resulted product >> on their computer or even better, store the data product in Nexus. >> The data products are the result of a sparql query (stored in SPARQL >> Library) run on a reference data set. A dataset has multiple data products >> associated with it. We want the user to select what data product they want. >> Effectively the user selects the sparql query to generate the data product. >> >> For now we use an ADS Explore action. This uses a graph.select function >> to retrieve the list of queries (from the urn:x-evn-user-data). We could >> show this list to the user (using the graph.html function), but how can we >> receive the users response. The response is the selection of the specific >> data product (= sprawl query) by the user. >> >> Are the Resource (or Batch) actions able to receive user interaction? Or >> do you see another way around this, while still staying within EDG? >> For now we see an external user interface and an ADS API as a possible >> solution. But we prefer to keep things within EDG if possible. >> >> Regards, >> >> Richard >> >> >> -- >> The topics of this mailing list include TopBraid EDG and related >> technologies such as SHACL. >> To post to this group, send email to topbrai...@googlegroups.com >> --- >> You received this message because you are subscribed to the Google Groups >> "TopBraid Suite Users" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to topbraid-user...@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/topbraid-users/f461bbb5-1c72-434a-94a8-6677c94f5cc5n%40googlegroups.com >> >> <https://groups.google.com/d/msgid/topbraid-users/f461bbb5-1c72-434a-94a8-6677c94f5cc5n%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> >> > -- > The topics of this mailing list include TopBraid EDG and related > technologies such as SHACL. > To post to this group, send email to topbrai...@googlegroups.com > --- > You received this message because you are subscribed to the Google Groups > "TopBraid Suite Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to topbraid-user...@googlegroups.com. > > To view this discussion on the web visit > https://groups.google.com/d/msgid/topbraid-users/ab318418-d1e6-464f-aa3e-de004fa0c220n%40googlegroups.com > > <https://groups.google.com/d/msgid/topbraid-users/ab318418-d1e6-464f-aa3e-de004fa0c220n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > > -- The topics of this mailing list include TopBraid EDG and related technologies such as SHACL. To post to this group, send email to topbraid-users@googlegroups.com --- You received this message because you are subscribed to the Google Groups "TopBraid Suite Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to topbraid-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/d9c69be5-d5ce-4a91-a086-7dbbeb476b82n%40googlegroups.com.
