Hi Richard et al., So sorry for the glacially slow reply. I'm not sure about the header idea. I haven't given it much thought, to be honest.
I did want say, "Yes! Exactly!" to you saying, "the schema didn't even come close to fitting dcterms" because in integrating Dataverse (my side) and Open Journal Systems (their side) we agreed upon what I've been calling "the XML attribute" hack to pack more (desperately needed) information into a dcterms XML element. This is best illustrated by example, I believe. Sure we support run-of-the-mill dcterms elements like this... <dcterms:title>Roasting at Home</dcterms:title> <dcterms:creator>Peets, John</dcterms:creator> <dcterms:creator>Stumptown, Jane</dcterms:creator> <dcterms:publisher>Coffee Bean State University</dcterms:publisher> ... but in order to get the article citation from OJS into Dataverse, we special case the "dcterms:isReferencedBy" element, allowing OJS to put extra XML attributes (DDI stuff like holdingsURI, agency, and IDNo) into the XML element like this: <dcterms:isReferencedBy holdingsURI="http://dx.doi.org/10.1038/dvn333"; agency="DOI" IDNo="10.1038/dvn333">Peets, J., & Stumptown, J. (2013). Roasting at Home. New England Journal of Coffee, 3(1), 22-34.</dcterms:isReferencedBy> It gets the job done AND I just learned today at http://irclog.iq.harvard.edu/dvn/2014-05-01#i_8982 that OJS got this "hack" merged into the PHP bindings for SWORD in this pull request: Allow attributes on dcterms elements in Atom entries by jwhitney · Pull Request #6 · swordapp/swordappv2-php-library - https://github.com/swordapp/swordappv2-php-library/pull/6 So maybe we (Dataverse and OJS) are not so off the mark with this... "interpretation" of SWORD... but I certainly feel like this isn't in the official spec and I don't know if this sort of thing is supported in any other client or server libraries. Phew! Glad to get that off my chest! :) Phil On Mon, Feb 10, 2014 at 1:42 PM, Richard Jones <rich...@cottagelabs.com> wrote: > Hi Phil, > > We have been doing this for the Duo project in Oslo. We're transferring > some custom student theses metadata from the national student system to the > repository, and the schema didn't even come close to fitting dcterms, so we > home-cooked our own (using dc where possible, but extending where > necessary). Here's my SwordEntryIngester that deals with the metadata-only > portion of the deposit (which is only a few fields): > > https://github.com/nye-duo/Duo-DSpace/blob/master/src/main/java/no/uio/duo/FSEntryIngester.java > > When doing a full package deposit we have a larger metadata file, which is > crosswalked just using an xslt to the native DSpace schema. > > So, not crazy - absolutely intended usage :) > > A thought that has been bashing around in my head for a while - we currently > have a way to describe what format the package being deposited is (via the > Packaging header), but no way to say what kind of metadata you are > depositing. From a server point of view, this means that if you support > multiple metadata formats, you need a bit of code that can look and try and > figure it out, rather than relying on an explicit cue from the deposit. But > would adding a header to give this information be viable/useful? > > Cheers, > > Richard > > > On 10 February 2014 17:50, Philip Durbin <philip_dur...@harvard.edu> wrote: >> >> Dear SWORDers, >> >> Sure, we all support dcterms, which is a simple key/value schema, in >> the Atom entry when creating a Resource. >> >> But what about going beyond dcterms? >> >> We are interested in supporting richer formats, some of which are >> hierarchical, such as DDI, as detailed below. >> >> Is anyone supporting anything other than dcterms when creating >> Resources? Is this crazy talk? >> >> Thanks in advance for the sanity check! >> >> Phil >> >> p.s. Here are the details of our situation: >> >> So far, according to the OJS Dataverse plugin testers surveyed with >> results recorded at >> >> https://docs.google.com/spreadsheet/ccc?key=0AjeLxEN77UZodDJyd0pZdnlDZ3I5eWxnOHBmV1Q4dHc&usp=sharing >> the most commonly requested feature is the ability to customize which >> metadata fields are available as part of the data deposit form, which >> should be implemented in a future version. In order to support this, >> we will need to expand the API's metadata support beyond Dublin Core >> metadata. SWORD Protocol *should* be flexible enough for us to use >> other standards like DDI. At >> >> http://swordapp.github.io/SWORDv2-Profile/SWORDProfile.html#protocoloperations_creatingresource_entry >> the SWORDv2 spec says (emphasis added): >> >> > * The client *SHOULD add Dublin Core* [DublinCore] terms to the Atom >> > Entry as foreign markup (if appropriate); the terms MUST be embedded as >> > direct children of the atom:entry element, if present. >> > * The client *MAY add any other metadata formats or foreign markup* to >> > the atom:entry element >> >> We interpret this to mean that in addition to Dublin Core (dcterms, >> specifically), the SWORD spec is flexible enough to support wildly >> different metadata formats such as DataCite (https://www.datacite.org >> ), DDI (Data Documentation Initiative: http://www.ddialliance.org ), >> VO (Virtual Observatory: http://www.ivoa.net/documents/latest/RM.html >> ) ISA-Tab (Investigation, Study, and Assay in Tabular format: >> http://isatab.sourceforge.net/format.html ), etc. >> >> >From https://redmine.hmdc.harvard.edu/issues/3425 >> >> -- >> Philip Durbin >> Software Developer for http://thedata.org >> http://www.iq.harvard.edu/people/philip-durbin >> >> >> ------------------------------------------------------------------------------ >> Android™ apps run on BlackBerry®10 >> Introducing the new BlackBerry 10.2.1 Runtime for Android apps. >> Now with support for Jelly Bean, Bluetooth, Mapview and more. >> Get your Android app in front of a whole new audience. Start now. >> >> http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk >> _______________________________________________ >> 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 > -- 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
