All,
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:
http://www.w3.org/DesignIssues/LinkedData.html) and "cool uri's" (Ref:
http://www.w3.org/TR/cooluris/).
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).
Redirection:
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)
http://my.domain.org/source/_design/resource/_view/ref/[some_doc_id}
which could 303 to
http://my.domain.org/source/[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: http://my.domain.org/source/[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:
http://my.domain.org/source/_design/resource/_view/render/[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...
Doug
