[dini-ag-kim-lld] Mappings jetzt im BEACON-Format

[Jakob Voss]

Hallo Kai,

> TARGETREFIX ist ungeschickt formuliert, was ist der Unterschied zu
> TARGET? Du meinst ja, dass bei Angabe des TARGETPREFIX in einer zweiten
> Spalte nach Target-IDs gesucht wird.

#TARGET und #TARGETPREFIX schließen sich gegenseitig aus. Im ersten Fall
wird die erste Spalte und im zweiten Fall die zweite Spalte als lokaler 
Identifier herangezogen. Über die Namen lässt sich lange streiten, ich 
würde dass auch anders nennen, wenn ich nochmal von vorne anfangen 
könnte, aber ist eben historisch so gewachsen.

> Der Ansatz gefällt mir, das ist eine Erweiterung, die sicher auch viele
> haben wollen. Muss man nur aufpassen, dass die Reihenfolge und Bedeutung
> der Felder wirklich klar bleibt. Was mich zu meinem Ansatz zurückbringt,
> ob man nicht doch ein allgemeines Header-Format definieren kann, das auf
> ein beliebiges CSV passt. Ich brainstorme mal:
>
> #FORMAT: BEACON
> #PREFIX|1: http://d-nb.info/gnd/
> #PREFIX|2: http://musicbrainz.org/artist/
> #LINK|1|2: http://www.w3.org/2002/07/owl#sameAs
> #DESCRIPTION|1|2: {4} Treffer auf MusicBrainz
> #LINK|2|3: rdfs:label
>
> 100140084|7c432bb8-2721-407d-a99f-d77d7a245958|Super Typ|23

"All problems in computer science can be solved by another level of 
indirection...except for the problem of too many layers of indirection"

Ich tendiere dazu, DESCRIPTION und LABEL aus der RDF-Interpretation ganz 
rauszunehmen und festzulegen, dass das Prädikat (LINK) für *alle* Tripel 
einer BEACON-Datei gleich ist.

> Beim DESCRIPTION Feld bin ich mir gerade nicht sicher, ob das das Feld
> war, wo auch die Anzahl der Treffer in deinen Beispielen ausgegeben
> wurde.

DESCRIPTION, INSTITUTION, und CONTACT sind Freitextfelder die nur für 
Menschen gedacht sind, die wissen wollen, was das für eine BEACON-Datei 
ist. Ich glaube du meinst das Feld MESSAGE.

> Auf jeden Fall könnte man so den Text klar einem Link zuweisen
> durch die Indizierung im Feldnamen, die Platzhalter im text selbst wie
> {5} beziehen sich auf beliebige andere Spalten des CSV.

In wieweit die "Anzahl der Treffer" als Möglichkeit in BEACON explizit 
definiert werden soll, bin ich unschlüssig. Sollte ein semantischer 
Unterschied gemacht werden zwischen

abc|12
def|2

d.h. 12 Treffer zu "abc" und 2 zu "def". Und

abc|hallo
def|welt

d.h. Label oder Kommentar "hallo" zu "abc" und "welt" zu "def"?

> Die Möglichkeit, im jetzigen Format mehrere Datenfelder zu nutzen (oder
> geht das gar nicht?) kollidiert aber dann auf jeden Fall mit
> erweiterungen wie der jetzigen, wo das Target in der zweiten Spalte
> stehen soll.

Die aktuelle Heuristik ist:

0. Wenn das TARGET-Feld kein '{ID}' enthält, hänge '{ID}' an.

1. Alle Felder werden getrimmt (Whitespace vorne und hinten weg)

2. Wenn das erste Feld leer ist, wird die Zeile ignoriert:

|Diese zeile wird ignoriert

3. Das Subject ergibt sich aus PREFIX + erstem Feld

4. Das Predicate ist immer dder LINK Header, oder standard rdfs:seeAlso

5. Wenn es mehr als ein Feld gibt und das *letzte* Feld wie eine URI 
aussieht (/[a-zA-Z][a-zA-Z+.-]*:.+/), nimm das letzte Feld so wie es ist 
als target:

123|Bla|fasel|http://example.org/about123.html
123|http://example.org/about123.html

In der Praxis gibt es allerdings höchstens ein weiteres Feld, z.B.

11864372X|Adam, A.|http://icking-music-archive.org/ByComposer/Adam.php

4. Wenn TARGET gesetzt ist, ersetzte {ID} durch das erste Feld, um 
daraus das target zu machen.

5. Wenn TARGETPREFIX gesetzt ist, ergibt sich das target aus 
TARGETPREFIX + dem zweiten Feld. Ist das zweite Feld leer, ignoriere die 
Zeile.

> Oder in der dritten? Oder in der letzten? Da muss man ggf.
> genauer werden. Wenn bisher aber eh nur der Wikipedia-Fall wirklich
> genutzt wird, kann man das ja auf dem Stand einfrieren und für alles,
> was darüber geht, auf das generische Format verweisen.

Zusätzliche Felder werden eigentlich ggf. nur für die HTML-Anzeige benötigt

<a href="..." title="HIER">UND HIER</a>

Ich habe mal eine Statistik über alle mir bekannten BEACON-Dateien [1] 
gemacht:

      76 #INSTITUTION:
      71 #CONTACT:
      70 #TARGET:
      61 #FEED:
      57 #VERSION:
      57 #DESCRIPTION:
      55 #TIMESTAMP:
      50 #PREFIX:
      49 #MESSAGE:
      47 #FORMAT:
      43 #REVISIT:
      37 #NAME:
      35 #EXAMPLES:
      29 #REMARK:
      29 #FORMAT:
      17 #DATE:
       6 #TARGETPREFIX:
       6 #LINK:
       5 #UPDATE:
       5 #ISIL:
       3 #COUNT:
       2 #SOMEMESSAGE:
       1 #X-REVISION:
       1 #DECRIPTION:

INSTITUTION, CONTACT und DESCRIPTION
sind Freitext-Beschreibungen

REMARK wird anscheinend für Bearbeitungskommentare verwendet, die nicht 
im gegensatz zu DESCRIPTIOn nicht öffentlich angezeigt werden sollen

TARGET, PREFIX, TARGETPREFIX und LINK
sorgen für URI-Expansion der Tripel

VERSION und FORMAT sind eigentlich irrelevant

FEED, REVISIT und UPDATE beschreiben die Bereitstellung der Datei.
X-REVISION ist anscheinend ein selber definiertes Feld.

NAME dient als Titel für die gesamte Datensammlung auf die Verlinkt wird

DATE ist veraltet für TIMESTAMP, sollte abgeschafft werden.
TIMESTAMP beschreibt die Aktualität der Daten (wichtig!).

EXAMPLES und COUNT sind nicht so verbreitet, aber ggf. praktisch zur 
Überprüfung der Daten. Sie können bei Bedarf auch automatisch aus einer 
Datei abgeleitet werden.

ISIL sollte besser wieder abgeschafft werden

Es bleiben die Felder NAME, MESSAGE, SOMEMESSAGE, aus denen irgendwie 
das Link-Label erzeugt wird

<a href="...">{label}</a>

Die bislang verwendete Heuristik dafür kann ich genauer erklären, 
allerdings macht eher jeder Client was er möchte.

Ich denke wir sollten BEACON eher verschlanken als komplizierter machen 
und deshalb höchstens ein weiteres Feld definieren. Somit gibt es drei:

source
source|target
source|label|target
source|label|

und die Möglichkeit benutzerdefinierter Erweiterungen vor dem 'target' Feld:

source|label|irgendwas|target
source||ganz|viel|dings|target

Es muss nur noch definiert werden, ob und wie das "label" Feld auch in 
RDF ausgedrückt werden soll und über welche header (bislang MESSAGE und 
ONEMESSAGE) sich das "label" Feld automatisch expandieren lässt.

Schöne Grüße
Jakob

[1] 
https://docs.google.com/spreadsheet/ccc?key=0Aro_DAmC_PbndHRqY1NVNHlROUx1YXowQnlyMnB4M3c

-- 
Jakob Voß <jakob.voss at gbv.de>, skype: nichtich
Verbundzentrale des GBV (VZG) / Common Library Network
Platz der Goettinger Sieben 1, 37073 Göttingen, Germany
+49 (0)551 39-10242, http://www.gbv.de