On 17-04-2005 00:53, "Stefano Mazzocchi" <[EMAIL PROTECTED]> wrote:
Example, if you have the Module object and the Project object, you have to decide which way the link goes and the notion of "Module.projects" means, this is the list of projects this module contains.
Problem is that this implicit modeling forces you to say decide the direction of the link, and, in case you want both, you have to model this explicitly and at update, you need to know where to change.
In RDF, you don't have to do all that.
Exactly! If you want a bi-directional link you have to model it explicitly and it is always very evident when using it, ie
project.module.repository.workspace.name
Just yells "You're handling a project and accessing something related to the workspace. Why is that????" right at ya.
Yep.
One thing that got Gump2 into problem was that things were relatively tightly coupled to another. Having "manual" modelling means that its easy to spot that coupling (just delete all links from repository->workspace, run your project-related code, boom, it blows up).
As with databases, I (model designer) have to work real hard so the plugin programmer has an easier time. Interestingly...
I find it somewhat ironic that you now code in a dynamically typed language (and, AFAIK, with good feelings about it) and you advocate that static typing of your data (object or SQL doesn't really matter) is better for you.
I hadn't realised that this clearly just yet. I've been conciously making a lot of things statically typed to keep it understandable. Now...
<snip/>
failed_builds = model.get("?x is_a Build where ?x status 'failed'")
Is indeed quite understandable. At least I had no problem understanding that when I first saw it.
Glad to hear that. I find it quite understandable myself, but only when you remove all the complexity that is introduced by the fact that all those things need to be globally unique URIs. Luckily some APIs came to the rescue.
Sure, the argument that objects are better than dealing with JDBC resultsets by hand stands, but making this a general rule could be turn out to be a mistake.
Do you know of an open-source reasonably sized RDF-model-based application that follows the approach you're describing? I'd like to see how it turns out! I was looking at Haystack the other day but uhm, it suffers from all of those "research project" flaws.
eheh, well, we are building one as we speak, but can't tell you more :-)
Let me just say that we have been dealing with as many as 30 million statements and as long as your queries are reasonable (say you don't iterate over all of the nodes!), the performance is reasonable as well.
Haystack tried to do too much (they are modelling their entire system, including the UI, with RDF statements... which means that its pretty much painful to do anything).
Same comment again....
I find it somewhat ironic that you now code in a dynamically typed language (and, AFAIK, with good feelings about it) and you advocate that static typing of your data (object or SQL doesn't really matter) is better for you.
You know, I still have mixed feelings about a lot of that. I have read so much python code recently that is hard to understand because its really dynamic, often for no good reason. And I've also see a lot of python code look really bad because developers want to add security in there that can't truly be enforced (ie Zope). And a whole lot of python code that is horribly structured simply because you can do a lot of "glueing" so easily.
On a code level scale, working with python can be real fun once you get the hang of it, but every time I write something like
for command in [command for command in commands \ if isinstance(command,Script)]: handle_script(command)
(which is kinda "pythonic") I do wonder whether
it = commands.iterator(); while(it.hasNext()) { command = it.next(); if(command instanceof Script) handleScript(command); }
Doesn't make more sense if there's other developers that have to understand the code.
True enough.
All I can tell is that semi-structures deal with the entropy of things a lot better than forcing structure on top of them: "refactoring" data in a triple store could be as easy as writing a few other owl:sameAs statements between node types and running an inferencing engine on it (maybe for a few hours or a day... *while* the system is still running).
-- Stefano.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
