Re: Using W3id for more than just persistent/permanent identifiers?

Agree that actually hosting should not be our concern, as it 
brings along issues like copyright, maintenance, ownership, 

There could potentially be room for this community to override a 
redirection to a web archived version if the original provider's
server goes AWOL (e.g. what almost happened with the VoID ontology
earlier this year).   Such "reawakenings" should however still
redirect to a third-party server, e.g.

On the other side, in my view, doing basic content negotiation as part of
.htaccess I think *could* be part of w3id, e.g. send browsers to, APIs to and RDF clients to

Even redirecting non-JSON-LD clients to online services like Gregg Kelloggs
RDF Distiller could be in scope.

The .htaccess way of doing content negotiation (e.g. by checking the Accept
header with a regex) is not strictly according to the HTTP spec as you would be
ignoring the quality parameter q= and multiple requested types -- but at least
it would be better than no content negotiation at all.

(I believe to get Apache to do the content negotiation properly you would need
some actual files with actual content types bound - this could in theory be
some empty dummy files with a .htaccess redirect overriding those files again -
but this sounds like a technology debt trap not for the faint hearted:)

One other issue here is that getting such .htaccess files right requrires a
fair amount of trial-and-error which we can't really be doing per pull request.

But I believe doing some kind of Docker-version of w3id could be a way to test
it locally - kind of extending the current .travis.yml to set up a w3id
redirector on http://localhost:8080/ for you to test - and then we could have
a recommended template to copy. (where you delete the file types you don't

Excerpts from David I. Lehn's message of 2015-11-17 21:39:06 +0000:
> On Thu, Nov 12, 2015 at 3:16 PM, Haag, Jason <> wrote:
> > I know that w3id was really established to provide a persistent identifier
> > mechanism for RDF resource and vocabulary IRIs. However, the fact that it is
> > already configured for content negotiation provides a real opportunity for
> > communities that don't have the resources (both severs & expertise).
> > Technical expertise such as contentneg and having a collaborative workflow
> > are often seen as a barriers to getting started with linked data.
> >
> > Are there any objections to also using the w3id server to host linked data
> > files such as html/rdfa, turtle, json-ld? I know that is not what it is
> > intended for, but thought I would ask. It could help automate my particular
> > workflow where I'm working with several different organizations that are
> > wanting to publish their linked data collaboratively and while also having a
> > tool to generate the persistent identifiers.
> >
> While it would be easy to allow arbitrary data, I don't think we
> should take in that direction at this time.  The service was
> designed to be a simple redirector.  If we also add in hosting user
> data there are three problems I see.
> 1. A likely small increase in resource usage and cost.
> 2. The current system involves manual interaction for updates.  Part
> of the choice for doing that was the assumption that link updates
> would be rare but content the links point to could be updated however
> the owners want without in the loop.  Better tooling would
> fix this issue.
> 3. If the service hosts user content, we'll have to worry about what
> that content is.  I don't think we want to be in the middle of
> copyright issues, other similar claims, or content policing.  With
> links we mostly avoid such problems.
> There are many cloud services out there that can host data and would
> be easy to point links at.  They also likely have better
> interfaces for dealing with files than what is using now.  If
> it in fact is too difficult for some people, perhaps that's an
> opportunity for another service?
> -dave

Stian Soiland-Reyes, eScience Lab
School of Computer Science
The University of Manchester

Received on Monday, 23 November 2015 11:09:46 UTC