On Feb 12, 2008, at 7:43 AM, David Huynh wrote:
Mark Diggory wrote:
[snip]
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.
I hear you :) And I think "server-side" is where Stefano and Ryan
have a
lot more experience than I do. I'm more focused on integration on the
client side, which is perhaps less mature than integration on the
server
side.
What I like about the Backstage implementation at this point, is how
light it is, its not to hard to follow the code and see how the
expressions and database are being handled. Webapplications don't
"need" to be heavy and should be focused on that integration layer,
optimization and configurability can come later (and ideally based on
feedback from those trying to actually maintain the tool in production).
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.
Yup, it goes along with my little silly slogan
your data, your mess, your business
meaning that however you model your data, we can make our tools
adapt to
your data model. That's easier said than done. Exhibit does pretty
well
on that front since we're not trying to scale. But it's not the same
story for Longwell (and Backstage).
What's your plan?
I actually think in the long run, it makes for a cleaner
implementation to have clear delineation's between the integration
your referring to above and the more mundane and standard management
of resources on the backend.
In trying to productionize Longwell for [EMAIL PROTECTED], I've learned It
would be benficial to be able to run Sesame as a middle-tier service
rather than in the web-application instance.
So, I'd make some recommendations to work on keeping the CRUD
functionality separate from the type of Repository being accessed so
that HttpRepositories or in process MemoryStore SailRepositories are
a matter of configuration and not coding. I would say this would be
beneficial for both Backstage and Longwell. Both have the
triplestore hardcoded in process. This doesn't mean that the middle-
tier isn't MemoryStore based, but just that its left open to
configuration and can be changed independently of the deployed webapp.
-Mark
~~~~~~~~~~~~~
Mark R. Diggory - DSpace Systems Manager
MIT Libraries, Technology Research and Development
Massachusetts Institute of Technology
_______________________________________________
General mailing list
[email protected]
http://simile.mit.edu/mailman/listinfo/general
