Title: Message Title
|
|
I agree that things like INTRODUCTORY_TEXT should support multiple languages. That was indeed one of the drivers for "proper" metadata support on all DSOs. COPYRIGHT_TEXT may be a special case, though, because it is legally actionable -- it may be difficult to have all the language variants mean precisely the same thing, and having variants might open up the issue of what jurisdiction (with its own local IP laws) applies to each. We may need real legal advice on this. In any case we couldn't properly enforce a limit to single values on some types but not others, without proper *schema* support. I'm treating that as a separate issue which we can later build on homogeneous metadata support. We may want to think about simply not offering multiple values in the UIs on a few fields, though, and documenting why we think multiple values in those fields might be problematic. We ought to be sure that we properly document any "internal" namespaces in the DSpace reference, anyway, and this is one thing we should mention.
|
|
|
|
|
Many have wished for the flexibility of DSpace's *operable* metadata infrastructure, which is specific to Item, to be available in other types such as Community and Collection. Support for operable metadata should be pushed down from Item to DSpaceObject so that all DSOs can use it. I recognize that there are a number of other ways in which DSpace's m...
|
|
|
|
------------------------------------------------------------------------------
Flow-based real-time traffic analytics software. Cisco certified tool.
Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
Customize your own dashboards, set traffic alerts and generate reports.
Network behavioral analysis & security monitoring. All-in-one tool.
http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
_______________________________________________
Dspace-devel mailing list
Dspace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-devel