Hi Richard,
I'm new to sword and this thread, so apologies if this has already been
covered, but one thought...
On Fri, Feb 04, 2011 at 08:54:49AM +0000, Richard Jones wrote:
> Dear All,
>
> Thanks for your extensive feedback on the various issues that we have
> been discussing on this list, it has been really valuable for the
> project team to get this input. We have, we think, identified 3
> particular issues of contention:
>
> 1/ Whether the Statement should be embedded in the Deposit Receipt or be
> a separate document referenced in an atom:link element
...why don't you allow servers to optionally inline the content within the
link? There are two separate IETF I-Ds covering an atom link inline extension,
one older [1] and one newer [2] which I believe is active.
I.e., allow something like...
<atom:entry>
<atom:link rel="http://purl.org/net/sword/terms/statement";
type="application/rdf+xml" href="http://.....";>
<atom:inline>
<rdf:RDF>
<!-- ORE statement goes here -->
</rdf:RDF>
</atom:inline>
</atom:link>
<atom:link rel="http://purl.org/net/sword/terms/statement";
type="application/atom+xml;type=feed" href="http://.....";>
<atom:inline>
<atom:feed>
<!-- statement goes here -->
</atom:feed>
</atom:inline>
</atom:link>
</atom:entry>
Seems to be a fairly commonly used pattern (we use it heavily for a malaria
data repository project).
Cheers,
Alistair
[1] http://tools.ietf.org/html/draft-mehta-atom-inline-01
[2] http://tools.ietf.org/html/draft-snell-atompub-inline-01
>
> 2/ Whether to use OAI-ORE for the Statement format or an Atom Feed (as
> per CMIS and GData)
>
> 3/ How the client and server should negotiate over the format of the
> content returned by the edit-media link (EM-URI)
>
> The project team has gone through each of these issues carefully, and
> attempted to extract the simplest solutions but with a view to keeping
> the SWORD 2.0 specification quite open at this stage, so that community
> best practices can actually inform the standard itself in the long run.
> Therefore, we're proposing the following approaches to these issues:
>
> 1/ Whether the Statement should be embedded in the Deposit Receipt or be
> a separate document referenced in an atom:link element
>
> If the Statement is to be embedded in the Deposit Receipt, then it needs
> really to be in OAI-ORE form, for the purposes of being clear foreign
> markup. Nonetheless, bearing in mind that there is a question as to
> whether the Statement should be an Atom Feed, it is clear that this
> solution will not be adequate by itself. We therefore propose that the
> standard provided to the project's funded developers to code against
> says that an OAI-ORE serialisation MAY be embedded in the Deposit
> Receipt (the Deposit Receipt will not be required to meet the OAI-ORE
> spec for being a resource map itself).
>
> Alongside - or instead - of this, there MAY be one or more atom:link
> elements in the Deposit Receipt which link to an external Statement.
> These atom:link elements can specify their type attribute to say whether
> they are an application/rdf+xml or application/atom+xml;type=feed. It
> will be a requirement of the spec that there MUST be an embedded
> Statement or at least one separate Statement.
>
> Therefore, you may see a Deposit Receipt like:
>
> <atom:entry>
> <atom:link rel="http://purl.org/net/sword/terms/statement";
> type="application/rdf+xml" href="http://....."/>
>
> <rdf:RDF>
> <!-- ORE statement goes here -->
> </rdf:RDF>
> </atom:entry>
>
> 2/ Whether to use OAI-ORE for the Statement format or an Atom Feed (as
> per CMIS and GData)
>
> Another good reason for the approach in (1) is that this means we can
> provide different Statement URIs with different type attributes. We
> plan to ask developers to produce an ORE and an Atom Feed Statement
> format under the project funding. So you may see a Deposit Receipt like:
>
> <atom:entry>
> <atom:link rel="http://purl.org/net/sword/terms/statement";
> type="application/rdf+xml" href="http://....."/>
>
> <atom:link rel="http://purl.org/net/sword/terms/statement";
> type="application/atom+xml;type=feed"
> href="http://....."/>
>
> <rdf:RDF>
> <!-- ORE statement goes here -->
> </rdf:RDF>
> </atom:entry>
>
> The combination of approaches in (1) and (2) may seem woolly or
> indecisive, but we believe that we can't determine in advance which of
> these approaches is better, and that it should be up to the community of
> users and implementers to decide which approach works best based on
> actual usage of the developed software. Therefore, while the burden of
> implementation is placed on the funded portion of the project, we expect
> community driven implementations/usages to favour one approach over
> another (possibly taking into account things like compatibility with
> GData and CMIS, or preferring the more semantic web approach of ORE).
> We can then use this information later in deriving a SWORD spec which is
> based on best practices.
>
> 3/ How the client and server should negotiate over the format of the
> content returned by the edit-media link (EM-URI)
>
> The Content Negotiation issue arises from the fact that AtomPub requires
> at most one edit-media URI with a given type to be available in the Atom
> Entry (Deposit Receipt). Since the SWORD server may contain multiple
> files rather than the one file that AtomPub assumes, what this EM-URI
> returns under GET is unclear. We initially considered 2 approaches:
>
> a/ A separate HTTP header like Accept-Packaging to allow content
> negotiation on a package format
> b/ A separate HTTP header like Accept-Media-Features to allow general
> content negotaiton on feature sets
>
> As we discussed, both of these have pros and cons, and none of the
> approaches to doing this are marked by any best practices, which makes
> the project team unwilling to commit to anything too complex or
> substantial, at a risk to the simplicity and overall success of SWORD.
> Instead we are suggesting adopting a much simpler approach:
>
> The Deposit Receipt can contain already contain a sword:package element
> (as per SWORD 1.3), and SWORD 2 plans to allow an arbitrary number of
> such elements. These elements will describe the packaging formats
> supported by the server, so the client will know in advance what the
> capabilities of the server are. Therefore, instead of engaging in a
> content negotiation process, the client will just specify a separate
> HTTP header indicating what package format should be returned. Whether
> this header re-uses the Packaging header used during deposit or
> specifies a new header has yet to be decided.
>
>
> Hopefully these approaches make sense to the group. We are interested
> in how you think these will go down both during the project and beyond
> in the community, and if there are any obvious problems with what we're
> proposing here as the way forward for SWORD.
>
> All the best,
>
> Richard
> (On-Behalf-Of the SWORD project team)
>
>
>
> ------------------------------------------------------------------------------
> The modern datacenter depends on network connectivity to access resources
> and provide services. The best practices for maximizing a physical server's
> connectivity to a physical network are well understood - see how these
> rules translate into the virtual world?
> http://p.sf.net/sfu/oracle-sfdevnlfb
> _______________________________________________
> Sword-app-techadvisorypanel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/sword-app-techadvisorypanel
--
Alistair Miles
Head of Epidemiological Informatics
Centre for Genomics and Global Health <http://cggh.org>
The Wellcome Trust Centre for Human Genetics
Roosevelt Drive
Oxford
OX3 7BN
United Kingdom
Web: http://purl.org/net/aliman
Email: [email protected]
Tel: +44 (0)1865 287669
------------------------------------------------------------------------------
The modern datacenter depends on network connectivity to access resources
and provide services. The best practices for maximizing a physical server's
connectivity to a physical network are well understood - see how these
rules translate into the virtual world?
http://p.sf.net/sfu/oracle-sfdevnlfb
_______________________________________________
Sword-app-techadvisorypanel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sword-app-techadvisorypanel
