---------- Forwarded message ---------- From: Richard Jones <rich...@oneoverzero.com> Date: 22 January 2011 01:57 Subject: Re: Key Changes and Justifications To: Tim Brody <t...@ecs.soton.ac.uk> Cc: techadvisorypa...@swordapp.org
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 > <atom:entry>, 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 <feed> 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 <atom:entry> with an <atom:category> of 'sword:work' (or > similar), with a link-rel to an <atom:feed> 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 (until now). I don't believe we can get rid of mentions of packaging, no matter how much we would like to. Packaging is used extensively across all repository types and if SWORD does not help with this it will not be successful. Also, interestingly, no one has previously questioned the use of ORE as the description format for the repository objects (presumably since this is its core use case). Does anyone else have such misgivings? > 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 > <accept>application/x-bibtex</accept>. > OAI-ORE can be supported through a <link-rel> of the work's <atom:entry>. This is not practical, unfortunately. We have to give people something that they can work with now, without having to care about registering mime-types. If I want to use SWORD within my organisation to move data around, do I really have to register a mime type just to announce my (possibly custom) packaging formats to my other servers? Way too high an entry barrier. > (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!?) That would be very cool. What applications of the tech did you have in mind? Could be interesting to register them in the SWORD use cases? 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 Sword-app-techadvisorypanel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sword-app-techadvisorypanel
