[Mulgara-general] Model-URI/URL Use-cases and Requirements andProposal

[Paul Gearon]

Hi Chris,

The registry that's been mentioned is supposed to handle the mapping  
of URLs to the URI of a graph.  In the short term we won't have a  
registry, and each server will need to map URLs to their own internal  
URIs (if such a mapping exists).  However, once we have the registry  
running then it should be easy to do what you want.

BTW, one of the things I'm working on is changing the "connection"  
mechanism to Mulgara.  At the moment you issue a query, and the  
client lib establishes a connection based on the URLs of the graphs  
in your query.  The new system will allow you to create your own  
connections (pooling them if you want), and send your queries over  
that connection.  Essentially it's the same thing you do with most  
relational databases.  For instance, on MySQL you have to connect to  
a server before you can issue any queries.  I've also written a  
utility class that emulates the old behavior of establishing  
connections based on the URLs in the query, so this shouldn't break  
anything existing.

The significance of this change is that you can now force your  
connections to go to any particular server.  The "distributed"  
resolver makes sure that the query will get forwarded on to another  
server, if required.  It will also allow each server to hold an  
internal map of URIs to URIs for the graphs.  This means that a model  
could be named with any URI at all - even a non-URL.  It wouldn't  
work with connection utilities that try to connect automatically  
based on URL, but that's OK, as I expect that old mechanism to be  
deprecated eventually.

So I expect to see support for what you're asking on 2 levels:
a) There will eventually be a registry that will let you find the  
location of a graph (ie. the server that the graph is on) within your  
network.  This lets you find the server that you need for part (b)...
b) Each server will allow you to call any graph by any URI (this will  
get mapped to a canonical URI by the code that Andrae is writing).   
This requires that you know which server to connect to (which you got  
from part (a)).

Regards,
Paul Gearon

On Sep 21, 2007, at 2:29 PM, Chris Wilper wrote:

> Hi Andrae and others,
>
> I think it would be great if, down the road, I could take
> take an already-named graph into Mulgara without having
> to change the name.  Would the proposal support that,
> or would I need to change the name to something special
> if I stored it in Mulgara?
>
> - Chris
>
> -----Original Message-----
> From: mulgara-general-bounces at mulgara.org on behalf of Andrae Muys
> Sent: Fri 9/21/2007 6:31 AM
> To: Mulgara General
> Subject: Re: [Mulgara-general] Model-URI/URL Use-cases and  
> Requirements andProposal
>
>
> On 21/09/2007, at 6:52 PM, tom lurge wrote:
> > can someone please shed a little light on that "registry" thing?
> > would that be a centralized service, a piece of code, an  
> institution?
>
> It's expected that eventually someone who is running multiple mulgara
> servers and using distributed queries would want some way to map from
> a URI to a URL.  However if you ever intend such a thing to scale you
> need each organisation to run their own resolution service - I expect
> this is an issue we will probably face 3-5 years hence, but names are
> hard to change so it's worth thinking about now (especially as it
> isn't any harder to implement).
>
> > regarding andrae's proposal i just have some aesthetical remarks.
> >
> > 1) since the issue is one of naming, why not use a scheme that
> > resembles more a name that we are used to? email-adresses are names
> > that are globally unique and not tied to a certain machine. they
> > fit the server-id/organisation-id scheme quite well. that would  
> mean:
> >
> >     rdfdb://rdfDatabase@netymon.com/addressBook
>
> This is unfortunately a valid URL.  My use of tilde was intentional -
> it is one of the characters that are permitted in the authority of a
> hierarchical URI, but not in a URL.
>
> > since this looks like a name i don't see a need to invert the dns-
> > like representation (which looks rather ugly to me).
> > this would much easier translate to
> >
> >    rmi://pneuma.netymon.com/rdfDatabase#addressBook
> >    soap://pneuma.netymon.com/rdfDatabase#addressBook ...etc...
> >
> > and at least for some webdesigners like me it may be easier to
> > grasp what's going on.
>
> Actually I would anticipate the opposite.  I anticipate that using
> the dns-order would cause significant confusion and conflation
> between the organisation-id and hostname.  After all you've just
> conflated them above - the reason we want to invert the order is to
> make it abundantly clear that the org-id and the host are two
> orthogonal concepts.
>
> rdfdb://personal~au.id.muys/addressBook is very likely to be found at
> http://pneuma.netymon.com/personal/addressBook.
>
> There is *no* way to translate an org-id to a hostname - and *no* way
> to translate a <server,org-id> pair to a hostname _except_ via some
> sort of resolver.  The name exists, not so you can use it to query a
> model, but rather so you can use it as a name to make statements
> about the model.  Initially there will be a resolver to permit you to
> map between URI's and URL's on a single server, a registry service
> and a resolver to access it will wait until people start using
> multiple mulgara instances and want to do meta-model based queries
> across them.
>
> > 2) then, dropping the fragmentidentifier right away:
> >
> >    rmi://pneuma.netymon.com/rdfDatabase/addressBook ...etc...
> >
> > and the connection is even more obvious.
>
> This is currently my preferred model URL scheme - of course it is
> incompatible with existing queries, so (unlike the URI change) will
> require all existing mulgara users to update their applications - the
> URI change will only affect users who do meta-model queries - and
> even then it will only affect what they insert into the store.
>
> > n) as an aside: i would prefer "store" over "rdfdb" - just sounds
> > sexier and since "store" is phrase that's quite common in the
> > context of rdf (metastore, triple store) ...
> >
> >     store://rdfDatabase@netymon.com/addressBook
>
> The reason I prefer rdfdb is that it is less general than store.
> There are a lot of 'store's out there, and very few of them have
> anything to do with rdf.  I considered graph: and rdfgraph: but
> again, the former is very general; while the latter is longer than I
> like.  Consequently when we first sat down and brainstormed a
> solution to this bug rdfdb: was the nominated scheme.
>
> Andrae
>
> --
> Andrae Muys
> andrae at netymon.com
> Senior RDF/SemanticWeb Consultant
> Netymon Pty Ltd
>
>
> _______________________________________________
> Mulgara-general mailing list
> Mulgara-general at mulgara.org
> http://mulgara.org/mailman/listinfo/mulgara-general
>
>
>
>
> _______________________________________________
> Mulgara-general mailing list
> Mulgara-general at mulgara.org
> http://mulgara.org/mailman/listinfo/mulgara-general

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mulgara.org/pipermail/mulgara-general/attachments/20070922/4d29702e/attachment.htm>