[
http://jira.dspace.org/jira/browse/DS-700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=11794#action_11794
]
Christophe Dupriez commented on DS-700:
---------------------------------------
Thank you Stuart!
For catalogues with many fields / languages, pre-filtering columns would ease
the job especially if operations are repeated (for instance translating new
records, reorganizing indexation for different keywords, etc.).
The handle is the "visible" ID: Don't you think it is better that users only
see it and never the internal ID? Also, it is very easy to look at the full
record in DSpace using the handle.
I forwarded your answer to Julien (he presented with me at Goteborg) so he can
decide what is the best for his operations.
But I remain interested by other users' (metadata managers) eventual wishes
!
Wishing you a very nice day,
Christophe
> Bulk Metadata Editing: defining "formats" for export/re-import of selected
> fields
> ---------------------------------------------------------------------------------
>
> Key: DS-700
> URL: http://jira.dspace.org/jira/browse/DS-700
> Project: DSpace 1.x
> Issue Type: Improvement
> Components: DSpace API, JSPUI
> Reporter: Christophe Dupriez
> Original Estimate: 2 days
> Remaining Estimate: 2 days
>
> When looking at use cases like:
> 1) bulk correction of keyword assignment (export existing indexation and let
> indexers create a new one using global search and replace)
> 2) translation of abstracts (export existing abstracts in different languages
> and let translators complete it and reimport)
> 3) export of records for merging in a word processor template
> current CSV Bulk Metadata Editing has many good feature and may be a lack in
> terms of defining exports/reimport of a selection of fields.
> Another thing which surprises me is the use of item ID instead of handle to
> identify the records. But this may be due to conflicting use cases:
> 1) bulk reorganisation of handle assignment (IDs stay but handles may change)
> 2) move from one version of an instance to another (IDs change but handles
> stay)
> I would like to define different thing in accordance with community whims if
> possible:
> 1) FORMATS: each format would be a list of metadata fields+language to be
> exported.
> 2) Standardize output directories: using a configurable pattern in
> DSpace.CFG, the exported/imported files would be send to a directory
> structure made of the user name and the format. A timestamp and/or a name
> choosen by the user would be used as a file name. For instance,
> /users/~[user]/dspace/csv/[format]/[filename].csv could be such a pattern.
> Missing directories would be automatically created. One could define a
> pattern where filenames contain the format type also:
> /users/~[user]/dspace/csv/[format]/[format]-[filename].csv
> My proposal for Export Formats Configuration would be to add a subdirectory
> dspace/conf/bulkedit where format.csv files would each give the headers of
> the desired columns in the export files with this format.
> We could keep a format named "allfields" for the current behavior.
> Please let me know soon what you would like so I can propose a module in line
> with community wishes!
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.dspace.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb
_______________________________________________
Dspace-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-devel
