[redland-dev] Storage options and more

[Dave Beckett]

On Thu, 18 Dec 2003 00:25:18 +0100
Morten Frederiksen <mof-rdf at mfd-consult.dk> wrote:

> Hi there,
> 
> I've been corresponding with Dave regarding the MySQL storage factory
> for Redland that I've been writing, and he suggested we took the
> conversation in here...

and I've added my reply

> I wonder if it would be a good idea to have the storage code do table 
> creation (with slient failures) when supplied with the "new" parameter
> - that should make it even easier to use?

Yeah it could do.  I was wondering what to do with the MySql script you
gave me.  Just sticking it in documentation didn't seem right.

> On my wish list is currently an nt(+)->rdf/xml converter, which I've
> hacked together in a Perl script, but it reads the complete input into
> a model before serializing, I imagine it could be made more effective
> with more direct access to some serializer methods? Perhaps rapper
> could be extended? Otherwise the name "reppar" is up for grabs... ;->

As we discussed, rdfproc should be able to do that via a few stages.
rapper will be able to do that when I update raptor to handle
serialization - not before raptor 1.2 since I want to get 1.1 out with
ntriples plus.

> Also, I'd really like the raptor_uri_parse method (and others) to be
> public, especially since I'd like to extend rdfproc to handle a RSI
> (Redland Storage Identifier) instead of a model name/id. Also, I'd
> want to add my "tree" code (that recursively extracts properties and
> resource from a base URI) to that, as a new command.

I'm not sure I want all of the raptor_uri_parse stuff to be public, or
at least if I made a public API it might be different and provide
get/set accessors.

> RSI ideas:
> * MySQL:  mysql://user:password@host:port/db/model[/context]
> * 3store: tstore://user:password@host:port/db/model[/context]
> * bdb:    bdb:///path/model[/context]

As I suggesed, maybe the storage level could do the work for you.
It might be visible to the storage impelentations as new storage
options. i.e. if I opened a store
name=mysql://user:password@host:port/db/model then the storage options
that an librdf_storage_mysql_init would get would be a hash of options
with key/values name="mysql", user="user" etc. just as if they had been
passed into it.   

However, maybe these parts of the structured name should be separate
from the options?

> Perhaps the context should be in the query string instead (definitely
> not as a fragid)?

I don't quite get why a context is being passed here; what are you
identifying? I can't see a BDB store for example could do anything with
a context passed in at store open time.

> PS: I just got my FOAF Explorer (
> http://xml.mfd-consult.dk/foaf/explorer/ ) to accept (almost) all of
> RDF/XML by invoking Redland from PHP - it works!

Great, I'll add it to http://www.redland.opensource.ac.uk/using.html

Dave