page is a misnomer, should be called article

[WardCunningham]

The implementation of this wiki would be easier to follow if the word article were used in place of almost every reference to page. Although the original wiki spoke of pages, Wikipedia prefers the more accurate term, article. For good reason. Article refers to the creative work, page refers to a medium upon which it might be delivered. Since we deliver multiple articles on a single web page, this misuse of terms is especially confusing. See also:

• Article-Page Pattern
• http://en.wikipedia.org/wiki/Article_(publishing)

I suggest wholesale replacement of the one term with the other in our code, in the file hierarchy and in our ongoing conversation.

[SvenDowideit]

Wikipedia is imo rarely a good example of all the different uses a wiki can have.

take for example this 'issue' - it feels pretty awkward to call it, and this discussion an Article, though still valid by Wikipedia's definition

http://dictionary.reference.com/browse/article - says 'a written composition, usually written in prose' (which sounds like a reasonable elevator definition) - which is much less than a 'page' in a federated wiki might be - I'm likely to have an shopping list, expense report, a image and its meta data, or even a definition for a custom item type in my wiki..

I thought page was a good compromise name for something i've called a 'topic' forever (with the accompanied awkward feeling) - as the way we're using the Miller columns evokes a UI metaphor of a 'page' of information for me.

[SvenDowideit]

one possible idea for naming is to put together the full vocabulary - right now, we're missing some of it

we have a wiki contains several pages that are made up of several items, with a possible view being one or more pages

should we change it to: a wiki server (should we call it a library :)) can contain one or more books/magazines/collections/??? (views) made up of one or more articles, which are compositions of paragraphs of different types?

I'm not totally a native english speaker, but to me Article is to narrow - but I do like what its made me think of:

I'm interested in how to render Foswiki's DataForm defintions and data sets. in Foswiki, each structured data entry (for example, one persons's contact details) would be stored in a separate topic, which doesn't map well to the initial way most people enter that kind of data - in a wiki table, one person per row. This awkwardness suggests that I've got something backwards in the previous comment.

SORRY - MORE LATER, KIDS WAKING FROM NAP.

[WardCunningham]

Since raising this issue, i've been careful to say "web page" or "wiki page" where there might be confusion. I'm hesitant to make a wholesale conversion to article unless we agree it is a good idea.

See also Concepts where I emphasize preferred terminology.

[SvenDowideit]

as you can see, I'm (sanitizing) a stream of consciousness, but as its been a few hours, rather than editing, I'll continue here :)

In my mind, I think I have some added confusions.

first up, I do not make the presumption that what is today a '(wiki) page' is the base container for an addressable thing. I've convinced myself that I should try a refactoring, where 'page' is is a plugin type, like 'paragraph' and 'image' (and 'journal' should be).

additionally, imo, each 'item' (which is thus the pure base data type) should be addressable, though its likely that most will not be addressed by users particularly often.

I got to the point (when I stopped) where I figured that it might make sense to call what Wikipedia strives for an Article specifically because they strive (in the ideal sense) for a static (what i call legacy) document that covers the topic fully and hopefully permanently - but this is none the less only one type of wiki page.

yup, I can't actually make up my mind, I just thought it might be useful to share my thoughts :/

[WardCunningham]

I did a video where "A visualization on one page can find data on another." I did this by looking for chart items in the dom. The code looks like this:

  wiki.getData = ->
    $('.chart,.data').last().data('item').data

This "associative" addressing of story items seems pretty loose but actually feels great and demos well. I'd like to make it sensitive to the shape of the dataset and have it look through the visualization's own wiki page first. That way if it isn't finding the right data you can just drag the data "under its nose".

[WardCunningham]

In the code, we'll say page to refer to a wiki page. In general discussion, we should say web page or wiki page to avoid confusion.