[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Myexperiment-discuss] Upload any type of Workflow you want...
From: |
James Howison |
Subject: |
Re: [Myexperiment-discuss] Upload any type of Workflow you want... |
Date: |
Wed, 5 Nov 2008 12:16:18 -0500 |
(btw, there are a group of personal addresses cc'd here as well as the
myexperiment list, I'm not quite sure that everyone realizes that this
discussion is going to the whole list. Anyway, I find it
interesting :) I'll drop all cc'd addresses after this email.
On 5 Nov 2008, at 10:37 AM, Rajarshi Guha wrote:
I've been observing the RDF discussion from the sidelines. For the
query given below:
"what are the compounds that have a solubility of 2-3 molar
in methanol?"
why would one prefer RDF over SQL?
For me:
1. Much simpler queries
2. Global namespacing through URIs makes merging diverse databases
easier (and owl:sameAs helps too).
3. Modeling is much more flexible, there's no set schema so when you
need to add more properties or objects you can without changing a
million things.
4. You can write your database in a plain text file, using Turtle/n3
5. datatypes like datetime are much more standardized than in the SQL
word and there's great work coming on measurements (weights, distances
etc). (query time conversion into whatever units you desire)
6. Metadata modeling is much easier, in part because
7. hierarchical types make modeling similarity easier, while
preserving differences. This is just harder in SQL.
I say that queries are simpler because:
- properties are more semantic and easier to understand and relate to
each other
- there are no joins, so one doesn't have to manage foreign keys etc
(ok, I guess FROM GRAPH is a join but always a full one)
- if you add rdfs/owl+SWRL reasoners into the picture then you have
the equivalent of procedures which handle 'expanding' all the
implications of statements that are inserted. This is essentially
what table joins in SQL do, but you have to handle them at query time,
which leads to complex queries if you want even a slightly different
view of your data. Yeah, SQL views can do this too.
In these ways semantic complexity is handled at modeling time, not
repeatedly at query time.
At least that's why I do it :)
Cheers,
James