A few more added comments... On Feb 7, 2008, at 4:44 PM, David Huynh wrote:
> Note that server-side Backstage uses the URL of the exhibit as well as > the set of data link URLs as the key to cache the triple store. This > is > so that when several users view the same exhibit, only one triple > store > is instantiated (to save space and time). There are technical > challenges > here to address the case where the data at any one of those URLs is > changed after the triple store is instantiated and loaded. Are you using the Sesame "Context" in terms of the key you are referring to above? > There is another technical challenge here: if the server session > expires, all the interactive sessions get thrown away on the server. > The > triple store might even get thrown away if no other user is looking at > the same exhibit. It makes sense then to keep the store in "memory/on disk" separate from the users session so that it can always be available for new users, Longwell is designed this way and simply takes an RDF source and loads it into the triplestore on initialization of the server long before users interact with it. The area that longwell that does initialize when the first user interacts with it are the facets that are calculated across the whole triplestore, held in memory and presented in the start pages. > But you might still have that exhibit shown on your > browser, and it's entirely reasonable to want to resume your > interaction > with it after leaving it alone for a long time. At this point, your UI > action (e.g., clicking in a facet) will cause client-side Backstage to > call server-side Backstage, who has lost all its states about your > interactive session. Server-side Backstage returns a particular error, > which causes client-side Backstage to send over its whole state so > that > server-side Backstage can reinitialize itself and pick up where it has > left off. When I think about our needs at MIT Libraries for Longwell and DSpace, the data will always be local or its source very controlled on the server side. So the above cases would not be requirements for our usage of the application. Though I'm sure such "dynamic loading" might be of strong interest for others in the community. Cheers, Mark _______________________________________________ General mailing list [email protected] http://simile.mit.edu/mailman/listinfo/general
