> 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
