Franziska Geisser
My feedback
15 results found
-
12 votesFranziska Geisser
supported this idea
·
-
32 votesFranziska Geisser
supported this idea
·
-
12 votes
An error occurred while saving the comment Franziska Geisser
supported this idea
·
-
15 votesFranziska Geisser
supported this idea
·
-
8 votesFranziska Geisser
supported this idea
·
-
2 votes
An error occurred while saving the comment Franziska Geisser
commented
Yes, this is really annoying. I thought that maybe sorting the IE Entity Type Code Table would help, but it doesn't...
Franziska Geisser
supported this idea
·
-
25 votesFranziska Geisser
shared this idea
·
-
35 votesFranziska Geisser
supported this idea
·
-
6 votesFranziska Geisser
supported this idea
·
-
1 voteFranziska Geisser
shared this idea
·
-
16 votes
An error occurred while saving the comment Franziska Geisser
commented
I am glad to see that suggestion no. 1 has been implemented with SP 5.4.
Franziska Geisser
shared this idea
·
-
7 votes
An error occurred while saving the comment Franziska Geisser
commented
In general, I would support the idea of separating more strictly the mechanisms of format identification, validation and metadata extraction. To the third paragraph listing the classes of errors, two elements might be added:
1.c.3: An extension that is not yet recorded in FL/PRONOM/YourFormatRegistryHere for the identified format
2.d: No Validator for that format available (equivalent to 3.a)From the second addition follows a general concern:
If the absence of a Validator or MD extractor plugin is regarded as an error and makes the file end up in TA, we (speaking from the perspective of an archive that has to handle a great variety of file formats) would face a lot of extra work in the TA workbench. It seems to me that Jörg’s idea is written from the point of view of an archive dealing with a limited number of well-established formats regarded as suitable for long-term preservation. For this almost ideal situation, it seems appropriate to set strict standards and voice the consequences as rigidly as it is done in the last paragraph. But in sordid reality, we need to be able to let unknown formats pass into the permanent repository – think of research data in specialized formats that are not yet recorded in PRONOM and cannot be converted into standard formats without losing vital information. While the decision to accept or not to accept unknown format should be guided by an institution’s policy, the digital preservation system itself should not in any way impose a specific policy, but should grant users the full scope of action.Franziska Geisser
supported this idea
·
-
2 votes
An error occurred while saving the comment Franziska Geisser
commented
I would see the extraction as a permanent action. We want the extracted files to be archived, not the container as a whole - otherwise we can't perform any meaningful preservation actions. The export functionality will give me a tar container anyway. Only for delivery I would prefer to get the zip container instead of having to download each file individually. In the best of all worlds, it would be possible to configure the deposit workflow in such a way that the extracted files are stored as a preservation master representation, and at the same time the unextracted zip file is added as a derivative copy representation.
An error occurred while saving the comment Franziska Geisser
commented
We too had to accept the fact that the option "automatically extract compressed files" does not work with a METS content structure material flow. However, we would come to a different conclusion: Our wish would be not that this option be removed, but that it actually worked! We are looking for a way to extract zip or tar files during automatic ingest from our research data repository to Rosetta, because we would prefer to archive single files rather than zip or tar containers.
We are of course well aware of the fact that this is rather a dream than a realistic expectation. In order to avoid the mismatch between the original METS structmap and the new file structure, there would probably have to be some transformation process in between.
-
10 votesFranziska Geisser
supported this idea
·
-
18 votesFranziska Geisser
supported this idea
·
I strongly endorse this idea (which looks rather like a bug fix to me). We have a case open for alphanumerical sorting of files with Aurigma folder and zip upload (with automatic decomposition). According to case 00023742, this should be fixed with SP 6.0, but I didn't find a reference in the release notes.