Thursday, April 28, 2016

Nachtrag zu den ersten Gruppentreffen & Raumplanung

Liebe Studis,

vielen Dank für die produktiven ersten Gruppentreffen. Für einige Gruppen gibt es hier noch ein paar Materialien und Infos, weil uns an mancher Steller leider die Zeit ausging.

Außerdem könnt ihr jetzt hier auch die Raumplanung für das restliche Semester einsehen. Wenn ihr nicht mehr wisst, in welcher Gruppe ihr seid, seht hier nach.

Gruppe Raum & Zeit
1 Word2Vec 13.00 - 13.30 H-2.58
2 COAL metadata 13.00 - 13.30 H-E.52
3 DBpedia Events 14.30 - 15.00 H-E.52
4 AV-Portal 14.30 - 15.00 H-2.58
5 COAL metadata 13.30 - 14.00 H-E.52
6 Word2Vec 13.30 - 14.00 H-2.58
7 COAL client 14.00 - 14.30 H-2.58


Gruppe 2+5: COAL metadata

  • Ladet euch das Programm aus dem github und probiert es aus
  • Sammelt Tools, die man als worker integrieren kann

Gruppe 7: COAL client

  • Findet einen Crawler und erweitert ihn für ein content negotiation basiertes crawling von rdf
  • Speichert das rdf sinnvoll ab (zBsp. im Triple Store)
  • Arbeitet mit dem yovisto Blog als erstes Beispiel und crawlt zBsp. die Bilder als rdf

Gruppe 4: AV-Portal

  • Schickt uns bitte eure Präsentation vom 28.04. 
  • Hier ist noch einmal meine kurze Präsentation von heute mit euren Aufgaben bis zum 12. Mai
  • Bitte schickt uns auch eure Email Adressen, damit ich euch die GND-DBpedia Mappings geben kann 
Gruppe 1+6: Word2Vec  
  • Präsentation zu NEL
  • das Paper dazu
  • Unsere geschilderte erste Idee als Beispiel:
    • Die ca. 97GB liegen auf einer unserer Maschinen. 
    • Jede Gruppe kann sich bei mir (Jörg, H-1.37) ein Login abholen.
      • Darin sind enthalten:
        • enwiki-latest-pages-articles.xml: original Wikipedia Article Dataset (XML + Wikisyntax)
        • data.sentences: transformiert in 'sentences' Dataset (ein Artikel pro Zeile, Sonderzeichen ersetzt, DBpedia URIs aus Wikilinks erzeugt, etc.)
        • PreprocessWiki2.java: das Tool zum Transformieren
        • train.py: der Code zum Trainieren mit Gensim (hat ca. 9 Stunden gedauert)
        • data.model*: die Modelldaten
  • Test- / Evaluationsdaten:
      • Ein Eingabetext ist daran zu erkennen, dass er als "nif:Context" typisiert ist (vgl. z.B. Zeile 18 und 19).
      • Der eigentliche Text ist über das Property "nif:isString" verknüpft (vgl. z.B. Zeile 22)
      • Für jeden "nif:Context"gibt es Annotationen, die typisiert sind als "nif:Phrase" (z.B. Zeilen 25 und 26). 
      • Eine Annotation bezieht sich immer auf einen "nif:Context", am Property "nif:referenceContext" zu erkennen (z.B. Zeile 30). 
      • Jede Annotation enthält folgende Informationen:
        • "nif:anchorOf" das Textfragment im Ausgangstext ("nif:Context"), auch "Surface Form" genannt.
        • "nif:beginIndex" den entsprechende Index des Anfangs der Annotation
        • "nif:endIndex" ebd.
        • "nif:referenceContext" wie gesagt, der Verweise auf den Ausgangstext
        • "itsrdf:taIdentRef" die DBpedia Entität, die der Annotation an der entsprechenden Stelle zugeordnet wurde (Dies ist die korrekte Entität, die manuell zugeordnet wurde. Ihr sollt mit Eurem Verfahren diese Entität sozusagen 'voraussagen'. )
        • ".../candidate>" Diese Elemente haben wir für Euch hinzugefügt. Es sind all die DBpedia Entitäten, die wir durch ein Mapping der "Surface Form" mit unserem "DBpedia Dictionary" als potentielle Kandidaten identifiziert haben. Der korrekte Kandidat ist dort immer enthalten.
    • Also nochmal FAZIT:
      • Für jede Annotation ("nif:Phrase") zu einem Ausgangstext ("nif:Context"), sollt ihr mit Eurem Verfahren aus der Kandidatenliste den korrekten Kandidaten ("itsrdf:taIdentRef") auswählen.
      • Dabei sollt ihr ein Word2Vec Verfahren verwenden. Welche Daten oder Parameter ihr dabei zum trainieren, optimieren, etc. verwendet ist Euch vollkommen freigestellt. (Es macht natürlich irgendwie Sinn, mit Wikipedia o. Ä. anzufangen.)
  • Aufgaben bis in 2 Wochen:
    • Schickt uns bitte eure Präsentation vom 28.04. 
    • generell Ansätze überlegen, oder den von oben verfeinern/verbessern
    • Möglichkeit des parallelisierten Trainings ermitteln
    • beginnen, erste Ansätze zu implementieren
    • Probleme + Lösungen die auftreten Dokumentieren


3 comments:

  1. Für die Client Gruppe: Welche Art von Oberfläche wird für den Client gewünscht?

    ReplyDelete
    Replies
    1. Eine Web-App wäre sinnvoll. Ihr seid freigestellt, welches Framework Ihr dafür verwendet. Wir haben Erfahrungen mit Apache Wicket & Play Framework, aber Ihr könnt auch gern was andere nehmen, oder auf die Möglichkeiten von Apache Solr aufsetzen.

      Delete
    2. Danke, wir schauen uns gerade node.js basierte wie sails.js und ähnliche an

      Delete