Re: [Sword-TAP] My Thoughts
On 17 Mar 2011, at 21:28, Richard Jones wrote: > Hi Scott, > > On 17/03/11 08:43, Scott Wilson wrote: >> >> On 17 Mar 2011, at 00:25, David Tarrant wrote: > 6.6. Adding Content to a Resource >>> >>> I'll get onto this and point, just as a pointer however look at the >>> 'Creating a folder' section in the GDocs API. >> >> This whole area of SWORD (secs 6.4-6.6) is effectively doing the same job as >> CMIS. Is there a good reason for creating a new spec here? >> >> If these kinds of operations (remotely manipulating the content of virtual >> packages) are part of the core functions of SWORD, should it be a profile of >> CMIS rather than AtomPub? > > I've tried /quite/ hard to get to grips with CMIS without a huge amount of > success. It seems extremely large and full of a lot of stuff which is way > way way over the top for what SWORD is trying to achieve, as far as I can > tell. It is indeed rather more complex than SWORD as it is handling content management rather than just deposit --> > > Also, we tried in the business case/technical architecture document to > position SWORD firmly in the "deposit" space rather than the "content > management space" (which I may or may not have succeeded in doing). Certainly > I can see the case that enabling CRUD means that you are doing some content > management, so we're striving to keep the details of what we say based > entirely on the aspects of transferring data point to point rather than > mandating what happens to that data at either end (this is, for example, part > of the reticence to formally incorporate GData). --> and so we really have to make sure the scope is correct. It has veered into CM with all these operations on the content of packages. > > So, profiling CMIS seems like a massive undertaking and a large burden on the > implementers just to make sense of what they would or wouldn't have to > implement. Could you comment on that, do you think? Actually I don't think profiling CMIS would be at all necessary. If SWORD is about deposit, and CMIS is about CM, then implementers can choose the specs they want to support based on the functionality they want to expose. So some implementations may just want to support deposit with some packaging format hints, while others may want to look at implementing CMIS (e.g. using CMIS libraries such as Apache Chemistry) - either instead of or as well as SWORD. At the moment there seems to be an assumption that a solution halfway between SWORD 1.x and CMIS is desirable. > > What does seem possible is that we could adopt terms from the CMIS namespace > to use in SWORD, rather than minting new terms. I'm thinking, for example, > of cmis:createdBy being used instead of sword:depositedBy, although there's > some argument to be had over whether those two are really the same thing. > Could you possibly suggest some similarities in terms in CMIS that might be > appropriate for reuse in SWORD? See above ... > > Also, do you know of any good introductions to CMIS that are bit more > penetrable than the specification that I could look at? Playing with the Apache Chemistry libs is probably more rewarding than reading the spec as you can see what its doing. http://chemistry.apache.org/ > > 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 Sword-app-techadvisorypanel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sword-app-techadvisorypanel
Re: [Sword-TAP] My Thoughts
Hi Scott, On 17/03/11 08:43, Scott Wilson wrote: > > On 17 Mar 2011, at 00:25, David Tarrant wrote: >>> 6.6. Adding Content to a Resource >> >> I'll get onto this and point, just as a pointer however look at the >> 'Creating a folder' section in the GDocs API. > > This whole area of SWORD (secs 6.4-6.6) is effectively doing the same job as > CMIS. Is there a good reason for creating a new spec here? > > If these kinds of operations (remotely manipulating the content of virtual > packages) are part of the core functions of SWORD, should it be a profile of > CMIS rather than AtomPub? I've tried /quite/ hard to get to grips with CMIS without a huge amount of success. It seems extremely large and full of a lot of stuff which is way way way over the top for what SWORD is trying to achieve, as far as I can tell. Also, we tried in the business case/technical architecture document to position SWORD firmly in the "deposit" space rather than the "content management space" (which I may or may not have succeeded in doing). Certainly I can see the case that enabling CRUD means that you are doing some content management, so we're striving to keep the details of what we say based entirely on the aspects of transferring data point to point rather than mandating what happens to that data at either end (this is, for example, part of the reticence to formally incorporate GData). So, profiling CMIS seems like a massive undertaking and a large burden on the implementers just to make sense of what they would or wouldn't have to implement. Could you comment on that, do you think? What does seem possible is that we could adopt terms from the CMIS namespace to use in SWORD, rather than minting new terms. I'm thinking, for example, of cmis:createdBy being used instead of sword:depositedBy, although there's some argument to be had over whether those two are really the same thing. Could you possibly suggest some similarities in terms in CMIS that might be appropriate for reuse in SWORD? Also, do you know of any good introductions to CMIS that are bit more penetrable than the specification that I could look at? 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 Sword-app-techadvisorypanel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sword-app-techadvisorypanel
Re: [Sword-TAP] An example Implementation (VIDEO)
Hi Alistair, Thanks for this detailed analysis. I believe your point is completely valid, and I hadn't considered it before. Some thoughts in line ... > Apologies again, please bear in mind these comments are based on a partial > reading of the doc, will hopefully have more time to read in full soon. More > inline... > > On Mon, Mar 14, 2011 at 06:08:56PM +, Richard Jones wrote: >>> I notice in the current spec you overload the 'edit-media' relation to >>> define new protocol behaviour when POSTing binary content to a deposit's >>> edit-media URI. >> >> I'm not sure what you mean, sorry. We haven't specified any >> behaviour for POST on the edit-media URI (EM-URI in the document). >> We do a PUT on that URI which I think is consistent with the AtomPub >> approach (replace the old file with the new file). We do do a POST >> on the edit URI (Edit-URI in the document) which isn't covered by >> AtomPub at all, but is consistent with a RESTful approach. Is it >> that that bothers you? > > Sorry, I must've mis-read first time. Now I'm reading section 6.6.1 "Adding > New Packages or Files to a Container"... > > ...OK, yes I think I would object to using the edit-URI for this purpose. > Well, > actually, no, I don't care what URI you use, what I would object to is > specifying the use of the 'edit' link relation to indicate which URI can be > used for this purpose. > > I'm just trying to come at this from a REST/hypermedia point of view. > > What this spec effectively does is to change the meaning of the 'edit' > link relation, or in this case to "overload" it by giving it an additional > meaning over what IANA (via the AtomPub spec) has to say about it. > >> From a practical point of view, as a client developer, how do I know when > the 'edit' link means only what it says in the IANA registry, and when the > 'edit' link also means what it says in the SWORD spec? Yup, this is a key insight. We are in want of polymorphism in @rel values ... > E.g., say my client receives an Atom entry document. The client finds an > 'edit' link, and because it's programmed with knowledge of atompub, it then > knows what URI to use to update or delete the entry. But how does my client > additionally know that the URI at the end of the 'edit' link also supports > adding new packages or files to a container? Should it look for other sword: > foreign markup in the entry document, then modify its understanding of the > 'edit' link relation based on the presence of this markup? Or should it just > assume that the 'edit' link means this in all cases, and just attempt the > operation (which may fail if it was actually just talking to a plain old > atompub server)? For simplicity in the profile this is what I would expect. As it is in the profile SWORDv2 allows for any URI to respond with Method Not Allowed or Not Implemented. But from a client implementation point of view, is this too indistinct? We could ensure that the server always announces to the client that it is a sword server, by mandating the use of a sword:version element in the atom:entry (deposit receipt). This is already mandated in the app:service element, so it would be a minimal extension. > Instead of specifying what operations the Edit-URI should support, which is > effectively redefining/overloading the meaning of the 'edit' link relation, > I would suggest that the SWORD specification simply define a new link > relation, e.g.: > > http://purl.org/net/sword/rel/append-package-contents > > Client developers would then know to use this link relation when looking for > the URI to use to POST additional package contents too. And server developers > would be free to implement this behaviour using whatever URIs they choose - > they could do it with the edit-URI, or they could do it with a completely > different URI, it's up to them, and it doesn't matter for the client because > the client is hypermedia-driven. So this would be an explicit way of just asserting that the URI can be used for that purpose, but in the profile we could say that the Package Contents URI MAY be the same as the Edit-URI. That's sort of a question, and sort of just me reflecting back what you're saying to confirm that I've understood. If I have understood, I like the approach - we wouldn't need to include the sword:version in the atom:entry as I suggest above in this case. > To labour this point a bit more, by specifying that the edit-URI has to > be used for this purpose, you are placing unnecessary constraints on how > servers are implemented. I.e., as a server implementer, I'm now forced to > extend/override/modify my existing server-side code for handling requests to > edit-URIs to implement this behaviour. If instead you just define a new link > relation, then server developers are free to stick this new behaviour at any > URI of their choosing, which gives the server-developer far more freedom in > how > the behaviour is implemented. And it's also simple and c
Re: [Sword-TAP] An example Implementation (VIDEO)
Hi Ian, On 15/03/11 11:55, Ian Stuart wrote: > On 14/03/11 21:21, Richard Jones wrote: >> I think that a large part of what SWORD adds to AtomPub is how you talk >> about packaging. We're definitely not going to go down the route of >> specifying package formats or support levels outside of AtomPub's basic >> definitions. What I'd be particularly interested to know is whether you >> think that SWORD currently provides you with enough tools to talk >> /about/ packaging? >> >> We have, for example, had a couple of mentions of the desire to ONLY use >> mime-types, which we know is insufficient for describing packages - what >> is the mime type of a DSpace METS package? And I have also verified that >> the registration process for mime-types is not strictly trivial. Do the >> extra features for providing Package information during deposit, >> Accept-Package headers for retrieval, and sword:packaging elements in >> the service documents and atom entries provide you with a framework >> which will work for your requirements? > From various conversations I've had with people, the concept of > "packaging" is confusing for people. > > For many people, a "package" is a simple thing... and therefore can be > assigned some kind of identifier (hence the idea of hooking into MIME > Types) > > For others, me included, a "Package" is a concept that is composed of > multiple parts: > 1) There is the singular Thing that holds everything (liken this to a > cardboard box) > 2) Inside the Thing, there is a file of descriptive data [metadata] and > some number of binary files (liken this to a Manilla file and some > data-disks in the box) > 3) There may also be a Manifest file that describes what the contents of > the box are, and how they relate to each other. It is this definition of Package that we need to be able to support within SWORD. Could the problem be down to the name (as you perhaps hint at here). Would we be better changing the names of "Package" related terms to something like "FormatProfile" or something? > In this second, expanded, view there are three things one need to define > within the discussion > > 1) What the singular Thing is: a (zip|xml|csv|xyz) file > 2) What "standard" the manifest file is written to (METS, EPrintsXML, > etc) > 3) What "standard" the metadata file is written to (DC, QDC, MODS, > EPrintsXML, BibTek, etc...) > > Now, one could define a new identifier for each combination of manifest > & metadata, or one can describe them separately > One has great flexibility & expandability, the other uses fewer header > fields. I think at the moment we're going for a URI which describes the combination. This is partly because /at the moment/ repositories tend to support a finite set of Packages which consist of their favourite metadata formats and their favourite structural manifests. So not all possible permutations of structural and descriptive data is currently likely. This may, of course, change. Thoughts? 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 Sword-app-techadvisorypanel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sword-app-techadvisorypanel
Re: [Sword-TAP] My Thoughts
On 17 Mar 2011, at 00:25, David Tarrant wrote: >> >>> 6.6. Adding Content to a Resource > > I'll get onto this and point, just as a pointer however look at the 'Creating > a folder' section in the GDocs API. This whole area of SWORD (secs 6.4-6.6) is effectively doing the same job as CMIS. Is there a good reason for creating a new spec here? If these kinds of operations (remotely manipulating the content of virtual packages) are part of the core functions of SWORD, should it be a profile of CMIS rather than AtomPub? -- 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 Sword-app-techadvisorypanel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sword-app-techadvisorypanel
Re: [Sword-TAP] My Thoughts
On 17 Mar 2011, at 00:25, David Tarrant wrote: > I'll try and break this email down, and only include the stuff from the email > I was meant to send. I'm humiliated that I sent this email. I was generally > having a bad day and did the worst thing possible by letting this get sent. > Still there are a few points I want to now raise. > >> >>> app:accept vs sword:acceptPackaging > > Firstly ignore the whole first one cos it's in the Atom-Pub spec, so that's > fine, not necessarily correct, but there. Its highly useful! Not all SWORD services are going to care about packaging specs. So being able to say talk about Zip/Gzip/Tar archive MIME types is still useful. -- 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 Sword-app-techadvisorypanel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sword-app-techadvisorypanel
