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. 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. Sincerely, Eric Hestenes Technical Lead NYLS Community Patent Review project eric.hestenes at communitypatent.org 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osdl.org/pipermail/p2patent-developer/attachments/20061126/d60e047b/attachment.htm
