Re: [sword-app-tech] URI in SWORD Post Responses

[Jim D. <oj...@ca...>]

Hi Tim,

This is one of the most changed areas of the spec since 1.2, and I'm
guessing that you're looking at 1.2 implementations. It's the atom:content
element that matters in 1.3.

The consensus was (is) that because of the situations where one deposit
might create many resources or  a POST might be successful but result in no
resources being created at all due to moderation etc, it was better to leave
the nature of the content@src resource undefined in the spec. It would be
interesting to know whether this is a big problem for applications like
BibApp.

Best regards,
jim



2008/11/25 Tim Donohue <tdo...@il...>

> I'm been working on updating the Ruby SWORD client that I built for
> Bibapp software (www.bibapp.org).  With BibApp, we want to be able to
> send files+metadata to a repository via SWORD, and maintain a link (in
> BibApp) to the "final resting place" of that item in the repository.
> The end result is that BibApp just has a link to the item(s) after it
> has successfully posted them to one or more repositories.
>
> So, for us, the *response* we receive from the SWORD server after a
> successful POST is important.  Unfortunately, it seems that there's
> little-to-no standardization around returning URI information in the
> response from DSpace, EPrints and Fedora.
>
> Based on the Atom PP Spec, it looks like it's recommended that an
> item's URI (or IRI, more appropriately) should be returned in <atom:link
> rel="edit"> in the response. [1]
>
> However, the SWORD server implementations don't seem to consistently
> follow this recommendation.  Here's what I'm seeing as responses from
> DSpace, Fedora and Eprints respectively:
>
>
> =======================
> DSpace 1.5.1 SWORD Response:
> (URI is in <atom:id>,
> "rel" attribute not even used on <atom:link>)
> =======================
>
> <atom:entry>
>   <atom:id>http://hdl.handle.net/123456789/5023</atom:id>
>   ...
>   <atom:link
> href="
> http://lakshmi.grainger.uiuc.edu/ideals//bitstream/123456789/5023/1/pdf1.pdf
> "/>
>   ...
> </atom:entry>
>
>
> =======================
> Fedora SWORD Response:
> (URI is in <atom:link rel="edit">)
> =======================
>
> <atom:entry>
>   <atom:id>sword:151</atom:id>
>   ...
>   <atom:link
> href="http://glen.dnsalias.org:8080/fedora/get/sword:151/ServletClient-7"
>    rel="edit-media" hreflang="en"/>
>   <atom:link href="http://glen.dnsalias.org:8080/fedora/get/sword:151"
>    rel="edit" hreflang="en"/>
>   ...
> </atom:entry>
>
>
> =======================
> EPrints SWORD Response:
> (URI is in <atom:link rel="edit-metadata"> ?)
> =======================
>
> <atom:entry>
>   <atom:id>2328</atom:id>
>   ...
>   <atom:link
> href="http://demoprints.eprints.org/sword-app/collections/2328"
>    rel="edit-media"/>
>   <atom:link
> href="http://demoprints.eprints.org/sword-app/collections/2328.atom"
>    rel="edit"/>
>   ...
> </atom:entry>
>
>
> Overall, Fedora looks to have the most "correct" implementation. EPrints
> seems to be using rel="edit-metadata", and DSpace uses <atom:id>.   Is
> there any work being done to make recommendations around how to
> appropriately structure these responses from a SWORD server?  Maybe I
> missed something in SWORD 1.3 dealing with this?
>
> Any recommendations/suggestions from any of the SWORD experts out there? :)
>
>
> References:
>
> [1] Atom Publishing Protocol Spec, on the "edit" link relation:
>
> http://www.atomenabled.org/developers/protocol/atom-protocol-spec.php#atom-entry-extensions
>
>
> - Tim
>
> --
> Tim Donohue
> Research Programmer, IDEALS
> http://www.ideals.uiuc.edu/
> University of Illinois
> tdo...@il... | (217) 333-4648
>
>
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> sword-app-tech mailing list
> swo...@li...
> https://lists.sourceforge.net/lists/listinfo/sword-app-tech
>