[Kobv-opus-tester] Testmigration auf OPUS 4.2.0 (ein Problem beim Editieren der Abstracts im Admin-Bereich)

[Sascha Szott]

Hallo Herr Heitmann,

ich erlaube mir mal die Konversation wieder auf die Liste zu leiten, so 
dass auch andere interessierte OPUS4-Anwender mitlesen können.

On 08.02.2012 16:36, Sven Heitmann [UB] wrote:
> nachdem uns das Set 'open_access' nicht bei 'verb=ListSets' mit
> ausgegeben wurde, hatten wir an dieser Stelle keine weiteren Prüfungen
> vorgenommen. Zudem zeigte uns der DINI-Check
> (http://oanet.cms.hu-berlin.de/validator/pages/validation_dini.xhtml)
> bei 'open_access' an, dass dieses Set nicht vorhanden ist.
>
> Mit 'verb=ListRecords&metadataPrefix=oai_dc&set=open_access' werden die
> Datensätze, wie Sie schreiben, dennoch ausgegeben.
>
> Sofern wir ein Subset anlegen und diesem mindestens ein Dokument
> zuordnen wird das Set 'open_access' bei 'verb=ListSets' mit ausgegeben.
> Das zeigt sich dann auch beim DINI-Check.
Gut. Dann besteht also der Bug "nur" darin, dass die Ausgabe bei 
verb=ListSets nicht korrekt arbeitet und hierbei Sets unterschlägt, wenn 
sie keine Subsets mit mindestens einem publizierten Dokument haben. Ich 
habe dafür bereits gestern ein Ticket eröffnet: OPUSVIER-2357. Sollte 
dann in OPUS 4.2.1 behoben werden.

In diesem Zusammenhang ist mir noch eine andere Unschönheit aufgefallen, 
die ich in OPUSVIER-2358 festgehalten habe: wenn leere Subsets abgefragt 
werden, dann erscheint statt dem Fehlercode code="noRecordsMatch", der 
unbekannte Fehlercode (code="unknown") im Element error. Das könnte 
evtl. bei Harvestern zu Problemen führen, die ihre Daten per OAI-PMH 
abziehen und kontextsensitiv auf solche Fehler reagieren.

Zu ihrer Frage:

> Gibt es eine Möglichkeit jedes neue Dokument in OPUS 4 automatisch einer
> bestimmten Collection zusätzlich zuzuordnen?
In der XML-Dokumenttypdefinition kann mit dem Element default 
prinzipiell ein voreingestellter Wert für ein Feld gesetzt werden. 
Außerdem kann mit den Attributen edit und public gesteuert werden, ob 
das Formularfeld editierbar und sichtbar ist oder nicht. Ein Beispiel 
dazu finden Sie auch im Testdokumenttyp all in

$BASEDIR/opus4/application/configs/doctypes/all.xml

Dieser Mechanismus greift aber bislang offenbar nicht bei den 
Collections (Sammlungseinträgen). Es ist also aktuell nicht möglich ein 
verstecktes Feld im Formular zu haben, das dazu führt, dass das Dokument 
beim Speichern automatisch zu einer Collection (Sammlungseintrag) 
zugeordnet wird.

Können Sie uns den konkreten Use-Case nennen, der hinter Ihrer Frage 
steckt? Vielleicht gibt es einen "dirty hack", der auch zur Lösung 
führt? Oder wir erachten den Use-Case als allgemeingültig und nehmen ihn 
als Feature Request auf.

Beste Grüße,
Sascha Szott

>
> Am 07.02.2012 10:09, schrieb Sascha Szott:
>> Hallo Herr Heitmann,
>>
>> On 06.02.2012 10:19, Sven Heitmann [UB] wrote:
>>> Wir haben versucht bezüglich DINI-Zertifikat eine Sammlung "open_access"
>>> anzulegen und diese als OAI-Set auszugeben. Leider ohne Erfolg. Das ein-
>>> bzw. ausblenden im Browsing und Frontdoor funktioniert einwandfrei.
>>> Die Einstellung "Sammlung als OAI-Set ausgeben" scheint ignoriert zu
>>> werden.
>> Ich kann diesen Fehler leider nicht in meiner Testinstanz
>> reproduzieren. Können Sie uns bitte eine detaillierte
>> Fehlerbeschreibung zukommen lassen. Die einzige Ungereimtheit, die mir
>> aufgefallen ist, betrifft die OAI-Ausgabe mit dem Parameter
>> verb=ListSets. Hier werden offenbar nur Sets ausgegeben, wenn sie auch
>> Subsets besitzen.
>>
>> Die Ausgabe der Dokumente eines Sets/Subset (mit verb=ListRecords)
>> verhält sich aber m.E. wie vorgesehen.
>>
>> Vielen Dank,
>> Sascha Szott
>>
>

-- 
Sascha Szott :: KOBV/ZIB :: <szott at zib.de> :: +49 30 84185-457