Thanks Larry! Looking at the XML which Manakin produces, I see that the file metadata is specified in a <file> element from the METS vocabulary, and the file type is specified only with a MIMETYPE attribute. There doesn't seem to be a way in METS to provide more specific information than that (such as is stored in the BitstreamFormat registry). AFAICS, it would be necessary to embed some extra XML markup in a foreign (non-METS) namespace.
Con On Mon, 2007-11-26 at 16:59 -0500, Larry Stone wrote: > I haven't looked at the Manakin code, but the MIME media-type of a Bitstream > must be coming from its associated BitstreamFormat -- so why not get > the human-readable name from the BitstreamFormat as well? There is no > need to establish a separate map of MIME-type to user-friendly name > when it already exists in teh BitstreamFormat registry. > > String friendly = bitstream.getFormat().getShortDescription(); > > One complication, or perhaps advantage, of using BSFs directly is that > some of them have the same MIME-type, so getting the friendly name > from the BSF actually identifies the format more precisely -- e.g. > XML-based formats might all have the MIME-type "text/xml", but distinct > friendly names. Thus, you should go to the Bitstream's BSF to get the > friendly name rather than attempt to use the BSF registry as a map, > because it might have multiple matches for one MIME-type. > > -- Larry > > > On Nov 21, 2007 10:06 PM, Conal Tuohy <[EMAIL PROTECTED]> wrote: > > > On Wed, 2007-11-21 at 16:43 -0600, Dorothea Salo wrote: > > > The mapping between media-types and friendly names could be introduced > > > into the pipeline using a Manakin Aspect, and then utilised in a View, > > > via XSLT. > > > > Aha. I can try to tackle this. What would be the closest existing code? > > > > > Alternatively, perhaps this is really just a case of i18n? > > > > I thought about that, but I can't quite make it work happily. Every > > time an administrator adds a new bitstream format (something I assume > > Manakin still has UI for?), DSpace itself would have to make an > > automatic change to messages.xml, which is under most circumstances a > > human-authored and source-controlled file. Automagically changing it > > will make a mess of any installation that keeps its source in source > > control, I would think. > > > > Dorothea > > > > -- > > Dorothea Salo [EMAIL PROTECTED] > > Digital Repository Librarian AIM: mindsatuw > > University of Wisconsin > > Rm 218, Memorial Library > > (608) 262-5493 > > > > ------------------------------------------------------------------------- > > This SF.net email is sponsored by: Microsoft > > Defy all challenges. Microsoft(R) Visual Studio 2005. > > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > > _______________________________________________ > > DSpace-tech mailing list > > DSpace-tech@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/dspace-tech > -- Conal Tuohy New Zealand Electronic Text Centre www.nzetc.org ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
