Wikipedia Diskussion:BEACON/Format

aus Wikipedia, der freien Enzyklopädie
Zur Navigation springen Zur Suche springen

Statistik zu #TIMESTAMP

[Quelltext bearbeiten]

Von 81 BEACON-Dateien, die ich bei mir in einem Verzeichnis herumliegen habe, tragen 76 einen Zeitstempel im Header (16 als "#DATE", 60 korrekt als "#TIMESTAMP").

Für das Format der Zeistempel gilt:

Form Norm Anzahl
YYYY-MM-DDTHH:MM:SSZ ISO8601, vgl. OAI-PMH 9
YYYY-MM-DDTHH:MM:SS ISO8601 43
YYYY-MM-DDTHH:MM:SS+HH:MM ISO8601 1
YYYY-MM-DDTHH:MM ISO8601 3
YYYY-MM-DD HH:MM:SS auch ISO8601 2
YYYY-MM-DD ISO8601 3
Mon, 12 Sep 2011 13:40:49 +0200 RFC[2]822 1
Thu Apr 7 14:35:32 2011 Unix "date" (C Locale? RFC dazu?) 3
Sat Sep 10 23:47:01 CEST 2011 Unix "date" 1
nnnnnnnnnn Unix 7
TT.MM.JJJJ HH:MM:SS DIN-obsolet? 2
TT.MM.JJJJ Legacy 1

ISO8601 dabei m.W. = (oder Superset von) RFC3339. -- Thomas Berger 23:31, 12. Sep. 2011 (CEST)Beantworten

Themensammlung Meta-Klärung

[Quelltext bearbeiten]
Danke für die Statistik! Ich denke, wir sollten bei den Meta-Feldern mal Klarheit schaffen. #DATE und #ISIL sollten abgeschafft werden und das schon genutzte #REMARK könnte als optionales Feld erwähnt werden. Einige nutzen außerdem #UPDATE. Unklar ist noch der unterschied zwischen #NAME und #MESSAGE. #SOMEMESSAGE dagegen ist wohl zu unverständlich, das kann eher auch weg. -- Nichtich 23:45, 7. Dez. 2011 (CET)Beantworten
#DATE gab es m.W. nie... #ISIL stört nicht besonders. #NAME sehe ich im Zusammenhang mit #INSTITUTION : Die Beacon-Datei erschliesst ein konkretes Web-Angebot mit #NAME, das durch die #INSTITUTION betrieben wird order erzeugt worden ist. #MESSAGE (#ONEMESSAGE/#SOMEMESSAGE) hingegen ist ein knackiger Kurztext, der nicht nur sagt, wo (Verkürzung / Kürzelung von #NAME und/oder #INSTITUTION) sondern auch was zu finden ist (Dein Vorstoß mit #LINK geht zwar auch in die Richtung, ist aber vermutlich nicht als Ersatz von #MESSAGE gedacht gewesen ;-).
Regeln sollte man, dass sowohl zu #NAME als auch #INSTITUTION jeweils URLs gehören (können), analog #CONTACT könnten die in "< ... >" am Ende stehen.
Noch ganz unklar ist, insbesondere nachdem #FORMAT: PND-BEACON nicht mehr erwünscht wird, wie die Semantik der genutzten Identifier festgezurrt werden kann, wenn (wie im PND/GND-Fall) #PREFIX nicht ausreicht: Ich sehe #PREFIX als Aussage über Format/Syntax der (in der BEACON-Datei genutzten) Identifier an und analog #LINK (Art des Ziels) wäre hier auch ein (Semantic-Web-)Identifier nützlich, der die Art der Quelle (Personen, individualisierte Personen, Musikerinnen, ...) angibt. Mag sein, dass das sogar Deine Intention bei der Einführung des #LINK-Elements war (mein ergänzender Edit vorhin hätte das dann gründlich missverstanden), ich sehe jedenfalls Bedarf zu (mindestens) zwei getrennten semantischen Verzurrungen:
  1. Welcher Art ist die Gesamtheit der Identifier oder der durch sie identifizierten Entitäten, zu denen die BEACON-Datei Links anbietet
  2. Welcher Art ist die Gesamtheit der Ressourcen, auf die verlinkt wird
Und dann gibt es natürlich noch die Frage des Konkordanzformats (zu gvk.txt hat es z.B. schon Reklamationen gegeben, weil die GBV-PPNs für PND-ID's gehalten wurden), das sich ja auch stark in zusätzlichen META-Feldern niederschlagen würde. -- Thomas Berger 01:55, 8. Dez. 2011 (CET)Beantworten