On 11/26/06, Eric Hestenes <erichestenes at vikiwi.com> wrote: > Hi Luis, > Thank you for your comments. > > Performance is definitely a question mark and requires further > investigation. Your point about adding complexity is also a good one, these > are excellent points. Thanks; hope they prove useful at some point in the evaluation process. Sorry I don't have time to help out with that directly. > The PLOS-TOPAZ project is working actively with > Mulgara triple-store and it might be possible to find out what the > performance is like by consulting with that project team. Ah, that is good to hear- the one other question I had, but forgot to ask, was 'are other projects using any of these in production?' The triple stores seem like neat technology, but when I was a project manager, neat technology only won out if it was also neat technology with a large and dynamic community of users. That sort of thing tends to ensure that the technology stays focused, maintained, and useful, instead of wandering off. If others are using any of the triple store techs (like Mulgara), that should be a large factor in choosing that particular tech. Luis > Luis Villa <luis at tieguy.org> wrote: > My reactions, offhand: > > On 11/22/06, Eric Hestenes wrote: > > Q1: Is there any reaction to the idea of using a triple store? > > > > Q2: Is use of a triple-store "over engineering" the solution, or is it > > called for? > > If any design problem calls for such a thing, this almost surely does. > I have a couple major concerns: > > * how is the performance of the existing triple-store frameworks? sql > is likely to be harder to work with, but is known to scale pretty > well, and all existing serious implementations are very seriously > optimized for speed. I have no idea of the state of the triple-store > frameworks in this respect, particularly in comparison with the > complex sql queries that you correctly note would often be necessary > for comparable operations in an sql framework. > > * how would this interact with data stored outside the triple > framework? Are there performance considerations (e.g., each page load > hitting both the triple store and an sql db); or complexity > considerations (e.g., losing the development advantages of a triple > store if each developer must learn/use both a triple store and a db > framework?) My sense is that inevitably at least other data will end > up in a good old-fashioned SQL db (because of the performance, > flexibility, and ubiquity of SQL), so you should consider the > interactions between stores when considering whether to use an > additional store. > > > Q3: If a triple store is over-kill, are there suggestions on the approach > > for creating a persistent metadata model (as data structures) so that it > > supports the application at runtime and also analytics about the metadata > > model after the system is deployed. > > If the triple store isn't the way to go? 'hire an sql guru' :) But I > think you're probably right that if performance, etc., are reasonable, > and there aren't any hidden penalties when the triple store is used > in combination with the inevitable sql DB, then the triple store seems > like the right solution for this problem space. > > HTH- > Luis > > >
