Not quiet Ian,
As Richard points out in section 12.1 of the atom pub specification, the type
of the EM-URI can be either an entry/feed or other mime type identifying the
media resource.
If you point the EM-URI at a feed (as this says you can) then each <entry> in
this feed can also have multiple contents and/or EM-URI links within it
pointing at different encodings of the same single bitstream item of media.
So the TOP level EM-URI represents a folder. Within this folder are lots of
files, some of which are grouped (by an atom:entry) and stated to be different
serialisations of the same file.
Here is a quick example (the full writeup on which can be found @
https://docs.google.com/document/d/1wkPPk1gHFOZGeJpzFwbIqe-t6CCdbbt6WWyBrccKvyU/edit?hl=en).
I hope this helps somewhat and that this seems logical to everyone using
section 12.1 of the atom specification in this way. There has been some
discussion on the atom pub mailing list some years ago about the multi-media
problem. I can dig it out, but it seems to concur with the ideas presented here
although they never took it as far as officially adding it to the spec. This is
a realisation of how it could be done within the bounds of the specification.
Cheers
Dave T
Lets say we have created our Top level object and it looks like this (using a
Get request to fetch it)
GET /object/1 HTTP/1.1
Host: repo.org
Accept: application/atom+xml
Authorization: Basic ZGFmZnk6c2VjZXJldA==
HTTP/1.1 200 Ok
Date: Fri, 7 Oct 2005 17:18:11 GMT
Content-Length: nnn
Content-Type: application/atom+xml;type=entry;charset="utf-8"
ETag: "c181bb840673b5"
<?xml version="1.0"?>
<entry>
<title>My Fantastic Deposit</title>
<id>http://repo.org/object/1</id>
<updated>2005-10-07T17:17:08Z</updated>
<author><name>Davetaz</name></author>
<link rel="edit-media" type=”application/atom+xml;type=feed”
href="http://repo.org/media/object/1"; />
<link rel="edit” href="http://repo.org/edit/object/1"; />
</entry>
Using this we can then get the media feed.
Note the edit-media and contents links in red which represent a different
serialisation of the same media item, these can be added by POSTing this
version to the Location URI returned when the first one was added type and/or
lang of the POSTed versions have to be different from those already listed.
GET /media/object/1 HTTP/1.1
Host: repo.org
Accept: application/atom+xml
Authorization: Basic ZGFmZnk6c2VjZXJldA==
<?xml version="1.0"?>
<feed xmlns="http://www.w3.org/2005/Atom";>
<entry>
<title>Word Doc Title</title>
<id>http://repo.org/file/1</id>
<updated>2005-10-07T17:17:08Z</updated>
<author><name>Davetaz</name></author>
<content type="application/word" lang=”en”
src="http://repo.org/file/1"/>
<link rel="edit-media" type=”application/word” lang=”en”
href="http://repo.org/file/1"; />
<content type="text/rtf" lang=”es”
src="http://repo.org/file/3"/>
<link rel="edit-media" type=”text/rtf” lang=”es”
href="http://repo.org/file/3"; />
</entry>
<entry>
<title>Spreadsheet Title</title>
<id>http://repo.org/file/2</id>
<updated>2005-10-07T17:17:08Z</updated>
<author><name>Davetaz</name></author>
<content type="application/spreadsheet" lang=”en”
src="http://repo.org/file/2"/>
<link rel="edit-media" type=”application/spreadsheet” lang=”en”
href="http://repo.org/file/2"; />
</entry>
</feed>
GET /media/file/1 HTTP/1.1
Host: repo.org
Authorization: Basic ZGFmZnk6c2VjZXJldA==
HTTP/1.1 200 Ok
Date: Fri, 7 Oct 2005 17:19:12 GMT
Content-Length: nnn
Content-Type: application/word
ETag: "c181bb840673b6"
… binary data ...
On 15 Apr 2011, at 12:01, Ian Stuart <ian.stu...@ed.ac.uk> wrote:
> On 12/04/11 17:34, Richard Jones wrote:
>> 2/ Add a section to explicitly allow the client to GET an atom:feed and
>> to POST content to the EM-IRI.
>>
>> The former of these is consistent with AtomPub as it stands at the
>> moment, so is uncontentious. SWORD will profile AtomPub appropriately here.
>>
>> The second of these allows the client to create new resources inside the
>> Media Resource itself, rather than the Entry Resource (identified by the
>> Edit-IRI). At the moment SWORD allows POST to the SE-IRI (which is
>> effectively the Edit-IRI) to add content to the container, but not to
>> the EM-IRI. Neither is this in the original AtomPub spec.
>>
>> The purpose of doing this is that when the server responds, it can
>> return an atom:entry for the deposited resource (or an atom:feed, see
>> questions below), giving the client the identifier that it requires as
>> per the stated problem. Note that this atom:entry is NOT the Deposit
>> Receipt as described by SWORD (at least, we don't think so - see
>> questions below).
>>
>>
>> 3/ To add to the Deposit Receipt an atom:link@rel="edit-media" with
>> href="application/atom+xml;type=feed" in order to support the GET of the
>> EM-IRI as described in (2) above.
>
>
> Can I just clarify what this means when an item has multiple Media items?
> For example, lets assume we have created a deposit & transferred in the
> Authors Final Version as a .doc file.
> Under ATOM, we can include the Authors Final Version in .rtf, .ods, and
> even .pdf formats, as these are all variations on the same media item.
> What happens when the depositor wants to add the spreadsheet of
> supporting data?
> RFC 5023 states in 11.2 'All "edit-media" link relations in the same
> Entry reference the same Resource. If a client encounters multiple
> "edit-media" link relations in an Entry then it SHOULD choose a link
> based on the client preferences for "type" and "hreflang"'
>
> As far as I can see from the current discussions, SWORD doesn't cope
> with this....
>
> --
>
> Ian Stuart.
> Developer: Open Access Repository Junction and OpenDepot.org
> Bibliographics and Multimedia Service Delivery team,
> EDINA,
> The University of Edinburgh.
>
> http://edina.ac.uk/
>
> This email was sent via the University of Edinburgh.
>
> The University of Edinburgh is a charitable body, registered in
> Scotland, with registration number SC005336.
>
>
> ------------------------------------------------------------------------------
> Benefiting from Server Virtualization: Beyond Initial Workload
> Consolidation -- Increasing the use of server virtualization is a top
> priority.Virtualization can reduce costs, simplify management, and improve
> application availability and disaster protection. Learn more about boosting
> the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
> _______________________________________________
> Sword-app-techadvisorypanel mailing list
> Sword-app-techadvisorypanel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/sword-app-techadvisorypanel
------------------------------------------------------------------------------
Benefiting from Server Virtualization: Beyond Initial Workload
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve
application availability and disaster protection. Learn more about boosting
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
_______________________________________________
Sword-app-techadvisorypanel mailing list
Sword-app-techadvisorypanel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sword-app-techadvisorypanel
