On 17/03/11 19:37, Richard Jones wrote: >> 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.
This is not a problem... we just need to be up-front about it. This mean, for example, that "METSDSpaceSIP" actually means "Zip file, with binary files included (subdirectories allowed). Manifest called 'mets.xml', which contains the meta-data in epcdx format." I'm happy with that..... but it does mean that this will spawn a LARGE number of distinct variations, each of which needs a unique IRI. (Again, not a problem: the package I develop for the OA-RJ broker has an IRI in my opendepot.org name-space) -- 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. ------------------------------------------------------------------------------ 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
