Talk:Stone tool

Mesolithic + Microliths

Ok, this article has references the the paleolithic and neolithic, but we are missing the Mesolithic and notes on microliths. Unfortunately I don't know much about them, someone else care to fill the article out? (Thefuguestate 09:09, 18 February 2006 (UTC)

I am doing a project and i need to make a early man tool and then write about it. can anyone give me some ideas?

Merge proposal

Flint is the earlier chipped tool, so deserves a separate article. However, it needs expansion, as the above comment shows. Stone axes is a wider topic, but also needs separate treatment. Peterlewis (talk) 05:54, 6 June 2008 (UTC)

merging

search "mineral", stone and flint do NOT have the same definition. flint has properties stone does not. this is important when doing field studies. when I search stone tools I do not want to see flint tools. they should be seperate.Whitefox921 (talk) 03:47, 7 October 2009 (UTC)

I am concerned over this merge and redirect

In June 2009 someone redirected tool stone to [[Stone tool#Tool stone]], with the edit summary "merged to Stone tool. Looks better in context." The redirector placed a {{mergeto}} back on stone tool. But when one places a {{mergeto}}, they are also supposed to place a {{mergefrom}}. And they are supposed to initiate a section on the talk page of the target article, explaining why they think the merge is a good idea. The contributor who merged this material didn't do either of those things.

I am concerned over this apparently unilateral merge for both reasons specific to this instance, and on what I regard as very serious general grounds about this kind of merge. Geo Swan (talk) 14:01, 3 October 2010 (UTC)

Specific objections to merging tool stone to stone tool

When one checks Special:WhatLinksHere/Tool_stone one sees close to a dozen articles target [[tool stone]].

What I found when I started to check those article that have wikilinks to tool stone is that the first three I looked at used both stone tool and tool stone in the same sentence. Obviously the authors of those other articles thought that stone tool and tool stone were separate topics. Ground stone had wikilinks to both stone tool and tool stone in its very first sentence.

I think anyone who checks with our actual readers will find that it is very annoying for readers to click on one link, and be taken to a different article. Imagine someone reading one of these articles, like ground stone, or knapping, wanting to know more information, first clicking on stone tool, reading it, then clicking the back button, and then clicking on tool stone. What is their reaction? "Why didn't I just read this in the other article?"

I think this merge should be reversed for this reason alone. Here are the first three articles I checked. Geo Swan (talk) 14:01, 3 October 2010 (UTC)

article	context
Ground stone	In archaeology, ground stone is a category of stone tool formed by the grinding of a coarse-grained tool stone, either purposely or incidentally.
chert	In prehistoric times, chert was often used as a raw material for the construction of stone tools. Like obsidian, as well as some rhyolites, felsites, quartzites, and other tool stones used in lithic reduction, chert fractures in a Hertzian cone when struck with sufficient force.
knapping	For stone tools and flintlock strikers, chert is worked using a fabricator such as a hammerstone to remove lithic flakes from a nucleus or core of tool stone.

General undesirability of wikilinks that target subsections within other articles

Wikilinks to subsection headings are widely used in the wikipedia namespace, and for historical reasons they will likely continue being used there. Wikilinks to subsection heading are lightly used in the article name space, and, if I had my way, this practice would be discontinued. If a topic is worthy of a wikilink, it is worthy of an article of its own.

Wikilinking to subsection heading is only partially supported by our underlying wikimedia software. A reader can follow wikilinks to subsection headings, by clicking on them. But other key features of wikilinks are not supported when the target is a subsection within another article.

The wikimedia software supports the very useful watchlist feature. But the granularity of our watchlists is whole articles. We can't put a subsection of an article on our watchlist. When a small article, that was capable of standing alone is merged to a larger article, then we degrade the value of the watchlists of everyone who was watching either of those two articles. When they were separate articles interested readers had four choices. Now they are reduced to two choices. And if they previously had just one of those articles on their watchlist, and they choose to continue to watchlist the merged article, they will get advised of lots of changes that are not of interest to them.

The Wikimedia software's redirect feature provides huge advantages over the unidirectional links of the regular world-wide-web. On the regular world-wide-web when the author of a web page changes its name they will irrevocably break all the existing links to that page. And they have no reliable way of knowing if lots of external pages link to their page, or whether no external pages link to their page. Wikimedia redirects transparently fix this enormous disadvantage of regular web links -- provided our wikilinks are article to article wikilinks. When an wikilink targets a subsection heading within an article it too will break if the subsection heading is removed or renamed. And the contributor who innocently removes or renames a section heading will have no way of knowing they are breaking wikilinks. This is highly undesirable behavior.

The wikimedia software's "what links here" feature is a powerful, and unfortunately underappreciated feature. When one is reading new articles, incomplete articles, and one finds that the last article they arrived at does not contain the information they were looking for, they can click on the "what links here" button. Often the articles that link to the current article will have the information they seek, or will link to other related articles that have the information they seek. The excessive urge to merge seriously degrades the value of the "what links here" button. I am a fan of the original UNIX design philosophy, of the original Research UNIX crowd at Bell Labs in the 1970s, as set out in the books coauthored by Brian Kernighan. He wrote that every tool should be small and focussed and do just one job, but do it well, and rely on the UNIX interprocess communication tools, to string together tools to do more complex tasks. I think a similar design philosophy should apply to wikipedia articles. In general, wikipedia articles should be small and focussed, and cover just one topic. When they are small and focussed and cover just one topic their "what links here" list is most useful, as everything on that list should be related to the one topic of the article. But when the "urge to merge" prevails looking at the "what links here" button gives a lot of false positives -- articles that link to the merged article that aren't related to what the reader is looking for because the article is no longer covering just one topic.

What I think mergist fail to appreciate is that it is easier for a reader to get to information that might be useful to them by clicking on a link, than by scrolling, or searching within the current article. If you scroll of search with an article you lose your place. When you click on a link, if the information is not what you want, you click the back button, and you are right where you started out.

Some old jazz guy said that the important thing about jazz was the space between the notes.

Similarly, the important thing about understanding the real power of the wikipedia is to appreciate that the links between information is at least as important, if not more important, than how well written our prose is. I believe a wikipedia full of poorly written prose, but richly linked, would be more useful than one full of professionally written prose, that was poorly linked.

Mergists sometimes defend their "urge to merge" with assertions that, "relax, all the important information" is still in the wikipedia -- it is just in one place, making it easier to find."

Anyone who ever worked with an old-fashioned database, one that could crash, and be inoperable, who had a boss who really needed one crucial piece of info from that database will appreciate how important our links are. I had occasions when I had to take my calculator, and my hex editor, and page through a crashed database.

Over and above the specific reasons why this redirection concerned me there is a very serious general concern I have with redirections of this sort.

Have you considered what makes the wikipedia more powerful and more useful than any paper encyclopedia? It is not that the wikipedia is vastly larger than any paper encyclopedia. The power of the wikipedia is due to several features:

1. The wikipedia is richly interlinked;
2. Unlike old-fashione www links, wikilinks are bidirectional;
3. Unlike old-fashione www links, wikilinks, when used properly, don't break when the link target is renamed;
4. Unlike old-fashione www links, with wikilinks one can determine exactly what articles link to the current article;

The importance of rich interlinking is that the size of the wikipedia would be irrelevant if the wikipedia's rich interlinking didn't make it easy to find the information one wants. Geo Swan (talk) 14:01, 3 October 2010 (UTC)

• Support merge. Geo Swans objection seems to be based on. (a) Tool stone is a topic on it's own. (b) Wikilinks to sections are in his oppinion bad due to limitations in the software. No one is claiming that tool stones isn't a topic on it's own, but it's a topic that in my opinion is better treated in the article on Stone tool. This can, and very well might, change as more content is added to the either topic. Point (b) is best adressed at the village pump, since it calls for discontinuation of section linking on a project wide scale. I disagree with Geo Swan on this point, feeling that section links, where appropriate, is a better solution than seperate articles. The reason for this is that with seperate articles there is a continual need to keep the articles in sync. Also several topics, Tool Stone included, is better treated in an article that provides the context. Finaly, in general, when the article becomes big enough that scolling causes a reader to lose his place then articles should be spun out. I do not see that this is the case with Stone tool. Taemyr (talk) 14:38, 3 October 2010 (UTC)

Mode 3...?

The link discussing Mousterian "Mode 3" lithic technology points to a telephone protocol. I can say with fair certainty that this is not the correct link location, but I do not know where it was intended to point. This is problematic. 129.93.158.62 (talk) 16:56, 12 October 2010 (UTC)