W3C home > Mailing lists > Public > semantic-web@w3.org > September 2010

Re: RDF data handover and dereferenceable URIs

From: Rahul Patil <rahulpatil12@gmail.com>
Date: Thu, 23 Sep 2010 15:38:38 +0530
Message-ID: <AANLkTi=2iESXN5st=LU=QpOQLnvgZJBef++1SE+Y_Noj@mail.gmail.com>
To: David Booth <david@dbooth.org>
Cc: Semantic Web Interest Group <semantic-web@w3.org>
Thanks for your reply David.
The thing with PURL is that
We are not sure if it will scale to millions of triples industry will be
churning out.
and also once we commit to PURL it needs to be around even if triples are at
the final endpoint (e.g. with international standard endpoint)
Is there a way to use PURL during the stages when endpoints are changing but
switch to actual endpoint address (and hence the namespace) when they reach
the final endpoint?


On Wed, Sep 22, 2010 at 10:01 AM, David Booth <david@dbooth.org> wrote:

> On Wed, 2010-09-22 at 09:31 +0530, Rahul Patil wrote:
> > Now the question is: how to keep a URI dereferenceable while it moves
> > from one physical endpoint to other through the standardization
> > process?
> > [ . . . ]
> > I can think of some ways like maintaining a separate server to
> > redirect abstract URIs or using something like PURL
> > (http://purl.org/docs/index.html) but want to check with this group
> > before committing  to a solution.
> >
> PURLs are the best solution that I know.  Furthermore, using partial
> redirects
> http://www.purl.org/docs/long_intro.html#partial
> you can even have your URIs point to private servers inside your
> firewall if you want, for example before you are ready to publish your
> ontology, and then move it to a public server when you're ready to
> publish it.  By changing the partial redirection the URIs will not have
> to be changed.
> >
> --
> David Booth, Ph.D.
> Cleveland Clinic (contractor)
> http://dbooth.org/
> Opinions expressed herein are those of the author and do not necessarily
> reflect those of Cleveland Clinic.
Received on Thursday, 23 September 2010 10:09:06 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 07:42:22 UTC