Wikipedia Diskussion:BEACON/Format
Letzter Kommentar: vor 12 Jahren von Gymel in Abschnitt Themensammlung Meta-Klärung
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)
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)
- #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:
- Welcher Art ist die Gesamtheit der Identifier oder der durch sie identifizierten Entitäten, zu denen die BEACON-Datei Links anbietet
- 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)