* Kingsley Idehen
> 
> I am sure you understand that as a fundamental principle, OpenLink 
> implements standards whenever such exist. If standards don't exist and a 
> problem persists, we innovate. If standards emerge later, we support 
> immediately.

What I wrote was not meant as criticism of OpenLink, merely as an explanation 
for why we did not choose what might seem a more obvious application of 
Virtuoso to our problem. It's entirely possible that we may wind up with 
Virtuoso on all nodes, joined by SDshare implementations written by ourselves. 
It would be more work, but would leave us free to choose the tools to use on 
each node without having to change every single node.

Anyway, I see that work is underway on standards similar to SDshare, so in time 
we may be able to migrate to something more widely supported.

> Which is why you may opt for other approaches e.g. you replicate the 
> data from foreign source to Virtuoso instance, and build views atop 
> Virtuoso. Otherwise, you can use Transient Views atop ODBC / JDBC to the 
> remote DSNs.

Yes. Another possibility is to use Ontopia's DB2TM with its SDshare 
implementation and RDF export.

> If you want backward chained inference and change sensitivity then there 
> are no alternatives to what we've implemented.

We're not greatly concerned with change sensitivity, as this is an archival 
application. As for inference all we really need is transitive closure over 
relations whose types meet a trivial criterion.

--Lars M.
http://www.garshol.priv.no/tmphoto/
http://www.garshol.priv.no/blog/


Reply via email to