[dini-ag-kim-lld] Re: Endgültige BEACON-Spezifikation als RFC

Jakob Voss Jakob.Voss at gbv.de
Mon Jun 4 14:34:08 CEST 2012


Alexander Haffner schrieb:

> Hab allerdings eine Frage/Anmerkung zu der XML-Serialisierung.  Mir
erscheint es etwas inkonsistent die Source-ID als Text zu hinterlegen
und die Target-ID als Attribut. Klar kann die ID gleichzeitig Source und
Target sein, aber das wird wahrscheinlich in den seltensten Fällen der
Fall sein. Vielleicht wäre es schöner alle Attribute sowie den Text vom
link-Element als Sub-Elements umzusetzen.

Du hast recht, es ist besser das einheitlich zu machen, ich habe jetzt
auch die id als XML Attribut modelliert und die Spezifikation der
XML-Serialisierung erweitert: http://purl.org/net/beacon. XML-Attribute
haben im Gegensatz zu Unter-Elementen vor Allem den Vorteil, dass sie
nicht wiederholbar sind und keine Unterelemente haben können. Bei
Elementen müsste erst durch ein zusätzliches Schema sichergestellt
werden, dass sie pro link-Element nur einmal vorkommen und keine
Unterelemente enthalten. Das Auswerten mittels SAX-Parser ist so auch
einfacher, da pro Link-Element nur ein startElement-Ereignis ausgewertet
werden muss.

> Im Netz gibt es ja einige BEACON-Dateien, wo zu jedem Link ein
Timestamp zu existiert (z.B. Wikipedia). Ist das nicht mehr vorgesehen?

Da stehe ich auf dem Schlauch. In welcher BEACON-Datei steht wo bei
jedem Link ein Timestamp?

> Zum offenen Punkt der Institutionsangabe: vielleicht empfiehlt es sich
dort sogar mit vCard zu arbeiten.

Die Metadaten *über* die BEACON-Datei sollten eher einfach und kurz
gehalten werden. Ich denke über ein Meta-Feld wie "ABOUT" nach, mit dem
auf eine URL verwiesen wird, wo genauere Angaben stehen, würde das nicht
reichen?

Gruß
Jakob


-- 
Verbundzentrale des GBV (VZG)
Digitale Bibliothek - Jakob Voß
Platz der Goettinger Sieben 1
37073 Goettingen - Germany
+49 (0)551 39-10242
http://www.gbv.de
jakob.voss at gbv.de


More information about the dini-ag-kim-lld mailing list