Hi David, Documenting the use cases for SWORD is a high priority for us - we actually have a journal article currently in review that lists the different uses that we know of, and for each we have a case study of how SWORD is being used (or could be used) to facilitate this.
We'll forward details once we know more. We're also now working on the same type of thing, but looking specifically at data deposit use cases, with an analysis of how well SWORD can meet these requirements. Cheers, Stuart On 13/10/2011, at 9:11 PM, David FLANDERS wrote: > Hi Kathi, For the sake why you “cannot edit a published item” in the > “connexions model” do you think you could provide the basic use cas? – > apologies if this is obvious for an OER side as most of the use cases we have > collected have been from a research PoV. > > @Richard, Stuart – the other interesting thing I’m finding here is the > evolution of SWORD from v1 where the blog entry was the basic use case we > spoke about when adopting ATOM pub versus the more elaborate scholarly CRUD > use case for SWORD v2. I think these basic use cases are really important > for dev coming upon SWORD for the first time so that we have an explicit use > case example for each of the SWORD versions... I think the spec is so > focused on looking profession as an IETF that we need some low steps for > humans by which people can understand and think about this? I’m sure we have > this inte blog or somewhere, but perhaps putting it in the spec somewhere > near the top so it is not just all formal spec? /2p /dff > > > From: Kathi Fletcher [mailto:kathi.fletc...@shuttleworthfoundation.org] > Sent: 12 October 2011 18:32 > To: Richard Jones > Cc: sword-app-tech@lists.sourceforge.net; Roché Compaan; Carl Scheffler > Subject: Re: [sword-app-tech] FW: Use of In-Progress header and the SE-IRI > vs. the EM-IRI > > Richard, thanks for the reply. I didn't immediately figure out how to unify > it with what Connexions is doing, but I think that I have finally had an > epiphany about SE-IRI, EM-IRI and In-Progress and why I was having such a > disconnect with "marking" an object as "In-Progress" so that you would know > its state for actions on the EM-IRI. > > Although AtomPUB is simpler than SWORD, it helped me to think of a blog entry > as a model. So I might create a blog entry, and either mark it as "draft" > (like In-Progress) or publish it straight away. And whether or not it is a > draft or published, I can send a new image using the EM-IRI. This action > should never effect whether the thing is draft or published. I think this is > essentially what you were explaining below. > > In the Connexions model, because you CANNOT edit a published item, but rather > must create a new version and publish that, the scenario above never happens. > We are implementing SWORD through the editing environment, which is all > "draft". > > One of the following two scenarios occur: > • You either create a new draft and publish it right away > (In-Progress=false). No more editing is possible after this action. You never > get an action on the EM-IRI in this case. > • You create a new draft with In-Progress=true, do PUTs and POSTs to > modify and add stuff. And then you eventually publish. > So I think that the Connexions implementation can be compliant AND enjoy the > following simplifications: > • Actions on the EM-IRI always assume In-Progress=true. Thus, no > marking is necessary. > • Publish never occurs due to actions on the EM-IRI. > I think the second bullet is actually true for all implementations of SWORD > V2. If In-Progress is false and you get an action to the EM-IRI, that won't > ever cause publishing to occur. It either already has occured, or it is in > some workflow that is proceeding along orthogonally to this latest edit. > Perhaps this latest edit satisfies some final requirement, but again, > something already in motion is evaluating that. > > Kathi > > On Tue, Oct 4, 2011 at 5:01 AM, Richard Jones <rich...@cottagelabs.com> wrote: > Hi Kathi, > > Sorry I didn't pick this up from the sword-app-tech list earlier. > There are some responses/justifications inline. > > > In implementing SWORD-V2, having the In-Progress header for all actions on > > the SE-IRI, but not having it on actions on the EM-IRI, turns out to add a > > fair amount of complication. I am wondering if that complication is actually > > buying anyone anything useful. > > Its interesting that that's the case, as it is actually omitted (in > part) to avoid complication ... > > > So on the SE-IRI, you just check the In-Progress header (or the implied > > default value of 'false' if the header is missing) in order to determine > > whether to publish the resource after the action is taken. > > > > > > > > But actions on the EM-IRI are supposed to respect the previous > > In-Progess='true' header on some prior SE-IRI action. So that means that we > > need to decide what the default "prior" setting for In-Progress is if the > > action to EM-IRI is the first action. I assume that would be 'false' for > > consistency. And it also means that services have to figure out a place to > > save state somewhere to record that flag and make sure that it is always > > properly initialized and maintained. This is the only place that additional > > state has to be created. > > The key here is that you can /never/ take your first action on the > EM-IRI, because this IRI doesn't exist until a container has been > created. The important identifiers in the interactions are: > > Col-IRI - the Collection identifier, to which the first action must > take place. This is a POST of either a binary object, an atom entry > or a multipart object, and results in the creation of the container. > During creation you would specify the In-Progress header to indicate > that the created object is to be held back from the workflow > > Edit-IRI/SE-IRI - the container's identifier; this is the entry point > to the object itself at the server end. All operations regarding the > object's state must be directed to this IRI (or the SE-IRI, which is > almost always going to be the same), and therefore In-Progress is > allowed here. Retrieving the Edit-IRI will give you an atom entry > document which will contain the EM-IRI. Therefore, you cannot have > acquired an EM-IRI until you have already created an object. > > EM-IRI - The identifier of the media contained in the container. > Since this is a media level identifier, it cannot be used to make > decisions about the container itself, and this is why In-Progress is > forbidden here. If you were to allow In-Progress to be sent to this > identifier, the server would need to understand whether the new media > files being deposited were "in progress" or whether the header referrs > to the container as a whole. This resolution of a complex state is > likely to be different per implementation, and also makes the > specification itself far more confusing than is viable (we did try > doing this, btw), but also is inconsistent with the nature of REST. > > > I can't figure out why we don't just use the header in all cases? What > > benefit accrues from not using the header on actions on EM-IRI? What is not > > using it for actions on the EM-IRI saving? If we use the header in all cases > > then the publish logic is always the same and super simple: check the header > > or its implied default. > > > > > > > > Thoughts? > > Hopefully the above clarifies the decision process. The crux, > ultimately, is that In-Progress on the EM-IRI would not be RESTful, > and the consequences of violating this principle bring uncertainty in > the implementation and complexity in the profile. > > Does that make sense? > > Cheers, > > Richard > > > > -- > Kathi Fletcher > Email: kathi.fletc...@shuttleworthfoundation.org > Alternate Email: kathi.fletc...@gmail.com > Twitter: kefletcher > Skype: kef-sky > Blog: kefletcher.blogspot.com > Phone: US 862-345-6178 > > ------------------------------------------------------------------------------ > All the data continuously generated in your IT infrastructure contains a > definitive record of customers, application performance, security > threats, fraudulent activity and more. Splunk takes this data and makes > sense of it. Business sense. IT sense. Common sense. > http://p.sf.net/sfu/splunk-d2d-oct_______________________________________________ > sword-app-tech mailing list > sword-app-tech@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/sword-app-tech ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct _______________________________________________ sword-app-tech mailing list sword-app-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sword-app-tech
