MagicMap Knotenmodell
aus Nomads, der freien Wissensdatenbank
Diese Seite beschreibt grundlegende Datenstrukturen und Konzepte im Funkortungssystem MagicMap. Ausgangspunkt ist ein abstraktes Modell mit Knoten und Kanten. Die Knoten repräsentieren Objekte, entweder physikalische oder informatorische, die Kanten und ihre Längen repräsentieren Objektzusammenhänge, dies können räumlich aber auch inhaltliche Distanzen sein. Dazu beschreibt diese Seite die konzeptionelle Zielsetzung und stellt dar, in wie weit die aktuelle Implementation in MagicMap diese Ziele umsetzt.
Wenn Sie die hier vorgestellten Konzepte mit uns diskutieren möchten, willkommen, die Diskussion hierzu findet in diesem Thread im MagicMap-Forum statt.
Objekte und ihre Positionen
Alle Objekte haben immer mindesten eine Positionsangabe, d.h. eine 3-dimensonale relative XYZ-Koordninate zu einem anderen Objekt (normalerweise eine Karte). Root-Objekt ist die Erde, XYZ-Angaben hierzu werden nach WGS84 Standard interpretiert. Dazu hat jede Positionsangabe eine Genauigkeitsangabe sowie optional eine 3-dimensionale relative Orientierung und Geschwindigkeit.
Warum reichen nicht einfach globale Positiosangaben?
Der Grund für diese relativen Positionsangaben ist, dass eine globale Position (z.B. nach WGS84) allein nicht ausreicht, da diese nicht immer (in ausreichender Genauigkeit) verfügbar ist. Eine GPS-Ortung ist zu ungenau und auch per Maus-Click in Google Earth ist die absolute Position nicht ausreichend genau. Eine bessere Genauigkeit zu ermitteln, ist zwar grundsätzlich möglich, aber aufwändig, und daher in den vielen Fällen nicht als realistisch anzunehmen. Man könnte dies durch GUI unterstützen, z.B. indem man aufgefordert wird, inkonsistente Objektpositionierungen durch eine Feinjustierung genau übereinander bzw. nebeneinander zu legen. Karten die irgendwie verzerrt sind, können dann aber nicht zugelassen werden. Das würde man oft erst später merken, wenn man eine bessere Karte darüberlegt. U.u. muss man alte Daten dann verwerfen oder erheblichen Aufwand treiben, um die Daten akkurat ins System zu migrieren. Fehler einer Karte (z.B. fehlpositionierte APs) wirken sich über Relationen auf benachbarte Karten aus. Es kann auch mobile "Karten" geben (z.B. ein Schiffsdeck). Wenn man allen Objekten absolute Positionen vergibt, müsste man die bei jeder Kartenbewegung aktualisisieren.
Diskussion
--Jan 19:15, 2. Jul 2006 (CEST) Ich schlage vor, daß alle Objekte eine default Position bekommen. Diese ist die physikalische Position auf die alle anderen im Netzwerk auch zugriff haben. Zusätzlich kann man beliebig viele andere Position berechnen.
--pi 14:14, 4. Jul 2006 (CEST): Hm. Bei physikalischen Objekten könnte nur genau eine Position reichen, wenn man Inkonsitenzen wie oben beschrieben auflöst und mit etwas weniger Genauigkeit zufrieden ist. Allerdings muss es wegen "mobiler Karten" (Schiffe, LKWs,...) auch relative Positionen geben können. Bei Info-Objekten ist das etwas anders. Deren Position ist stark abhängig von der jeweiligen Perspektive. Was davon "default" ist, lässt sich schlecht sagen. Ist auch egal, man bucht einfach die Berechnung für jeden Knoten von einem bestimmten, frei definierbaren anderen Knoten. Der muss seine Berechnung durch das Flag "public" freigeben. So ist das ein einheitliches Konzept, das physikalische Objekte genauso behandelt wie Info-Objekte.
Physikalische und Informatorische Objekte
Es gibt "physikalische" Objekte, die befinden sich an genau einer Position.
Informatorische Objekte, kurz Info-Objekte, haben keine physikalische Position, sondern eine logische. Ihre direkten und indirekten Bezüge zu physikalischen Objekten geben ihnen einen Ortsbezug.
Um die Position eines Objekte angeben zu können, bedarf es eines Referenzobjektes (normalerweise eine Karte), zu dem mindesten ein Verknüpfungspfad besteht. Über diesen Pfad addiert sich die Positionsungenauigkeit, existieren mehrere Pfade, ergibt sich eine Überlagerung, die die Genauigkeit verbessert.
Physikalische Objekte können in unterschiedlichen Kontexten geortet werden, besitzen unter Umständen also mehrere Positionsschätzungen. Haben Objekte mehrere solcher Positionsangaben, werden diese nicht identisch sein, sondern mehr oder weniger stark voneinander abweichen. Liegt die Abweichung über einem Schwellwert, betrachten wir sie als "inkonsistent" - eine Fehlermeldung wird generiert. Bei "konsistenten" Positionsschätzungen kann man diese zur Mittelwertbildung heranziehen, oder aber auch, um die Position des dahinterliegenden Referenzobjektes (die Karte) zu verbessern. So kann eine Karte aus Referenzmessungen mit WLAN und GPS Informationen schließlich recht genau positioniert werden.
Die Positionsangaben sind entweder "extern" (kommen von extern) oder sind "intern" (von unserem System berechnet). Ortsbezogene Objekte sind bezüglich ihres Referenzobjektes (normalerweise der angezeigten Karte) entweder "stationär" (bewegen sich nie) oder sie sind "mobil". Physikalische Objekte können sich physikalisch bewegen, Info-Objekte bewegen sich inhaltlich. In beiden Fällen bedeutet es, dass sich die Distanzen zu Ihren Bezugsobjekten verändern.
Auch wenn sich Objekte selbst nicht verändern bzw. bewegen - also bei stationären Objekten - kann durch Kantendynamik ihre Positionsschätzung variabel sein - beispielsweise aufgrund neuer Messwerte und Berechnungen oder aufgrund von Neubewertungen von inhaltlichen Distanzen, etwa durch bahnbrechende Nachrichten. Positionsschätzungen, die sich nicht verändern, heißen "fixe Positionen". Eine Möglichkeit, Objektpositionen zu fixieren, ist es, sie zu einem bestimmten Zeitstempel einzufrieren. Solche heißen "historische Positionen". Fixe Positionen werden natürlich nicht mehr berechnet - sie verändern sich ja nicht.
Absolute, stationäre und fixe Objekte
Ist ein Objekt zum Root-Objekt (der Erde) verknüpft, ist die sich ergebende Position (nach WGS84) "absolut". Bewegt sich das Objekt darüberhinaus nicht zur Erde, ist seine Position "absolut stationär" und "absolut fix", wenn es darüberhinaus auch unabhängig von Einflüssen (Messungen) ist. Kartenpositionen sind typischerweise alle absolut fix, dies ist aber nicht zwingend. Beispiel für eine Ausnahme ist z.B. ein Schiffsdeck, auf dem man sich orten möchte, und das Schiff sich dabei bewegt.
Zwischen stationär und mobil kann in vielen Fällen der präzise Unterschied verschwinden, je nach Beobachtungszeitraum im verhältnis zur Dynamik. Hier gibt es interessante Fragestellungen, wie man Dynamik verteilter Objekt-in den Griff bekommen kann. Ein Stichwort ist Client- versus Mediator-zentrierte Aggregation von Objekten.
Flächige Objekte
Weiter sind ortsbezogene Objekte entweder 1-, 2-, oder 3-dimensional, also "punktuell", "flächig" oder "volumig". Flächige Objekte haben ein "Shape", z.B. einen Polygonzug und eine "Textur", z.B. ein jpg-Bild. Karten sind spezielle flächige Objekte. Sie können rechteckig sein, allgemein aber beliebige Polygonzüge haben.
Sie könne einen Bezugspunkt haben, das ist normalerweise der Schwerpunkt. Hier kann, identisch zu den punktuellen Objekten, ein Icon angezeigt werden, auf dem u.a. Kontext-Menü-Funktionen ausgelöst werden.
Andere Objekte mit Bezug zu dem Flächenobjekt haben ihre Kanten zu diesem Bezugspunkt. Dem Flächenobjekt zugeordnete "regionale Dienste" (siehe Dienste unten) werden per Doppelkclick auf den Bezugspunkt angzeigt (dies ist die Standardoperation bei Child-Objekten). Rechtsklick irgendwo innerhalb des Objekt-Shapes, zieht die Child-Objekte an die Stelle an.
Verzerrungen
Angenommen die HU kooperiert mit der New York Uni. Nun kann man alle Gebäudepläne und Mitarbeiter einblenden. In der Weltkarte mit Europa und Amerika sind diese Karten wenn man sie in der richtigen Skalierung anzeigen würde leider verschwindend klein also bringt das nichts. Setzt man in New York bzw. Berlin aber lediglich Positionsmarker und macht die Karten ansonsten "Spring Layoutbar" und unabhängig skalierbar könnten die sich anziehen und könnten dann nah beieinander und in passender Größe erscheinen. Dann kriegt man ggf. schönen Überblick wie sich Kompetenzcluster über beide Institute erstrecken. Mann müsste hierzu im Knotenmodell nur flächigen Objekte (Karten) definieren mit einer Kante zu ihrer Position. Dazu die Karten unabhängig zoombar. Die physikalischen Objekte in jeder Karte würden sich dabei nicht von äußeren Objekten beeinflussen lassen, deren Positionen sind sowieso relativ zu der Karte. Die Karten sollten sich aber etwas anziehen (die sind dann keine Realabjekte mehr mit Position sondern Infoobjekte mit einem Link zu einer Position. Genauso mit den Mitarbeitern. Die sind Infoobjekte und nur zu einem Objekt ihrer Position über eine Kante verlinkt. Wenn man möchte (Click auf "entwurzeln"), können die Personen dann z.B. in Richtung ihrer Kompetenzbereiche angezogen werden und würden sich dort clustern. Damit bleibt das einheitich innerhalb des Gesamtkonteptes und Implementation sollt nicht soo aufwändig sein.
Sowas bräuchte man auch z.B. für internationale Logistikunternehmen, die einen weltweiten überblick über Beladezustände ihrer Schiffe/LKW sowie Lagerhäuser behalten wollen. Dann zeigt man die Weltkarte mit den Schiffchen/LKWs/Lagerhäusern, auf Klick öffnen sich gewünschte Zoom-Ansichten der Lagerhäuser/Schiffdecks/LKWs mit den Stückgutpositionen, ohne die Weltkarte zu verlassen. Ein anderer Click zeigt z.B. die Verladezustände aller Teile für den "Airbus A380, Seriennummer 013". Das könnte die bisherige Navigationsansicht überflüssig machen oder zumindest sehr hübsch ergänzen. Finde das sehr reizvoll. Für übereinanderliegende Etagen müssen wir uns aber noch was einfallen lassen...
Objekt-Hierarchie
Alle Objekte sind durch einen "Parent Link" hierarchisch strukturiert. Normalerweise weist der Parent Link auf ein Flächenobjekt (eine Karte), aber prinzipiell kann es auch auf punktuelle oder volumige Objekt verweisen. Überschneidungen sind damit nicht erlaubt, jedes Objekt hat genau einen Parent Link, ist also beispielsweise eindeutig in Frankreich oder in Deutschland - bzw. entweder auf Palette A oder aber auf Palette B. Objekte können außer Karten auch anderen Objekten untergeordnet sein. Typsch sind z.B. Transportmittel und Verpackungen (Schiff, LKW, Palette, Karton), Geräte (Handy, Laptop, Roboter) oder Benutzer (Peter, Jan, Sebastian). Auch hier gilt die eindeutige Zuordnung, also entweder in Karton A oder aber in B, aber nicht beides (wobei B durchaus in A liegen kann). Bei mobilen Objekten ist also ein atomarer Übergang zu definieren.
Durch die Parent-Links lassen sich Objeke unterschiedlicher Größenordnung strukturieren.
- Grundstruktur: Welt, Kontinent, Land, Bundesland, Stadt, Stadtteil, Block, Gebäude, Haus, Stockwerk
- Beispiel: JvN-Gebäude hat 4 Häuser à 4 Stockwerke. Jedes Stockwerk entspricht einer Karte.
- In den Karten wiederum befinden sich Verpackungseinheiten, User und Geräte
Sensor-Objekte und Interface-Objekte
Sensor-Objekte sind in MagicMap spezielle Objekte, die von ihrer Umgebung bestimmte Messwerte wahrnehmen können. Speziell interessieren Messwerte, aus denen Rückschlüsse auf die Aufenthaltswahrscheinlichkeit möglich sind. Dazu unterscheiden wir Kommunikationssensoren als Interface-Objekt. Interface-Objekte gibt es die Typen "TDOA", "Sinalstärkebasiert" und "Direkt".
- TDOA-Interfaces enthalten die Info Distanzschätzung mit Erwartungswert und Varianz. Daraus kann der Ortungsalgorithmus eine Positionsschätzung ermittel bzw. eine ermittelte Positionsannahme innerhalb des zur Anwendung kommenden Suchverfahres bewerten.
- Für die Typen "Signalstärkebasiert" muss die Normalisierung dies erst in Distanzschätzungen umrechnen.
- Direkte geortet werden z.B. GPS-Sensoren. Diese Positionsschätzung wird als normalverteilt angenommen und kann im Suchverfahren des Ortungsalgorithmus zur bewertung direkt benutzt werden. Einige Parameter, etwa die Zahl der empfangbaren Satelliten, gibt Aufschluss über die Varianz.
In Zukunft können weitere Sensortypen, etwa optische Sensoren oder Beschleunigungssensoren integriert werden.
In MagicMap kann jedes Gerät mehrere Interfaces haben. Also z.B. neben Bluetooth auch WLAN und GSM. GGf. können auch mehrer Interfaces gleichen Typs existieren, also z.B. 2x WLAN. Interfaces können hierarchisch (d.h. über den Parent-Link) mit dem Geräte-Objekt, z.B. "Jan's Handy", verknüpft werden, in dem sie sich befinden.
Jedes Interface kann eine Relative Position zu dem Gerät besitzen, in dem es sich befindet. Normalerweise ist diese (0,0,0), etwa in einem Handy, denn dort sind die Interfaces alle am selben Punkt (bzw. dieAbweichung ist vernachlässigbar gering). Im Allgemeinen kann das aber abweichen. So kann z.B. ein Transportroboter an den Eckpunkten jeweils einen Ultraschall-Sensor haben, sowie an einer mittigen Stelle ein Steuergerät mit WLAN. Hierzu können diese Interfaces (hier 4x Ultraschall + 1x WLAN) dem Geräte-Objekt "Fahrroboter" einschliesslich relativer Positionen zugeordnet werden.
Die Positionen der Interfaces sind normalerweise fix, d.h. sie bewegen sich nicht relativ zu ihrem Parent-Objekt. In einigen Fällen können Positionen von Interfaces aber auch unbekannt sein, also nicht fixiert. Sie werden - wie alle anderen unfixierten physikalischen Objekte auch - innerhalb ihres Parent-Objektes geortet.
Zu einem Gerät gibt es i.d.R. einen Benutzer. Dieser wäre in obigem Beispiel also durch ein 5. Objekt "Jan" repräsentierbar und mit dem Geräteobjekt "Jan's Handy" verknüpft (wieder über den Parent-Link). Selbstverständlich kann ein Nutzer noch weitere Geräte haben, hvormalsvormalsier z.B. "Jan's Laptop".
Logistische Objekte und Änderungen von Objekthierarchien
In einigen Fällen verändern sich Objekthierarchien. Bei logistischen Objekten (z.B. Paletten) werden Inhalte häufig umgepackt (bzw. anders gesehen sind die untergeordneten Objekte mobil). Einige logistische Objekte können aber auch fest zugeordnete Sensoren haben. Z.B. Onboard Unit eines LKW, diese wäre also "stationär" zum Parent-Objekte "LKW XY". Bei einem Übergang untergeordneter Objekte von einem übergeordneten Objekt zu einem anderen müssen die Parent-Links der untergeordneten Objekte umdefiniert werden. Beispiel: Ein User kann mehrere Handys besitzen und ggf. eines zu Hause lassen. Parent-Links sollten nur gesetzt werden, wenn solche Änderungen lückenlos erfasst werden können, damit es nicht zu Inkonsistenzen kommt.
In MagicMap wird ein Objekt aufgrund aller darin enthaltenen Sensorinformationen geortet
Wenn z.B. auf einer Palette 10 Kartons sind und alle 10 Kartons Sensoren besitzen, die Messwerte liefern, ortet MagicMap die Kartons nicht einzeln (die stehen ja alle gemeinsam auf der Palette), sondern ortet die Palette so, dass deren Position die beste Erklärung der Messwerte der 10 Kartons liefert (Maximum Likelihood). Voraussetzung dazu ist, dass MagicMap die Logistik-Zuordnungen (Kartons auf Palette) kennt. Ist die Zuordnung nicht bekannt, werden die Kartons natürlich einzeln geortet. Ein dedizierter "Logistik-Server" könnte daraus die Position der Palette ggf. als Mittelwert schätzen. Das ist ungenauer geht aber auch.
MagicMap ortet also logistische Objekte wie eine Palette analog zu einem Handy, dass ja auch mehrere Sensoren/Technologien vereinigt, immer auf Basis aller enthaltenen Sensoren/Technologien. Dieser Ansatz ist entscheidend genauer als die Einzelpositionen der Sensoren auf Koordinatenebene zu aggregieren.
Objekt-Aggregation
Neben Objekt-Hierarchien gibt es Objektaggregationen. Unter Objektaggregation verstehen wir eine Menge von Objekten, die bestimmte Auswahlkriterien erfüllen. Ein einfaches Kriterium wäre beispielsweise "befindet sich innerhalb eines rechteckigen Kartenausschnitts". Dies definiert eine Menge (als Datenstruktur durch eine Liste implementiert) von allen (auch nur teilweise) innerhalb des definierten Ausschnitts befindlichen Objekten. Andere, komplexe Aggregationen sind denkbar, z.B. "alle Universitätsgebäude in Deutschland".
Damit dies effizient implementierbar ist, werden Objekte hierarchisch strukturiert. Hierarchien geben somit effiziente Aggregationspfade vor. Man könnte aber auch quer zu den Hierarchien aggregieren, z.B. Ebene1 des JvN Hauses (über die 4 Häuser hinweg).
Objekt-Aggregationen können natürlich auch mobile Objekte umfassen, z.B. "alle Taxis in Berlin". Damit werden die Mengen dynamisch und eine Umsetzung sehr komplex. Man könnte das relevante Zeitintervall berücksichtigen und Wahrscheinlichkeiten, zu der sich mobile Objekte innerhalb einer Aggregation befinden und nur die Objekte berücksichtigen, deren Wahrscheinlichkeit, innerhalb des Selektionskriteriums zu liegen oberhalb eines Threshold rangiert.
Ein anderer Ansatz sind "Schnappschussaggregationen". Hierbei werden nur die mobilen Objekte berücksichtigt, die zum Schnappschuss-Zeitpunkt innerhalb der Aggregationskriterien lagen. Andere Objekte, die sich dort hinein bewegt haben, werden nicht registriert. Der Schnappschuss muss also von Zeit zu Zeit wiederholt werden.
Andersherum könnten die mobilen Objekte Events auslösen, sobald sie Aggregationsbereiche passieren, um diese zu aktualisieren.
Welcher Ansatz sich am besten eignet und wie das in großen Skalen umzusetzen ist, ist ein aktiver Forschungsbereich.
Zur einfachen Umsetzung kann man zusätzliche Aggregationen später als "Suchordner" hinzufügen und zunächst nur entlang der vorgegebenen Hierarchien aggregieren, also nur bestehende Karten als Aggregationskriterien auswählen.
Zur Umsetzung in MagicMap wurde ein hierarchischen Kartenmodell (siehe MagicMap Kartenmodell) gewählt. Dazu ein Tracking-Service der Objektaggregationen überwacht und ggf. Ereignisse generiert, siehe MagicTracker-Plugin.
Allgemein sind es aber "Beobachtungseinheiten", wie sie auch der Tracker beobachtet (siehe MagicTracker-Plugin).
Diskussion
von Dirk: In Punkto MagicTracker muss man zwischen Aggregation und Gruppierung unterscheiden. Eine Aggregation ist nämlich eine Verdichtung und eine Gruppierung - wie oben beschrieben - einfach eine Menge von Objekten mit ähnlichen Attributen. Stellt man sich das mal als Pseudo-Ereignismuster (ja, die MagicTracker-Ereignismuster sehen wirklich wie SQL-Statements aus) vor, wäre eine Aggregation SELECT sum(x) FROM y und eine Gruppierung SELECT * FROM y WHERE pos LIKE 'flur 1' oder SELECT * FROM y GROUP BY pos.
Ein simples Anwendungsbeispiel im Rahmen des MagicTrackers für Aggregation wäre z.B. die Anlieferung einer Palette mit Milchtüten. Der MagicTracker nimmt 1000mal das Ereignis 'Milchtüte mit RFID x:y ist eingetroffen' und einmal das Ereignis 'Palette mit RFID x:y ist eingetroffen' entgegen und generiert daraufhin ein(!) Application Level Event 'Eine Palette mit 1000 Milchtüten ist eingetroffen'. Die 1001 Einzelereignisse wurden also verdichtet.
Der zweite Fall, Gruppierungen von Objekten, z.B. alle Taxis in Berlin oder alle Objekte in allen ersten Stockwerk der Uni Berlin kann im MagicTracker allein über Attribute erfolgen. Hierarchien spielen keine Rolle. Der Benutzer registriert ein komplexes Ereignismuster, z.B. SELECT * FROM Obj WHERE ((Obj instanceof TaxiObj) OR (type LIKE 'Taxi')) AND pos LIKE 'Berlin' . Und alle Ereignisse, die im Laufe eines bestimmten Intervalls (zeit- oder volumenabhängig) eintreffen und das Muster erfüllen werden als Liste wieder ausgegeben. Vielleicht kann man mit Hilfe komplexerer Muster auch erkennen, dass ein Taxi an pos = 'Kreuzberg' ebenfalls in die Berlin-Gruppe gehört, aber derartige Hierarchien muesste man dem MagicTracker explizit bekanntgeben. Würd ich einfach mal so behaupten.
--pi 12:56, 18. Jun 2009 (CEST): Ich meine das so: eine Objektggregation ist einfach eine Menge von Objekten. Kann aber dynamisch sein und sich ständig ändern. Eine Gruppe ist eine besonders einfache Objektaggregation, i.d.R. ist sie statisch. (eine "Ereignisaggregation" würde Deinen o.a. Verdichtungen entsprechen).
Nehmen wir obiges Beispiel, die Milchtüten plus die Palette, das wäre eine Objektaggregation, die man beobachten möchte (hierbei haben alle Milchtüten als Parent-Link die Palette). Nennen wir diese Aggregation mal A1. Ein Ereignismuster darauf müsste durch eine Art Beschreibungssprache erfolgen. Der Tracker filtert erstmal alles was mit der Aggregation A1 passiert und schickt es durch die Regeln, die durch die Ereignissprache definiert wurde, nennen wir sie R1 ("Rules"). Erzeugt die ein positives Resultat, triggert der Tracker ein entsprechendes Event und schickt es an alle Clients, die sich für die Ereignisbeschreibung E1, definiert durch das Paar (A1, R1) subscribtet haben. Dabei kann es viele Regeln je Aggregation geben. Man kann sich für einzelne, mehrere oder alle subscriben, also immer Paare (Ax, Rx). Dann erhält man als subscribiteter Client genau die Ereignisse die hier zutreffen.
Dabei könnte es folgende Ereignise geben:
- Milchtütenpalette passiert Warehouse-Eingangsbereich
- Milchtütenpalette ist unvollständig
- Milchtüten der Palette haben ihr Verfallsdatum überschritten
- die Kühlkette beim Transport der Milchtüten wurde nicht korrekt eingehalten
Man kann auch von bestimmten Objektaggregationen ausgehend sich an Ereignisbeschreibungen subscripten. Ein Client verwaltet dann viele solcher Objektaggregationen. Und man müsste Reaktionen auf Events definieren können. Hier ist zu überlegen, was passiert, wenn sich Aktionen widersprechen (gewinnt das letzte erhaltene Event? Das kann zu Problemen führen). Beispiel für eine Objektaggregation: "Waren im Kommissionierungsbereich X". Ereignisse wären hier:
- Zugang / Abgang von Objekten in den Bereich
- Unzulässige Objektkonstellation
- Objekt ohne Auftrag
- Objekt mit zeitlicher Abweichung vom Plan
Implementation
- für jede Objektaggregation wird ein zuständiger "Master" definiert - normalerweise findet diese Auswertung physiklisch auf unserem Server statt, muss aber nicht so sein.
- auf diesem Master wird für jede Nachricht geprüft, in welcher Objektaggregation sie liegt (erfordert effiziente Datenstruktur)
- dann werden alle Regeln zu dieser Objektaggregation ausgeführt
- und ggf. die entsprechenden Ereignisse getriggert und an die Subscriber gesendet
- auf den Clients wird dies ausgewertet
Hier könnten Rule Engines bei der Implementation helfen? Siehe diese Liste von Rule Engines in Java. Es gibt wohl auch ganze Frameworks dazu. Z.B. beschreibt diese Dissertation ein Matchmaking Framework für Condor.
Zusammenspiel zwischen NavigationView- und MapView-Fenster
Im MagicMap "MapView"-Fenster werden immer alle Objekte einer Objekt-Aggregation dargestellt. Wählt man im NavigationView-Fenster ein Objekt aus, wird eine neue Objekt-Aggregation erzeugt und an das MapView Fenster übergeben. Darin sind alle Objekte innerhalb der zu dem Parent-Objekt untergeordneten Objekt-Hierarchie. Damit das effizient möglich ist, müssen alle Objekte eine Liste Ihrer Childs haben. Ausserdem muss es die Dienste open, close, und update für die erste Child-Ebene, für n Child-Ebenen und für alle Childs geben. Durch geignete shortcuts muss eine einfache Bedienung möglich sein, ähnlich wie bei FreeMind mit seinem Fold/unfold Tree.
Verläßt ein Objekt den Bereich seines Parent-Objektes (i.d.R. einer Karte), wird es aus der Liste der Child-Objekte gelöscht und der Parent-Link wir erneuert. Dies führt der Knoten durch, der für die Positionsbestimmung des Objektes zuständig ist. Objekte, für die keine Positionsinformation existiert, bzw. für die keine Parent-Zuordnung gelingt, erhalten den Parent-Link <NIL>. Ist das Parent-Objekt nicht im Aggregationsbereich (allgemein: entspricht nicht den Aggregationskriterien), wird das Objekt aus der Aggregation entfernt und daher nicht mehr angezeigt. Innerhalb der Aggregation kann man zoomen und pannen.
--Jan 20:37, 2. Jul 2006 (CEST)Was machen wir mit Infoobjekten. Die könnten mehrere Eltern haben. Z.B. wäre mein Klient und der von Peter mit diesem Wiki verbunden....
--pi 18:07, 4. Jul 2006 (CEST): Ja. Hier müssen wir noch etwas nachdenken. Ich hatte das so gedacht: Zu jedem Objekt gibt es eine Liste mit "Child-Knoten" auf die es eine Relation gibt. Nun kann man die Art der Relation annotieren, oder aber einen intermediären Knoten schalten, der den Typ der Relation angibt.
Strukturansicht
Die Strukturansicht beginnt mit dem Root-Objekt. Hier könnte man den Server nennen, zu dem man verbunden ist. Darunter gibt es die Childs: Karten, Access Points, Clients, ... In allen Objekte kann man ein + vor einem Objekt anclicken um es zu öffnen (bzw. zu schließen). Ein Einfachclick öffnet und zeigt seine Childs, aktualisiers sie aber nicht. Erst ein Doppelklick führt eine echte Neuberechnung durch, aktualsisiert die Clients und auch die Liste der Child-Objekte, die zu jedem Objekt gespeichert werden.
Öffnet man nun die Root/Clients, erhält man alle (global), also nicht nur die eine bestimmten Karte. Möchte man nur die Clients einer bestimmten Karte sehen, muss man diese vorher öffnen. Hier gibt es wieder die Einträge: Karten, Access Points, Clients, ...
Jedes Objekt hat einen Filter, den man durch Shortcut erreicht (z.B. Alt-Linksclick). Dann kann man einen regulären Ausdruck angeben. Es werden daraufhin nur die Childs geholt, die den Regulären Ausdruck erfüllen. Dass der Filter aktiv ist, wird entsprechend visualsiert, z.B. durch ein Tortensymbol für die Prozentzahl der ausgefilterten Childs gegenüber der Gesmtzahl der hier befindlichen Childs.
Objekte könen rekuriv verschachtelt sein, so hat beispielsweise "Jan" Bezug zu "Peter", "Peter" zu "Johannes" und "Johannes" wieder zu "Jan".
Kantentypen werden durch Objekte repräsentiert. So hat "Jan's Positionsschätzung" die Childs: Distanzschätzungen und Punktschätzung. Distanzschätzungen hat die Childs: WLAN AP XYZ, Bluetooth Sender UVW. Punktschätzung die Childs: GPS und ZigBee (Annahme hier: ZigBee-Tag berechnet seine Position autonom).
Mit einem Shortcur (z.B. Ctrl-Linksclick) wird die Kartenansicht zu dem in der Strukturansich ausgewählten Objekte gezeigt. Das ausgewählte Objekt der Strukturansich wird entsprechen markiert.
Dienste
Das UML-Diagramm kann in diesem Visio-Dokument bearbeitet werden.
Dienste sind Info-Objekte und werden als solche in einem Spring Layout um die Objekte angeordnet, auf die sich die Dienste beziehen.
Beispiel: "Drucke ein File in Farbe" ist ein Dienst des Druckers "Herkules" im JvN-Gebäude, Haus 4, Raum 212, nach Jetdirct-Protokoll, mit Parameter <File> und den möglichen Datentypen A,B,C.
Es kann 0-, 1- , 2- oder vielstellige Dienste geben, also mit Bezügen zu mehreren Objekten bzw. abhängig von einer Benutzereingabe (z.B. die Position des Maus-clicks). Entsprechend können Dienste mehrere Kanten im Springlayout haben. Ebenfalls kann jedes Objeket auf einen oder mehrere Services verweisen.
In einer (verteilten) Registry werden alle angebotene Dienste eintragen. In der Registry kann man dann Dienste, mit Typ, Schnittstellenbeschreibung und Aufrufprotokoll, sowie die Objekte, die diese anbietet, nachschlagen. Beispiel: "zeige alle Druckdienste im JvN-Haus, die farbig drucken können".
Für eine Registry bei globaler Skala stellt sich offenbar ein Problem.
Weiter kann es regionale Dienste geben, beispielsweise "zeige mit die nächste S-Bahn Station" (1-stellig, d.h. abhängig von einer Positionsangabe), oder "wie wird das Wetter morgen?" (typischerweise 0-stellig, also unabhängig von einer Position, sondern nur von der Region). Diese regionalen Dienste haben dann Kanten zu einem flächigen Objekt, d.h. zu seinem Bezugspunkt.
Anmerkung zur Abb: In der Abbildung werden "Services with Scope" differenziert - das scheint mir nicht nötig.
--Andreas Es könnte schwer werden in der Hierarchie "regionale" Dienste zu finden. Angenommen ich lege eine Karte für das J.v.N Haus an und aktiviere z.B. über eine Option regionale Dienste, dann muss über den Parent Link nach passenden Diensten gesucht werden. Das reicht aber nicht, wenn ich den Wetterdienst für Berlin haben will, weil ich dann erst in Adlershof lande. Die Frage ist also, wann hört man auf? Deutschland kann viele Dienste haben und die Welt hat garantiert noch mehr.
pi 21:15, 12. Feb 2007 (CET): Es werden ja in der MapView-Sicht alle Objekte einer Aggregation angezeigt. Um die Aggregation zu erzeugen, muß man geeignete Such- und Filter-Funktionen bereitstellen. So kann man sich weitere Dienste der übergeordneten Ebenen holen. Filtereinstellungen könnten etwa sein: Zeige Regionale Dienste (Ja/Nein); Zeige Regionale Dienste der übergeordneten Objekte; Zeige nur Dienste die bzgl. eines Suchstrings "Wetter" einen Rang größer Threshold erreichen.
Signatur und Object Discovery
Verallgemeinert handelt es sich bei der Positionsangabe um einen Teil der "Signatur", also eine Objektcharakteristik, die verkürzend ist und geeignet, das Objekt zu identifizieren und aufzufinden. Alle Elemente, nach denen wir suchen möchten, müssen in die Signatur, u.a. die absolute Position (falls verfügbar), Name, UUID, Schlagwortliste, angebotene Dienste, später ggf. mehr. Die Signatur wird in einem (verteilten) Repository abgelegt. Das Repository kann dann nach Signaturelementen durchsucht werden (Discovery Service). Unterschiedliche Standardisierungen für solche Discovery Services existieren, z.B. UDDI, UPnP oder Jini.
Die Signatur ist entweder statisch (verändert sich nie) oder dynamisch. Wenn man bei mobilen Objekten die Position indizieren möchte, ist die Signatur natürlich dynamisch. Dies stellt bei zahlreichen Objekten mit hoher Mobilität für die Indizierung und das Discovery eine Herausforderung. Hier gilt es, die Signatur-Update-Intervalle zu optimieren, abhängig von Signatur-dynamik (Mobilitätsgrad der Objekte), Leserate, Aufwand, um die Signatur zu berechen und zu aktualsieren gegenüber der Einsparung im Vergleich zu einer Brute-force Suche.
Redundanz, Inkonsistenz und kumulative Ungenauigkeit
Durch Verkettung können fehlende, absolute Positionsbezüge abgeleitet werden. Das erzeugt Redundanz. Redundante Daten können veralten. Durch zyklische Verkettung können darüberhinaus Widersprüche entstehen. Für statische Signaturen kann man das einmalig berechnen bzw. prüfen. Für dynamische Signaturen ist das wiederum viel schwieriger.
Beispiel: Befindet sich in der Objektverkettung ein Root-Bezug (also WGS84 Koordinaten), kann nacheinander für alle verketteten Objekte die absolute Position berechnet werden. Dabei addiert sich die (Un-)Genauigkeit. Um dennoch eine bessere Genauigkeit in einigen Karten zu erhalten, können beliebig viele Positionsangaben zu verschiedenen Karten eingetragen werden. Nun können aus diversen Root-Verknüpfungen Ableitungen getroffen werden. Dabei können Inkonsistenzen aufgedeckt werden (z.B. fehlerhafte Initialpositionierungen der Karten oder stationär-/mobil-Widersprüche in den Positionsangaben). Ausserdem können Mittelwertbildungen für die Positionen die Genauigkeit verbessern.
Bei der verteilten Datenhaltung kann es grundsätzlich zu (temporären) divergierenden lokalen Sichten kommen.
Informations-Objekte
Informations-Objekte unterscheiden sich von physikalischen Objekten dadurch, dass sie keinen unmittelbaren Ortsbezug (Position) besitzen. Ihre (logische oder Darstellungs-) Position leitet sich stattdessen aus der Stärke des Bezugs zu physikalischen Objekten ab, zu denen ein Informationsobjekt in Beziehung steht.
Die präzise Unterscheidung von physikalisch und logisch kann im Einzelfall sehr unscharf werden, daher ist es eher eine willkürliche Zuordnung von Objekten, die bewirkt, dass sich ortzbezogene Objekte nicht an Infoobjekten ausrichten, nur umgekehrt. Bezogen auf das Spring Layout kann man auch einheitlich für alle Objekte von der "Darstellungsposition" (innerhalb der gewälten Karte) sprechen.
Die Darstellungsposition von Info-Objekten kann auf vielfältige Weise durch den Nutzer entsprechend seines Bedarfs beeinflusst werden. Die Infoobjekte positionieren sich aufgrund von Verknüpfungen, die sie zu anderen angezeigten Objekten haben, einige davon haben Initialpositionen, an denen sich alle anderen Objekte ausrichten. Die Verknüpfungen werden als parametrisierte Kanten in einem Graph so gewählt, dass im Spring Layout (s.u.) geeignete Darstellungspositionen resultieren.
Info-Objekte können verankert oder frei sein. Verankerte Info-Objekte haben eine explizite Verbindung zu einem physikalischen Objekt. Diese Verbindungen werden beispielsweise von Benutzern des System angelegt oder können per Skript automatisiert aus existierenden Datenbeständen initial generiert werden. In der GUI werden diese Verbindungen "Positionsannotationen" genannt. Die Verbindungen haben einen Titel, eine Beschreibung und eine Menge von Tags (Schlagwörtern).
--Jan 19:12, 2. Jul 2006 (CEST)Infoobjekte sollten sehr wohl eine physikalische Positionhaben können. Wenn ich -z.b. - auf einer Karte den Standort einer Stadtsparaksse eintrage so hat diese eine absolute physikalische Position.
--pi 18:18, 4. Jul 2006 (CEST): Mein Konzept geht so: Das Info-Objekt "Stadtsparkasse, Zweigstelle XY" hat einen Bezug zu dem physikalischen Objekt "Position der Zweigstelle", die ist relativ zur Karte, nehmen wir mal an "Karte von Berlin Adlershof", die wiederum ein physikalisches Objekt ist. Normalerweise werden beide Objekte "Zweigstelle" und "Zweigstellenposition" an der gleichen Stelle visualisiert (ja nach Anzeigeoptionen, transparent oder leicht nebeneinander nach Spring Layout). Nun interessiert sich z.B. jemand für den Zweigstellenleiter, Herrn Meier. Den kriegt er durch Klick auf das Zweigstellen-Objekt, dadurch werden alle Childs aufgeklappt. Nach Bedarf kann man die uninteressanten wieder wegklicken. Ein Klick auf den Zweigstellenleiter Meier offenbart, wo der gerade ist. Es kommt also ein Link zu dem physikalischen Objekt "Positionsschätzung von Herrn Meier" hinzu. Dadurch verschiebt sich die Darstellungsposition des Info-Objektes "Herr Meier" und auch die Darstellungsposition des Zweigstellenobjektes. Nur die physikalischen Objekte bleiben an ihren Positionen, die reagieren nicht auf Info-Objekte. Das hört sich komplex an, ist aber m.E. wegen seiner Homogenität recht leicht umsetzbar. Damit Herr Meier, der vielleicht gerade in Mallorca Urlaub macht, nicht völlig aus der Karte "Berlin Adlershof" wegrauscht kann man rauszoomen und kriegt die Europakarte. Nun muss über die transitive Hülle die Position der Niederlassung in der Europakarte berechnet werden. Die wird als interne Positionsschätzung an alle Objekte angehängt und im Knotenmodell im Cache abgelegt. Die Position in Europa ist etwas ungenau, aber das ist hier ja auch egal. Nun sieht man, aha, Herr Meier ist auf Malle, seine Zweigstelle ist in Ahof, das Infobjket zur Zweigstelle wird gewichtet dazwischen angezeigt. Klicke ich Herrn Meier weg, zoomt das ganze automatisch wieder auf Adlershof. Dieses Verhalten kann man unter Ansicht einstellen als "Zoom automatisch an die Auswahl angepassen". Damit man in Europa nicht Millionen von Objekten zu sehen kriegt, gibt es eine separat änderbare Auswahl. Nur die Objekte in der Auswahl werden visualisiert.
Weiteres unter Informationsobjekt.
Spring Layout
Kanten zwischen ortsbezogenen Objekten repräsentieren Distanzschätzungen und haben die Parameter erwartete Länge m und Streung s auf Basis einer Lognormalverteilung. Der Spring Layout Algorithmus erreicht effizient den wahrscheinlichsten Zustand ("Maximum Likelyhood Schätzer"), indem er in einer iterativen Suche die Summe der (entsprechend der Lognormalverteilung mit Parameter m und s) gewichteten Kantenfehlerquadrate minimiert. Im Moment macht das JUNG, später der Algo von Stefan. Es sollte etwa das gleiche rauskommen. Unterschiede entstehen nur aus der Gewichtung (natürlich erwarten man auch unterschiedliche Performance).
Kanten von ortsbezogenen Objekten zu Infoobjekten bzw. zwischen den Infoobjekten, haben kantentypspezifische Parameter (z.B. "Länge" und "Gewichtung" oder auch "Dehnkoeffizient"). Im Spring Layout für die orstbezogenen Objekten werden die Kanten zu nicht-orstbezogenen Objekten ignoriert. M.E. kann für beide "Layouts" der gleiche Spring Layout Algorithmus zum Einsatz kommen (ist mehr eine Frage der Programmiereffizienz und der Modularisierung), lediglich die Gewichtung ist etwas unterschiedlich. Bei der Gewichtung müssen wir überlegen, wie das genau geht; durch einen "Dehnkoeffizienten" zwischen 0 und unendlich sollte es z.B. möglich sein, ortsfeste Verankerungen bzw. zu ignorierende Kanten anzugeben.
Beim Spring Layout Algortihmus muss man sich ein paar Skalierbarkeitsgedanken machen. Zum einen können Positionen extern berechneter Objekte übernommen werden, und müssen lokal nicht mehr berechnet werden, zum anderen muss die "Rekursionstiefe" der berücksichtigten Kanten beschränkt werden (Kanten können über Kartengrenzen hinweg existieren, u.U. hat man eine weltweite Vernetzung). Schließlich können in der aktuellen Ansicht zu viele Objekte sein, so dass man geeignet filtern oder clustern muss.
Initiale und Externe Positionangaben
Initiale Positionangaben sind beispielsweise:
- externe Positionsberechnung von Client xy
- Wikipedia GeoTag-Eintrag
- Fixierungsinformation eines Users (wird mit angenommener Genauigkeit eines Mausclicks in der Karten-Auflösung eingetragen)
- eine durch den User angegebene Positionsschätzung mit (Un-)Genauigkeitsparameter
Alle diese Positionsangaben sind nicht aus dem System heraus hergeleitet sondern sind unveränderlich vorgegeben. Besonderheit der initialen Objekte ist, dass sie natürlich (zu Ihrem Beszugsobjekt) stationär sind. Sie sind aber auch fix (durch keine Messung beeinflusst, da ihre Positionsangabe einmal initial erstellt wird).
Während initiale Positionsangaben ihre Position "mitbringen" haben interne Positionen keine eigenen Ortsangabe, sondern eine abgeleitet/berechnete. Sie können fix sein, wenn die Berechnung nur einmalig stattfand, meistens wird sich ihre Position aber auf Basis von Messungen ändern.
Fixe Positionsangaben sind unbeweglich und werden als "Anker" dargestellt, an denen sich alle übrigen Objekte ausrichten.
Initiale Positionsangaben sind ein Spezialfall "externer" Positionsangben. Beispiel für eine externe Positionsangabe, die aber nicht initial ist:
- GPS-Ortsschätzung
- Positionsschätzung eines autonomen ZigBee-Tags
diese sind nicht fix, sondern werden standig neu berechnet (wie bereits erwähnt, kann man Invarianz immer durch Zeitstempel und Einfrieren erreichen). Alle externen Positionsangaben sind wiederum ortszbezogene Objekte und werden als solche verarbeitet und visualisiert.
Eine gewisse Mindestmenge externer Positionangaben ist nötig, um weitere Positionen abzuleiten.
Visualisierungsbeispiel "Wo ist Jan?"
So sieht man (auf Wunsch) zum dem Info-Objekt "Jan's Hompage" eine Kante zum Objekt "Jan's aktuelle Position" und mehrere Objekte als spezifische Positionsschätzungen (WLAN-, GPS-, ZigBee- Positionschätzung), dazwischen "Genauigkeits-Kanten". Die Kanten haben eine Gewichtung abhängig von der erwarteten Ortungsgenauigkeit und ziehen das Objekt "Jan's aktuelle Position" auf die wahrscheinlichste Position.
Die Positionsschätzungen haben wiederum Kanten zu anderen ortsbezogenen Objekten, im Fall der WLAN-Positionsschätzung z.B. zu verankerten Access Points, d.h. zu Objekten mit initalen Positionen.
Hybride Positionen und Interfaces
"Jan's aktuelle Position" aus dem obigen Beispiel repräsentiert einen neuen Objekttyp - eine "Hybride Positionsschätzung". So kann man die diversen Technologien - Interfaces - vereinigen und auch direkt sehen, ob Fixierung und unterschiedliche Ortung überhaupt konsistent sind. Dies läßt auch spätere Erweiterungen zu, z.B. weitere Einflüsse auf die Hybride Positionsschätzung, wie etwa indoor Umgebungsmodelle. Es kann Positionsschätzung nach Algorithmus A und eine andere nach Algorithmus B (andere Gewichtung) geben.
Jedes Interface hat ja ggf. eine eigene Positionschätzung. Die Hybride Positionsschätzung dazu könnte man dann durch die gewichtete Mittelwertposition der Interfacepositionen bestimmen. Die ergibt sich als Faltung der Normalverteilung mit den Parametern Erwartungswert und Varianz (der Positionen der Interfaces). Diese Berechnung wird angewended bei externen Positionsschätzungen. Füt interne Positionsschätzungen ergibt sich aber eine genauere Ortung, wenn die Interfaces genau an der Stelle des übergeordneten Objektes sind und entsprechend im Ortungsalorithmus (Suchverfahren mit "Partikelbewertung") dort bewertet werden.
Pfad-Objekt und Bewegungsmuster
Sehr interessant finde ich es, einen Objekttyp "Pfad-Objekt" zu integrieren, also z.B. Bezier-Kurve die das historische Bewegungsmuster anhand der Stützpunkte (Historie der Positionsangaben, die mit Zeitstempel und einfrieren invariant gemacht wurden) darstellt.
Kanten-Parameter
Die Kanten-Parameter müssen vom Ranking/Web-Parser und der Ortung befüllt werden und die "Schieberegler" können darauf einwirken - Schwupps baut sich alles um. Wie genau die Parameter aussehen und die Kanten-Gewichtung beeinflussen, müssen wir kantentypspezifisch überlegen. Kanten zu Positionschätzungen haben z.B. die Länge 0 und eine Genauigkeit, die allerdings bei mobilen Objekten "altert". Bei der Gewichtung der Kanten und aufsummieren der Fehler im Spring Layout Algorithmus, muss man das entsprechend berüchsichtigen. Es sollen ja auch zeitliche Bewegungsmuster dargestellt werden (Schieberegler "Zeitfenster"). Auch die Integration von Richtantennen (bzw. RFID mit Richtwirkung), kann so stattfinden. Wir sollten also getrennte Module "Spring Layout" und diverse "Kantengewichtungen" vorsehen (statt nur "Berechnung").
Knoten- und Kantenmodell
Basis ist ein hierarchisches Knoten- und Kantenmodell, wo man auswählen kann, welche Typen und Untertypen welche Parameter haben und wie diese eingestellt werden. Hier muss es hohe Flexibilität geben, weil man später typindividuell mit spezifischen Filtern bestimmte Knoten und Kanten umgewichten will. Z.B. um auf einen Click GPS-, WLAN oder ZigBee-Anteile an-/abzuschalten oder umzugewichten.
Zu den Typen gibt es bestimmte zusätzliche Infos/Flags, beispielsweise: "von wem berechnet", "wann berechnet", "mobil/stationär", "Mobilitätsklasse 1,2,3,4,5", "Geschwindigkeit", "Bewegungsrichtung", "fixiert/unfixiert", "synchron/individuell" und "public/private". Hier müssen wir uns Gedanken machen, wie das genau funktioniert. Als Visualisierung gefällt mir die Baumansicht, so wie bei Stefans CE Lösung: beliebige knotenspezifische Parameter werden da einfach auf-/zuklappbar per + im Strukturfenster hierarchisch angezeigt. Zusätzlich muss es dort "Filter" geben, um es zu beschränken oder "Masken" um gruppierte Schreibvorgänge vornehmen zu können.
Synchronisation
Es sollte ferner möglich sein, bestimmte Daten und Ansichten mal individuell oder mal synchronisiert zu anderen Clients haben zu können. Daten, die auf "public" stehen, sind für alle anderen sichtbar, u.a. um die Ansichten zu synchronisieren. Gleichzeitig ist dies knotenspezifisch abschaltbar (individuell = extern ignorieren, stattdessen selber berechnen), um Fehlerquellen (u.a. "malicious user") aufspüren zu können. Stellt man auf "privat" kann man in der Visualisierung rumspielen, ohne das andere was mitkriegen (man arbeitet auf dem lokalen Cache, für diese Objekte ist dann die Daten-Distribution abgeschaltet). "Invisible" heißt, dass die eigene Position "privat" geschaltet ist und lokal berechnet wird. Sehr wichtig ist es, zeitnah angezeigt zu bekommen, ob die auf "synchron" bzw. "public" eingestellten Objekte auch wirklich korrekt übertragen wurden. Auch "unberechnete" Knoten müssen sofort visualisiert werden.
Ranking und Caching
Den durch die MagicMap User erzeugten Traffic kann man durch Aufruf/Speichern mitzählen und für den Objekt-Rank nutzen. Für Info-Objekte mit URL kann man den Google-Page-Rank abfragen und dazu kombinieren. Schlagworte/Kategorien kann man über einen speziellen Dienst zuornen. Ggf. gibt es auch "automatische" Webseitenklassifikatoren, die man aufrufen kann.
Das Objekt-Modell sollte so sein, dass diese externen Daten auf Wunsch an alle Clients übertragen und dort gecacht werden können, damit auch Offline-Zugriff geht. Beispielsweise möchte man die CeBIT besuchen. Dazu braucht man zunächst irgendwo vorher Internetzugang, da man dort keinen permanenten Zugang hat. Nun clickt man die CeBit Karten an. Dadurch werden alle bekannten Messwerte und AP-Standorte sowie Info-Objekte incl. Webseiten in den lokalen Cache geladen. Dazu macht man z.B. Rechtsklick auf eine Karte und wählt: "Prefetching: alle Objekte der Karten incl. Subtree". Dadurch holt sich der Client alle Objekte der CeBit in den Cache und zwar in der Reihenfolge ihrer "peronalisierten spatiotemporalen Ranking-Dichte" (Objekt-Rang aus Sicht des Users, unter Berücksichtigung des Ortes und der Zeit geteilt durch Speicherbedarf) so viele, wie in den Cache passen. Das Ranking wird durch zunehmende Zahl von CeBit-Besuchern, die MagicMap nutzen, immer besser, da deren Trafic ja gelernt wird.
Anderes Beispiel: Man besucht Berlin. Da möchte man z.B. alle Objekte aus der Wikipedia, die was mit Berlin zu tun haben. Dazu gehört vermutlich die Seite der HU. Vieleicht auch eine Biografie von A.v.Humboldt? Je nachdem was das Ranking ergibt und der Cache groß genug ist.
Der relative Rang eines Objektes ergibt sich aus dem absoluten Objektrang mal Assoziationsstärke zwischen Person (dem User) und Objekt, mal Assoziationsstärke Lokalität zu dem Objekt, mal Assoziationsstärke Zeit zu dem Objekt. Die Assoziationsstärke berechnet sich aus den Kanten zwischen den Objekten (z.B. Summe aller Weglängen (Kehrwert) über die transitive Hülle). Idealerweise geht das auch parametrisiert mit einem speziellen Interessensprofil (z.B. Interesse für "Navi-Systeme") a la: "andere, die sich für "Navi-Systeme" interesssiert haben, haben bevorzugt folgende Seiten besucht...". Den Grad der Personalisierung oder der Gewichtung mit dem speziellen Interesse kann man über "Schiebregler" anpassen.
Aufteilung
@Johannes: das generische Knoten-/Kantenmodell incl. Berechnung/Gewichtung und Plugin-Konzept würde ich als Bestandteil Deiner Diplomarbeit und Kern eines Konzeptes zur "hybriden Ortung" sehen.
@Jan: Da Du das Grundkonzept ja um diverse Infoobjekte, Kantentypen, Rankings und Gewichtungen erweitern wirst, solltet ihr intensiv kommunizieren.
@Matthias: Du machst ja in Deiner Diplomarbeit die "globale Sicht", also Schnittstellen, GIS/OGC-Standards, WGS84, Map Services, Google Maps/Earth und Location Based Discovery, adaptive Dienstkomposition, Client- vs. Mediator-zentrierte Aggregation in Karten. Wie siehst Du die Einordnung Deiner Beiträge?
@Thorsten/Sebastian: Wie passt Euer Konzept?
Bitte hier einfügen und auf Eure Seiten verlinken.
Dienste
Bei den Diensten hab ich 2 bedenken:
- Ist das Konzept mit den Diensten nicht fürs erste viel zu umfangreich?
- pi 11:48, 29. Jun 2006 (CEST): diese Diskussion ist nicht zut sofortige Umsetzung gedacht, sondern mehr als Roadmap.
- Ist die Festlegung auf SOAP nicht recht limitierend? ein Wiki, Forum oder BLOG ist auch ein Dienst.
- pi 11:48, 29. Jun 2006 (CEST): ja, her mit allen Diensten! Konzeptionell sollte das nicht beschränt sein. Die Implementation wohl schon.
- Ich hatte mir gedacht das die Infoobjekte als Dienste implementiert werden. Diese würden z.B. den Dienst "zeige mir alle thematischen Nachbarn an" bieten.
- pi 11:48, 29. Jun 2006 (CEST): ja, verwantde Infoobjekte finden ist ein sinnvoller Dienst. Wieso?
Plugins
Die bestehende Pluginarchitektur soll aufgebohrt werden um das Entwickeln von (besseren) Plugins zu erleichtern
Dazu wird der bestehende Plugin Manager ducch einen neuen ersetzt.
Plugin Struktur
Plugins sind Jars oder Verueichnisse die eine bestimmte Struktur haben.
plugin/
META-INF/
plugin.xml
org/
lib/
... mehr später...
