Accessing vs Naming Models

We recently had a use case where the directory where the triples were persisted moved to a different machine or where the host name of the machine frequently changed (moving from network to network).

Our existing scheme for naming models takes the form:
protocol://hostname/servername#modelname

Which usually becomes:
rmi://www.kowari.org/server1#model1

This is pretty brittle given the above use case. We've known for quite some time that our model naming scheme confused two distinctive properties:
* How to access the model, and
* The name of the model.

By ignoring this issue we could get around to adding views, security and the iTQL FROM and IN clause.

However, we now have the need to uniquely identify the model as well as continuing to support the old naming scheme. The currently proposed idea is to first map the URL of a model to a URN so that:
<rmi://fully.qualified.hostname/server1#model1>

Becomes:
<urn:fully-qualified-hostname:server1:model1>

This also allows us some added flexibility such that you can now have names for RSS feeds and external models that can be described using:
<urn:slashdot-org:news-rss> <access> <http://slashdot.org/news.rss>
<urn:my-com:server1:hr> <access> <rmi://localhost/server1>

The second entry refers to a local copy, which can be changed to:
<urn:my-com:server1:hr> <access> <rmi://my.com/server1#hr>

Which will access the live version of the database. It will break some of the current functionality in iTQL. This is where it creates a model on the fly if it happens to use an external model. For example:
select $s $p $o
from <http://slashdot.org/rss.xml>
where $s $p $o ;

This downloads the RDF and puts it in a model. Subsequent calls will be done against the local model. Also, iTQL doesn't implicitly have a default host so you must give it another way of giving the connection.

The simplest way is to create the mapping when creating a model:
create <urn:slashdot-org:rss-feed> <http://slashdot.org/rss.xml>

In the future, resolvers will have configuration settings so you could make statements such as:
<urn:slashdot-org:rss-feed> <updateOnlyIfChanged> <every 5 minutes>

Once created, it can then be accessed in the FROM:
select $s $p $o
from <urn:my-com:server1:hr> and <urn:slashdot-org:rss-feed> <rmi://my.com/server1>
where $s $p $o ;

This will do a set operation over the two listed models as defined in the Kowari/TKS server at "my.com".

However, this can get verbose so we'll probably borrow something from RDQL and the like and add a USING clause:
select $s $p $o
from <urn:my-com:hr> and <urn:pi-com:cal>
where $s $p $o
using <rmi://my.com/server1> ;

Or alternatively, we could set the server before doing a query using:
set server <rmi://localhost/server1> ;

To turn it from a local query to a distributed query (a TKS only feature):
set server <rmi://my.com/server1> for <urn:my-com:hr> ;
set server <rmi://pi.com/server1> for <urn:pi-com:cal> ;