Comments on: Goodbye Database! http://www.dftproject.org/blog/2007/06/19/goodbye-database/ Wed, 19 Nov 2008 04:12:54 +0000 http://wordpress.org/?v=2.1 By: Jocelyn http://www.dftproject.org/blog/2007/06/19/goodbye-database/#comment-3254 Jocelyn Tue, 19 Jun 2007 23:53:53 +0000 http://www.dftproject.org/blog/2007/06/19/goodbye-database/#comment-3254 Silent, yet avid readers...Unite! Silent, yet avid readers…Unite!

]]> By: Ian Jacobi http://www.dftproject.org/blog/2007/06/19/goodbye-database/#comment-3256 Ian Jacobi Wed, 20 Jun 2007 00:10:57 +0000 http://www.dftproject.org/blog/2007/06/19/goodbye-database/#comment-3256 It only makes sense, but it is also true that databases CAN be run mostly (if not entirely) within memory. Perhaps the database was set up poorly, caching everything to disk immediately and reading everything from the drive immediately? I know you can delay disk writes and still keep data in the database by having a separate disk-writer thread that works independently (in part, because last.fm works (or used to) on that principle) Also, I question the use of owl:sameAs, as it is a very strong statement to make, and I don't know how its ontological semantics would work in the named graph context. More and more from my start on that independent library, I'm believing that the named graph set itself needs a dedicated named graph in which assertions can be made, such as the 'owl:sameAs' claim... Lastly, I'd think that the difficulties seen, in particular, with the owl:sameAs unification in Genesis, are more algorithmical than database-related (though of course disk-throughput may make a difference, depending on how much of the database is cached). But this is all speculation on my part. It only makes sense, but it is also true that databases CAN be run mostly (if not entirely) within memory. Perhaps the database was set up poorly, caching everything to disk immediately and reading everything from the drive immediately? I know you can delay disk writes and still keep data in the database by having a separate disk-writer thread that works independently (in part, because last.fm works (or used to) on that principle)

Also, I question the use of owl:sameAs, as it is a very strong statement to make, and I don’t know how its ontological semantics would work in the named graph context. More and more from my start on that independent library, I’m believing that the named graph set itself needs a dedicated named graph in which assertions can be made, such as the ‘owl:sameAs’ claim…

Lastly, I’d think that the difficulties seen, in particular, with the owl:sameAs unification in Genesis, are more algorithmical than database-related (though of course disk-throughput may make a difference, depending on how much of the database is cached).

But this is all speculation on my part.

]]> By: Hilton http://www.dftproject.org/blog/2007/06/19/goodbye-database/#comment-3280 Hilton Wed, 20 Jun 2007 21:53:02 +0000 http://www.dftproject.org/blog/2007/06/19/goodbye-database/#comment-3280 It's true that the database may have been set up poorly, but even if I could get the database to run as quickly as an in-memory model, I would still have the unmentioned hassle of keeping Lucene indexes synchronized with the data in the database (which is problematic without transactions). The whole problem is greatly simplified by dropping teh database altogether, seeing as it isn't really neccessary. As for owl:sameAs, I agree that it should go into a special assertions graph. When it is asserted by an agent, it goes into the agent's assertion graph, which is not trusted by default, so it gets ignored in reasoning. When it is asserted by the user, it goes into the user's assertion graph, which is of course trusted and therefore used in reasoning. Because it can be either trusted or not trusted, I'm OK with it being a strong statement. For reference, I'm planning on using <a href="http://sites.wiwiss.fu-berlin.de/suhl/bizer/wiqa/index.htm" rel="nofollow">WIQA</a> to manage trust. It’s true that the database may have been set up poorly, but even if I could get the database to run as quickly as an in-memory model, I would still have the unmentioned hassle of keeping Lucene indexes synchronized with the data in the database (which is problematic without transactions). The whole problem is greatly simplified by dropping teh database altogether, seeing as it isn’t really neccessary.

As for owl:sameAs, I agree that it should go into a special assertions graph. When it is asserted by an agent, it goes into the agent’s assertion graph, which is not trusted by default, so it gets ignored in reasoning. When it is asserted by the user, it goes into the user’s assertion graph, which is of course trusted and therefore used in reasoning. Because it can be either trusted or not trusted, I’m OK with it being a strong statement.

For reference, I’m planning on using WIQA to manage trust.

]]> By: Steve.ivie http://www.dftproject.org/blog/2007/06/19/goodbye-database/#comment-18944 Steve.ivie Sat, 23 Feb 2008 19:43:47 +0000 http://www.dftproject.org/blog/2007/06/19/goodbye-database/#comment-18944 So I like the idea that only the "view" gets saved. There can be an invisible "layer" thou where somethings can be cached in a BDB for speed purposes only, but I really like the idea of being able to go to any computer and using this. Just one question... are "collections" going to be stored locally? So I like the idea that only the “view” gets saved. There can be an invisible “layer” thou where somethings can be cached in a BDB for speed purposes only, but I really like the idea of being able to go to any computer and using this. Just one question… are “collections” going to be stored locally?

]]> By: Hilton http://www.dftproject.org/blog/2007/06/19/goodbye-database/#comment-18949 Hilton Sun, 24 Feb 2008 01:26:47 +0000 http://www.dftproject.org/blog/2007/06/19/goodbye-database/#comment-18949 That's funny, just this morning I started working on caching using BDB (thanks to your encouragement in past discussions, BDB is <i>awesome</i>)! Maybe I should write a new post, "Hello Database!" :) A "collection" can exist anywhere, whether it be local or remote. Putting data online is very strongly encouraged, but I can imagine reasons why one might want to maintain a local collection instead. If you're a Luddite, maybe? ;) That’s funny, just this morning I started working on caching using BDB (thanks to your encouragement in past discussions, BDB is awesome)! Maybe I should write a new post, “Hello Database!” :)

A “collection” can exist anywhere, whether it be local or remote. Putting data online is very strongly encouraged, but I can imagine reasons why one might want to maintain a local collection instead. If you’re a Luddite, maybe? ;)

]]>