In your example, your portal site  and sub-sites are all part of a single site
collection. The site collection  term can be a little misleading, but it can
actually refer to just one top level site.

I have understood that the root site  and the subsites
below that are one site collection. But can a stie
collection can have one or more site collections  with
in that root site collection?

No, a site  collection only refers to a single top-level site. Any corresponding
sub sites  are still part of the same site collection.

That's correct.

However, it is possible to create separate site  collections that
(from a URL perspective) look like they are "underneath" another
site collection, by creating an explicit inclusion managed path in
central administration.

This is not scalable for large numbers of sites, mainly because of
the admin overhead. But you could use it to have (say) a
portal "home" at http://ourintranet with 4 or 5 departmental site
collections underneath at http://ourintranet/finance,
http://ourintranet/hr etc.

Really? I'm slightly confused then too. Say I have a main portal  at
http://intranet.domain.com. That's the main corporate portal. Each division
wants to have a unique site  collection. So I go into central admin and make
a named path of /divison. Then from central admin I create a site collection
for our manufacturing division at intranet.domian.com/division/manufacturing.

Functionally, manufacturing works as a top-level site, but it's still under
the corporate portal path. As opposed to being a new web application at
http://manufacturing-intranet.domain.com.

I'm sure I'm just still a little unclear on what the accepted definition of
"top-level site" is in sharepoint parlance, but anything at a url  below the
domain seems like it's not a top-level site to me.

The term top-level site  is always confusing which is why I try to avoid
it.

Let me take a shot at this.

All site collections  hosted by an application are equal regardless of
where they appear in the URL.

The root site collection, all site collections within all managed paths,
and all site collections in explicit managed paths are equal.

There is no hierarchy to SharePoint even though you may have created one
to presents your site collections in a URL taxonomy.

The "top-level" site really is not the site collection  but the "root"
site of the site collection. It becomes confusing because to have a site
collection, you need at least one site.

Just like to have a antique car collection you need at least one antique
car.

Other sites  within the site collection are sub sites (at some level) of
the top-level site.

Therefore, there is a hierarchy WITHIN the site collection but not OF
site collections.

The URL construction is just for taxonomy requirements and may include
applications and site collections both at the root of applications and
with managed paths (either wildcard or explicit).

To add to this:

I can give some examples using (sorry!) SPS 2003. We have one portal
which is still pretty much w/ out of box setup. From the "sites"
area, "Create new site" starts a new site  collection. Once I'm in a
(WSS) root-level site, any time I "create" a site or workspace
beneath it, I'm adding subsites that ultimately will make up the
site collection. The site collection  must always start w/ one top-
level site.

Further, there are certain things that are available only at the
site collection level. Site and list template galleries and web part
galleries are maintained at the site collection level. You cannot
have a template just for one subsite- it will be available to all
sites w/in the collection, and to manage these, you must go up to
the top-level site to get to the collection admin options.

Also, a site collection administrator is all-powerful w/in all sites
in the collection. You could technically have someone be an
administrator of a site w/in a collection, even the top-level site,
but that person wouldn't necessarily have admin power (or even
access) in other sites  in the collection if inheritance is broken.
BUT whoever is listed as a site collection administrator can get
into and do anything to any of those sites w/in the collection.

From the site collection administration, you can view the site
hierarchy, usage summary, storage space allocation, site collection
user info (i.e. all users of all sites in the collection), and
configure the connection ("up to" link) to the portal.

From central admin, you do things like lock sites, set quotas, etc.,
all at site collection levels.

I'm an intranet manager w/ full admin power of our portal, but only
via the UI. I'm not in IT, so I don't do anything w/ STSADM, etc.
I'm sure I'm missing a lot of "site collection" level info, but this
may help some of the less-technical folks out there.

In training last month I was taught that you can, indeed, have site
collections contained within site  collections. Is that not true?

Is this a difference between Portal 03 and MOSS 07?

You cannot have a site  collection contained within a site collection. A
site collection  consists of a top-level site and zero or more sub-sites.

You CAN architect your web app > managed path > site collection
structure to *look like* they are nested.

Like:

http://portal.company.com/ is a site collection

http://portal.company.com/HR is a site collection (using an embedded
managed path site collection
mindsharpblogs.com/.../1491.aspx )

I am not sure about the definition of site  collection
now. I thought a site collection  is a collection of a
site and subsites below that. If my definition is
correct a root site is also a site collection as we
can have subsites under root site.

The only difference is of a subsite and site
collection under a root site is the url  that we can
have incase of subsite under a root site will be

http://www.rootsite.com/Subsite1/

and in case of site collection under a root site will
be http://www.rootsite.com/Sites/sitecollection1/

and also in case of subsites we can inheret the
security from root site, in case of sitecollection  i
do not think we can inheret the security from the root
site.

Please correct me if i am wrong.

And also i am still not clear about subsite and site
collection concept, please put more light on this.

Technically, there is a distinct difference between a site  Collection
and the root site of the Site Collection.

* A Site collection  can have two (and only two) Administrators.
They are assigned and/or changed in Central Administration on the
Applications page. They and only they have access to the Site Collection
column of settings pages which is only available at the top level of
Site Settings. They cannot be locked out of any site in the Site
Collection by site owners.

* All sites  in the Site Collection can have Site Owners. By
default, the security of the root or Top Level site of the Site
Collection is inherited down the site hierarchy. This inheritance can be
broken at any level. The Site Owners group is managed by the first site
owner added. By default, this would be the Site Collection
administrators who are automatically added to the root or top-level site
Site Owners group.

Try adding a user to the site owners group of the root or top-level site
of your site collection.

Log on as that user.

Go to Site Settings. This user will not see the Site Collection column
even when at the top level of site settings.

Why? He (or she) is not a Site Collection administrator. Some galleries
are also not available because they are managed at the Site Collection
not the site level.

Sites hold content. Site Collections hold sites and configuration
settings that are scoped to the Site Collection level.

A great explanation, Daniel. It appears that the choice between creating
(for example) an HR subsite and creating an HR site  collection depends
largely on how you expect it to be administered, and what functionality the
HR sites  must share (or not share) with non-HR sites.

I agree strongly with your statement in your other note that the fact that
the site collection  root site has the same name as the site collection is
confusing, since they are not the same thing. It might be better if there
were a "Site Collection Admin" site (like the "Central Admin" site for
MOSS), and there didn't have to be a "root" site.

Breadcrumbs, Quicklaunch and Global navigation would work by default if HR is
chosen as a subsite. If HR is a seperate site  collection, I believe it is
difficult to provide navigation to HR site collection  from the home site
collection. Navigation option that is available to connect site collections  is
only "Portal Site Connection" available through Global Breadcrumbs.

The other options that would again work more easily if HR is a subsite are
1. HR site can refer to the same master page and other galleries. So, need for
maintaining multiple versions in various site collection galleries can be
avoided.
2. I believe content query web part can only pull content from the current
site collection only.

The advantages in choosing HR as a seperate site collection are the
administrative reasons as people have suggested and options like site quotas.

I believe more points can be added to the above list.

Basing on my understanding, it seems like Microsoft is suggesting to use a
single collection as much as possible to take advantage of all the default
features and only go for a seperate collection if we have a strong reason to do
so. I would like to know other people's thoughts on this.

You're confused because you're thinking of SharePoint as a web server with a
file system, where sub-directories have to be under the root. This is one of
the biggest misconceptions that I have seen with this product, and Microsoft
has done very little to explain it.

SharePoint is a database, not a file system. Your SharePoint site, and
almost everything on it, exists only in the database. I blame Jolt Cola and
the Matrix for this.

There are a few exceptions to this. The site  and list templates, CSS files,
and a few other bits exist on the file system, and the database reads those
when constructing your pages. But the pages themselves are built dynamically
from the database. There are also cases where, when you do something
particularly weird to a page (in the database), SharePoint gives up and says
"I'll stick this in the file system and figure it out later." In that case,
the page itself is stored on the file system, with a reference to it in the
database. This is called "unghosting" a page, and will slow your system
right down.

Now, when you create your first site collection, you typically do so at
http://intranet.domain.com" target="_blank" rel="nofollow">http://intranet.domain.com <http://intranet.domain.com" target="_blank" rel="nofollow">http://intranet.domain.com/> . Any sub-sites
that you create (through Site Settings, for example) are part of that same
site collection.

But, if you want to create another site collection, which is a different
choice than creating a sub-site, you can give it any unique address. So you
could have a second site collection  starting at
http://intranet.domain,com/manufacturing/ or even at
http://intranet.domain.com" target="_blank" rel="nofollow">http://intranet.domain.com/nothing/nothing/manufacturing. It's up to you
because it's just a name, not a real URL. Your SharePoint server will
interpret the URL and request the correct records.

Does this help?

Two comments:

* It is also confusing in that the site  Collection and the top
level site share the same name.

* My understanding of ghosted/unghosted is that the page on the
file system is "ghosted" because the database entry for the page is
<null> and this is the preferred solution. "unghosted" would store the
page in the database and be forced to load it for each instance it was
needed. Todd Bleeker can do much, much better explanation on this
subject than this old admin type.

I find  it best to explain that a site  Collection is a *container* that
contains a *hierarchy* of SharePoint web sites.

The web site at the top of the hierarchy is the Top-Level Site; every other
web site in the site collection  is a subsite.

You might be confused because you're thinking of SharePoint as a web server
with a file system, where sub-directories have to be under the root. This is
one of the biggest misconceptions that I have seen with this product, and
Microsoft has done very little to explain it.

SharePoint is a database, not a file system. Your SharePoint site, and
almost everything on it, exists only in the database. I blame Jolt Cola and
the Matrix for this.

There are a few exceptions to this. The site  and list templates, CSS files,
and a few other bits exist on the file system, and the database reads those
when constructing your pages. But the pages themselves are built dynamically
from the database. There are also cases where, when you do something
particularly weird to a page (in the database), SharePoint gives up and says
"I'll stick this in the file system and figure it out later." In that case,
the page itself is stored on the file system, with a reference to it in the
database. This is called "unghosting" a page, which will slow your system
right down if it happens often enough.

Now, when you create your first site collection, you typically do so at
http://intranet.domain.com" target="_blank" rel="nofollow">http://intranet.domain.com <http://intranet.domain.com" target="_blank" rel="nofollow">http://intranet.domain.com/> . Any sub-sites
that you create (through Site Settings, for example) are part of that same
site collection.

But, if you want to create another site collection, which is a different
choice than creating a sub-site, you can give it any unique address. So you
could have a second site collection  starting at
http://intranet.domain,com/manufacturing/ or even at
http://intranet.domain.com" target="_blank" rel="nofollow">http://intranet.domain.com/nothing/nothing/manufacturing. It's up to you
because it's just a name, not a real URL. Your SharePoint server will
interpret the url  and request the correct records.

Does this help?

I get the database driven nature of it. We've hand-built our share
of both filesystem driven and database driven sites. I can intellectually
accept that a site  collection is a "top level" entity, but it will take a
while before I internalize the concept. To me a web application is the top
level and anything under the FQDN for it is subordinate to that. I'm not
hung up on the issue, it's just going to take time to get the definitions
matched up with the concepts.