[Berlin-wireless] Fwd: Ueberlegungen zu Mesh-RDF

So Dez 2 20:16:52 CET 2007

-------- Original-Nachricht --------
Datum: Sun, 14 Oct 2007 19:53:05 +0200
Von: "Alina Friedrichsen" <x-alina at gmx.net>
An: berlin at berlin.freifunk.net
Betreff: [Berlin-wireless] Ueberlegungen zu Mesh-RDF

Hallo,

ein Grosses, wenn ich, das Groesste Problem, was es bei Mesh-RDF momentan noch gibt, ist, dass wir aehnlich wie bei FOAF keine wirklich weltweit eindeutiegen URIs (Uniform Resource Identifier) fuer die Nodes und Links haben. Folgendes geht mir schon laenger durch den Kopf, zulaetzt laetzte Nacht und ich denke, ich hab jetzt was halbwegs kosistentes erreicht, das ich gerne zur Diskussion stellen wuerde.
Leider wird sich das wohl nicht auf die geflutetten Daten vom olsrd anwerden lassen, da dieser die MAC-Adressen nicht mit uebertraegt. Aber fuer zentrale Map und die dezentrale Einzammelung ihrer Daten waere das eine grosse Hilfe.
Du breuchtest eigentlich nichts anderes zu tuhn als den Inhalt der Dateien (innerhalb des <rdf:RDF/>-Elements) aneinander zu haengen und schon haettest Du ein mesh.rdf von dem gesammten Netz. Um es der darstellenden Map-Softwaere zu erleichtern, und um kompatiebel mit denen zu sein, die nur GeoRSS (also nicht Mesh-RDF) sprechen, sollten noch die <georss:line/>-Elemente in den <Link/>-Elementen hinzugefuegt werden. Das waere aber nicht zwingend erforderlich, da die Map-Softwaere sich diese theoraetisch auch selbst raussuchen koennte.
Ein Beispiel wie zukuenfig das RDF ausehen koennte, was zum Server gepostet hab ich angehaengt.
Meine Idee waere, dass wir einen Node in Zukunft an der MAC-Adresse von (moeglichst) eth0 identifizieren. Ein eth0-Interface sollte ja einglich jedes Geraet haben, da dieses meistens oder fast immer auf dem Board (im Gegensatz zu einer WLAN-Karte) verloetet ist, sollte sich die MAC-Adresse auch nicht aendern. Um aus dieser MAC-48 nun eine ID zu machen, wuerde ich sie um future-compatible zu sein in eine EUI-64 konvertieren. Dazu musst Du einfach nur zwei 0xff (255) Bytes in die Mitte packen. (Achtung: IPv6 macht dies falsch, sie packen 0xff 0xfe dazwischen, da die MacherInnen des einen Standards den anderen Standard nicht richtig verstanden hatten.) Um diese 8 Bytes der EUI-64 nun moeglichst platzsparend in eine URI zu kriegen, will ich sie Base64 kodieren und dabei das "'URL and Filename safe' Base 64 Alphabet" (RFC 3548) verwenden. Vor dem daraus resultiereden String koennten wir dann z.B. "http://meshrdf.org/n/" haengen um klarzustellen, das es sich dabei um eine Node-URI 
 handelt. In meinem Beispiel waere das "http://meshrdf.org/n/ABv8__9XqzU=".
Zum identifizieren eines Interfaces wuerde ich einfach dessen MAC-Adresse verwenden und sie auf die gleiche Weise koodieren. Also z.B. "http://meshrdf.org/i/ABv8__9XqzU=". Wichtig dabei zu beachten waere, das wir so nur physikalische Interfacese auseinanderhalten koennten, also nicht Interfaceses aus Sicht der Software, wie z.B. virtuelle Interfaces, VLANs usw. (Wenn mensch mit ner Atheros mehrere ESSIDs aufmacht, hat dann auch jedes representierende Interface die selbe MAC-Adresse? Kann das bitte mal jemand nachschauen?) Eine Loesung fuer das Problem waere es die Haupt-IP mit in die URI einzubauenen, dann wuerden sich aber leider keine Layer 2 Protokolle wie z.B. B.A.T.M.A.N. Advanced mehr abbilden lassen, da diese keine Ahnung von den IP-Adressen haben und dies auch nicht haben sollen.
Naechster Schritt waere eine eindeutiege URI fuer eine IP-Adresse, da ja ein Interface mehrere haben kann. Dazu haeng ich bei IPv4 einfach die 4 Bytes von dieser an die 8 Bytes der EUI-64 bzw. MAC des Interfaces ran und koodiere sie wieder mit Base64. Also z.B. "http://meshrdf.org/a/ABv8__9XqzVogAFA".
Jetzt breuchten wir nur noch eine eindeutiege URI fuer die Links. Dazu wuerde ich die beiden IP-Adressen-IDs (also MAC/EUI-64 + IP) der Endpunkte nehmen und diese aneinander haendengen. Dabei wuerde ich die ID, die als Zahl gesehen kleiner ist, als erstes schreiben. Der Endpunkt mit der ID wird auch bei allem weiteren, als der angesehen, von dem der Link ausgeht. Also z.B. bei den Elementen <fromInterface/>, <fromAddr/> und <lq/>. So wuerde kein Kuddelmuddel enstehen, wenn die mesh.rdf Files gemerged werden. Es koennten sich ja beide Nodes als "from" oder "to" sehen. Bei B.A.T.M.A.N. Advanced Links wuerde ich fuer die URI einfach nur die IDs der Interfaces des Links auf die selbe Weise aneinander haengen. Hier ein Beispiel fuer einen OLSR-Link: "http://meshrdf.org/l/ABnS__-YLmNoQADfABv8__9XqzVogAFA".
Ich wuerde mich freuen, wenn Ihr Euch mal Gedanken darueber machen wuerdet und wenn es noch andere Probleme dabei gibt, sie mir mitteilen koenntet. Ein moeglichst universellen Standart zu entwerfen ist nicht so einfach, wie es auf dem ersten Blick vielleicht aussehen mag. Meine Hochachtung fuer die Arbeit des W3Cs, auf der Mesh-RDF ja aufbaut.
Achja, die einziege Instanz die wissen muesste, wie sich die URIs zusammensaetzen, muesste das mkmeshrdf-Tool sein, an dem ich grade arbeite. (Dieses generiert ein RDF, das den localen Node beschreibt.) Alle anderen Tools, CGIs und Maps brauchen das einfach nur als eindeutiege Zeichenkette zu sehen. Also keine Panik, die URI brauch nie wieder geparst werden.
Wie gesagt, wuerde das mit dem Daten aus dem olsrd ("denzentrale Map") leider nicht funktionieren. Entweder, dieser muesste auch die MAC-Addressen fluten, oder wie muessten uns zum mergen der Daten etwas anderes einfallen lassen.

Liebe Gruesse
Alina

-- 
Psssst! Schon vom neuen GMX MultiMessenger gehört?
Der kanns mit allen: http://www.gmx.net/de/go/multimessenger

-- 
GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS.
Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : mesh.rdf
Dateityp    : application/rdf+xml
Dateigröße  : 1604 bytes
Beschreibung: nicht verfügbar
URL         : <http://lists.berlin.freifunk.net/pipermail/berlin/attachments/20071202/411dc736/attachment.rdf>
-------------- nächster Teil --------------
_______________________________________________
Berlin mailing list
Berlin at berlin.freifunk.net
http://lists.berlin.freifunk.net/cgi-bin/mailman/listinfo/berlin