On 24 Feb 2011, at 15:39, Ian Stuart wrote: > On 23/02/11 11:37, David Tarrant wrote: >> In simple terms yes, however because both the repository and client >> can be in control of an object then it is actually a lot more >> complex! >> >> Plus you have missed some obvious things, like the fact that people >> don't know, and don't care what a sword endpoint in, they just want >> to deposit. > I agree that **PEOPLE** just want to deposit, however **SYSTEMS** need > to work out where that is :)
Indeed, i've solved that problem but no one cares :P link rel="Sword" href="http://service-doc"; link rel="SwordDeposit" href="http://a-deposit-endpoint"; > > >> ** conversation one ** >> C: Hello URL (any URL in the repo), I've been >> told I can POST something at you >> >> S: Yes here is a link rel="SWORD" from which you can get more >> description or if you are lazy here is a link rel="SWORDDeposit" >> which you can just use to deposit directly into >> >> Client then picks a URL (either involving the user or not, i would >> recommend not unless the user is a power user, and yes I'm taking >> about you Ian) > The issue is that the repository probably has a number of places the > user could deposit into. > EPrints is simple, it is either "Inbox", "Review", or possibly "Archive" > DSpace is much more complex, with a raft of "collections" the user could > deposit into. And how many users care about AT THE POINT of uploading a file? I'd argue this is just metadata which can be set later, it is a barrier to deposit. I'm not saying abolish it, but don't made it mandatory. > > >> >> ** concersation two ** C: Hello SWORD here is an object and some >> authentication details S: Ok i've done that, the object is at this >> "Location" - (HTTP HEADER) > "object" - needs to be defined No it doesn't it's just the thing the user wants to deposit and the user is right :) > >> C:Hello server i'd like to modify the metadata "edit-uri" relating to >> this record A: OK done OR not a chance, the repository has taken >> control of this record muhahahaha > "modify the metadata" - needs to be collected.... into an agreed package Again wrong, there doesn't need to be an agreed package, just one the repository supports, there can be a recommended package (and that by the way is ATOM PUB cos that's what SWORD is based upon) > >> C: Hello server I'd like to modify the content of this item >> "edit-media" URI A: As above > (as above) There is no requirement to package the media! > >> C: Hello server I have a replacement package for this old one >> "Location" URI from before. A: OK > (as above) > >> Now some valuable stuff to user which Ian doesn't care about cos he >> loves packaging. > I'm not sure I "love" packaging.... I just think its a important part - > heck. an integral part - of the overall conversation. Formats are the integral part, not package and unpacking. > > >> C: I have a new file which I want to add to a new object in the >> repository, can you please give me a container to put this in (done >> with an empty atom entry POST) A: Yes, here is the Location URI for >> your object and the edit and edit-media URI. > Returns URIs, no problem with that..... > >> >> C: Thank-you, now here is the file to go in the edit-media >> "container" A: Here is the "Location" of that file > No problem with a single file. > >> C: Here is another file A: Here is the "Location" of that on > No problem with a single file. > >> C: Here is another file A: Here is the "Location" of that on > No problem with a single file. > .... can you send two+ files? Not at the same time as how do you know where each is, individually yes. > >> C; Delete file 2 (DELETE to location of file 2) A: Done > No problem... > >> C: Can you give me a list of the media please "GET edit-media URI >> Accept Atom Feed" A: Sure here you go > "media" = "files".... no problem: a list of URIs to files > >> C: Here is some metadata describing this object (PUT to edit URI) A: >> Thank you > "some metadata" - needs packaged no, needs a format. > >> C: Can you give me a report on location X (any of the above), e.g. >> MD5sums, last changed headers, or atom entry etc A: Sure > agreed package of data returned.... but that's a sword-level issue I guess no this is a head request in the case of MD5 :) the package of the data returned is a content-negotiation to happen between client and server, SWORD again should recommend that at least application/atom+xml be supported. > >> C: File 1 has change, can you update it please A: Done > combination of PUT + DELETE from above.... no problem Can't combine PUT and DELETE really. you can PUT to a URI and overwrite data (so the DELETE is implicit). If you delete a URI, technically you shouldn't then re-instate it. > >> C: Metadata has change can you update it please, A: Not on this URI >> but here is the URI of a new object which is a more recent version of >> the one you gave me previously > Pass-by-reference - URI to a package of data > > > Every time we talk about transferring metadata from A to B, there needs > to be an agreement what the fields are, and how they relate to what's in > *your* repository. > > This is not a SWORD issue, directly.... however it *is* an issue SWORD > needs to address: if we can't transfer data in a uniform manner, then > the uniform transport mechanism is going to flounder. Agreed, which is where Atom Pub should be the minimal limit really. Just used only for what Atom Pub supports :) > > > -- > > 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. > > > ------------------------------------------------------------------------------ > Free Software Download: Index, Search & Analyze Logs and other IT data in > Real-Time with Splunk. Collect, index and harness all the fast moving IT data > generated by your applications, servers and devices whether physical, virtual > or in the cloud. Deliver compliance at lower cost and gain new business > insights. http://p.sf.net/sfu/splunk-dev2dev > _______________________________________________ > Sword-app-techadvisorypanel mailing list > Sword-app-techadvisorypanel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/sword-app-techadvisorypanel ------------------------------------------------------------------------------ Free Software Download: Index, Search & Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev _______________________________________________ Sword-app-techadvisorypanel mailing list Sword-app-techadvisorypanel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sword-app-techadvisorypanel
