Quoth Asger Askov Blekinge on Sat, Oct 31, 2009 at 07:56:29AM -0400: > Either we devise a language to embed in the POST content (like Delete, > Update, Create), to work around the problems with where content can be.
Perhaps something like SPARQL/Update? http://jena.hpl.hp.com/~afs/SPARQL-Update.html Alternately, I’ve also seen people give each statement its own URI and letting people DELETE that, but that can get a bit ugly. For me, I’m not sure: I’ve clearly put a lot less thought into it than several other people here. My sense, though, is that all of these (even addRelationship and purgeRelationship, really) are starting to blur the line between an object as a simple collection of datastreams and an object as a rich OO thingie. And while part of me appreciates the latter, the former’s focus on simplicity of data model seems important to repository sanity. But again, I’m a relative newcomer to this project, so I don’t claim to have the big picture. > On second thoughts, getting the entire RELS-EXT datastream on > /objects/{pid}/relations and being able to post an entire new version > directly to this location could work. If you wanted to combine with the > original relations, you must do it yourself, but you can post RDF > directly, instead of converting this to an URL You mean like a PUT to /objects/{pid}/datastreams/RELS-EXT in the current (~3.2.1) REST API? That’s worked reasonably well for me: GET RELS-EXT, parse it, modify it, serialize it, and PUT a new version. It feels like a fair chunk of work on the client side, but I found it easy enough to wrap in a client-side function. -- Ben Ranker <bran...@emory.edu> Software Engineer, Sr. Emory University Libraries
signature.asc
Description: Digital signature
------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference
_______________________________________________ Fedora-commons-developers mailing list Fedora-commons-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers
