On 5 Jan 2011, at 15:23, Ian Stuart wrote: > On 24/12/10 17:06, Richard Jones wrote: >> Of all the areas of the proposal, there is one area which stands out as >> particularly contentious and on which I would be very interested in your >> feedback: When more than one file has been deposited into the same item >> on the sword server (first with create, and then with update), what does >> the edit-media URI refer to? My proposal in the paper is that the >> edit-media URI (referred to as EM-URI throughout) abstractly refers to >> all the content of the item, and that exactly what you get back depends >> on how you content negotiate for it. This means that it does not >> necessarily return to you what it was that you deposited originally (how >> could it, if you have deposited multiple files?). I then hope to fix the >> issue of allowing the client to retrieve the originally deposited >> files/packages by providing an ORE resource map which describes the >> structure of the item on the server, and is extended to identify which >> files are the original deposits. >> >> Any thoughts that people have on this perversion of AtomPub would be >> gratefully received. > > Here is my thought..... > > For any "item" being deposited, there is a historical record of deposit, > update, update, update, .... > > In a really simple world, this is a single deposit, followed by a single > update that goes "deposit -> value-added work by injest systems -> published" > > In a slightly more complicated world, this is still a linear flow. > It can be one of two processes - > A single object, altered in place: > "deposit -> value-added work by ingest systems -> published -> add/remove > file -> add/remove metadata -> add/remove <something> -> [and so on]" > or it can be a series of linked simple-world examples: > "deposit -> value-added work by injest systems -> published" -> "deposit -> > value-added work by injest systems -> published" -> "deposit -> value-added > work by injest systems -> published" -> [and so on] > > Finally, there is the more likely scenario, where the updates can come from > multiple sources (one would hope that is tracked) and interweave over time > (some are started, but marked "in-progress" for a while; others start later, > but go straight through) - which would result in a tree of changes & updates. > > What would probably be sensible is for the URI to refer to the item in its > current state - after all actionable deposits and updates have been > performed. From here, the client can query for the history of the object - > which would return all the changes, who posted them, and when they were > actioned... and all the outstanding "in-progress" items [that have been > posted by the client?]
I think CMIS uses a Change Events extension to Atom to handle the case of returning the change history of an item. (Actually, for any of the CRUD extensions, first point of call should be to ask "what does CMIS do?" as they are likely to have had exactly the same discussion already). > > -- > > 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. >
smime.p7s
Description: S/MIME cryptographic signature
------------------------------------------------------------------------------ Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________ sword-app-tech mailing list sword-app-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sword-app-tech
