Closed StilgarBF closed 9 years ago
Genau das war auch mein Vorschlag! Nach längerer Diskussion auf der WebTeam Mailingliste hat sich die Mehrheit aber dagegen entschieden. Hauptgrund: Man möchte keine weitere Komplexität und Abhängigkeiten in der API - Die API soll flach und einfach bleiben! Man nimmt lieber die Komplexität in den Tools in kauf um das Verzeichnis einfach zu halten. (Außerdem sind Metacommunities wohl an sich nicht sonderlich "gewünscht" und deren Bildung soll daher wohl auch nicht gefördert werden.)
Der bevorzugte Ansatz für Metacommunities ist nun lokal ein Meta-File zu pflegen und dann in die einzelnen Sub-Communities reinzumergen. Sowas machen z.B. wir in Franken. Dadurch sind alle Infos in Allen Communities enthalten. Die entsprechenden Tools (Maps, Timelines, Feed-Aggregatoren usw.) müssen dann intelligent genug sein das zu erkennen und entsprechend zu behandeln. Zur untersützung gibt es das Tag "metacommunity".
(Ich halte die Entscheidung immer noch für unschön. Müssen wir Tool-Bauer jetzt aber mit leben...)
Ok, dann weiß ich Bescheid und werde das Mapping auch in der Karte umsetzen.
Vielleicht liegts auch am Namen Metacommunity suggeriert, dass sich Communities zu etwas zusammenschließen. Tatsächlich ist es aber in den häufigsten Fällen eher so, dass sich in den Communities lokale Gruppen bilden, die die Technik der Community nutzen, sich aber selbst representieren wollen. Metcacommunity vs subcommunity. aber ich will hier keine Diskussion führen - ein Ticket ist ein Ticket ist ein Ticket :-)
Am Donnerstag, den 29.01.2015, 02:25 -0800 schrieb Tino Dietel:
Ok, dann weiß ich Bescheid und werde das Mapping auch in der Karte umsetzen.
Vielleicht liegts auch am Namen Metacommunity suggeriert, dass sich Communities zu etwas zusammenschließen. Tatsächlich ist es aber in den häufigsten Fällen eher so, dass sich in den Communities lokale Gruppen bilden, die die Technik der Community nutzen, sich aber selbst representieren wollen. Metcacommunity vs subcommunity.
es gibt doch den Collector: https://github.com/freifunk/common.api.freifunk.net/tree/master/collector Den kann man doch so erweitern, dass er neben dem flachen summarized Directory auch ein anders strukturiertes auswirft, gruppiert z.B. nach dem Feld Metacommunity.
Dann liegt die Komplexität nicht in den Tools, sondern lediglich in einem Tool.
Grüße
Andi
Am 29.01.2015 17:25, schrieb Andi:
Dann liegt die Komplexität nicht in den Tools, sondern lediglich in einem Tool.
Die Idee ist gute - sollten wir machen - Bleibt aber das Problem, dass man nicht weis welche der Felder zur MetaCommunity und welche zur SubCommunity gehören.
Beispiel:
Welche URL gehört zur Meta-Community?
Ergebnis:
Is halt suboptimal...aber schaffen wir schon!
wäre es sinnvoll den Metacommunities ein eigenes Verzeichnis zu geben? Aktuell wissen wir zwar welche Gruppen sich welcher Meta zuordnen, es fehlen aber Informationen zu diesen. Webseite, Ziele, Region, Focus, Dienste, Kontakt etc
Da es deutlich weniger Metacommunities geben wird als gruppen könnte es vielleicht sogar Sinn machen ein entsprechendes extra file nicht analog zum community-file mit verweisen auf externe Files aufzubauen, sondern alles im Metacoomunity-file zu führen? Weil stark dynamische Daten gehören da sicher garnicht rein.
Eine flache Struktur mit den wichtigsten Daten wäre vorstellbar, als Key ein eindeutiges Kürzel, das dann auch wieder in den Community-files verwendet wird.
Konkret fällt mir bei der Freifunk-karte auf, dass ich die Gruppen zwar in ihrer Metacommunity zusammen fassen kann, dann aber keine Information habe, welche Webseite nun für jene Metacommunity führend ist. Das ergibt dann, dass ich im Rheinland großflächig bei den Knoten zu falschen Webseite verlinke.