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] An example Implementation (VIDEO)
On 21/02/11 22:27, Graham Klyne wrote: On the topic of packaging, I don't think this should be progressed in isolation. There's a community of interest in e-Research looking at Research Objects, which share many high-level requirements with packages for deposition - roughly, composite objects + metadata, in a simple, easy-to-construct, easy-to-deconstruct container. Can you send me some contacts for this? As part of the OA-RJ work, I will be producing a consistent method for transfer between myself and a number of repository applications. -- 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. -- 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. Free Software Download: 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
Re: [Sword-TAP] An example Implementation (VIDEO)
On 18/02/11 12:52, David Tarrant wrote: I think that, if you want to upload a package, don't expect to be able to edit parts of the package. I feel if you want to edit using packages, then you delete the previous version and upload a whole new package. Supporting more features than that is going to be very hard in the packaging scenario. I think I agree with much of this. My feeling is that using multiple transactions to assemble and/or edit a package can become very complex. While some systems may wish to offer such capabilities, I don't think they're a useful basis for an spec whose primary goal is interoperability. I think this is a different issue from that which Alistair Miles was raising, which was, as far as I could tell, about the use of different link-rel types for different functions rarher than overloading an existing one. In my experience, overloading can over-constrain design choices, and often lead to tears, and is probably best avoided. On the topic of packaging, I don't think this should be progressed in isolation. There's a community of interest in e-Research looking at Research Objects, which share many high-level requirements with packages for deposition - roughly, composite objects + metadata, in a simple, easy-to-construct, easy-to-deconstruct container. At this stage, I'd suggest that SWORD the spec should avoid specifying package formats, and that SWORD (the application) should keep its powder dry regarding specific packaging recommendations until some clearer community consensus emerges. (Some common themes I see in several places are: ZIP file container; ORE manifest; metadata in files within the container.) #g -- [1] Bechhofer, S., De Roure, D., Gamble, M., Goble, C. and Buchan, I. (2010) Research Objects: Towards Exchange and Reuse of Digital Knowledge. In: The Future of the Web for Collaborative Science (FWCS 2010), April 2010, Raleigh, NC, USA. [2] Bechhofer, S., Ainsworth, J., Bhagat, J., Buchan, I., Couch, P., Cruickshank, D., Delderfield, M., Dunlop, I., Gamble, M., Goble, C., Michaelides, D., Missier, P., Owen, S., Newman, D., De Roure, D. and Sufi, S. (2010) Why Linked Data is Not Enough for Scientists. In: Sixth IEEE e--Science conference (e-Science 2010), December 2010, Brisbane, Australia. Ian Stuart wrote: On 18/02/11 12:52, David Tarrant wrote: On 18 Feb 2011, at 12:49, Ian Stuart wrote: SWORD is a transport mechanism... we all understand that - but sword can either be a bling truck (http://farm1.static.flickr.com/120/307424194_ccb7df1246.jpg) or a container (http://www.shipping-container-modification.com/images/standard_large.jpg) and both are really expensive!!! The Shipping container is an un-patented design open access, if you like ;-) I think that, if you want to upload a package, don't expect to be able to edit parts of the package. I feel if you want to edit using packages, then you delete the previous version and upload a whole new package. Supporting more features than that is going to be very hard in the packaging scenario. The question still comes down to at some point, the client and the server need to exchange metadata and files - how is this negotiated and how is the data transferred? Even in your video, you are transferring a small set of metadata items from client to server. In your example, you control both ends of the link, so you know the fields to transfer. What happens when the objects get more complex, and you don't control both ends? Copying binary files is (relatively) easy copying sets of metadata from one system to another requires packaging Packaging is the area I'm interested in. -- 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. Free Software Download: 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
