I get odd questions like this all the time:
How is a "portal site" different from a "WSS site" different from a "site" in a SharePoint portal different from a Web different from a Subweb different from an Area? And by the way, what's a Topic?
I was asked by several people to share one of my recent replies to just such a question here on my blog (sorry, no pictures).
First, when discussing SPPT, please do not use the term "site". Ever. You don't need it, really.
The SPPT documentation, screens, and API are far too ambiguous regarding the term "site". Examples follow:
- The portal Site Collection and all of its Areas are referred to as a "site",
- An Area is sometimes referred to as a "site",
- The default location for new top-level Webs in a Sites Directory area initially called Sites is in a Managed Path called "sites" and its characteristics are kept for grouped display in a WSS list in the Sites Area called "sites",
- A WSS Site Collection is often referred to as a "site" (e.g. team site - don't even get me started about Workspaces which are just Webs that can be created from within the Office client),
- The top-level Web in a Site Collection is commonly referred to as a "site",
- A Subweb is often referred to as a "site",
- The API object SPSite is called a "site" but so is the API object SPWeb.
Help me stop the madness...
- Start with a SharePoint Server Farm
- A Server Farm can have one or more Virtual Servers (IIS Web Sites)
- A Virtual Servers must have one or more Managed Paths (including the root)
- A Managed Path can have one or more Site Collections
- A Site Collection must have one or more Webs (or Areas)
- A Web can have one or more Lists but can also have one or more Subwebs
- An Area is a special Web created for use only with SPS
- A Listing is a special link create for use only with an SPS Area
- A List can have one or more ListItems
- A ListItem must have one or more Fields
Of course, there are other hierarchies (Virtual Servers have Content Databases, Libraries are a subclass of a List with Files and other functionality like events, etc.) and other concepts (Excluded, Explicit Included, and Wildcard Included Managed Paths, the collection of Site Collections in a Virtual Server, etc.) but let's at least all agree on the terms listed above. I realize that the cardinality and optionality of the above relations could be nit-picked, but they represent the most common configurations.
I commonly say,
- "A Site Collection is a collection of Webs (or Areas)."
- "A Web is a collection of Lists (and Libraries) and the pages to manage them."
These are the two scope boundaries that you should be most interested in. Everything in SharePoint revolves around them.
I know that the SPPT user interface uses the term "site" and sometimes even "portal site" with reckless abandon but we, the SharePoint community, can stop the madness.
That said, when you see the term "portal site" in SPS administration, SPPT really means the Site Collection of Areas (think special Webs). An Area is just a WSS Web based upon a unique Site Definition that leverages special SPS metadata, SPS Web Parts, and SPS administrative screens.
When you create a "site" on the SPS Sites Directory Area, SPPT really creates a top-level Web in a Site Collection located in a Managed Path typically called sites.
Remember, SPS is a product built on top of the WSS platform (C# notation follows).
- "SPS == Product"
- "WSS == Platform"
So, while a "portal site" is radically different from a "WSS site", it isn't because a WSS Web in a portal is any different than a WSS Web in any other context. They are different because of the ambiguity in the term "site".
Oh, and one last thing, a Topic is just one of the seven kinds of SPS Areas. So, you cannot use a Topic Area anywhere in WSS. It can only run within a portal.
HTH,
<Todd />