couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Douglas Fils <>
Subject couchdb and linked data
Date Mon, 15 Jun 2009 14:14:11 GMT
I am actively exploring the use of couchdb for our group.  However, I 
have a few questions related to couchdb and linked data approaches (Ref: and "cool uri's" (Ref:

I have not been able to find references for this information so if I 
have missed anything I would enjoy hearing about it.  Additionally I am 
new (like many of us) to couchdb, so there may be some "wrong thinking" 
here.   I am using the Views and HTTP API pages on the wiki as primary 
sources for my couchdb comments.

Note that many of these issues are easily solved by placing a 
'traditional web app' like a Grails or Rails based layer in front of 
couch and letting that app address these while using couchdb as a 
backend store.  That is fine, but this email is trying to explore what 
couchdb itself can do with minimal effort by such an app (if any).

One tenant of linked data is that a URI should not represent both a 
"real world" object and a web document.  This is why 303 are often 
used.  A URI can be defined as a representation of a real world object, 
but also use the web architecture back end to provide a 303 redirection 
to another URI of a web page with info about that object.

Question:  Is there a means to provide this in the couchdb space?  My 
first thought is that there would be a view that does this.  So we would 
have (though one might URL re-write this to something 'nicer' even)[some_doc_id}
which could 303 to[some_doc_id]
Is there a means to do a 303 redirection via a javascript view?

ACCEPT vary:
Another point is that a resource should be able to be rendered in 
multiple manners.  One popular approach is for web browsers to typically 
get XHTML+RDFa  while machines can send an accept header with media type 
like application/rdf+xml and get an RDF version of the same information 
at the same URI.  The different rendering is done by the app server 
based on the ACCEPT header settings.

Question:  Is it possible for couchdb to take a method GET request for a 
URI like:[some_doc_id] and render different 
views of the stored JSON (say as XHTML or RDF) based on the ACCEPT 
header.  Note, converting from JSON to some other format is "just 
programming".  I am curious about if there is a mechanism within couchdb 
that would expose the ACCEPT header to code.
Again, it seems like the "doc" URI is not the place to do this and a 
second view like:[some_doc_id]
is again needed?

Can a view see/get HTTP header information?

Really these two things seem like the core aspects that would enable 
couchdb to not only be RESTful but also play in a linked data approach 
to being placed in a large web architecture based approach.

I have been looking at the  validate_doc_update as well wondering if 
there is something in that approach that might address some of this as well.

Thanks much for any and all comments...

View raw message