rev="canonical"

[Anon]

http://shiflett.org/blog/2009/apr/save-the-internet-with-rev-canonical
http://revcanonical.wordpress.com/
http://simonwillison.net/2009/Apr/11/revcanonical/

Siehe auch: rel="canonical"

[Felix Riesterer]

Lieber Anon,

da finde ich doch die erste kritische Stimme gleich auch die vernünftigste... vor allem in Hinblick auf die Inkompatibilität zu HTML5 - auch wenn das jetzt kaum interessiert.

Liebe Grüße,

Felix Riesterer.

[molily]

Hallo,

warum sollte man URIs überhaupt abkürzen?

Mathias

[Beat]

warum sollte man URIs überhaupt abkürzen?

Um Spamfilter zu entkommen.

mfg Beat

[molily]

warum sollte man URIs überhaupt abkürzen?

Um Spamfilter zu entkommen.

Na, in erster Linie werden diese Dienste auf Twitter benutzt, weil die URI Twitters allgemeiner Text-Längenbegrenzung unterliegt. Sie eignen sich dort natürlich auch vorzüglich, um die URI zu verschleiern und Leute auf Sites zu locken, die sie sonst nicht besuchen würden. Man weiß selten, wo es einen hinführt, wenn man einen solchen Link klickt. Und Linktexte gibts im Twitterland auch nicht. Ein üblicher Tweed sieht eher so aus: »Das ist hier ist lustig: http://short.url/xyz«

Dass man jetzt endlich merkt, wie beknackt die Sache mit den Short-URIs eigentlich ist, ist begrüßenswert. Aber genauso dumm ist es, irgendwelche technischen Gegenmaßnahmen zu ersinnen, die die Symptome behandeln. Man braucht, soweit ich das überblicke, im Web keine Short-URIs, sondern gute, sprechende URIs. Short-URIs braucht man nur, wenn die URI-Länge einer künstlichen Begrenzung unterliegt, wie etwa bei Twitter. DAS ist ein Fehler von Twitter, ein von Twitter geschaffenes Problem, dieses Problem wäre dort, bei seiner Ursache, zu lösen. Nicht die URI-Länge ist ein Problem, sondern diese Zwangs-Begrenzung, dass man Text plus URIs in 140 pressen soll (und alle darauf abfahren, es zu tun). Diese hat, wenn man recht darüber nachdenkt, keinen Vorteil. Aber dutzende Nachteile, die den Leuten jetzt nach und nach auffallen... Als hätte man darauf nicht vorher kommen können.

Mathias

[Beat]

Na, in erster Linie werden diese Dienste auf Twitter benutzt, weil die URI Twitters allgemeiner Text-Längenbegrenzung unterliegt.

Nicht nur die URI, sondern die ganze Message. Bei sprechenden Links würde einfach nichts mehr ausserdem existieren, damit Twitter eigentlich noch überflüssiger, als es eh schon ist. (Ich erinnere mich da mal ein gegenteiliges Beispiel indiziert zu haben.)

Sie eignen sich dort natürlich auch vorzüglich, um die URI zu verschleiern und Leute auf Sites zu locken, die sie sonst nicht besuchen würden.

Ja aber das ist nicht ein twitter Problem, sondern ein TinyURL Problem. Denn mit soclhen Diensten kannst du irgendwo, nicht nur auf Twitter, anonymisierte Links auf Drive-By-Downloader Sites anbringen.

Man weiß selten, wo es einen hinführt, wenn man einen solchen Link klickt.

Das ist allerdings in der Natur von URLs selbst begründet. Das einzig verräterische ist die Domain. Was immer dahinter liegt, lässt sich vom Domaininhaber ja on the Fly generieren/intern umleiten.

So gesehen ist nicht der lange Pfad das Problem, sondern eine langer Domainname. Ode halt doch: Links auf Domains, die nicht unter deiner Kontrolle liegen.

Und Linktexte gibts im Twitterland auch nicht. Ein üblicher Tweed sieht eher so aus: »Das ist hier ist lustig: http://short.url/xyz«

Hmm, wenn mir die Messagelänge egal sein kann, kann ich natürlich jede Kunst anwenden, dass auch lange Urls informativ aber überschaubar kurz bleiben. Genau dies steht bei Twitter ausserhalb des selbst definierten Betriebsmodus.

Dass man jetzt endlich merkt, wie beknackt die Sache mit den Short-URIs eigentlich ist, ist begrüßenswert. Aber genauso dumm ist es, irgendwelche technischen Gegenmaßnahmen zu ersinnen, die die Symptome behandeln. Man braucht, soweit ich das überblicke, im Web keine Short-URIs, sondern gute, sprechende URIs.

Kleingedrucktes am Fuss von TinyUrl
"TinyURL was created as a free service to make posting long URLs easier, and may only be used for actual URLs. Using it for spamming or illegal purposes is forbidden and any such use will result in the TinyURL being disabled and you may be reported to all ISPs involved and to the proper governmental agencies. This service is provided without warranty of any kind."

Was bedeutet "all ISPs involved"? Das ist doch nur dann realistisch, wenn alle ISPs sogenannte TinyURLs speziell loggen, bevor etwas geschehen ist. Im Nachhinein ist ja nicht verifizierbar, wer jetzt alles einen faulen Link dort geklickt hat.
Das klingt für mich wie ein "Ich bin 18, Ich darf Eintreten" Button.

Item. Tiny-URLs werden nicht gepflegt. Man betrachtet sie als Wegwerf-URLs, und es würde mich nicht überraschen, wenn viele dieser URLs vorschnell verwaisen und somit ein Müll-Netz hinterlassen. Das tolle am social net ist ja, dass der Müllmann immer der andere ist.

Der Weg zu andauernden URIs führt meiner Meinung nach schon über die Entkoppelung der publizierten URI gegenüber der/den Adresse/n der verwendeten Ressourcen. Es liegt da da in der Eigenverantwortung der Betreiber, dass sie sich ihre Tabellen von unique URIs generieren und diese verwalten. Wenn man hier klug vorgeht, sehe ich keinen Widerspruch zwischen kurzen Pfaden und sprechendem Pfad-Inhalt.

Short-URIs braucht man nur, wenn die URI-Länge einer künstlichen Begrenzung unterliegt, wie etwa bei Twitter. DAS ist ein Fehler von Twitter, ein von Twitter geschaffenes Problem, dieses Problem wäre dort, bei seiner Ursache, zu lösen.

Die Problemlösung beinhaltet die Abschaffung von Twitter, weil es nun mal an die SMS Messagelänge gebunden ist.

Nicht die URI-Länge ist ein Problem, sondern diese Zwangs-Begrenzung, dass man Text plus URIs in 140 pressen soll (und alle darauf abfahren, es zu tun).

Genau. Aber da hatte jemand mal eine "geniale" Idee, wie man noch mehr social über das handy sein kann... Da scheint ein viel tieferer Kulturkonflikt zu bestehen. Die URI-Kürze ist nur ein Kolateralschaden.

Diese hat, wenn man recht darüber nachdenkt, keinen Vorteil. Aber dutzende Nachteile, die den Leuten jetzt nach und nach auffallen... Als hätte man darauf nicht vorher kommen können.

Jaja. Ich frage mich auch immer, warum man zuerst 16bit, dann 32bit und heute 64bit Architekturen baut. Sind doch alles irgendwie beschränkte Modelle. irgend wann wird jemand auf die idee kommen, dass es gar keine solche binäre Festlegung braucht.

mfg Beat

[Jens Holzkämper]

Tach,

Jaja. Ich frage mich auch immer, warum man zuerst 16bit, dann 32bit und heute 64bit Architekturen baut. Sind doch alles irgendwie beschränkte Modelle. irgend wann wird jemand auf die idee kommen, dass es gar keine solche binäre Festlegung braucht.

nö, das Problem ergibt sich bald von selbst, schon mit einer 256-Bit-Architektur könnte man bequem alle Atome des Universums einzeln adressieren.

mfg
Woodfighter

[hotti]

Moin!

http://shiflett.org/blog/2009/apr/save-the-internet-with-rev-canonical
http://revcanonical.wordpress.com/
http://simonwillison.net/2009/Apr/11/revcanonical/

Siehe auch: rel="canonical"

Und Wozu soll das gut sein???

Hotte

[Cybaer]

Hi,

»» Siehe auch: rel="canonical"
Und Wozu soll das gut sein???

Damit auch *die* Webseitenbetreiber gute, lesbare URLs in den Suchmaschinen (und damit im Bewußtsein der Surfer) haben können, die mit den "normalen" Mitteln des Webdesigns (Nachdenken und ggf. gute CMS') dazu nicht fähig waren.

Gruß, Cybaer

[Beat]

»» Siehe auch: rel="canonical"
Und Wozu soll das gut sein???

Damit auch *die* Webseitenbetreiber gute, lesbare URLs in den Suchmaschinen

Meinst du das kleine grüne?
Ich interessiere mich da doch lieber für das kleine schwarze.

mfg Beat