Re: [Sword-TAP] Decisions regarding the challenges of SWORDv2
For my 2 pence, I have implemented the statement in EPrints in the Google Docs API way which has solved a lot of problems with one solution in my view and is also compliant with the GDocs clients. If an object has contents (e.g. a resource has many documents) then the following tags are included in the atom: http://schemas.google.com/docs/2007"; xmlns:batch="http://schemas.google.com/gdata/batch"; xmlns:gd="http://schemas.google.com/g/2005";> http://schemas.google.com/g/2005#kind"; term="http://schemas.google.com/docs/2007#folder"; label="folder"/> [Required to state that this item has contents] http://www.myrepository.com/id/eprint/154/contents"/> [The abstract URI for the contents of the folder/resource] http://www.myrepository.com/id/eprint/154/contents"/> [Direct link to contents of resource - not from GDocs API] According to GDocs if you want to put an item in a folder, you create the folder then post to the contents URI (the EM-URI) which can then return an entry corresponding to the document where the Edit-Media URI is then the URI of the item, not the abstract one (solving that problem) So for backward compatibility, if a SWORD 1.3 client posts a file, I think we should create the container (folder) put the file in the contents URI and return the EM-URI as the contents link, not the document URI (unless the folder only contains one file at which point it might just be easier to return the URI of that as the edit-media URI). Further if you wanted you could content negotiate on the contents URI to return a single file/document of that type. A kinda bodge of all previous thoughts! SWORD 2 clients should first create the container, obtaining the contents URI and then POST files into this. A statement about any of the URIs can then be obtained by simply querying the URI of each element (container and contents). Further you can create really complex objects (if the server lets you) by creating lots of sub-folders for HTML documents for example. Really quiet nice, plus all the implementation docs are already written. Dave T On 10 Feb 2011, at 07:51, Richard Jones wrote: > Hi Alistair, > >> 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 +, 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... >> >> >> http://purl.org/net/sword/terms/statement"; >> type="application/rdf+xml" href="http://.";> >> >> >> >> >> >> >> http://purl.org/net/sword/terms/statement"; >> type="application/atom+xml;type=feed" href="http://.";> >> >> >> >> >> >> >> >> >> Seems to be a fairly commonly used pattern (we use it heavily for a malaria >> data repository project). > > This is quite intriguing, I definitely want to consider using this > approach. There is only one thing that I'm not sure about: > > It is possible (at the moment) that servers may only supply the embedded > Statement, and not any atom:link elements which resolve to it. In this > case there would be no atom:link to embed the atom:inline inside. > > The question then, is should we /require/ that a server be able to > provide at least one separate Statement URI? If so, then I think we > should adopt the atom:inline approach here, but if not we'll have to > continue with the rdf embedded as foreign markup. > > Looking at the examples in the references, I see that they actually > embed atom:feed elements; this would level the playing field nicely with > ORE as the embedded format. > > Thoughts? > > Cheers, > > Richard > > >> >> 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 specificati
Re: [Sword-TAP] Decisions regarding the challenges of SWORDv2
Hi Alistair, > 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 +, 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... > > > http://purl.org/net/sword/terms/statement"; > type="application/rdf+xml" href="http://.";> > > > > > > > http://purl.org/net/sword/terms/statement"; > type="application/atom+xml;type=feed" href="http://.";> > > > > > > > > > Seems to be a fairly commonly used pattern (we use it heavily for a malaria > data repository project). This is quite intriguing, I definitely want to consider using this approach. There is only one thing that I'm not sure about: It is possible (at the moment) that servers may only supply the embedded Statement, and not any atom:link elements which resolve to it. In this case there would be no atom:link to embed the atom:inline inside. The question then, is should we /require/ that a server be able to provide at least one separate Statement URI? If so, then I think we should adopt the atom:inline approach here, but if not we'll have to continue with the rdf embedded as foreign markup. Looking at the examples in the references, I see that they actually embed atom:feed elements; this would level the playing field nicely with ORE as the embedded format. Thoughts? Cheers, Richard > > 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: >> >> >> http://purl.org/net/sword/terms/statement"; >> type="application/rdf+xml" href="http://."/> >> >> >> >> >> >> >> 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: >> >> >> http://purl.org/net/sword/terms/statement"; >> type="application/rdf+xml" href="http://."/> >> >> http://purl.org/net/sword/terms/statement"; >> type="application/atom+xml;type=feed" >> href="http://."/> >> >> >> >> >> >> >
Re: [Sword-TAP] Decisions regarding the challenges of SWORDv2
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 +, 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... http://purl.org/net/sword/terms/statement"; type="application/rdf+xml" href="http://.";> http://purl.org/net/sword/terms/statement"; type="application/atom+xml;type=feed" href="http://.";> 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: > > > http://purl.org/net/sword/terms/statement"; > type="application/rdf+xml" href="http://."/> > > > > > > > 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: > > > http://purl.org/net/sword/terms/statement"; > type="application/rdf+xml" href="http://."/> > > http://purl.org/net/sword/terms/statement"; > type="application/atom+xml;type=feed" > href="http://."/> > > > > > > > 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) >
Re: [Sword-TAP] Decisions regarding the challenges of SWORDv2
I think at this stage, the question should be 'does this make things easier for people to use and implement, or does it make it harder?' - the points being discussed are likely to be tested by implementation. Certain of the points would require very little code to be changed to switch between uses, and if there is an implementation issue or an issue about semantics that other people might get worried about, then this will be the point at which it will become apparent. And if nobody aside from us cares one way or the other, then I think we can prioritise the discussions around them accordingly. Ben On 4 February 2011 08:54, 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 > > 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: > > > http://purl.org/net/sword/terms/statement"; > type="application/rdf+xml" href="http://."/> > > > > > > > 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: > > > http://purl.org/net/sword/terms/statement"; > type="application/rdf+xml" href="http://."/> > > http://purl.org/net/sword/terms/statement"; > type="application/atom+xml;type=feed" > href="http://."/> > > > > > > > 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 Accep
[Sword-TAP] Decisions regarding the challenges of SWORDv2
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 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: http://purl.org/net/sword/terms/statement"; type="application/rdf+xml" href="http://."/> 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: http://purl.org/net/sword/terms/statement"; type="application/rdf+xml" href="http://."/> http://purl.org/net/sword/terms/statement"; type="application/atom+xml;type=feed" href="http://."/> 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 kno
