Talk:Key:website

From OpenStreetMap Wiki
Jump to: navigation, search

Simple vs. specific URLs

I object to the recommendation against using specific URLs. They might last longer, but could in many cases make the whole URL more or less useless. Consider the case of hiking route relations: A hiking route relation describes a hiking route, so defined often my a destination company or hiking association. An example is this URL http://www.hovden.com/no/TellusView/?&TLl=no&TLp=564065 which points to a page about that specific route. The simple URL would be http://hovden.com. If you go to the latter, you could spend quite some time trying to find the information you want, while if you go to the first you get there instantly. --Dittaeva 16:26, 22 February 2012 (UTC)

As far as I am concerned, this recommendation means that you should choose simple URLs over complex URLs if they basically point to the same content. So for example, you would use http://www.bahn.de instead of http://www.bahn.de/p/view/index.shtml, because while both get you to the front page of that website, the second variant depends very much on the current implementation of their site and doesn't add any maningful information. --Tordanik 17:13, 22 February 2012 (UTC)
I see. I'll try to edit it to reflect your understanding of it which does make sense. --Dittaeva 10:23, 23 February 2012 (UTC)

separating multiple values with space

hi,

it seems reasonable to to divide multiple values not with a semi-colon in this case but with a space. I just tried it and was surprised that it actually already works on osm.o: (see Node 1941952571 (XML, Potlatch2, iD, JOSM, history))

--Shmias 22:42, 1 October 2012 (BST)

Multiple values are unnecessary for a website tag, though, because it is meant to contain "the official website". This might be a useful suggestion for Key:url. --Tordanik 12:50, 2 October 2012 (BST)

as far as I can see, this feature is deprecated. I also had a problem with multiple values because urls are usually long and values may not be longer than 255 characters. does anyone have a better idea where to place that stuff? --Shmias 10:44, 3 October 2012 (BST)

We shouldn't encourage crippled URLs

I really don't like the idea of omitting the http:// because it cripples the URL. The article should not written in a way that users may be encouraged to omit the "http://" (or "https://"). Remember, the string is not neccessarily the same string which is presented to the user, it is stored in a file, waiting to be processed by software. There are quite some programs which expect to parse URLs. Not crippled URLs, almost-URLs or "urls without the scheme"[1]. The good thing about URLs is that most programs already understand how they work; no extra code has to be written. . The purpose of an URL is to get munched by a program directly. It is generally a bad idea to require applications to give OSM a "special treating" because there has to be extra code just because OSM doesn't give a damn about Internet standards. What comes next? Suggesting to drop the "www."?

There should be at least a pointer to RFC1738 section 3.1, section 3.3 (for the http scheme) and RFC2818 section 2.4 in the article for reference. (Update: I just did it anyways --Wuzzy 23:44, 28 November 2012 (UTC)) And there should be a clarification that the value should be a valid URL. You really need only to read these three relevant sections to understand URLs and these are rather short. You don't even need to fully understand URLs to use them: Just copy the frikking address bar of your browser! Nothing can be easier than that. ;-)

I know at least one program which interprets the value always as an URL and fails badly if it is not an URL. It is a plugin in JOSM which adds an entry to the context menu for the website tag. I think this plugin does it absolutely right, and this definition made it wrong.

Here's my suggested new definition for the website key:

Just copy the frikking address bar of your browser! ;-)

I personally consider it an error if I encounter a "website" tag without the proper scheme. I always add the scheme in front of it, check if it works and if it does, I upload the change, if it doesn't, I remove the website key. By the way: Is there any quality assurance tool in the wild which checks URLs for (syntactic) validity?

If there are no serious objections within a week, I would change this wiki page in a way that it clearly expresses that only full URLs should be used and not crippled ones. I also would remove the "no scheme if http" exception then. --Wuzzy 23:15, 28 November 2012 (UTC)

  1. Oh, by the way, it is wrong that that "http://" is the scheme, like the article says. "http" is the scheme, because ":" is a seperator and "//" is the start of the common Internet scheme syntax


Disagree with the suggested "Just copy the frikking address bar of your browser!" definition because of the #Simple vs. specific URLs issue. But otherwise, yes, the http:// should imo be included in the value. I've always read that section as a suggestion to application authors for a potentially useful fallback, not as a guideline for mappers. So I would support a clarification in that direction. --Tordanik 17:03, 29 November 2012 (UTC)
Okay, my friends. The time is over! I just removed the section in discussion, with respect to Tordaniks little objection. --Wuzzy 20:27, 6 December 2012 (UTC)
If this would be a generic URL field I would fully agree, but it is not. It is a tag to specify a website. Apart from the very, very few websites that can only be reached via https all of them use http. Adding the protocol does not give OSM any advantage and is redundant. The argument of "some software" that needs to parse URLs is also invalid. The content of the field are not full URLs, so no URL parser is to be expected to be able to parse it. A scheme of "crippled" URLs (they are not URLs actually, the wording is wrong) are used for wikipedia articles too and works very well and has been so for a long time. The removal of the section explaining all this (IIRC) and abandoning the scheme by a single user is... at least impolite, Wuzzy. --Stefanct 23:01, 13 January 2013 (UTC)
The old definition (before I touched it) was too ambigious. I am aware that https-only websites are rare but https-enabled websites are not. Even Google has HTTPS! And if I have the choice between the HTTPS and the HTTP version of a certain website, I’d rather link to the HTTPS version (except when it’s broken). And there are way more HTTPS-enabled websites than you’d believe, so I don’t think that HTTPS is a strange side case. Don’t believe me? Look at HTTPS Everywhere! Also note that the old definition in fact already included the abbreviation “URL” some times, so one may legitimely think to use a full URL as value. On the other hand, the definition allowed to drop the “http://” part. This was a contradiction, so the definition HAD have to be changed. I chose full URLs because URLs are very common and standarized. I call the other definiton “crippled” URLs because the definition implied (sort of) that one could “omit the ‘http://’ part”. Sorry, but this sounds very much like “URL without schema”, I fail to see how this definition does not relate to URLs. My software argument is not invalid. The big advantage of strictly using full URLs only for this scheme is a software may not have to parse the URL at all, it could simply blindly give the value to a browser (for instance). I also don’t think it a good practice to mix well-defined standarized URLs with “crippled” URLs (or call them “non-URLs” or “strings that look like URLs but aren’t” or whatever).
The wikipedia argument is a false analogy because the wikipedia tagging scheme is not even similar to an URL, because the common format is "lg:Pagename" with lg=language code and Pagename=name of page (usually with spaces). You never have real spaces (read: unencoded) in an URL and the “:” character has a completely different meaning in URLs. Most important, the wikipedia scheme is clear and unabigious, therefore I didn’t touch it.
In my view, the current definition is clear and unabigious. The old definition was ambigious. Someone had to change that. I hoped some more people would discuss with me but only one was interested who also agreed on the important part, then I got tired of having a ambigious definition and just went on. Yes, I may be bold. But be bold is a common wiki motto. And I didn’t simply edit, nope, my edit was based on a rational decision. As there are still no serious counter-arguments (I just have dismantled your counter-arguments.) after about one-and-a-third months, I do not regret this decision.
If you are still not convinced, please keep in mind that a simple revert would not help, because you’d revert to all the problems the old version had. --Wuzzy 20:48, 17 January 2013 (UTC)
+1. The Protocol belongs into the tag value. I would even suggest to prefer specifying HTTPS whenever the website supports it. Well maybe except for self-signed certificates but that is a tricky question anyway.--Scai 09:29, 18 January 2013 (UTC)

Deprecate this tag when it is used to provide contact information in favor of contact=*?

Reason: contact=* is more clear and precise way to link URL with world/POI objects. Xxzme (talk) 06:52, 20 July 2014 (UTC)

When I look at the relative popularity, I think it makes much more sense to deprecate contact:website. --Tordanik 14:06, 20 July 2014 (UTC)
Yes but you look it in wrong way. contact=* is not single tag but group of tags, to compare them fairly you have to sum all contact tags vs something. You have to use website=* 3 times vs there precise ways of contact contact:twitter=* contact:facebook=* contact:webcam=*. Contact is not limited to websites. IMO website=* should be deprecated when it is used to provide contact information, contact=* does this job better. Xxzme (talk) 06:50, 22 July 2014 (UTC)
Alright, if you want to look at contact as a group, let's compare the full range of contact keys:
no prefix contact:*
website 551 879 43 154 [1]
phone 363 319 66 195 [2]
email 69 684 25 787 [3]
fax 47 138 17 807 [4]
facebook 778 849 [5]
twitter 372 236 [6]
webcam 58¹ 213 [7]
sum 1 033 228 154 241
¹ I used url:webcam here
I don't think this looks better for the contact keys. Except with the rarely used facebook and webcam keys, the usage counts are clearly in favour of the alternatives. --Tordanik 18:52, 25 July 2014 (UTC)
Well, okay, they are 10 times more popular. But again, my point is still valid. Contact: namespace is precise way to specify information linked with phone number or facebook page. Some of phone=* values are not contact phones, but emergency phones. I personally use delivery: namespace to specify delivery phone (quite often this is different from contact phone where you can book table). To avoid confusion we need to use namespaces for each purpose, contact: is just one of them. Xxzme (talk) 05:06, 19 August 2014 (UTC)
Most phone numbers are contact phone numbers. It makes much more sense to use emergency:phone for a exception. Also if you care that much about contact then you should remove 50% of the Social Media pages, because you can't actually reach most businesses that way. --AndiG88 (talk) 20:49, 21 October 2014 (UTC)