On Feb 8, 2008, at 2:03 PM, David Huynh wrote: > Mark Diggory wrote: >> A few more added comments... >> >> On Feb 7, 2008, at 4:44 PM, David Huynh wrote: >>> ... >>> 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).
Certainly a valid approach that works as long as you have very separate "exhibits", In our case we want to provide a shared search/ discovery space across all our collections so it sounds like we would want a system that used one triple-store so that queries could be run across data coming from all collections, this is what Longwell is currently giving us. Based on your comments to Neil and on comments Stefano and others have made about maybe refactoring Longwell into a "Service" and separate "Clients". I'd say the important use-case for those of us who are already running java enterprise / web-applications is that we would like to have flexibility and configurability on the server side as much as possible. To be able to combine data-sets in one server and deliver multiple client configurations on that combined data. I.E. that managing the data and delivering a User experience on that are activities performed by separate but overlapping roles. > 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. That would be a very powerful capability and one I wish was present in Longwell, It would not only allow us greater control the inclusion of fields into a facet (and thus possibly improved performance) but also would allow us to make conditional decisions about the inclusion of a value based on the state of of items that have > one degree of separation. To me this means less need to "shape" or "dumb down" the RDF going into the Longwell triple-store so that is renders in facets appropriately. >>> ... >> >> 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. I hope you can glean from what I've said above, that what we are working to accomplish is much more than theme and branding HTML/CSS, we are actually trying to give the user greater ability to explore a metadata space that is managed by more than one role... For instance, with the following roles on a Digital Object (Admin, Manager, Submitter and Viewer) We may have one "Item" with statements made by the different users in those different roles, I.E. Users or Submitters may make a "Comment" about the "Item", while Managers and Admin would be able to change the "Item" more directly. And even then, we might retain a "History" of those changes that did happen to the "Item". After all these roles are creating statements in their various domains. We then need a expose the whole space in a way that can be both explored by both user choice and also have controlled access by users rights in the system. > 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)... Sure to allow more adventurous users to create their own exhibits. we might expose our backstage as a service that their externally maintained exhibit can connect to. But that well outside our current roadmap. This is mostly just an exercise, our current push for a production prototype is Longwell focused. But its good to explore this other option and see if it may inform our final solution. Anyways, Backstage looks like a great tool with a promising future. Cheers, Mark _______________________________________________ General mailing list [email protected] http://simile.mit.edu/mailman/listinfo/general
