Re: [GOOLAP] Basisextraktoren Typsystem

[Oleg Mayevskiy]

TODO/Unklarheiten

• info.goolap.date.* unterordnen nach info.goolap.extraction.date

einverstanden

• Wozu ist QualifiedDate? Das wird scheinbar garnicht benutzt!?

ja wird es nicht, kann entfernt werden

• Wozu die Unterscheidung POSDate/QualifiedDate/RegexDate? - Wäre es nicht sinnvoller nur einen Date Type zu haben, der einfach von verschiedenen Annotatoren annotiert wird?

es wird nur regexDate verwendet, die anderen beiden können weg

Vorschlag für Neusortierung des Typsystems

• info.goolap.extraction.address.Email (value)
• info.goolap.extraction.address.PhoneNumber (value)
• info.goolap.extraction.address.URL (value)
• info.goolap.extraction.date.Date (normalizedDate)
• info.goolap.extraction.metrik.MetrikGeneric (value, name)
• info.goolap.extraction.metrik.MetrikUnit (dimension, value, unit, normalizedValue, normalizedUnit)
• info.goolap.extraction.metrik.Currency (amount, name)

Die Klassen sind erstmal ok.

Was allerdings wichtig und angezeigt wird, sind nicht die Klassen, sondern die Annotationen die im Aggregate sprich UIMA festgelegt werden. Falls nicht ganz klar ist, was gemeint ist, bitte nachfragen. Es ist wichtig das UIMA Framework zu verstehen.
Es soll möglich sein, alle Metriken "abzufragen". Deswegen müsste es eine Annotation Metrik geben, die alle möglichen Metriken beinhaltet.

Ein Vorschlag meinerseits:
Annotation Metrik mit features

type (Email,MSISDN,URL,Date..)
name(kg,cm,$,€...)
value(100;10;10,99;10.99;..)
dimension?
normalizedValue?
normalizedUnit?
...
..
.

Mir ist bewusst wie die Objektorientierte Ableitungshierarchie zu den Metriken aussieht, ich habe die flache Variante der Darstellung ausgewählt. Vergleiche Single Table Inheritance Strategy

Grüße

Oleg


Am 02.12.2010 18:13, schrieb Stefan Schramm:

Hallo,

Alexander schrieb ja, ich soll ein Aggregate anlegen für Metriken,
generische Metriken, Datum und Währungen.
Ich denke es wäre sinnvoll dafür zunächst nochmal die Types etwas
aufzuräumen (die sollen dann ja auch im GUI dargestellt werden).

Hier ist ein erster Vorschlag, wie ich es umsortieren würde (unterer
Punkt auf der Wikiseite):
https://bird.cs.tu-berlin.de:4430/wiki/index.php/Basis_Extraktoren/Type_System

Oleg, vielleicht kannst du auch mal draufgucken, ob das in dieser Form
sinnvoll wäre. Insbesondere, ob es OK ist nur einen Date-Typen zu benutzen.

Und ob Currency bei Metrik drin bleiben soll, oder ein eigenes Modul
bekommen sollte frag ich mich noch. ... und ob es überhaupt statt
"Metrik" einen passenderen englischsprachigen Begriff gibt.


Grüße
Stefan

[Alexander Löser]

Fein. Geht in die richtige Richtung.  Bitte den Ratschlag von Oleg unbedingt beherzigen: Es muss eine Klasse „KONSOLIDIERER“ geben, die den Input von allen anderen Klassen (via SPANS, CAS etc.) konsolidiert und letztendlich entscheidet, was der Text bedeutet. Diese Klasse kann am Anfang noch Fehler machen, die sollten dann später raus …

 

Danke Oleg, Danke Stefan

Alexander

[Oleg Mayevskiy]

Am 03.12.2010 21:30, schrieb Stefan Schramm:
> Hi Oleg,
>
> On 12/03/2010 03:54 PM, Oleg Mayevskiy wrote:
>>> Vorschlag f�r Neusortierung des Typsystems
>> [...]

>> Die Klassen sind erstmal ok.
>> Was allerdings wichtig und angezeigt wird, sind nicht die Klassen,
>> sondern die Annotationen die im Aggregate sprich UIMA festgelegt werden.

> ich meinte mit dem Typsystem schon die Annotationen (also die Types)
> selbst. Die werden in den TypeSystem-Deskriptoren definiert und dann von
> den Annotator-Deskriptoren eingebunden. Ein Aggregate �bernimmt
> automatisch die Typen aus den in ihm enthaltenen Annotatoren.
> Mittels JCasGen werden aus diesen Typsystem-Deskriptordateien ja Klassen
> f�r alle Typen generiert (entsprechend der Namen, die in den
> Deskriptordateien angegeben sind).
>
>> Es soll m�glich sein, alle Metriken "abzufragen". Deswegen m�sste es
>> eine Annotation Metrik geben, die alle m�glichen Metriken beinhaltet.
> Ich muss sagen, dass mir nicht ganz klar ist, f�r was der Begriff
> "Metrik" jetzt tats�chlich steht. Ich w�rde z. B. E-Mailadressen, URLs
> und Telefonnummern nach meinem Verst�ndnis eigentlich nicht dazu z�hlen
> - oder einen anderen Begriff w�hlen, der das �bergeordnet zusammenfasst.
>
Metrik ist alles was messbar ist. Siehe
http://en.wikipedia.org/wiki/Units_of_measurement
Ich muss dir recht geben, Email , MSISDN, URL , Date, geh�ren alle nicht
dazu.
Gute Kandidaten sind eher: L�nge, Gr��e, Gewicht, Anzahl von etc. z.B.:
10 kg, 10,99 �, $1.000.000, 100.000 people, 10 apples etc.

>> Ein Vorschlag meinerseits:
>> Annotation Metrik mit features
>>
>> type (Email,MSISDN,URL,Date..)

>> name(kg,cm,$,EUR...)

>> value(100;10;10,99;10.99;..)
>> dimension?

> Dimension ist z. B. Mass, Volume, Length, Area, Temperature etc.
> (Dimension Attribut aus
> http://www.freebase.com/view/freebase/unit_profile )
>
>> normalizedValue?
>> normalizedUnit?
> Z. B., wenn Meilen in Meter umgerechnet werden.
> Sofern Normalisierung m�glich ist normalizedUnit "m" bei L�ngenangaben,
> "s" bei Zeitangaben und "m�" bei Volumenangaben.
> (Das sind die drei Dimensionen, wo Freebase Umrechnungsfaktoren in diese
> SI-Basiseinheiten bereitstellt - was also vom Annotator gleich
> umgerechnet wird.)
>
Die Fragezeichen waren als Andeutung gedacht, dass diese Features auch
hier rein kommen k�nnen.

>> Mir ist bewusst wie die Objektorientierte Ableitungshierarchie zu den
>> Metriken aussieht, ich habe die flache Variante der Darstellung

>> ausgew�hlt. Vergleiche Single Table Inheritance Strategy
>> <http://www.martinfowler.com/eaaCatalog/singleTableInheritance.html>
> Meinst du damit, es sollte real nur eine einzige Annotation (einen
> UIMA-Typ) geben mit diesen Features (also single table
> inheritance-m��ig),
Ja.
> oder dass es doch mehrere Typen geben sollte, die
> als Supertype (das ist ja in UIMA auch m�glich) Metrik haben sollen? Mir
> scheint es mit echter Vererbung so aus UIMA-Perspektive eigentlich
> sauberer,
Kannst du ein Beispiel zeigen, der die Vererbungshierarchie der
UIMA-Typen veranschaulicht?
Wie sieht danach ein java code Snippet aus, der alle Typen des
Supertypes Metric liefert?
> oder ist es besser es direkt flach zu machen, damit es sich
> danach besser in eine Datenbank speichern l�sst (ich hab �berhaupt keine
> Ahnung, wie das GoOLAP-Datenbankschema aussieht und die Speicherung
> funktioniert).
Das Ganze ist nicht Datenbankstrukturen verbunden.
>
> Gr��e
> Stefan
>
Danke und Gr��e

Oleg.

[Oleg Mayevskiy]

Danke Stefan.

Etwas dazu gelernt.

Gr��e

Oleg.

Am 05.12.2010 11:04, schrieb Stefan Schramm:
> Hi,

>
> On 12/03/2010 09:53 PM, Oleg Mayevskiy wrote:
>> Kannst du ein Beispiel zeigen, der die Vererbungshierarchie der
>> UIMA-Typen veranschaulicht?
>> Wie sieht danach ein java code Snippet aus, der alle Typen des
>> Supertypes Metric liefert?

> Das geht im Prinzip genau so, wie bei flachen Typstrukturen. Das
> Beispiel hier benutzt noch die alte Hierarchie, die ich dann aber
> entsprechend �ndern w�rde. Im Attachment ist ein Screenshot, wie es im
> CVD aussieht.
>
> // (Metrik ist supertype fuer MetrikNormalized)
> System.out.println("--- alle Metriken: ---");
> FSIterator metrikIterator = indexRepository.getAllIndexedFS(Metrik.type);
> while (metrikIterator.hasNext()) {
> Metrik m = (Metrik) metrikIterator.next();
> System.out.println(m.getValue());
> }
> System.out.println("--- nur normalisierte Metriken: ---");
> FSIterator metrikNormalizedIterator =
> indexRepository.getAllIndexedFS(MetrikNormalized.type);
> while (metrikNormalizedIterator.hasNext()) {
> MetrikNormalized m = (MetrikNormalized) metrikNormalizedIterator.next();
> System.out.println(m.getValue());
> }
>
> Erzeugt beim Beispiel im Screenshot folgende Ausgabe:
>
> --- alle Metriken: ---
> 1,063
> 52
> --- nur normalisierte Metriken: ---
> 1,063
>
>
> Gr��e
> Stefan
>