[Talk-de] Best Practice fürs Erfinden von Tags

[M∡rtin Koppenhoefer]

Am 31. Oktober 2010 19:47 schrieb Jochen Topf <jochen at remote.org>:
> Die Frage ist mal wieder, was man mit diesen Tags machen will. Beim Namen macht
> es Sinn einen Tag zu haben, weil der Name eines Objektes letzlich nichts anderes
> ist als der Name eines anderen Objektes. Beides sind willkürliche Bezeichner,
> die uns Menschen helfen, auf das Ding zu verweisen. Bei der Eingabe habe ich
> einfach ein Eingabefeld. Beim Erstellen einer Karte, kann ich den Namen einfach
> mal so dazuschreiben, egal, was das Objekt genau ist.
>
> Bei einem "ref" sehe ich das schon anders. Für Straßen gibt es bestimmte
> offizielle Bezeichnungen, die wir im "ref" speichern. Die haben eine
> spezifische Struktur und Bedeutung. Wenn ich jetzt für, sagen wir,
> Bushaltestellen, auch einen "ref"-Tag nehme, weil das ja auch irgendwie eine
> "Nummer" ist, dann bringe ich zwei Sachen durcheinander. Die Bezeichnung der
> Bushaltestelle hat eine andere Struktur, wird von jemand anderem vergeben und
> auf einer Karte anders dargestellt.


das ist doch aber nicht entscheidend, ob der Bezeichner von einer
anderen Stelle vergeben wird oder in einem anderen Format ist. Auch
international ist das ja der Fall bei highways.

Wenn ich einen Tag habe, werde ich den m.E. immer öfter im Kontext
interpretieren müssen, bzw. wird immer klarer, dass das auch jetzt
schon so ist.


> Ganz absurd wird es, wenn es wie im aktuellen healthcare-Vorschlag einen Tag
> "specialty" gibt, der die Art des Mediziners angeben soll, um den es hier geht.
> Aber wenn ich das wiederverwenden will, z.B. mit "specialty=italian" an einem
> Restaurant oder "specialty=football" bei einem Sportverein. Dann habe ich total
> verschiedene Dinge miteinander vermischt.


naja, wie man will. "vermischt" ist da eigentlich nichts. Dein
Programm zur Auswertung muss nur "schlau" genug sein, die
Informationen richtig zu interpretieren.


> Will ich jetzt im Editor eine
> Auswahlbox einbauen, die mir eine Auswahl der wichtigsten Werte erlaubt, dann
> muss ich berücksichtigen, ob ein "heathcare", "restaurant" oder "sports"-Tag
> zusätzlich hier dran ist.


ja, stimmt.


> Schau ich eine Statistik der Werte an, finde ich alle
> möglichen wild durcheinander.


je nachdem, wie die Statistik aufgebaut ist.


> Das Wort "speciality" ist zu generisch, es sagt
> eigentlich nichts aus, außer dass hier eine hierarchische Unterordnung
> stattfinden will. Es wird niemals Sinn machen, die "specialty"-Fälle von
> healthcare und restaurant zusammen zu betrachten, so wie man z.B. im Falle
> von "name" gerne eine gemeinsame Suche hätte, sodass man nach Straßennamen
> und dem Namen von Medizinern suchen kann.


das stimmt zwar, Vorteil ist aber, dass man mit einem geringen
Vokabular (geringer Einstiegshürde) viele und mächtige
Taggingmöglichkeiten hat. Man könnte das allerdings auch erreichen,
indem man die Tags "logisch" aufbaut, also z.B: "healthcare:specialty"
(oder anders rum), restaurant:specialty, ...


> Natürlich gibt es hier keine perfekte Definition, wie man diese Fälle
> auseinanderhalten kann. Es gibt eher einen fließenden Übergang. Vielleicht will
> man einer Brücke einen anderen Namen geben als der Straße darauf, dann wäre ein
> bridge_name nicht schlecht.


in der Tat, oder name:bridge oder sowas. Macht da auch Sinn, weil es
ja durchaus beides geben kann (dass es derzeit Sinn machen würde ist
aber vielleicht auch nur eine Folge aus den unterentwickelten
Brücken).


> Hier hilft es auch, sich zu überlegen, was denn der
> typische, häufige Fall ist und was eher ein Spezialfall.


Ja, das ist sehr wichtig, aber teilweise auch schwierig zu beantworten.


Gruß Martin