Daniel; I think the best way to conceptualize this is to view SPARQL Update as applying to data stores, just as done in relational stores. CONSTRUCT allows one to return a graph instead of a SELECT result set. Therefore it's a good tool for manipulating triples that reside in memory. But I don't think there is, or should be, a general expectation that the SPARQL Update language should apply to temporary in-memory graphs.
Hence in your use case, I'd suggest using the pipeline with ApplyConstruct and replace=true/false, FilterByConstruct, etc., to manipulate your temporary triples using SPARQL CONSTRUCT. When finished you can insert/delete all by specifying ?s ?p ?o to a PerformUpdate module. This is probably what you have seen in colleagues' work and would constitute best practices when using SPARQLMotion. -- Scott On Dec 9, 3:13 am, Daniel Mekonnen <[email protected]> wrote: > I can only speak to the former and say that using these modules > together was a programming habit that I was allowed to develop when I > did not have to think about graph identifiers. I'm fairly certain > that I've seen the same pattern in the work of colleagues. Any work- > around I believe will require at least two modules. > > My sensibility is that if some modules are going to require graph > identifiers, then other modules that produce anonymous graphs should > offer the option to make those graphs identifiable. Adding an > optional sml:baseURI property to ApplyConstruct, for example, would > appeal to me as a clean resolution. > > The best practice that one could then follow would be to avoid the use > anonymous graphs. > > thank you, > > -Daniel > > On Dec 8, 11:24 pm, Jeremy Carroll <[email protected]> wrote: > > > Daniel, Holger, > > > I am unclear which of the following is true: > > > - Daniel has a use case for the old behavior of PerformUpdate with no > > graph uri when used with an ApplyConstruct, which can no longer be > > addressed as cleanly > > > - Daniel's problem with the clarification in PerformUpdate to have > > precisely one graph URI for the updates is resolved. > > > If the former, what should the contract be? > > My understanding was that we clarified it to fail because it was > > genuinely unclear what a reasonable behavior would be, and any useful > > behavior was essentially accidental. > > > Jeremy > > > >>> * The query template that appears in a PerformUpdate module s > > >>> sml:updateQuery does not contain a GRAPH modifier understandable > > >>> since it cannot be predicted where one is needed. However, a query > > >>> can be filled out without an indicated graph and the syntax is treated > > >>> as valid (no red outline in the query box). An update to the syntax > > >>> checking may be in order here. > > >> You don't need to specify a GRAPH anywhere. It will simply run the WHERE > > >> clause over the input graph of the current module, i.e. the union of its > > >> predecessors in the SM graph. > > > > I mis-spoke here. A graph URI is now required with INSERT and > > > DELETE. That is "DELETE FROM<...> {}" and "INSERT INTO<...> {}" are > > > required syntax when used, "DELETE {}" and "INSERT {}" no longer are, > > > but the form presently accepts it as valid. > > > >>> * Using PerformUpdate I add new triples intohttp://tb-session. When > > >>> viewing the debugger s Input Graph tab, I do not see this graph > > >>> listed. > > >> The debugger only lists the graphs that are input to the current module. > > >> Unless you have done something like sml:ImportCurrentRDF, this will not > > >> be the case. > > > > Once triples are inserted into thehttp://tb-sessiongraphin a given > > > module, doesn't this graph become input for the following module? It > > > is in the following module where I do not see this graph listed. Also > > > the case in the module following an ApplyConstruct, the newly > > > constructed graph does not appear in the list. > > > >>> * A PerformUpdate cannot be used following an ApplyConstruct because > > >>> the URI of the constructed graph is unknown I think even undefined. > > >> The WHERE clause will work fine - as explained above. Just don't specify > > >> a GRAPH and it will work. The recent change was to disallow not > > >> specifying INSERT INTO ... and DELETE FROM ... in sml:PerformUpdate. > > > > Yes, the WHERE clause is fine. To clarify the issue, it is in > > > specifying the constructed graph from ApplyConstruct as the argument > > > in DELETE FROM and INSERT INTO. For example: > > > > ApplyConstruct: > > > CONSTRUCT { > > > ?person test:grandchild ?grandChild . > > > } > > > WHERE { > > > ?person kennedys:child ?child . > > > ?child kennedys:child ?grandChild . > > > } > > > > ...<pipeline>... > > > > PerformUpdate > > > DELETE FROM<???> { > > > ?person test:grandchild ?grandChild . > > > } > > > WHERE { > > > } > > > > Cannot be performed any longer, because the graph URI that the triples > > > were constructed into is itself unknown. > > > > Please correct me if I am mistaken, it seems there is an assumption > > > here that I'm not aware of. > > > > thanks! > > > > -Daniel -- You received this message because you are subscribed to the Google Group "TopBraid Suite Users", the topics of which include TopBraid Composer, TopBraid Live, TopBraid Ensemble, SPARQLMotion and SPIN. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/topbraid-users?hl=en
