Hi Phil,
The sword clients themselves are pretty raw, and designed only to take the
data you want to send and serialise it to the wire and then parse the
response and give you a decent programmatic way of interacting with it.
You could certainly write a wrapper around a client which gave you a bit
more control over what documents you could construct and send, but I would
certainly keep those separate from the client itself.
Going in a similar direction, although certainly not the same, I have been
working with the University of Oxford to build a git-like client
environment for sword, which allows you to select local files or specify
metadata (in dc, or other formats), and to identify repositories to which
you would like to deposit, and then give you a push from your local
object to some remote repository. This doesn't do anything clever with
metadata, but it does have a whole aspect to do with packaging, and perhaps
the concept could be extended to cover the kind of validation that you
describe below.
Essentially, when you deposit you ask it to either deposit all the content
in some package format, or you ask it to deposit a specific metadata
format.
In the package deposit case it loads a plugin which knows how to do that
format, and it builds the zip for you before sending it - at this stage you
could validate the content of the object to check that it can be packaged,
and give the user feedback if this validation fails.
In the metadata deposit case, it just sends the XML of the metadata that it
has on record, but you could theoretically make the process more
plugin-oriented, so that you could specify a validation route prior to
deposit.
At the moment the code is in a not-quite-finished state, but you are
welcome to take a look. The core library is here:
https://github.com/CottageLabs/dip
and there is the beginnings of a command line environment here:
https://github.com/CottageLabs/dip-ui
Also, generally interested in your thoughts on this - is it useful, are we
going in an interesting direction?
Cheers,
Richard
On 20 May 2014 16:13, Philip Durbin philip_dur...@harvard.edu wrote:
I was just looking at Typically, the subject will be represented
using keywords, key phrases, or classification codes. Recommended best
practice is to use a controlled vocabulary. from
http://dublincore.org/documents/2012/06/14/dcmi-terms/?v=terms#subject
Let's pretend I take this advice and only want to support a controlled
vocabulary for dcterms:subject. Something like this:
dcterms:subjectArts and Humanities
dcterms:subjectAstronomy and Astrophysics
dcterms:subjectBusiness and Management
etc. etc.
But can I communicate my list of controlled vocabulary for
dcterms:subject (and possibly other fields such as dcterms:language)
to the SWORD client in the Service Document?
Of would I let the SWORD client *try* to create an Atom resource and
when it fails (because it can't possibly guess what my controlled
vocabulary is) that's when I state in the error message what the
controlled vocabulary is? Sorry, you must use one of the following
values: Arts and Humanities, ... Seems messy to parse.
I expect the answer to all this will be... don't even try this... the
S in SWORD is for simple. :)
But I'm curious what people think.
Phil
--
Philip Durbin
Software Developer for http://thedata.org
http://www.iq.harvard.edu/people/philip-durbin
--
Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform
available
Simple to use. Nothing to install. Get started now for free.
http://p.sf.net/sfu/SauceLabs
___
sword-app-tech mailing list
sword-app-tech@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sword-app-tech
--
Richard Jones,
Founder, Cottage Labs
t: @richard_d_jones, @cottagelabs
w: http://cottagelabs.com
--
Time is money. Stop wasting it! Get your web API in 5 minutes.
www.restlet.com/download
http://p.sf.net/sfu/restlet___
sword-app-tech mailing list
sword-app-tech@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sword-app-tech
