Drop By!

In der deutschen Jira-Version wird das Datumsformat unter Administration – Globale Einstellungen Gestaltung eingestellt.
Hier ist ein Beispiel:

Datums-/Zeitformate
                            Format   Beispiel
  Zeitformat           HH:mm   22:28
  Datumsformat   EEEE HH:mm   Freitag 22:28
  Vollständiges Datums-/Zeitformat   dd. MMM yyyy HH:mm   21. Nov 2008 22:28
  Format Tag/Monat/Jahr   dd. MMM yyyy   21. Nov 2008
  Format Datumsauswahl (Format javascript)   dd. MMM yyyy (%e. %b %Y)   21. Nov 2008
  Format Datums-/Zeitauswahl (Format javascript)   dd. MMM yyyy HH:mm (%e. %b %Y %H:%M)   21. Nov 2008 22:28

Dabei muss man das Format für die Auswahl in Formularfeldern per JavaScript in einer externen Konfigurationsdatei einstellen:
WEB-INF/classes/jira-application.properties

Ein Beispiel:

# These two properties need to match for the datepicker to perform correctly
# The first date is in Java format
# (http://java.sun.com/j2se/1.4.2/docs/api/java/text/SimpleDateFormat.html).
# The second in unix format (see the FORMAT section of http://unixhelp.ed.ac.uk/CGI/man-cgi\
?date)
# Please note that the following options are not recognised: %c %D %E, %F, %G, %g, %h %r %R\
 %T %x %X %z %Z - _ ^ #
# After editing ensure the date picker creates valid dates, we also recommend you make this\
 format the same as Day/Month/Year Format
# in the administration section of JIRA
jira.date.picker.java.format = dd. MMM yyyy
jira.date.picker.javascript.format = %e. %b %Y

# These two properties need to match for the datetime picker to perform correctly
# The first date is in Java format
# (http://java.sun.com/j2se/1.4.2/docs/api/java/text/SimpleDateFormat.html).
# The second in unix format (see the FORMAT section of http://unixhelp.ed.ac.uk/CGI/man-cgi\
?date)
# Please note that the following options are not recognised: %c %D %E, %F, %G, %g, %h %r %R\
 %T %x %X %z %Z - _ ^ #
# After editing ensure the date time custom field picker creates valid dates
jira.date.time.picker.java.format = dd. MMM yyyy HH:mm
jira.date.time.picker.javascript.format = %e. %b %Y %H:%M

Am 17. Juni 2008 fanden in Brüssel zwei Meetings statt, die die Entwicklung des Handle Systems betreffen. Zum Einen der Handle System Workshop (erstmalig in Europa), zum Anderen ein Meeting der International DOI Foundation .

IDF Meeting 

DOIs sind nicht anderes als Handles mit zusätzlichen Regelungen, einem Layout und Schema sowie Services drumherum. DOIs und der DOI Resolver sind ein Bestandteil des globalen Handle PID und Resolution Infrastructure.

Den deutschsprachigen Raum betreffend würde ich die Präsentation des TIB Hannover hervorheben: Access to Non-textual Information: The Big Challenge for Libraries – What the DOI System Can Do to Help .

• The German Research Foundation (DFG) has started the project Publication and Citation of Scientific Primary Data to increase the accessibility of scientific primary data, starting with the field of earth science.
• The German National Library of Science and Technology (TIB) is now established as a “non-commercial” DOI-registration agency for scientific primary data as a member of the International DOI Foundation (IDF).

Die wissenschaftlichen Daten sollen in den Bibliothekskatalog und über DOI referenzierbar und mit den Artikeln u.ä. verknüpft werden. Bspw. bekommen Kristall-Strukturen eine DOI verpasst.

Handle System Workshop 2008

Wer nutzt es?

• Library of Congress
• DTIC (Defense Technical Information Center)
• IDF (International DOI Foundation)
  • CrossRef (scholarly journal consortium, representing >2K publishers & societies)
  • CAL (Copyright Agency Ltd – Australia)
  • MEDRA (Multilingual European DOI Registration Agency)
  • Nielsen BookData (bibliographic data – ISBN)
  • R.R. Bowker (bibliographic data – ISBN)
  • Office of Publications of the European Community (OPOCE)
  • German National Library of Science and Technology (TIB)
  • Wanfang Data
• OECD
• NASA
• National Agricultural Library/USDA
• DSpace (MIT + HP)
• ADL (DoD Advanced Distributed Learning initiative)
• Los Alamos National Laboratory Research Library
• Australian Dept. of Ed., Sci, and Training (DEST) – PILIN project
• Clarin (Common Language Resources and Technology Infrastructure)

Interessant ist das PILIN Project, die genau das leisten, was für einen nachhaltigen Handle System bzw. PID Infrastruktur Betrieb nötig wäre. Der Vortrag gibt eine gute Übersicht über die Probleme und Tragweite, kann als guter Ausgangspunkt benutzt werden für eigene Überlegungen. Unter anderem wird auf FRBR Bezug genommen.

Zu erwähnen ist Crossref.org ebenfalls mit einem Vortrag anwesend.

CLARIN macht Ähnliches wie wir, siehe der Vortrag : “The CLARIN project is a large-scale pan-European collaborative effort to create, coordinate and make language resources and technology available and readily useable. As one of its goals CLARIN will create a federation of LR repositories and aims to create a unified resource registry using persistent identifiers.” Single resource identifier system for all “published” resources using the Handle System. Unified metadata catalogue. Identity federation using Shibboleth. Zusätzlich Problem mit verteilten Registries. Deswegen werden dort auch Tools entwickelt zum Verschieben, Wiederherstellen usw. von Handles – etwas was mit der Übernahme von externen Handles bspw. DOIs von Nature usw. interessant werden könnte.

Damit zusammenhängend (DAM-LR Distributed Access Management for Language Resources) Engagement der MPG:

• Single resource identifier system for all “published” resources using the Handle System. Unified metadata catalogue. Identity federation using Shibboleth. Zusätzlich Problem mit verteilten Registries. Deswegen werden dort auch Tools entwickelt zum Verschieben, Wiederherstellen usw. von Handles – etwas was mit der Übernahme von externen Handles bspw. DOIs von Nature usw. interessant werden könnte.
• Proposal within the MPG to support a MPG wide PID registration service based on the HS.
• Run by MPG computing center GWDG

Neue Entwicklungen

Dazu konsultiere man Introduction and Handle System Update ab slide 20 . Unter anderem

• Konfigurierbare und parametrisierbare Auflösung auf mehrere URLs
• Auflösung von nicht registrierten Handles nach Namensmustern, spart Speicherplatz, wird realisiert über neues Storage Modul
• Mehr globale Mirrors
• Update der RFCs
• Registrierung von Handles als URI Schema (im Augenblick : info:hdl )

Handle soll innerhalb von GRIDS benutzt werden um Objekte verteilt zu identifizieren: Grid Computing

Handle Types

Die bisherigen Typen für Handle Values sollen über eine Registry erweiterbar und formalisierbar werden. Beteiligung der Nutzer.

Siehe Handle Value Types.

This post was published originally in the intranet wiki of the Head Quarter (VZG) Common Library Union (GBV). Some friends asked me to make it accessible for them. To import the confluence post to wordpress one can just copy the html source code.

Bei dem Event für Entwicklung von Digitalen Repositories trafen sich dieses Jahr ca. 500 Teilnehmer aus aller Welt in  Southampton (UK) (Homepage der Konferenz) . Wer am Montag anreiste, konnte in der Dämmerung noch einen Spaziergang durch die (Hafen-)Stadt machen und ein paar eher zu dunkel geratene Fotos schießen (von hier aus startete unter anderem die Titanic).  Danach blieb wenig Zeit, der Bus holte die Teilnehmer um 8:30 vom Hotel ab, ab 9:00 dann zahlreiche Vorträge und abends die ergänzenden Veranstaltungen und Gespräche, gegen 11 p.m. trudelte man dann noch zu ein paar Ale oder Bitter im Hotel ein. Der 30min Nachtmarsch von der Uni, wo die Veranstaltungen stattfanden, zum Hotel war da eine willkommene Abwechslung zum sonst vorherrschenden Dauersitzen in Vorlesungssälen, deren Ausstattung eindeutig aus Zeiten vor der großen Laptopflut stammt.

Hier einige meiner inhaltlichen, sicher subjektiv-selektiven Eindrücke, teilweise mit Links teilweise aus dem Bauch oder Gedächtnis, gerne auch als Grundlage einer mündlichen Diskussion. Wer Details nachlesen möchte sei auf das Repository der Konferenz verwiesen.

• Die wichtigsten Entwicklungen kommen vor allem aus den USA, Australien und UK. In Dänemark scheint auch einiges los zu sein. Deutschland war diesmal mit eSciDoc (Karlsruhe+MPDL) präsent.
• Um ein größeres Repository aufzubauen, wurde die auf Erfahrung beruhende Aufwandsschätzung von 50 Mann/Frau-Jahren genannt.
• Die “Großen” riechen Lunte und engagieren sich zunehmend:
  • Microsoft mit eigner OpenSource-Initiative und wie man munkeln hört mit über 20 Entwicklern extra dafür abgestellt: Research-Output Repositories – An Overview of Microsoft Initiatives
  •  Sun mit der Förderung von Honeycomb als OpenSource-basierte Speichergrundlage für Fedora in einem gemeinsamen Projekt: Fedora and Honeycomb: A New Buzz in Creating and Managing Large-Scale Digital Archives, interessant auch das spezialisierte Filesystem mit eingebauten Metadaten. Hier der Link für unsere Systemtechniker Sun StorageTek 5800 System
  • Google hatte ebenfalls Leute vor Ort
  • BioMed Central bietet jetzt Reps als Service zum Kaufen/Outsourcen auf Basis von DSpace: http://www.openrepository.com/
• Motivationen für den Aufbau eines Reps: Archivierung, Veröffentlichung, Werbung (für Uni u.ä.), Erstellung von Metriken (Citation usw.), Neuerfindung von Universitätsverlagen, neue Geschäftsprozesse.
• Die große Schwierigkeit: Wie Daten in’s Reps bringen (politische und technische Aspekte) – a) per Gesetzt digitale Veröffentlichung von Dissertationen u.ä. erzwingen, b) Textmining . Der Trend geht dahin vorhandene, dem User gewohnte Tools und Standards zu nutzen: also bspw. Word, Atom-Protokoll… Zu technischen Fragen siehe auch Breaking the Repository Ingest Barrier.
• SWORD – lightweight protocol für Ingest (Speicherung und Einbringen) – als ein Profil des ATOM Publishing Protokolls
• Natürlich war und ist, wie nicht anders zu erwarten: “Wie verbinde ich den ganzen Kram mit Web2.0 zu Open Repositories 2.0?” ein zentrales Thema.
• Wie Daten verwaltbar aufbereiten und speichern, wie austauschbar machen zwischen unterschiedlichen Repositories?
• Textmining wird zunehmend an Bedeutung gewinnen.
• Woher sollen semantische Informationen zu den Objekten kommen? vom Verlag, von Bibliothekaren, ( von Nutzern, vom Autor ?)
• Auf Spezialgebieten sind schon beeindruckende Resultate erzielt worden wie bspw. CrystalEyefür Analyse chemischer Verbindungen zeigt, hier werden automatisch Daten aus heterogenen Quellen gesammelt und ausgewertet, enthaltene Beschreibungen von neuen chem. Verbindungen werden extrahiert und visuell als auch als Formel dargestellt. Die Verweise auf die Quellen gesammelt. (siehe auch Session 4b – Scientific Repositories )
• Ein wichtiges Thema ist das sog. cross-repository browsing, also das Suchen in unterschiedlichen Reps unter einer Oberfläche. Ähnlich einem Portal für Z3950-Kataloge. Hier wurde richtags( Vortrag: Rich Tags: Cross-Repository Browsing) vorgestellt, mit einem, wie ich finde, beachtenswerten User-Interface.
•  NCore von Cornell ist der Konkurrent zu eSciDoc auf dem Markt, ist OpenSource und basiert auch auf Fedora, einige bemerkenswerte Features, und  praktisch in größeren Maßstäben erprobt. (Vortrag: The NCore Platform: An Open-Source Suite of Tools and Services for Implementing Digital Libraries), die komplette Vergleichsmatrix zu erstellen ist sicher ein Projektchen für sich, nur ein Fakt: eSciDoc unterstützt Publikations-Workflows, was bei NCore nicht der Fall ist.
• Mittlerweile haben sich abhängig vom gewählten Basis-Softwaresystem unterschiedliche Nutzergruppen innerhalb der Reps-Landschaft herausgebildet. Also gab es für  Fedora, DSpace und und EPrints jeweils parallele Tagesveranstaltungen: Subject: User Groups
• Erwähnenswert ist die neue OAI-ORE ( Object Reuse and Exchange (OAI-ORE) ) Initiative (extra Veranstaltung am Freitag, da saß ich aber leider schon im Flugzeug): http://www.openarchives.org/ore/ - eine Art Austauschprotokoll, um Informationen über Digitale Objekte zwischen verteilten Reps auszutauschen

… so, das soll’s erstmal sein hier. Mehr zu lesen, hat sowieso niemand die Zeit … und auch bis hierher werden es die Wenigsten geschafft haben … ist ja auch im Augenblick noch ziemlich “nerdy”. Insgesamt eine interessante und bewegte Veranstaltung, die den Eindruck bestätigt, dass um wirklich aktiv an der neuen Welt der Digitalen Objekte teilzunehmen, es einer größeren Investition bzw. Commitments bedarf.

The eSciDoc Infrastructure is published now under the CDDL-Licence .

eSciDoc uses the Fedora Repository as backend to store the digital objects and runs within a JBoss Application Server. Although it is still beta the main features are implemented and the install works without bigger problems now.

Hier einige freie Bücher von Galileo Computing auf deutsch.

Integrationshandbuch Microsoft-Netzwerk
Ubuntu GNU/Linux
C von A bis Z
Java ist auch eine Insel – umfangreich
Praxisbuch Objektorientierung – enthällt auch moderne Konzepte wie IoC und Dependency Injection (siehe Spring Framework)
JavaScript und Ajax – ist für Ende November versprochen

Einen ausführlichen Artikel findest du hier: http://java.sun.com/docs/hotspot/gc5.0/gc_tuning_5.html und hier: http://java.sun.com/performance/reference/whitepapers/tuning.html . Siehe auch das Beispiel für Eclipse in Eclipse Crash Problem . Ein geeignetes Profiling-Tool ist GCViewer.

• Der Speicher für die JVM wird regelmäßig durch einen Garbage Collector gereinigt, um nicht benötigte Objekte zu entsorgen und Speicher wieder frei zu geben. (Das Ganze lässt sich vielleicht mit der Bettenverwaltung auf der Intensivstation einer Klinik vergleichen.)
• Es existieren mehrer GCen, die auf den jeweiligen Einsatzzweck hin optimiert sind.
• Die Arbeit des GC kostet Rechenzeit und ist deshalb mit Hilfe von Parametern einstellbar; kann sich als plötzliches “Hängen” der Anwendung bemerkbar machen.
• Der verwaltete Speicher wird eingeteilt in tatsächlich allozierten (also tatsächlich reservierten) und virtuellen Speicher (potentiell zur Nutzung vorgesehenen).
• Im Speicher der VM unterscheidet man 3 Haupt-Bereiche: Young Generation (kürzlich erzeugte Objekte, werden öfter eingesammelt vom GC, da die Erfahrung zeigt, dass diese auch schneller sterben), Tenured Generation und Permanent Generation (“Meta”-Bereich für Klassentemplates, Classloader, alles was die VM selbst benötigt um Aufgaben zu erfüllen, also Betten für die Nachtschwestern). Young und Tenure Generation gehören zum sogenannten Heap-Speicher, der der Anwendung selbst zur Verfügung steht.
• GC findet getrennt in YoungGen und TenureGen statt (Minor- bzw. Major-Collections), je größer diese Bereiche sind, desto seltener muss der GC nach toten Objekten suchen, um Speicherplatz frei zu geben.
• Die JVM kann beim Start mit Hilfe von Parametern “getuned” werden: http://java.sun.com/docs/hotspot/VMOptions.html
  • Aufruf: java -parameter anwendungs-class
  • -Xmx maximale Heapgröße (Virtuell+Reserviert), bsp. -Xmx1024m auf 1024 MB
  • Achtung! Diese Werte haben keinen Einfluss auf PermGen!
  • -Xms Mindest-Heapgröße (immer fest Reserviert)
  • -XX:MaxNewSize=64M max. Größe von YoungGen
  • -XX:NewSize=64M mind. Größe von YoungGen
  • -XX:MaxPermSize=128M max. Größe des PermGen Speichers, oft können auftretende Probleme hiermit gelöst werden, da dieser per default nur 64 M groß ist
• Für große Anwendungen reichen die default Einstellungen nicht aus.
• Für große Server:
  • Die default Einstellung (64M) ist oft viel zu klein. Besser soviel wie möglich Speicher zur Verfügung stellen.
  • Wenn man -Xms und -Xmx gleich setzt, erreicht man bessere Performance, da der Aufwand zur Allokation von zusätzlichem Speicher entfällt. Wenn dieser Wert aber unpassend gesetzt ist, kann die VM den Fehler nicht abfangen.
  • Speicher raufsetzten, wenn mehrere Prozessoren beteiligt sind, denn Speicherallokation kann parallelisiert werden.
  • Evntl. auch -XX:MaxNewSize und -XX:NewSize gleich setzen, aber nicht zu klein, bspw. wenn in einem Serveraufruf eine komplexe XML Datei verarbeitet wird oder, wie in Confluence möglich, eine große Excel-Datei geparst und importiert werden muss.
  • Da im Serverbetrieb viele Objekte nur einen Aufruf oder eine Session lang leben und der Lauf des GC im Unterschied zu einer GUI Anwendung von der Latenzzeit des Netwerks verdeckt wird, ist es evntl. sinnvoll (habe es nicht probiert) den YoungGen Bereich kleiner zu setzen (siehe -XX:NewRatio), wenn bekannt ist, dass die einzelnen Threads klein bleiben.
  • Für mehrer Prozessoren probiere den Throughput Collector (-XX:+UseParallelGC)

Weitere Tips (aus der oben genannten Quelle):

• For most applications the permanent generation is not relevant to garbage collector performance. However, some applications dynamically generate and load many classes. For instance, some implementations of JSPTM pages do this. If necessary, the maximum permanent generation size can be increased with MaxPermSize.
• Some applications interact with garbage collection by using finalization and weak/soft/phantom references. These features can create performance artifacts at the Java programming language level. An example of this is relying on finalization to close file descriptors, which makes an external resource (descriptors) dependent on garbage collection promptness. Relying on garbage collection to manage resources other than memory is almost always a bad idea.

Beachte auch (siehe http://java.sun.com/performance/reference/whitepapers/tuning.html)
:

Before you start to tune the command line arguments for Java be aware that Sun’s HotSpot™ Java Virtual Machine has incorporated technology to begin to tune itself. This smart tuning is referred to as Ergonomics. Most computers that have at least 2 CPU’s and at least 2 GB of physical memory are considered server-class machines which means that by default the settings are:

• The -server compiler
• The -XX:+UseParallelGC parallel (throughput) garbage collector
• The -Xms initial heap size is 1/64th of the machine’s physical memory
• The -Xmx maximum heap size is 1/4th of the machine’s physical memory (up to 1 GB max).