[Mulgara-dev] System Model and Canonical Aliases

James Leigh james-nospam at leighnet.ca
Mon Oct 5 13:12:51 UTC 2009


Hi Paul,

Can the canonical aliases be removed safely by the next release? If so,
when can we expect this release?

Thanks,
James

On Tue, 2009-09-08 at 07:26 -0400, James Leigh wrote:
> On Sat, 2009-09-05 at 21:51 -0400, Paul Gearon wrote:
> > Sorry it's taken me so long to look at this....
> > 
> > On Sat, Sep 5, 2009 at 7:41 PM, Life is hard, and then you die
> > <ronald at innovation.ch> wrote:
> > > On Fri, Sep 04, 2009 at 03:58:13PM -0400, James Leigh wrote:
> > >>
> > >> When creating a new Database like this:
> > >>   DatabaseFactory.newDatabase(systemModel, dataDir, config);
> > >>
> > >> I have been using java.net.URI("http://mulgara.org/local/server1"), but
> > >> that causes other model names (that resolve to the local hostname) to be
> > >> rewritten to use the authority mulgara.org.
> > 
> > I'm curious why you're using that URI.
> > 
> > I'm not saying it was a great idea (far from it), but this URI for the
> > server was really designed to be a URL identifying the host/server
> > combo. I don't believe it was never designed to be flexible enough to
> > be a generic URI.
> > 
> 
> The software is design to run on multiple hosts, not sure where this URI
> came from, but at the time I didn't think the URI authority would make a
> difference.
> 
> > These days, the world has moved on from the originally envisioned
> > deployment environment, so I appreciate that you (and others) may need
> > this sort of thing. But I'm just trying to clarify where it's coming
> > from.
> > 
> 
> We want to create a web service, that supports virtual hosts, and is
> backed by Mulgara. Many of the URIs (subject, object, and graph) will
> resolve to this host, so it is important for us that Mulgara is able to
> accurately store them.
> 
> > >> For example, when using the above systemModel, adding values to the
> > >> graph "http://igor.zepheira.com:8080/data.ttl" actually puts them into
> > >> "http://mulgara.org/data.ttl" (when running on the host
> > >> igor.zepheira.com). However, since "http://mulgara.org/data.ttl" is not
> > >> a known graph it tries to fetch the values from the server mulgara.org
> > >> and fails. The end result is that I can't create any named graphs that
> > >> resolve to the current host name (unless there is no port and the host
> > >> name is used in the systemModel).
> > >>
> > >> I would like the graphs "http://igor/data.ttl",
> > >> "http://igor.zepheira.com/data.ttl",
> > >> "http://igor.zepheira.com:8080/data.ttl", etc to be treated as different
> > >> named graphs, even if the URL authority is a host alias.
> > >>
> > >> That is, I would like all model names to be left as-is without resolving
> > >> host aliases. How can I prevent Mulgara from using canonical aliases?
> > 
> > I *think* that the design decisions that led to this were based on
> > finding graphs on servers via their URLs, which were always rmi://.
> > Things have changed a lot since then. For instance, a server can store
> > a graph with any URI, and not just those starting with
> > rmi://hostname/servername#. So maybe the aliasing can be dropped
> > altogether.
> > 
> > I can't think of any reason why aliases are still needed, except to
> > avoid going through network interfaces when non-canonical names are
> > used. I'd like to play around with dropping them and see what happens.
> > 
> > > The easiest is to not use URL's for your graph URI's; e.g. use
> > > "urn:igor:data.ttl" instead (or anything for which
> > > java.net.URI.isOpaque() returns true); this does preclude the use of
> > > relative uri's in queries, though.
> > >
> > > Other than that, there's no way to disable the canonicalization, short
> > > of changing the code.
> > 
> > I think that's what James may have been suggesting, somewhat subtly.
> > :-)  That's fine. The system is full of old design decisions that
> > ought to be revisited to confirm that the reasons for them still
> > apply.
> 
> Thanks for the input, we would need a solution by the end of the month.
> If this aliases is no longer required could it be removed from the next
> release?
> 
> Thanks,
> James




More information about the Mulgara-dev mailing list