[MonetDB-users] rdf.sql missing from Mar2011 branch
Hello,
the rdf.sql file for creating the schema of an RDF database is missing from the branch of Mar2011. Could you add it please?
Thanks, Babis
On 2011-02-18 11:51, Babis Nikolaou wrote:
Hello,
the rdf.sql file for creating the schema of an RDF database is missing from the branch of Mar2011. Could you add it please?
I guess you mean the file sql/sql/30_rdf.sql which should get installed when RDF is enabled. When you create a new database after this file was installed, it should get executed automatically. In other words, newly created database should have the schema.
On 18-02-2011 12:28:02 +0100, Sjoerd Mullender wrote:
On 2011-02-18 11:51, Babis Nikolaou wrote:
Hello,
the rdf.sql file for creating the schema of an RDF database is missing from the branch of Mar2011. Could you add it please?
I guess you mean the file sql/sql/30_rdf.sql which should get installed when RDF is enabled. When you create a new database after this file was installed, it should get executed automatically. In other words, newly created database should have the schema.
Note that you need to have MonetDB configured with --enable-rdf, as this component is disabled by default.
On Fri, Feb 18, 2011 at 1:30 PM, Fabian Groffen Fabian.Groffen@cwi.nl wrote:
On 18-02-2011 12:28:02 +0100, Sjoerd Mullender wrote:
On 2011-02-18 11:51, Babis Nikolaou wrote:
Hello,
the rdf.sql file for creating the schema of an RDF database is missing from the branch of Mar2011. Could you add it please?
I guess you mean the file sql/sql/30_rdf.sql which should get installed when RDF is enabled.
Yes, that is the file in quest. It has been renamed from rdf.sql apparently.
When you create a new database after this file was installed, it should get executed automatically. In other words, newly created database should have the schema.
What is the design decision for this? If i would like to have other databases together with RDF ones, why should i have a predefined RDF schema and then drop it?
Thanks, Babis
Note that you need to have MonetDB configured with --enable-rdf, as this component is disabled by default.
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb _______________________________________________ MonetDB-users mailing list MonetDB-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/monetdb-users
On 18-02-2011 14:58:12 +0200, Babis Nikolaou wrote:
When you create a new database after this file was installed, it should get executed automatically. In other words, newly created database should have the schema.
What is the design decision for this? If i would like to have other databases together with RDF ones, why should i have a predefined RDF schema and then drop it?
why would you drop it?
On Fri, Feb 18, 2011 at 1:59 PM, Fabian Groffen Fabian.Groffen@cwi.nl wrote:
On 18-02-2011 14:58:12 +0200, Babis Nikolaou wrote:
When you create a new database after this file was installed, it should get executed automatically. In other words, newly created database should have the schema.
What is the design decision for this? If i would like to have other databases together with RDF ones, why should i have a predefined RDF schema and then drop it?
This is not a predefined RDF schema. In order for the internal relational representation of RDF to work, there is a need of some information to be added to the SQL cataloque. That is the purpose of the file 30_rdf.sql It does not affect the functionality of the database nor the freedom to define whatever databases and schemas you want.
But what is exactly that you want to do? I don't think it has to do anything with the specific file (plus you can always drop it and rerun it when you want indeed).
why would you drop it?
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb _______________________________________________ MonetDB-users mailing list MonetDB-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/monetdb-users
On Fri, Feb 18, 2011 at 3:05 PM, Lefteris lsidir@gmail.com wrote:
On Fri, Feb 18, 2011 at 1:59 PM, Fabian Groffen Fabian.Groffen@cwi.nl wrote:
On 18-02-2011 14:58:12 +0200, Babis Nikolaou wrote:
When you create a new database after this file was installed, it should get executed automatically. In other words, newly created database should have the schema.
What is the design decision for this? If i would like to have other databases together with RDF ones, why should i have a predefined RDF schema and then drop it?
This is not a predefined RDF schema. In order for the internal relational representation of RDF to work, there is a need of some information to be added to the SQL cataloque. That is the purpose of the file 30_rdf.sql It does not affect the functionality of the database nor the freedom to define whatever databases and schemas you want.
But what is exactly that you want to do? I don't think it has to do anything with the specific file (plus you can always drop it and rerun it when you want indeed).
why would you drop it?
Because, it may be the case that i don't want to store RDF data in this new database. Let me explain further:
suppose I create a new database. Then, running mclient and connecting to this database I can run the following query
select * from rdf.graph;
and get as answer the following relation:
+-------+--------+ | gname | gid | +====+===+ +——+------+
This means, that each database a create, regardless the type of data (RDF, structured) that will be stored, it is configured to a predefined database schema, the one that 30_rdf.sql creates: containing a two-columned table with name rdf.graph.
It does not seem logical to me to drop this schema and then create the preferred one to store relational data.
Hope that i made my point clear now.
Thanks, Babis
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb _______________________________________________ MonetDB-users mailing list MonetDB-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/monetdb-users
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb _______________________________________________ MonetDB-users mailing list MonetDB-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/monetdb-users
On 18-02-2011 15:27:02 +0200, Babis Nikolaou wrote:
why would you drop it?
Because, it may be the case that i don't want to store RDF data in this new database. Let me explain further:
suppose I create a new database. Then, running mclient and connecting to this database I can run the following query
select * from rdf.graph;
and get as answer the following relation:
+-------+--------+ | gname | gid | +====+===+ +——+------+
This means, that each database a create, regardless the type of data (RDF, structured) that will be stored, it is configured to a predefined database schema, the one that 30_rdf.sql creates: containing a two-columned table with name rdf.graph.
It does not seem logical to me to drop this schema and then create the preferred one to store relational data.
Hope that i made my point clear now.
If you don't want to use, don't --enable-rdf. If you want to use RDF sometimes, just use the rdf schema's graph table whenever you shred something. Why is this predefined table such a problem? I agree it should be created as part of the shredding phase, but alas, it is not. It doesn't harm anything, does it?
(PS. I'm on the list, no need to Cc me)
On Fri, Feb 18, 2011 at 3:32 PM, Fabian Groffen Fabian.Groffen@cwi.nl wrote:
On 18-02-2011 15:27:02 +0200, Babis Nikolaou wrote:
why would you drop it?
Because, it may be the case that i don't want to store RDF data in this new database. Let me explain further:
suppose I create a new database. Then, running mclient and connecting to this database I can run the following query
select * from rdf.graph;
and get as answer the following relation:
+-------+--------+ | gname | gid | +====+===+ +——+------+
This means, that each database a create, regardless the type of data (RDF, structured) that will be stored, it is configured to a predefined database schema, the one that 30_rdf.sql creates: containing a two-columned table with name rdf.graph.
It does not seem logical to me to drop this schema and then create the preferred one to store relational data.
Hope that i made my point clear now.
If you don't want to use, don't --enable-rdf. If you want to use RDF sometimes, just use the rdf schema's graph table whenever you shred something. Why is this predefined table such a problem? I agree it should be created as part of the shredding phase, but alas, it is not. It doesn't harm anything, does it?
No, of course it does not, and of course i can leave with it. If you see my first question, i was wondering from the perspective of the design decision.
Regards, Babis
(PS. I'm on the list, no need to Cc me)
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb _______________________________________________ MonetDB-users mailing list MonetDB-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/monetdb-users
On 18-02-2011 15:45:14 +0200, Babis Nikolaou wrote:
If you don't want to use, don't --enable-rdf. If you want to use RDF sometimes, just use the rdf schema's graph table whenever you shred something. Why is this predefined table such a problem? I agree it should be created as part of the shredding phase, but alas, it is not. It doesn't harm anything, does it?
No, of course it does not, and of course i can leave with it. If you see my first question, i was wondering from the perspective of the design decision.
You requested RDF (--enable-rdf) so you get it ;) That's the design decision.
On Fri, Feb 18, 2011 at 2:27 PM, Babis Nikolaou charnik@di.uoa.gr wrote:
On Fri, Feb 18, 2011 at 3:05 PM, Lefteris lsidir@gmail.com wrote:
On Fri, Feb 18, 2011 at 1:59 PM, Fabian Groffen Fabian.Groffen@cwi.nl wrote:
On 18-02-2011 14:58:12 +0200, Babis Nikolaou wrote:
When you create a new database after this file was installed, it should get executed automatically. In other words, newly created database should have the schema.
What is the design decision for this? If i would like to have other databases together with RDF ones, why should i have a predefined RDF schema and then drop it?
This is not a predefined RDF schema. In order for the internal relational representation of RDF to work, there is a need of some information to be added to the SQL cataloque. That is the purpose of the file 30_rdf.sql It does not affect the functionality of the database nor the freedom to define whatever databases and schemas you want.
But what is exactly that you want to do? I don't think it has to do anything with the specific file (plus you can always drop it and rerun it when you want indeed).
why would you drop it?
Because, it may be the case that i don't want to store RDF data in this new database. Let me explain further:
suppose I create a new database. Then, running mclient and connecting to this database I can run the following query
select * from rdf.graph;
And also in all databases if you run:
select * from sys.tables;
you will get an answer no matter what.
This is part of the cataloque that internaly the database is using to know where to find stuff, such as the names of the tables, or the names of the graphs. It has nothing to do with user defined schemas or structured and unstructured data. Think it of simply having the schema rdf reserved by the database in the same was as the schema sys is reserved and many others too.
and get as answer the following relation:
+-------+--------+ | gname | gid | +====+===+ +——+------+
This means, that each database a create, regardless the type of data (RDF, structured) that will be stored, it is configured to a predefined database schema, the one that 30_rdf.sql creates: containing a two-columned table with name rdf.graph.
It does not seem logical to me to drop this schema and then create the preferred one to store relational data.
You do not drop anything to create your database. It was just like this, in the old times you had to manually run a script to update the internal catalog information, now this is done automatically by a script, in the future it will be done during RDF shredding throw the internals of monetdb (aka c functions) the same as everything else is done. RDF is just still experimental and some things are done by hand to start with.
Hope that i made my point clear now.
Thanks, Babis
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb _______________________________________________ MonetDB-users mailing list MonetDB-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/monetdb-users
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb _______________________________________________ MonetDB-users mailing list MonetDB-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/monetdb-users
That explains it, but again why is this information accessible when querying the database schema, using for example command \D. I mean command \D does not return information about tables of sys such as sys.schemas, sys.types, sys.functions, sys.triggers, etc. I would expect the same behavior for the case of the rdf.table.
Thanks, Babis
On Fri, Feb 18, 2011 at 3:51 PM, Lefteris lsidir@gmail.com wrote:
On Fri, Feb 18, 2011 at 2:27 PM, Babis Nikolaou charnik@di.uoa.gr wrote:
On Fri, Feb 18, 2011 at 3:05 PM, Lefteris lsidir@gmail.com wrote:
On Fri, Feb 18, 2011 at 1:59 PM, Fabian Groffen Fabian.Groffen@cwi.nl wrote:
On 18-02-2011 14:58:12 +0200, Babis Nikolaou wrote:
> When you create a new database after this file was > installed, it should get executed automatically. In other words, newly > created database should have the schema.
What is the design decision for this? If i would like to have other databases together with RDF ones, why should i have a predefined RDF schema and then drop it?
This is not a predefined RDF schema. In order for the internal relational representation of RDF to work, there is a need of some information to be added to the SQL cataloque. That is the purpose of the file 30_rdf.sql It does not affect the functionality of the database nor the freedom to define whatever databases and schemas you want.
But what is exactly that you want to do? I don't think it has to do anything with the specific file (plus you can always drop it and rerun it when you want indeed).
why would you drop it?
Because, it may be the case that i don't want to store RDF data in this new database. Let me explain further:
suppose I create a new database. Then, running mclient and connecting to this database I can run the following query
select * from rdf.graph;
And also in all databases if you run:
select * from sys.tables;
you will get an answer no matter what.
This is part of the cataloque that internaly the database is using to know where to find stuff, such as the names of the tables, or the names of the graphs. It has nothing to do with user defined schemas or structured and unstructured data. Think it of simply having the schema rdf reserved by the database in the same was as the schema sys is reserved and many others too.
and get as answer the following relation:
+-------+--------+ | gname | gid | +====+===+ +——+------+
This means, that each database a create, regardless the type of data (RDF, structured) that will be stored, it is configured to a predefined database schema, the one that 30_rdf.sql creates: containing a two-columned table with name rdf.graph.
It does not seem logical to me to drop this schema and then create the preferred one to store relational data.
You do not drop anything to create your database. It was just like this, in the old times you had to manually run a script to update the internal catalog information, now this is done automatically by a script, in the future it will be done during RDF shredding throw the internals of monetdb (aka c functions) the same as everything else is done. RDF is just still experimental and some things are done by hand to start with.
Hope that i made my point clear now.
Thanks, Babis
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb _______________________________________________ MonetDB-users mailing list MonetDB-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/monetdb-users
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb _______________________________________________ MonetDB-users mailing list MonetDB-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/monetdb-users
On Fri, Feb 18, 2011 at 3:03 PM, Babis Nikolaou charnik@di.uoa.gr wrote:
That explains it, but again why is this information accessible when querying the database schema, using for example command \D. I mean command \D does not return information about tables of sys such as sys.schemas, sys.types, sys.functions, sys.triggers, etc. I would expect the same behavior for the case of the rdf.table.
That will be the behavior ones RDF becomes a stable module for montedb. For now it is just in an experimental stage thus no effort is made for sorting out such cosmetic details. Enabling RDF with --enable-rdf is only suggested for people who want to experiment with it, not to have a production RDF storage (for now at least).
Thanks, Babis
On Fri, Feb 18, 2011 at 3:51 PM, Lefteris lsidir@gmail.com wrote:
On Fri, Feb 18, 2011 at 2:27 PM, Babis Nikolaou charnik@di.uoa.gr wrote:
On Fri, Feb 18, 2011 at 3:05 PM, Lefteris lsidir@gmail.com wrote:
On Fri, Feb 18, 2011 at 1:59 PM, Fabian Groffen Fabian.Groffen@cwi.nl wrote:
On 18-02-2011 14:58:12 +0200, Babis Nikolaou wrote:
>> When you create a new database after this file was >> installed, it should get executed automatically. In other words, newly >> created database should have the schema.
What is the design decision for this? If i would like to have other databases together with RDF ones, why should i have a predefined RDF schema and then drop it?
This is not a predefined RDF schema. In order for the internal relational representation of RDF to work, there is a need of some information to be added to the SQL cataloque. That is the purpose of the file 30_rdf.sql It does not affect the functionality of the database nor the freedom to define whatever databases and schemas you want.
But what is exactly that you want to do? I don't think it has to do anything with the specific file (plus you can always drop it and rerun it when you want indeed).
why would you drop it?
Because, it may be the case that i don't want to store RDF data in this new database. Let me explain further:
suppose I create a new database. Then, running mclient and connecting to this database I can run the following query
select * from rdf.graph;
And also in all databases if you run:
select * from sys.tables;
you will get an answer no matter what.
This is part of the cataloque that internaly the database is using to know where to find stuff, such as the names of the tables, or the names of the graphs. It has nothing to do with user defined schemas or structured and unstructured data. Think it of simply having the schema rdf reserved by the database in the same was as the schema sys is reserved and many others too.
and get as answer the following relation:
+-------+--------+ | gname | gid | +====+===+ +——+------+
This means, that each database a create, regardless the type of data (RDF, structured) that will be stored, it is configured to a predefined database schema, the one that 30_rdf.sql creates: containing a two-columned table with name rdf.graph.
It does not seem logical to me to drop this schema and then create the preferred one to store relational data.
You do not drop anything to create your database. It was just like this, in the old times you had to manually run a script to update the internal catalog information, now this is done automatically by a script, in the future it will be done during RDF shredding throw the internals of monetdb (aka c functions) the same as everything else is done. RDF is just still experimental and some things are done by hand to start with.
Hope that i made my point clear now.
Thanks, Babis
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb _______________________________________________ MonetDB-users mailing list MonetDB-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/monetdb-users
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb _______________________________________________ MonetDB-users mailing list MonetDB-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/monetdb-users
participants (4)
-
Babis Nikolaou -
Fabian Groffen -
Lefteris -
Sjoerd Mullender