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

Chris Wilper cwilper at cs.cornell.edu
Fri Sep 21 19:29:17 UTC 2007


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



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mulgara.org/pipermail/mulgara-general/attachments/20070921/0b5dd347/attachment.htm>


More information about the Mulgara-general mailing list