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

[Kai Eckert]

Hi Jakob,

Am 07.12.2011 15:32, schrieb 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.

Ah, verstanden, ich dachte, das hättest du gerade wegen Alex eingeführt.

>> 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 seh schon, da kommen wir nicht zusammen. Dann diskutieren wir hier 
Detailverbesserungen für BEACON (keine Häme, ich finde das gut und es 
spricht nichts gegen ein einfaches Format für einen speziellen Zweck). 
Ich finde aber die Idee mit dem CSV-Header auch sehr bestechend, wie 
wäre es mit einem weiteren neuen Format? Wie sehen das andere hier auf 
der Liste?

> 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.

Das sollte auch nur als Beispiel dienen, wie das Format um weitere 
Aussagen ergänzt werden kann, wie wir das auf der SWIB besprochen haben.

>> 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.

Genau.

>> 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"?
>

Ich würde Einheitlichkeit empfehlen. Ich fand die Idee mit einem 
Template-Text und dem Einfüllen einer Spalte in einen Platzhalter schon 
ganz gut. Es hätte allerdings keine Entsprechung in RDF, was ich aber 
nicht schlimm finde, es ist eben ein Addon für eine HTML-Aufbereitung 
der Links. Wer es implementieren will, könnte die Message als 
Metainformation an das erzeugte Triple hängen, das wäre semantisch 
korrekt (über einen Graph Container, das kommt mit der nächsten 
RDF-Version).

>> 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.

Ok. Ein paar der Vorgaben gefallen mir nicht, vor allem die 
Fallunterscheidung nach Aussehen des letzten Feldes und das optional ein 
Feld zwischengeschoben wird, angehängt wäre in der Implementierung 
übersichtlicher. Aber das ist müßig zu diskutieren, wenn BEACON bereits 
produktiv im Einsatz ist und eine Änderung ohne Abwärtskompatibilität 
nicht gewünscht ist.

> 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.

Kann man dann nicht wenigstens das label-Feld fest vorgeben? Oder werden 
schon so viele source|target Dateien genutzt? Wenn man dann noch die 
Benutzererweiterungen (die ja anscheinend eh noch keiner nutzt), nach 
hinten schiebt, dann hat man eine stabile Struktur und weit weniger 
Fallunterscheidungen (die mit der URI würde ich auch noch abschaffen 
durch einen geeignten Header). Also deine obigen Beispiele wiederholt:

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

Hat auch den Vorteil, dass man im letzten Beispiel den angehängten 
Seperator nicht braucht. Der ist ja in den vorhandenen Dateien 
wahrscheinlich eh nicht drin, womit du die Abwärtskompatibilität auch 
schon aufgibst.

Erweiterungen:

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



> Schöne Grüße
> Jakob

Viele Grüße,

Kai

-- 
Kai Eckert
Universitätsbibliothek Mannheim
Stellv. Leiter Abteilung Digitale Bibliotheksdienste
Schloss Schneckhof West / 68131 Mannheim
Tel. 0621/181-2946 Fax 0621/181-2918