Hi Phil,

Looks like devious usage of dcterms xml :)

I'm sure a metadata purist would not be so happy, but from sword's point of
view this is all fine.  I guess either way you need to modify the ingester
on the repository end to pull out all your special attributes, and so if
you wanted to be less-dc about it, you could just replace the existing
ingester which understands the full OJS export format.

Just thinking out loud: OJS has a native export format (which contains the
base64 encoded files) and also supports the DOAJ format.  Would be cool if
they were available over sword, and if there was an ingester for DSpace
that could handle them.  Probably wouldn't be an enormous amount of work,
either!

Cheers,

Richard



On 1 May 2014 21:25, Philip Durbin <philip_dur...@harvard.edu> wrote:

> 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., &amp; 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&trade; apps run on BlackBerry&reg;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
>



-- 

Richard Jones,

Founder, Cottage Labs
t: @richard_d_jones, @cottagelabs
w: http://cottagelabs.com
------------------------------------------------------------------------------
"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

Reply via email to