Hi Joe, (with thanks for sending me your files off-list). The approach in general might be fine, but it seems like a database would be a better choice. Your scripts are opening and writing the files each time, and this has performance problems, and may also have issues if you have multiple servlet requests calling the same script (on the latter topic I am not sure how single-write databases such as TDB would handle concurrent SM writes).
Regarding the namespace issue, I think Scott has hit the nail on its head, and your UPDATE query was using the default namespace, which can lead to confusion between the script's model and the data model that you are loading. *Default namespaces are harmful anyway* and should be avoided in every use case, independent of SM scripts. Holger On Oct 22, 2009, at 8:54 AM, Joseph Shea wrote: > > I am not as worried about the namespace issues as I am with the > soundness of the methodology that I am using to set this in memory > model up. The "ModifyPrefixes" module seems to have solved my null > pointer error. > > On Oct 22, 11:01 am, Scott Henninger <[email protected]> > wrote: >> Joseph; Keep in mind that there are two things at work here. The >> script model and the model the script is manipulating (let's call it >> the result model). The existence of prefix definitions in the script >> model does not mean the prefixes are defined in the result model. >> >> It's hard to say without looking at the script, but I think the >> problems could be resolved by adding a ModifyPrefixes module that >> defines the prefixes for the result model. >> >> -- Scott >> >> On Oct 22, 9:48 am, Joseph Shea <[email protected]> wrote: >> >> >> >>> Hello all. I am trying to write a web service that will take in >>> parameters, construct triples, update the in memory model, and >>> save to >>> a file. For reference, I am using TBC 3.1 and TBL 3.1. >> >>> In reality, I want a user to be able to submit data through a web >>> service and have it persist. Since I am using an in memory model and >>> would like to have this actually used by people through a front end >>> interface, it is not possible to reload the workspace every time new >>> triples are added. I am currently using the following approach: >> >>> Step one: Take in parameters + importRDFFromWorkspace >> >>> Step two: PerformUpdate (constructs new triples, adds to in memory >>> model) >> >>> Step three: ExportToRDFFile (saves the current model in case it >>> needs >>> to be restored) >> >>> I am running into several problems. First, there are namespace >>> issues >>> that I am running into. I will have the file lose the default >>> namespace and receive a j.0 namespace. Beyond that, I am also >>> receiving null pointer errors when trying to write some SM scripts >>> (which is a result of null namespaces, which Holger had said to >>> me). I >>> use prefixes in the PerformUpdate, since other files are referenced. >>> The namespaces are instantiated before the query in the UpdateQuery >>> field, as follows. >> >>> PREFIX ES:<http://www.test.com/ES#> >> >>> I am not sure if I am taking the incorrect approach to this problem, >>> or am doing something wrong that will not let me proceed. >> >>> Joseph Shea- Hide quoted text - >> >> - Show quoted text - > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TopBraid Composer Users" group. 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-composer-users?hl=en -~----------~----~----~----~------~----~------~--~---
