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
