[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