Permanent model names in TKS/Kowari

Hi guys,

Here is a summary of the discussions that we've been having internally 
on permanent model names and ideas for a) how we name models and b) how 
we separate model names from their access mechanism, there's also some 
syntax at the bottom. For the record, a most of this discussion comes 
from Andrew Newman. All comments are speculation, I don't believe we've 
implemented these ideas as yet ;)

Our discussions have been motivated by a number of reasons, a lot of 
which have been coming to us from customers:

o Models should to be named in order to be able to reference them in 
queries;
o Names should be independent of the method of access (i.e. protocol);
o Names should be independent of the hostname of the machine they're 
stored on;
o Models should be able to be moved from machine to machine;
o The content of a model may reside in a different storage mechanism 
over time, e.g. RDF/XML file or TKS/Kowari model.

Some other work has been done around similar things. @semantics did a 
presentation on resolving models at the WWW2004 conference:

http://www.asemantics.com/presos/devdays-2004/y-532x400-12.html

There's a few RFCs that cover similar topics:

DDDS part 3: http://www.ietf.org/rfc/rfc3403.txt
DDDS part 4: http://www.ietf.org/rfc/rfc3404.txt
Using HTTP in URN Resolution: http://www.ietf.org/rfc/rfc2169.txt
Handle System Overview: http://www.ietf.org/rfc/rfc3650.txt

So cutting to the crunch, TKS/Kowari currently use model names of the 
form:

protocol://hostname/servername#modelname

For example:

rmi://knuth.bne.tucanatech.com/server1#foo
beep://knuth.bne.tucanatech.com/server1#foo

This confuses two distinct properties of a model: the model name and 
how to access the model.

TKS/Kowari stores model information in a special place called the 
system model. This model stores information such as the type of a 
model, e.g. a full text model or a native "Tucana" model. As far as 
Tucana is concerned, we want to solve the problems outlined above, but 
also allow for backwards compatibility with existing queries. As we 
want to be able to store model information in RDF, and make statements 
about models, we need to use a resource to reference a model. We're 
considering using URNs to name models.

Our proposed new model naming scheme would use the system model to 
contain information about the models including their name and how to 
access them. So for example we could be storing the following triples:

<urn:slashdot-org:news-rss> <access> <http://slashdot.org/news.rss>
<urn:slashdot-org:news-rss> <updateEvery> <5 minutes>
<urn:knuth-com:server1:foo> <access> <rmi://localhost/server1>
<urn:tucanatech-com:server1:hr> <access> <rmi://localhost/server1>

The first model <urn:slashdot-org:news.rss> is an remote model that you 
access using the given URL (http://slashdot.org/news.rss) and you 
update it every 5 minutes. The second and third models are local 
models. The third model is a company model that you just happen to have 
a local copy of.

So now onto some syntax examples, feel free to tune out.

If you want to explicitly access a model with a given name on a given 
server without having an entry into the system model you'd have to give 
two entries in the from clause.

For example:

select $s $p $o
from <rmi://hr.tucanatech.com/server1> <urn:tucanatech-com:server1:hr>
where $s $p $o ;

Some other syntax ideas (you'll get the picture):

select $s $p $o
from <urn:tucanatech-com:hr> and <urn:tucanatech-com:cal>
where $s $p $o
using <rmi://hr.tucanatech.com/server1> ;

or

select $s $p $o
from <urn:tucanatech-com:hr> in <rmi://hr.tucanatech.com/server1> and 
<urn:tucanatech-com:cal> in <rmi://my.com/server1>
where $s $p $o ;

These would set the server whose system model to use when resolving 
model names local to the query. So setting it for the session:

set server <rmi://hr.tucanatech.com/server1> ;

select $s $p $o
from <urn:tucanatech-com:hr> and <urn:tucanatech-com:cal>
where $s $p $o ;

If you wanted to specifically override on a model by model basis:

set server <rmi://hr.tucanatech.com/server1> for 
<urn:tucanatech-co:server1:hr> ;

So an example of a local query:

set server <rmi://localhost/server1> ;
select $s $p $o
from <urn:tucanatech-com:server1:hr> and <urn:my-com:server1:foo>
where $s $p $o ;

The same query but distributed:

set server <rmi://tucanatech.com/server1> for 
<urn:tucanatech-com:server1:hr>;
set server <rmi://my.com/server1> for <urn:my-com:server1:foo>;
select $s $p $o
from <urn:tucanatech-com:server1:hr> and <urn:my-com:server1:foo>
where $s $p $o ;

And to do it without requiring the session to hold state:

select $s $p $o
from <urn:tucanatech-com:server1:hr> in <rmi://tucanatech.com/server1> 
and <urn:my-com:server1:foo> in <rmi://my.com/server1>
where $s $p $o ;


I think that about wraps it up, I can get some more detail on how we'd 
resolve local and remote models when doing distributed (federated) 
queries if anyone is interested.

Cheers,
Tom
-- 
Tom Adams                  | Tucana Technologies, Inc.
Support Engineer           |   Office: +1 703 871 5312
tom@tucanatech.com         |     Cell: +1 571 594 0847
http://www.tucanatech.com  |      Fax: +1 877 290 6687
------------------------------------------------------

Received on Sunday, 21 November 2004 04:04:53 UTC