Re: [Sword-TAP] The SWORD2 conversation
Cool. Maybe the specification checkers should flag if this doesn't exist then? On 14 Mar 2011, at 21:28, Richard Jones wrote: > > > On 24/02/11 16:22, David Tarrant wrote: >> >> 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"; > > FYI, See Section 4 of the SWORD 1.3 spec... > > http://www.swordapp.org/docs/sword-profile-1.3.html > > Cheers, > > Richard > > > > -- > Colocation vs. Managed Hosting > A question and answer guide to determining the best fit > for your organization - today and in the future. > http://p.sf.net/sfu/internap-sfd2d > ___ > Sword-app-techadvisorypanel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/sword-app-techadvisorypanel -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d ___ Sword-app-techadvisorypanel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/sword-app-techadvisorypanel
Re: [Sword-TAP] The SWORD2 conversation
On 24/02/11 16:22, David Tarrant wrote: > > 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"; FYI, See Section 4 of the SWORD 1.3 spec... http://www.swordapp.org/docs/sword-profile-1.3.html Cheers, Richard -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d ___ Sword-app-techadvisorypanel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/sword-app-techadvisorypanel
Re: [Sword-TAP] The SWORD2 conversation
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 >
Re: [Sword-TAP] The SWORD2 conversation
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 :) > ** 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. > > ** 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 > 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 > C: Hello server I'd like to modify the content of this item > "edit-media" URI A: As above (as above) > 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. > 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? > 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 > 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 > C: File 1 has change, can you update it please A: Done combination of PUT + DELETE from above no problem > 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. -- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/sword-app-techadvisorypanel
