Mark Diggory wrote: > 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? > No, there are several separate triple stores, each instantiated and loaded on demand (whenever a user views an exhibit that no other users are currently viewing).
>> 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. > The first user to view a particular backstaged exhibit will suffer all that initial cost. Subsequent users will benefit from it. Facets found in exhibits can actually be a lot more complicated than facets in Longwell instances. In Longwell, a facet can only be defined by a property (an RDF predicate). In Exhibit, it can be defined by an Exhibit expression. >> 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. > Right. I think what you care about is the ability to customize the site using just HTML rather than hacking Velocity templates, JSP pages, etc. Note that a single DSpace instance might still have sub-communities who want to customize their own front pages, or even users who want different pages for certain sub-collections. RDF lets users afford flexible data models, and Exhibit style of UI configuration lets users afford flexible UIs. Or even better, a user might want to combine some DSpace data with her own data (stored on her web site)... David _______________________________________________ General mailing list [email protected] http://simile.mit.edu/mailman/listinfo/general
