New URIs from GraphQL Create operations

70 views
Skip to first unread message

Matt Goldberg

unread,
Apr 5, 2022, 12:36:08 PM4/5/22
to TopBraid Suite Users
Hello-

I've been working with the GraphQL API to programmatically create and modify resources. If I create a new resource and do not provide a URI, I expected that the generated identifier would be a URI created using the Asset Collection's configured URI Construction Rules in the Manage tab. However, it created a blank node instead. I couldn't find a way in the documentation to have it use the URI Construction Rules instead. Is that an option somewhere, or must the caller be responsible for generating a URI if a blank node is not desired? 

Thanks! 

Holger Knublauch

unread,
Apr 5, 2022, 7:13:50 PM4/5/22
to topbrai...@googlegroups.com

Hello Matt,

correct, this isn't supported at the moment, and you're right it should work in principle. I have recorded an internal development ticket (TBS-4783) for a future version.

Meanwhile, if that's an option, you could use JavaScript/ADS scripting for similar purposes, with a similar syntax. ADS includes a function graph.newURI(type) that will look at the URI construction rules.

let uri = graph.newURI(g.City);
let newCity = g.createCity({
    uri: uri,
    prefLabel: 'Hagen',
    altLabel: 'Das Tor zum Sauerland'
})

The advantage here over GraphQL is that you can actually DO something with the generated URIs because you can assign them to variables and use those variables in other places, e.g. to define further references:

someCountry.capital = newCity;

GraphQL would be a bit of a one-way-street where you can create instances but then would need to make additional queries to process the newly generated instances. In the case of auto-generated URIs you wouldn't even know what those generated URIs are.

Holger

--
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/a6e70516-dc62-4f82-9d12-b2fca1d97b55n%40googlegroups.com.

Matt Goldberg

unread,
Apr 5, 2022, 7:37:10 PM4/5/22
to TopBraid Suite Users

Agreed, ADS is more flexible. But for simple things it's convenient to be able to go through GraphQL since it's less work, especially since it is hooked into SHACL validation and the Teamwork change history. 

I'll either use ADS or generate URIs externally in the meantime.

Thanks! 

Holger Knublauch

unread,
Apr 5, 2022, 7:45:59 PM4/5/22
to topbrai...@googlegroups.com


On 2022-04-06 9:37 am, Matt Goldberg wrote:

Agreed, ADS is more flexible. But for simple things it's convenient to be able to go through GraphQL since it's less work, especially since it is hooked into SHACL validation and the Teamwork change history.

FYI ADS is also using SHACL validation and the change history. That's how the Preview button on the Script Editor panel is implemented.

Holger


Matt Goldberg

unread,
Apr 5, 2022, 8:01:56 PM4/5/22
to topbrai...@googlegroups.com
Interesting, I must have missed that in the documentation. I'll play around with that. Thanks! 

You received this message because you are subscribed to a topic in the Google Groups "TopBraid Suite Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/topbraid-users/7Pg-GGGcmR0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to topbraid-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/6046cf2d-0986-ea9f-bd6f-ab2d74b8fb12%40topquadrant.com.

Matt Goldberg

unread,
Apr 14, 2022, 2:39:01 PM4/14/22
to TopBraid Suite Users
I've been playing around with both options.

In GraphQL mutations, there's a "strict" argument to not perform the commit if there is a warning or above. Is there a way to make that the default behavior so one doesn't have to rely on someone remembering to set it to true? 

Thanks.

Holger Knublauch

unread,
Apr 14, 2022, 5:32:10 PM4/14/22
to topbrai...@googlegroups.com

No, there is no such global setting. strict needs to be repeated.

Holger

Matt Goldberg

unread,
May 9, 2022, 8:49:45 AM5/9/22
to TopBraid Suite Users
A couple follow up questions on this:
  1. If I wanted to customize the message added to the change associated with running a script, is the easiest way to use graph.transaction? 
  2. What is the easiest way to validate that any changes produced by running a script do not violate any SHACL constraints before actually making the changes, like how strict=true prevents GraphQL changes if there are issues? 
Thanks! 

Holger Knublauch

unread,
May 9, 2022, 10:47:30 PM5/9/22
to topbrai...@googlegroups.com


On 2022-05-09 10:49 pm, Matt Goldberg wrote:
A couple follow up questions on this:
  1. If I wanted to customize the message added to the change associated with running a script, is the easiest way to use graph.transaction?
Yes, it's the only clean way. A script can also make multiple changes to different graphs, and thus produce multiple log messages.

  1. What is the easiest way to validate that any changes produced by running a script do not violate any SHACL constraints before actually making the changes, like how strict=true prevents GraphQL changes if there are issues?

See the documentation of graph.transaction:

    /**
     * Temporarily switches the active data graph to a given named graph and executes a function with that active graph.
     * The new graph will also become the default graph of SPARQL queries.
     * After the function has been executed, the previously active data graph will become active again.
     * The result of the transaction call is the result of its callback.
     * Assuming the script is not executed in read-only mode, the inner graph is writable.
     * The system will activate a "diff graph" that collects all changes, and features such as graph.changes can be used.
     * At the end of the transaction, the changes will be committed, unless no changes have been made.
     * Use graph.changes.rollBack() at the end of a transaction in case you want to make sure that no changes will be committed.
     * @param {string|NamedNode} graphURI - the URI of the named graph that the transaction should be applied to
     * @param {?string} logMessage - a log message for the change history, or null for an automatically generated message
     * @param {function} callback - a function (that has no parameters) that will be called (immediately)
     * @returns {?*} the result of the callback
     */

In particular you can use graph.changes.rollBack():

You can call graph.changes.rollBack() based on the outcome of tbs.validate()

let results = tbs.validate()
if(results.length > 0) {
    graph.changes.rollBack()
}

HTH
Holger


Matt Goldberg

unread,
May 9, 2022, 10:49:14 PM5/9/22
to topbrai...@googlegroups.com
That's perfect, thanks! 

You received this message because you are subscribed to a topic in the Google Groups "TopBraid Suite Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/topbraid-users/7Pg-GGGcmR0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to topbraid-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/120e74bc-32e3-67bb-5dae-4508966adb98%40topquadrant.com.
SAX9SZ5QDg93F3Fl.png
Reply all
Reply to author
Forward
0 new messages