On Nov 26, 2006, at 8:27 PM, Luis Villa wrote: > 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. I am very pessimistic about the real world applicability of RDF stores in todays content management systems. I've written pretty extensively on this subject here: http://zacker.org/semantic-web-research-isnt-working http://zacker.org/the-battle-for-the-semantic-web-rdf-vs-xml The only case I know first hand that attempted to use triple store technology ended disastrously, the data-store technology was unusably slow and the project lost funding and was scrapped. -Zack > >> 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 >> >> >> > _______________________________________________ > p2patent-developer mailing list > p2patent-developer at lists.osdl.org > https://lists.osdl.org/mailman/listinfo/p2patent-developer
