[Sword-TAP] Fwd: Key Changes and Justifications
-- Forwarded message -- From: Graham Triggs Date: 22 January 2011 05:00 Subject: Re: Key Changes and Justifications To: Tim Brody Cc: Richard Jones , [email protected] On 21 January 2011 14:54, Tim Brody wrote: > > I don't think bundling things into a .zip saves you work because it just > moves the complexity into a different domain. You will get 90% of the way > to moving objects from one system to another with low loss by using Atom + > Dublin Core + a feed of media resources. If you require more complexity but > in a limited scope use a private MIME type. > Hmm. I'm going to step in here with regards to metadata. From doing (real, live) publisher to repository deposits - and from discussions in the DSpace community about what we want to be able to do with our repositories - Dublin Core or even SWAP simply doesn't cut it. As a publisher, we have more metadata available that we would want to pass to the repositories, which they have told us they want to take, and is needed to properly support export functionality from the repository that is desired. G -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ Sword-app-techadvisorypanel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/sword-app-techadvisorypanel
[Sword-TAP] Fwd: Key Changes and Justifications
-- Forwarded message -- From: Tim Brody Date: 22 January 2011 03:54 Subject: Re: Key Changes and Justifications To: Richard Jones Cc: [email protected] On Fri, 21 Jan 2011 12:57:19 +, Richard Jones wrote: > Hi Tim, > While this is all lovely... Why is it that Google docs API and CMIS both use THE SAME solution to returning an ATOM entry which has a link rel to a feed which outlined the resources which are part of this object? >>> >>> Wouldn't this require an extra URI? >>> >>> In the original proposal we had a Deposit Receipt as an Atom Entry, >>> and a Statement as a separate document (which you could content >>> negotiate for, so rdf or an atom feed would have been fine), but when >>> we discussed it you were against this approach. It was, in fact, you >>> who convinced me that the Statement should become part of the Deposit >>> Receipt rather than a document in its own right! >> >> The root feed in SWORD contains a list of atom entries that (I think) we >> all agree should be the top level of the 'work'. > > Do you mean the service document? Each entry in there is a Collection, > in line with the Atom definition. I mean the root collection that the SWORD client interacts with i.e. where a dumb AtomPub client would start POSTing entries to. >> The workflow state is >> the state of the 'work' so lives at this level. It isn't overly >> controversial to have this as inline or as a link-rel. > > During the original feedback to the white paper, it was felt that doing > this inline was insufficient, as the state information could be > extensive depending on your implementation decisions. Would your > atom:link go to another document for describing the state, as opposed to > the Statement (which describes the object and the state)? Yes, I think. Use *two* : one to the contents and one to the state. >> What's more >> important is the mechanism to change that state - do you PUT to the >> , do a pseudo-move (see CMIS/GData) between collections or >> use some new RPC (POST?args)? > > We are not planning to include any semantics to allow the depositor to > change the state in this way. SWORD is a deposit tool only, and the > idea of relating the state back to the client is for informational > purposes only. I think it's a step to far to attempt to include > workflow controls into SWORD a) this early (before CRUD is even settled > in) or b) possibly even at all. Well anything you define I would define "in the light" of the mechanisms used in CMIS/GData: the ability to PUT to an ACL to change permissions or to POST to a collection with a src to move entries between collections. So you could control state by PUTting a modified Statement (as long as it lives at a URI). >> What Dave is talking about is how the media is represented (which >> relates to 'packaging'). What we've discussed at Soton and decided, >> before looking at CMIS & GData, is that the simplest representation of >> the *contents of the work* is a link-reled that aggregates the 0 >> or more media resources. > > I agree with this approach almost entirely: In the original proposal > the contents of the work were to be retrievable via the Statement > (located from a link-rel), for which we had proposed ORE as the format. > Nonetheless, the business case also stated that this format would be > content negotiable, so an application/atom+xml;type=feed content type > would be acceptable if you wanted to implement one. After extensive > discussion with Dave, he convinced me that the Statement should be > embedded in the Deposit Receipt, not available under a separate URI - > hence my confusion at the latest feedback. > > [snip] Don't combine contents and statement in one: atom:entry # work | |- RDF:statement # workflow status | |- atom:feed # contents That is the conceptual model. Linked is more flexible in terms of CRUD but it may be useful to inline where that will help dumb AtomPub clients. >> As Scott has previously suggested creating a >> complex object involves multiple POSTs to the link-reled feed. CMIS & >> GData use this mechanism to support folders. > > So the CMIS and GData approaches allow you to create a collection on the > server by POST? I had not proposed this approach because it is not part > of the AtomPub spec. Wouldn't it also make quite a big > back-compatibility issue, to change the deposit process in this way? > (not that there aren't such issues already, but at the moment updating > SWORD 1 code to SWORD 2 for POST only should be relatively minor - this > change would require more engineering). They support collection creation by POSTing an with special tags. IIRC CMIS uses a tag while GData uses . As the that triggers this behaviour is an extension it doesn't preclude any other valid AtomPub behaviour (including, if you wish, unpacking a SWORD Package in response to a X-Package HTTP header). You always return an but you have to understand t
[Sword-TAP] Fwd: Key Changes and Justifications
-- Forwarded message -- From: David Tarrant Date: 22 January 2011 02:06 Subject: Re: Key Changes and Justifications To: Richard Jones Cc: Tim Brody , [email protected] +1 The deposit recept should still return useful info, but all the info should be static, e.g. can never be changed, only deleted. On 21 Jan 2011, at 12:57, Richard Jones wrote: > Folks - Perhaps we could have a brief show of hands with regard to the notion > that the Statement be separated from the Deposit Receipt? -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ Sword-app-techadvisorypanel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/sword-app-techadvisorypanel
[Sword-TAP] Fwd: Key Changes and Justifications
-- Forwarded message -- From: Richard Jones Date: 22 January 2011 01:57 Subject: Re: Key Changes and Justifications To: Tim Brody Cc: [email protected] Hi Tim, >>> While this is all lovely... >>> >>> Why is it that Google docs API and CMIS both use THE SAME solution to >>> returning an ATOM entry which has a link rel to a feed which outlined >>> the resources which are part of this object? >>> >> >> Wouldn't this require an extra URI? >> >> In the original proposal we had a Deposit Receipt as an Atom Entry, >> and a Statement as a separate document (which you could content >> negotiate for, so rdf or an atom feed would have been fine), but when >> we discussed it you were against this approach. It was, in fact, you >> who convinced me that the Statement should become part of the Deposit >> Receipt rather than a document in its own right! > > The root feed in SWORD contains a list of atom entries that (I think) we > all agree should be the top level of the 'work'. Do you mean the service document? Each entry in there is a Collection, in line with the Atom definition. > The workflow state is > the state of the 'work' so lives at this level. It isn't overly > controversial to have this as inline or as a link-rel. During the original feedback to the white paper, it was felt that doing this inline was insufficient, as the state information could be extensive depending on your implementation decisions. Would your atom:link go to another document for describing the state, as opposed to the Statement (which describes the object and the state)? > What's more > important is the mechanism to change that state - do you PUT to the > , do a pseudo-move (see CMIS/GData) between collections or > use some new RPC (POST?args)? We are not planning to include any semantics to allow the depositor to change the state in this way. SWORD is a deposit tool only, and the idea of relating the state back to the client is for informational purposes only. I think it's a step to far to attempt to include workflow controls into SWORD a) this early (before CRUD is even settled in) or b) possibly even at all. > What Dave is talking about is how the media is represented (which > relates to 'packaging'). What we've discussed at Soton and decided, > before looking at CMIS & GData, is that the simplest representation of > the *contents of the work* is a link-reled that aggregates the 0 > or more media resources. I agree with this approach almost entirely: In the original proposal the contents of the work were to be retrievable via the Statement (located from a link-rel), for which we had proposed ORE as the format. Nonetheless, the business case also stated that this format would be content negotiable, so an application/atom+xml;type=feed content type would be acceptable if you wanted to implement one. After extensive discussion with Dave, he convinced me that the Statement should be embedded in the Deposit Receipt, not available under a separate URI - hence my confusion at the latest feedback. Personally, I'd be happy to return to the original proposal with an additional defined feature that the Statement be negotiable as an atom:feed or an ore resource map. I would also like to ensure that the atom:feed can suitably hold all the information that we would like to include in the Statement, such as the state information (which could, of course, be embedded as foreign markup). Folks - Perhaps we could have a brief show of hands with regard to the notion that the Statement be separated from the Deposit Receipt? It strikes me that there are some opportunities here to leverage the Aggregation-URI in ORE. At the moment it feels like a bit of an appendix, existing only to be different from the other URIs that we can't use for it. Perhaps instead the Aggregation-URI can be our main entry point for the Statement in it's various forms, via content negotiation? This would at least stem any proliferation of unnecessary URIs. > As Scott has previously suggested creating a > complex object involves multiple POSTs to the link-reled feed. CMIS & > GData use this mechanism to support folders. So the CMIS and GData approaches allow you to create a collection on the server by POST? I had not proposed this approach because it is not part of the AtomPub spec. Wouldn't it also make quite a big back-compatibility issue, to change the deposit process in this way? (not that there aren't such issues already, but at the moment updating SWORD 1 code to SWORD 2 for POST only should be relatively minor - this change would require more engineering). > My previous attempt to explain this approach fell on deaf-ears, so let > me try to headline this: > 1) Get rid of all mentions of "packaging" > 2) Get rid of OAI-ORE > 3) Use with an of 'sword:work' (or > similar), with a link-rel to an I promise that it didn't fall on deaf ears, but it did fall on the ears of someone who hasn't had the chance to properly reply (u
[Sword-TAP] Fwd: Key Changes and Justifications
-- Forwarded message -- From: David FLANDERS Date: 22 January 2011 00:08 Subject: RE: Key Changes and Justifications To: Tim Brody , "[email protected]" +1 > -Original Message- > From: Tim Brody [mailto:[email protected]] > Sent: 21 January 2011 11:04 > To: [email protected] > Subject: Re: Key Changes and Justifications > > On Thu, 20 Jan 2011 19:36:13 -, Richard Jones > wrote: > > > > > > > On 20/01/11 17:41, David Tarrant wrote: > >> > >> > >> While this is all lovely... > >> > >> Why is it that Google docs API and CMIS both use THE SAME solution > to > >> returning an ATOM entry which has a link rel to a feed which > outlined > >> the resources which are part of this object? > >> > > > > Wouldn't this require an extra URI? > > > > In the original proposal we had a Deposit Receipt as an Atom Entry, > and > > a Statement as a separate document (which you could content negotiate > > for, so rdf or an atom feed would have been fine), but when we > discussed > > it you were against this approach. It was, in fact, you who > convinced > > me that the Statement should become part of the Deposit Receipt > rather > > than a document in its own right! > > The root feed in SWORD contains a list of atom entries that (I think) > we > all agree should be the top level of the 'work'. The workflow state is > the > state of the 'work' so lives at this level. It isn't overly > controversial > to have this as inline or as a link-rel. What's more important is the > mechanism to change that state - do you PUT to the , do a > pseudo-move (see CMIS/GData) between collections or use some new RPC > (POST?args)? > > What Dave is talking about is how the media is represented (which > relates > to 'packaging'). What we've discussed at Soton and decided, before > looking > at CMIS & GData, is that the simplest representation of the *contents > of > the work* is a link-reled that aggregates the 0 or more media > resources. As Scott has previously suggested creating a complex object > involves multiple POSTs to the link-reled feed. CMIS & GData use this > mechanism to support folders. > > My previous attempt to explain this approach fell on deaf-ears, so let > me > try to headline this: > 1) Get rid of all mentions of "packaging" > 2) Get rid of OAI-ORE > 3) Use with an of 'sword:work' (or > similar), > with a link-rel to an > > Anyone who wants to use 'packages' to bundle metadata and files into a > single .zip should document it and mint a MIME-type. For instance, > BibTeX > is plain text but has a commonly accepted MIME-type. If your repository > supports "BibTeX" then it can do application/x-bibtex. > OAI-ORE can be supported through a of the work's > . > > (Ideally I would like SWORD to be compatible with Google Docs, so we > can > leverage any tools built for that API with SWORD and vice-versa - now > how > cool would that be!?) > > All the best, > Tim. -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ Sword-app-techadvisorypanel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/sword-app-techadvisorypanel
[Sword-TAP] Fwd: Key Changes and Justifications
-- Forwarded message -- From: Tim Brody Date: 22 January 2011 00:03 Subject: Re: Key Changes and Justifications To: [email protected] On Thu, 20 Jan 2011 19:36:13 -, Richard Jones wrote: > > > On 20/01/11 17:41, David Tarrant wrote: >> >> >> While this is all lovely... >> >> Why is it that Google docs API and CMIS both use THE SAME solution to >> returning an ATOM entry which has a link rel to a feed which outlined the >> resources which are part of this object? >> > > Wouldn't this require an extra URI? > > In the original proposal we had a Deposit Receipt as an Atom Entry, and a > Statement as a separate document (which you could content negotiate for, so > rdf or an atom feed would have been fine), but when we discussed it you were > against this approach. It was, in fact, you who convinced me that the > Statement should become part of the Deposit Receipt rather than a document in > its own right! The root feed in SWORD contains a list of atom entries that (I think) we all agree should be the top level of the 'work'. The workflow state is the state of the 'work' so lives at this level. It isn't overly controversial to have this as inline or as a link-rel. What's more important is the mechanism to change that state - do you PUT to the , do a pseudo-move (see CMIS/GData) between collections or use some new RPC (POST?args)? What Dave is talking about is how the media is represented (which relates to 'packaging'). What we've discussed at Soton and decided, before looking at CMIS & GData, is that the simplest representation of the *contents of the work* is a link-reled that aggregates the 0 or more media resources. As Scott has previously suggested creating a complex object involves multiple POSTs to the link-reled feed. CMIS & GData use this mechanism to support folders. My previous attempt to explain this approach fell on deaf-ears, so let me try to headline this: 1) Get rid of all mentions of "packaging" 2) Get rid of OAI-ORE 3) Use with an of 'sword:work' (or similar), with a link-rel to an Anyone who wants to use 'packages' to bundle metadata and files into a single .zip should document it and mint a MIME-type. For instance, BibTeX is plain text but has a commonly accepted MIME-type. If your repository supports "BibTeX" then it can do application/x-bibtex. OAI-ORE can be supported through a of the work's . (Ideally I would like SWORD to be compatible with Google Docs, so we can leverage any tools built for that API with SWORD and vice-versa - now how cool would that be!?) All the best, Tim. -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ Sword-app-techadvisorypanel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/sword-app-techadvisorypanel
[Sword-TAP] Fwd: Key Changes and Justifications
-- Forwarded message -- From: Richard Jones Date: 21 January 2011 08:36 Subject: Re: Key Changes and Justifications To: David Tarrant Cc: [email protected], [email protected] On 20/01/11 17:41, David Tarrant wrote: > > > While this is all lovely... > > Why is it that Google docs API and CMIS both use THE SAME solution to > returning an ATOM entry which has a link rel to a feed which outlined the > resources which are part of this object? > Wouldn't this require an extra URI? In the original proposal we had a Deposit Receipt as an Atom Entry, and a Statement as a separate document (which you could content negotiate for, so rdf or an atom feed would have been fine), but when we discussed it you were against this approach. It was, in fact, you who convinced me that the Statement should become part of the Deposit Receipt rather than a document in its own right! Perhaps I misunderstood your objections? > Do we need to leave the Atom/Atom Feed spec to solve this problem? > > I don't like the idea of SIMPLE suddenly needing knowledge of 2 > specifications (ATOM and ORE) I don't think there was anything sudden about it - it's been in the design proposal since the start. Cheers, Richard > > Dave T > > > On 19 Jan 2011, at 18:57, Richard Jones wrote: > >> Hi Rob, >> >> I've just mocked up another deposit receipt serialisation which I think is a >> valid Resource Map. I don't suppose you could give it a once over for me >> could you? >> >> I've kept the full RDF/XML part intact, although it now resides in an >> oreatom:triples element rather than an rdf:RDF element. I have kept the >> describes and isDescribedBy declarations, which are not in the Atom >> implementation guide for ORE, but it didn't seem to hurt. Then I have >> basically just created all the relevant atom:link and atom:category elements >> that I need to. Oh, I also created a new URI form for Aggregations. >> >> Cheers, >> >> Richard >> >> >> On 19/01/11 13:04, Richard Jones wrote: >>> >>> Hi Rob, >>> >>> * URIs used in Statements. Could you either unpack this section a little, or give an example? When reading in conjunction with the previous document, it seems that you're reusing identifiers incorrectly. I'm happy that the Edit-URI (URI of Atom Entry) is the Resource Map URI. This is as per the ORE/ATOM spec ( http://www.openarchives.org/ore/1.0/atom ) and should be in /entry/link[@rel=self] in the entry document. I'm less convinced that you can reuse EM-URI as the URI of the aggregation. EM-URI (and "almost always" Cont-URI) isn't a non information resource that represents the set of aggregated resources. > > From Cont-URI you can "retrieve representations of the object as it resides in the SWORD server", making it a negotiable information resource? My understanding is that EM-URI / Cont-URI is the value of link[@rel="edit-media"] and Edit-URI is the value of link[@rel="edit"]? In RFC 5023, section 11, I think that the distinction is pretty clear that edit is to modify the entry (as you have) and edit-media is to modify an associated media resource (the actual content). Thus the re-use of it as the Aggregation URI seems very strange. The practical requirements for the URI of the aggregation are that it return a 303 status in response to a GET request, and a Content-Location of a Resource Map. In the default SWORD case this would only be the Atom Entry document, but that's perfectly acceptable as ConNeg could be used to get RDF serializations. Basically, I think you need a new URI here. >>> >>> Attached is a mock up of how I originally thought we would do this, >>> which is basically the original SWORD deposit receipt, but with a >>> resource map embedded into it (using the Edit-URI and EM-URI as the >>> REM-URI and Agg-URI respectively) as RDF/XML foreign markup. >>> >>> I'm now starting to question this a little more. >>> >>> For a start, I should have re-checked the ORE spec to make sure that >>> these URIs were used right - in some way we definitely need a new URI >>> for the aggregation as you suggest. >>> >>> I was also just taking a look at the Atom serialisation for ORE and am >>> wondering whether the Deposit Receipt has to be a resource map as >>> described here, or whether my current approach of embedding the RDF/XML >>> resource map as foreign markup in the Deposit Receipt is ok. The thing >>> with the Atom serialisation of a Resource Map is that it is /really/ >>> verbose, and not so straightforward to read from the perspective of >>> someone familiar with RDF/XML but not with ORE. >>> >>> Cheers, >>> >>> Richard >>> >>> >>> >> > > -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class lo
[Sword-TAP] Fwd: Key Changes and Justifications
-- Forwarded message -- From: David Tarrant Date: 21 January 2011 06:41 Subject: Re: Key Changes and Justifications To: Richard Jones Cc: [email protected], [email protected] While this is all lovely... Why is it that Google docs API and CMIS both use THE SAME solution to returning an ATOM entry which has a link rel to a feed which outlined the resources which are part of this object? Do we need to leave the Atom/Atom Feed spec to solve this problem? I don't like the idea of SIMPLE suddenly needing knowledge of 2 specifications (ATOM and ORE) Dave T On 19 Jan 2011, at 18:57, Richard Jones wrote: > Hi Rob, > > I've just mocked up another deposit receipt serialisation which I think is a > valid Resource Map. I don't suppose you could give it a once over for me > could you? > > I've kept the full RDF/XML part intact, although it now resides in an > oreatom:triples element rather than an rdf:RDF element. I have kept the > describes and isDescribedBy declarations, which are not in the Atom > implementation guide for ORE, but it didn't seem to hurt. Then I have > basically just created all the relevant atom:link and atom:category elements > that I need to. Oh, I also created a new URI form for Aggregations. > > Cheers, > > Richard > > > On 19/01/11 13:04, Richard Jones wrote: >> Hi Rob, >> >> >>> * URIs used in Statements. >>> >>> Could you either unpack this section a little, or give an example? When >>> reading in conjunction with the previous document, it seems that you're >>> reusing identifiers incorrectly. >>> >>> I'm happy that the Edit-URI (URI of Atom Entry) is the Resource Map URI. >>> This is as per the ORE/ATOM spec ( >>> http://www.openarchives.org/ore/1.0/atom ) and should be in >>> /entry/link[@rel=self] in the entry document. >>> >>> I'm less convinced that you can reuse EM-URI as the URI of the >>> aggregation. EM-URI (and "almost always" Cont-URI) isn't a non >>> information resource that represents the set of aggregated resources. From Cont-URI you can "retrieve representations of the object as it >>> resides in the SWORD server", making it a negotiable information >>> resource? >>> >>> My understanding is that EM-URI / Cont-URI is the value of >>> link[@rel="edit-media"] and Edit-URI is the value of link[@rel="edit"]? >>> In RFC 5023, section 11, I think that the distinction is pretty clear >>> that >>> edit is to modify the entry (as you have) and edit-media is to modify an >>> associated media resource (the actual content). Thus the re-use of it as >>> the Aggregation URI seems very strange. >>> >>> The practical requirements for the URI of the aggregation are that it >>> return a 303 status in response to a GET request, and a Content-Location >>> of a Resource Map. In the default SWORD case this would only be the Atom >>> Entry document, but that's perfectly acceptable as ConNeg could be >>> used to >>> get RDF serializations. >>> >>> Basically, I think you need a new URI here. >> >> Attached is a mock up of how I originally thought we would do this, >> which is basically the original SWORD deposit receipt, but with a >> resource map embedded into it (using the Edit-URI and EM-URI as the >> REM-URI and Agg-URI respectively) as RDF/XML foreign markup. >> >> I'm now starting to question this a little more. >> >> For a start, I should have re-checked the ORE spec to make sure that >> these URIs were used right - in some way we definitely need a new URI >> for the aggregation as you suggest. >> >> I was also just taking a look at the Atom serialisation for ORE and am >> wondering whether the Deposit Receipt has to be a resource map as >> described here, or whether my current approach of embedding the RDF/XML >> resource map as foreign markup in the Deposit Receipt is ok. The thing >> with the Atom serialisation of a Resource Map is that it is /really/ >> verbose, and not so straightforward to read from the perspective of >> someone familiar with RDF/XML but not with ORE. >> >> Cheers, >> >> Richard >> >> >> > -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ Sword-app-techadvisorypanel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/sword-app-techadvisorypanel
[Sword-TAP] Fwd: Key Changes and Justifications
-- Forwarded message -- From: Richard Jones Date: 20 January 2011 07:57 Subject: Re: Key Changes and Justifications To: [email protected] Cc: [email protected] Hi Rob, I've just mocked up another deposit receipt serialisation which I think is a valid Resource Map. I don't suppose you could give it a once over for me could you? I've kept the full RDF/XML part intact, although it now resides in an oreatom:triples element rather than an rdf:RDF element. I have kept the describes and isDescribedBy declarations, which are not in the Atom implementation guide for ORE, but it didn't seem to hurt. Then I have basically just created all the relevant atom:link and atom:category elements that I need to. Oh, I also created a new URI form for Aggregations. Cheers, Richard On 19/01/11 13:04, Richard Jones wrote: > > Hi Rob, > > >> * URIs used in Statements. >> >> Could you either unpack this section a little, or give an example? When >> reading in conjunction with the previous document, it seems that you're >> reusing identifiers incorrectly. >> >> I'm happy that the Edit-URI (URI of Atom Entry) is the Resource Map URI. >> This is as per the ORE/ATOM spec ( >> http://www.openarchives.org/ore/1.0/atom ) and should be in >> /entry/link[@rel=self] in the entry document. >> >> I'm less convinced that you can reuse EM-URI as the URI of the >> aggregation. EM-URI (and "almost always" Cont-URI) isn't a non >> information resource that represents the set of aggregated resources. >>> >>> From Cont-URI you can "retrieve representations of the object as it >> >> resides in the SWORD server", making it a negotiable information >> resource? >> >> My understanding is that EM-URI / Cont-URI is the value of >> link[@rel="edit-media"] and Edit-URI is the value of link[@rel="edit"]? >> In RFC 5023, section 11, I think that the distinction is pretty clear >> that >> edit is to modify the entry (as you have) and edit-media is to modify an >> associated media resource (the actual content). Thus the re-use of it as >> the Aggregation URI seems very strange. >> >> The practical requirements for the URI of the aggregation are that it >> return a 303 status in response to a GET request, and a Content-Location >> of a Resource Map. In the default SWORD case this would only be the Atom >> Entry document, but that's perfectly acceptable as ConNeg could be >> used to >> get RDF serializations. >> >> Basically, I think you need a new URI here. > > Attached is a mock up of how I originally thought we would do this, > which is basically the original SWORD deposit receipt, but with a > resource map embedded into it (using the Edit-URI and EM-URI as the > REM-URI and Agg-URI respectively) as RDF/XML foreign markup. > > I'm now starting to question this a little more. > > For a start, I should have re-checked the ORE spec to make sure that > these URIs were used right - in some way we definitely need a new URI > for the aggregation as you suggest. > > I was also just taking a look at the Atom serialisation for ORE and am > wondering whether the Deposit Receipt has to be a resource map as > described here, or whether my current approach of embedding the RDF/XML > resource map as foreign markup in the Deposit Receipt is ok. The thing > with the Atom serialisation of a Resource Map is that it is /really/ > verbose, and not so straightforward to read from the perspective of > someone familiar with RDF/XML but not with ORE. > > Cheers, > > Richard > > > http://purl.org/net/sword/terms/"; xmlns="http://www.w3.org/2005/Atom";> SWORD Deposit tag:container@sss/584511c0-50bb-4fb0-ac16-390b174cadfb/9e5b0167-ade7-4be4-b79a-5d33a9cca16d 2011-01-19T18:50:08Z SWORD Client Content deposited with SWORD client http://www.swordapp.org/sss"; version="1.0"/> http://localhost:8080/cont-uri/584511c0-50bb-4fb0-ac16-390b174cadfb/9e5b0167-ade7-4be4-b79a-5d33a9cca16d"/> http://purl.org/net/sword/package/default Treatment description SSS has done this, that and the other to process the deposit http://localhost:8080/edit-uri/584511c0-50bb-4fb0-ac16-390b174cadfb/9e5b0167-ade7-4be4-b79a-5d33a9cca16d"/> http://localhost:8080/em-uri/584511c0-50bb-4fb0-ac16-390b174cadfb/9e5b0167-ade7-4be4-b79a-5d33a9cca16d"/> http://FIXME/ALT/URL/HERE"/> http://localhost:8080/edit-uri/584511c0-50bb-4fb0-ac16-390b174cadfb/9e5b0167-ade7-4be4-b79a-5d33a9cca16d"/> http://www.openarchives.org/ore/terms/describes"; href="http://localhost:8080/agg-uri/584511c0-50bb-4fb0-ac16-390b174cadfb/9e5b0167-ade7-4be4-b79a-5d33a9cca16d"/> http://www.openarchives.org/ore/terms/Aggregation"; label="Aggregation" scheme="http://www.openarchives.org/ore/terms/"/> http://www.openarchives.org/ore/terms/aggregates"; href="http://localhost:8080/part-uri/584511c0-50bb-4fb0-ac16-390b174cadfb/9e5b0167-ade7-4be4-b79a-5d33a9cca16d/2011-01-19T18%3A50%3A08Z_example.zip"/> http://www.openarchives.org/ore/atom/"; xmlns:rdf="http://www.w3.org/1999/02/22-r
[Sword-TAP] Fwd: Key Changes and Justifications
-- Forwarded message -- From: Richard Jones Date: 20 January 2011 02:30 Subject: Re: Key Changes and Justifications To: [email protected] Cc: [email protected] Hi Folks, > * Content Negotiating for Package Formats > > RFC2533 seems massive overkill, and very different from HTTP content > negotiation. > > Could you set out the requirements that cannot be fulfilled by accept > headers? My understanding is that the packaging format and the wrapped > media format should be separately negotiable, but that can be handled with > just a single new Accept- header that handles the wrapped data's format. > [As the packaging is the outermost layer, it goes into Accept] > > If RFC2533 is the way you decide to go, then you should follow RFC2295 > Section 6, which discusses a Accept-Features. Note in RFC 2616 (HTTP) > defined after 2533/2295, it doesn't mention Accept-Features. However, > 2295 defines a different syntax than 2533, and 2533 doesn't appear to > officially update 2295. Transparent Content Negotiation from 2295 is very > poorly implemented, and 2533 doesn't appear to be implemented at all. > > Basically, ... don't do it. Whatever the problem is, 2295 + 2533 is not > the solution. Regarding this, perhaps the easiest thing to do is share my first stab at an internet draft for the various HTTP headers that look relevant to SWORD 2.0. http://sword-app.svn.sourceforge.net/viewvc/sword-app/spec/trunk/PackagedContentDelivery.txt?revision=226&view=markup Feel free to mock my first attempt at writing anything of this nature - I've hacked it together from a variety of example sources, and hope that it's the right sort of thing, but any hints as to how to make it better would be great. The main point, though, is that it describes briefly the Accept-Media-Formats header with its constrained contents, which will hopefully clarify what we're trying to achieve. I originally discarded Accept-Features, because the definition of it seemed to concern the features of the request, rather than any content negotiation (in Section 8.2 of RFC2295): "The Accept-Features request header can be used by a user agent to give information about the presence or absence of certain features in the feature set of the current request." Must be I'm reading that wrong. The more we discuss it the more I'm leaning towards a lazy approach of having a separate Accept-Packaging header, and some clearly stated rules as to the way in which servers should interpret the combination of Accept and Accept-Packaging. This issue must arise in other types of content negotiation, for example with Accept-Language where not all content-types are available in all languages, so perhaps there are some resources on that that we can learn from. Cheers, Richard -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ Sword-app-techadvisorypanel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/sword-app-techadvisorypanel
[Sword-TAP] Fwd: Key Changes and Justifications
-- Forwarded message -- From: Richard Jones Date: 19 January 2011 21:45 Subject: Re: Key Changes and Justifications To: Ian Stuart Cc: [email protected] Hi Ian, > - Simplification of acceptPackaging: surely the list of what's not > accepted is (in essence) infinite? The list of package types (even if > they are defined by some Internet Taskforce) will grow over time. > This NEEDS to be a "list of things I understand" - be they "I can give > you in one of these formats" or "I can receive in one of these > formats"... preferably each with a 'q'-weighting The reason for the comment about not accepting formats was because the q value can be used to list formats the server will NOT accept, by setting q=0.0. This was the only thing that I could think that would cause any problems with removing the q value from acceptPackaging. Is anyone aware of anyone using SWORD who cares about the q values? I agree with you, Ian, that this should be a list of "things that I understand", but the q value muddies this water a little by allowing it to also be a list containing "things I definitely don't understand". > - Recording Depositors and OnBehalfOf users: Could a client (well, a > server) set a depositor or an OnBehalfOf value? > Thought example: The Open Access Repository Junction Deposit Broker > passes an item to repository "Foo". In that deposit is a statement > defining that the item has come from Publisher "Bah". "Foo" accepts that > deposit, however it has internally elected to have [virtual] > Deposit-users to represent each of the publishers, therefore it sets the > OnBehalfOf record to show it has been assigned to the depositor "Bah". > Whether the Open Access Repository Junction Deposit Broker uses this > information is moot - it is valid for "Foo" to state that it has defined > the deposit as being OnBehalfOf "Bah" Well, that's an interesting question. Obviously, the server is at liberty to do whatever it wants with the data when it's got hold of it, so something like you describe could happen. I think that this would be an implementation decision, though, rather than one for us to address during the spec. > - MD5 vs SHA1: I don't understand the context in full... as I understand > it, Content-MD5 is a checksum for the content. > Is there a significant issue in this checksum being spoofed? > Ignoring the fact that the development for SWORD2 is coming from the > Open Access Movement, is there a requirement for transfers to have a > checksum that is "more secure" that any other? > For 90-plus percent of situations, the difference between MD5 & SHA-1 is > moot. > The only issue that needs to be considered is "Backward Compatibility" - > if we switch the checksum algorithm, then it will be more complex for > systems to understand both SWORDv1 & SWORDv2 connections. Agreed; thanks. > - Extracting Metadata from an Atom Entry: there are two thoughts here - > 1) Why complicate the extraction process by having metadata in both me > message carrier AND the payload? I don't think this is what's suggested. The metadata is all in the Atom part, and presumed not to be in the payload when the default package format is specified. > 2) How does the system deal with multiple authors? > This seems to be a solution to a fairly specific problem, and one that > is designed to make life easy for that problem, at the expense of the > larger whole. I'm not sure I understand. The metadata in the atom entry is no different than if the metadata were in the attached zip. This is simply our "default" package format, so that we don't have to have a long argument about which is SWORD's officially supported format. Instead we just take advantage of the standard that we are already employing. > - Content-Location header: Again, I'm not sure I fully understand this > issue. > "Location" is where the whole deposit can be found on the InterWeb (the > abstract page, if you like //) > Is "Content-Location" a reference to recover the content... such as a > script to extract the item (the Edit URI, I guess) The atom spec I find a little confusing on the matter, hence the question and suggestion to continue to omit it :) I believe the answer is to continue to omit it! Cheers, Richard -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ Sword-app-techadvisorypanel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/sword-app-techadvisorypanel
[Sword-TAP] Fwd: Key Changes and Justifications
-- Forwarded message -- From: Richard Jones Date: 20 January 2011 02:04 Subject: Re: Key Changes and Justifications To: [email protected] Cc: [email protected] Hi Rob, > * URIs used in Statements. > > Could you either unpack this section a little, or give an example? When > reading in conjunction with the previous document, it seems that you're > reusing identifiers incorrectly. > > I'm happy that the Edit-URI (URI of Atom Entry) is the Resource Map URI. > This is as per the ORE/ATOM spec ( > http://www.openarchives.org/ore/1.0/atom ) and should be in > /entry/link[@rel=self] in the entry document. > > I'm less convinced that you can reuse EM-URI as the URI of the > aggregation. EM-URI (and "almost always" Cont-URI) isn't a non > information resource that represents the set of aggregated resources. >> >> From Cont-URI you can "retrieve representations of the object as it > > resides in the SWORD server", making it a negotiable information resource? > > My understanding is that EM-URI / Cont-URI is the value of > link[@rel="edit-media"] and Edit-URI is the value of link[@rel="edit"]? > In RFC 5023, section 11, I think that the distinction is pretty clear that > edit is to modify the entry (as you have) and edit-media is to modify an > associated media resource (the actual content). Thus the re-use of it as > the Aggregation URI seems very strange. > > The practical requirements for the URI of the aggregation are that it > return a 303 status in response to a GET request, and a Content-Location > of a Resource Map. In the default SWORD case this would only be the Atom > Entry document, but that's perfectly acceptable as ConNeg could be used to > get RDF serializations. > > Basically, I think you need a new URI here. Attached is a mock up of how I originally thought we would do this, which is basically the original SWORD deposit receipt, but with a resource map embedded into it (using the Edit-URI and EM-URI as the REM-URI and Agg-URI respectively) as RDF/XML foreign markup. I'm now starting to question this a little more. For a start, I should have re-checked the ORE spec to make sure that these URIs were used right - in some way we definitely need a new URI for the aggregation as you suggest. I was also just taking a look at the Atom serialisation for ORE and am wondering whether the Deposit Receipt has to be a resource map as described here, or whether my current approach of embedding the RDF/XML resource map as foreign markup in the Deposit Receipt is ok. The thing with the Atom serialisation of a Resource Map is that it is /really/ verbose, and not so straightforward to read from the perspective of someone familiar with RDF/XML but not with ORE. Cheers, Richard http://purl.org/net/sword/"; xmlns="http://www.w3.org/2005/Atom";> SWORD Deposit tag:container@sss/584511c0-50bb-4fb0-ac16-390b174cadfb/e8720629-1721-460d-adb1-acd7ee2895ef 2011-01-11T21:58:39Z SWORD Client Conten deposited with SWORD client http://www.swordapp.org/sss"; version="1.0"/> http://localhost:8080/cont-uri/584511c0-50bb-4fb0-ac16-390b174cadfb/e8720629-1721-460d-adb1-acd7ee2895ef"/> Treatment description http://purl.org/net/sword/package/default http://localhost:8080/edit-uri/584511c0-50bb-4fb0-ac16-390b174cadfb/e8720629-1721-460d-adb1-acd7ee2895ef"/> http://localhost:8080/em-uri/584511c0-50bb-4fb0-ac16-390b174cadfb/e8720629-1721-460d-adb1-acd7ee2895ef"/> http://www.w3.org/1999/02/22-rdf-syntax-ns#"; xmlns:ore="http://www.openarchives.org/ore/terms/";> http://localhost:8080/edit-uri/584511c0-50bb-4fb0-ac16-390b174cadfb/e8720629-1721-460d-adb1-acd7ee2895ef";> http://localhost:8080/cont-uri/584511c0-50bb-4fb0-ac16-390b174cadfb/e8720629-1721-460d-adb1-acd7ee2895ef"/> http://localhost:8080/cont-uri/584511c0-50bb-4fb0-ac16-390b174cadfb/e8720629-1721-460d-adb1-acd7ee2895ef";> http://localhost:8080/edit-uri/584511c0-50bb-4fb0-ac16-390b174cadfb/e8720629-1721-460d-adb1-acd7ee2895ef"/> http://localhost:8080/part-uri/584511c0-50bb-4fb0-ac16-390b174cadfb/e8720629-1721-460d-adb1-acd7ee2895ef/example.zip"/> http://localhost:8080/part-uri/584511c0-50bb-4fb0-ac16-390b174cadfb/e8720629-1721-460d-adb1-acd7ee2895ef/example.zip"/> http://purl.org/net/sword/state/archived"/> http://localhost:8080/part-uri/584511c0-50bb-4fb0-ac16-390b174cadfb/e8720629-1721-460d-adb1-acd7ee2895ef/example.zip";> http://purl.org/net/sword/package/default"/> http://www.w3.org/2001/XMLSchema#dateTime";>2011-01-11T21:58:39Z http://www.w3.org/2001/XMLSchema#string";>sword http://purl.org/net/sword/state/archived";> The work has passed through review and is now in the archive -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using pro
[Sword-TAP] Fwd: Key Changes and Justifications
-- Forwarded message -- From: Robert D. Sanderson Date: 19 January 2011 06:19 Subject: Re: Key Changes and Justifications To: Richard Jones Cc: [email protected] Comments on the sections: * URIs used in Statements. Could you either unpack this section a little, or give an example? When reading in conjunction with the previous document, it seems that you're reusing identifiers incorrectly. I'm happy that the Edit-URI (URI of Atom Entry) is the Resource Map URI. This is as per the ORE/ATOM spec ( http://www.openarchives.org/ore/1.0/atom ) and should be in /entry/link[@rel=self] in the entry document. I'm less convinced that you can reuse EM-URI as the URI of the aggregation. EM-URI (and "almost always" Cont-URI) isn't a non information resource that represents the set of aggregated resources. >From Cont-URI you can "retrieve representations of the object as it resides in the SWORD server", making it a negotiable information resource? My understanding is that EM-URI / Cont-URI is the value of link[@rel="edit-media"] and Edit-URI is the value of link[@rel="edit"]? In RFC 5023, section 11, I think that the distinction is pretty clear that edit is to modify the entry (as you have) and edit-media is to modify an associated media resource (the actual content). Thus the re-use of it as the Aggregation URI seems very strange. The practical requirements for the URI of the aggregation are that it return a 303 status in response to a GET request, and a Content-Location of a Resource Map. In the default SWORD case this would only be the Atom Entry document, but that's perfectly acceptable as ConNeg could be used to get RDF serializations. Basically, I think you need a new URI here. * Content Negotiating for the Statement (moved in order) As above, you should ConNeg on the Aggregation URI to get a different mimetype for the resource map, not on the resource map URI. The Aggregation does a 303 redirect to the chosen serialization. Resource maps are not negotiable resources themselves. * Content Negotiating for Package Formats RFC2533 seems massive overkill, and very different from HTTP content negotiation. Could you set out the requirements that cannot be fulfilled by accept headers? My understanding is that the packaging format and the wrapped media format should be separately negotiable, but that can be handled with just a single new Accept- header that handles the wrapped data's format. [As the packaging is the outermost layer, it goes into Accept] If RFC2533 is the way you decide to go, then you should follow RFC2295 Section 6, which discusses a Accept-Features. Note in RFC 2616 (HTTP) defined after 2533/2295, it doesn't mention Accept-Features. However, 2295 defines a different syntax than 2533, and 2533 doesn't appear to officially update 2295. Transparent Content Negotiation from 2295 is very poorly implemented, and 2533 doesn't appear to be implemented at all. Basically, ... don't do it. Whatever the problem is, 2295 + 2533 is not the solution. * Obtaining Original Deposits Looks good to me. Is there also an atom link rel that could be used, or is it better to be in RDF? * Suppression of Metadata Handling I think the problem is more general, not just at the metadata level. What seems to be required is the ability to tell the server not to do any post-processing, just what was requested explicitly. This could extend to not indexing/unindexing the actual data, not updating feeds, and so forth. * Simplification of acceptPackaging Agree. If the client sends something that the server wants to reject ... it can just reject it. Can't this information be in the service description document anyway? * MD5 vs SHA1 Backwards compat seems more important than secure hashing. * Removal of userAgent Agree. * Package Formats in Deposit Receipt I'm not sure of the semantics here, but Atom semantics for extensions are so wishy-washy you're probably okay. It would be cleaner to define a slightly more structured extension: http://swordapp.org/server/100";> default MetsDspaceSip And then the order of elements isn't important -- the information is self contained within the extension block. * Default Packaging, etc (URIs not Mimetypes) I know it's a pain, but until the rest of the world accepts that URIs for formats is the only sensible way to go, we're stuck with mime types. If those identifiers are to go into HTTP headers ever (as above), then I would recommend registering new mime types for them. * Content-Location header I would continue to omit. I think that client behavior when getting Location and Content-Location would be undefined, or at the very least unpredictable. HTH Rob > Hi Folks, > > Since writing the business case/technical design document, I have been > working on a detailed analysis of the spec's requirements based on that > document, the comments of this group, and the existing SWORD 1.3 > documents. I have enumerate
[Sword-TAP] Fwd: Key Changes and Justifications
-- Forwarded message -- From: Ian Stuart Date: 19 January 2011 03:01 Subject: Re: Key Changes and Justifications To: [email protected] On 17/01/11 19:27, Richard Jones wrote: > > Hi Folks, > > Since writing the business case/technical design document, I have been > working on a detailed analysis of the spec's requirements based on that > document, the comments of this group, and the existing SWORD 1.3 > documents. I have enumerated a number of key points which represent > either decisions that I have provisionally made for the 2.0 version of > the spec, or questions that the group might have answers for or views upon. 1) Help ma poor wee head. that was certainly not a LadyBird Books reading :) 2) Some comments: - Simplification of acceptPackaging: surely the list of what's not accepted is (in essence) infinite? The list of package types (even if they are defined by some Internet Taskforce) will grow over time. This NEEDS to be a "list of things I understand" - be they "I can give you in one of these formats" or "I can receive in one of these formats"... preferably each with a 'q'-weighting - Recording Depositors and OnBehalfOf users: Could a client (well, a server) set a depositor or an OnBehalfOf value? Thought example: The Open Access Repository Junction Deposit Broker passes an item to repository "Foo". In that deposit is a statement defining that the item has come from Publisher "Bah". "Foo" accepts that deposit, however it has internally elected to have [virtual] Deposit-users to represent each of the publishers, therefore it sets the OnBehalfOf record to show it has been assigned to the depositor "Bah". Whether the Open Access Repository Junction Deposit Broker uses this information is moot - it is valid for "Foo" to state that it has defined the deposit as being OnBehalfOf "Bah" - MD5 vs SHA1: I don't understand the context in full... as I understand it, Content-MD5 is a checksum for the content. Is there a significant issue in this checksum being spoofed? Ignoring the fact that the development for SWORD2 is coming from the Open Access Movement, is there a requirement for transfers to have a checksum that is "more secure" that any other? For 90-plus percent of situations, the difference between MD5 & SHA-1 is moot. The only issue that needs to be considered is "Backward Compatibility" - if we switch the checksum algorithm, then it will be more complex for systems to understand both SWORDv1 & SWORDv2 connections. - Extracting Metadata from an Atom Entry: there are two thoughts here - 1) Why complicate the extraction process by having metadata in both me message carrier AND the payload? 2) How does the system deal with multiple authors? This seems to be a solution to a fairly specific problem, and one that is designed to make life easy for that problem, at the expense of the larger whole. - Content-Location header: Again, I'm not sure I fully understand this issue. "Location" is where the whole deposit can be found on the InterWeb (the abstract page, if you like //) Is "Content-Location" a reference to recover the content... such as a script to extract the item (the Edit URI, I guess) -- 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. -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ Sword-app-techadvisorypanel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/sword-app-techadvisorypanel
