Could someone please explain in a nutshell the difference between Share
point service and Share point portal? I get asked this a lot and am
not really sure what to say. They are fundamentally the same but it
seems that Portal is just much larger and scalable, is this correct?
With Portal I can build a larger collection of sites without them being
tied to a singe root? Another words from the portal can I build
multiple sites that reside one level below the portal page? I think if
the initial portal page was laid out better or had templates for
different organizational needs it would be easier to understand. Sorry
for the rambling just trying to get a grasp on this thing now that they
have thrown it on my plate on top of SQL.

Thanks..Dan

Take a look at the FAQ here
http://www.asaris-matrix.com/mvp-wal...20General.aspx

"Dan" <Daniel.hogsed> wrote in message
news:3980
[..]

Portal - Index method of navigation - Enterprise Search - Targeted Content
based on who you are are - My Sites - Ability to create a Taxonomy.

WSS - Collaberation - Document Management features - Site Collections -
Reusable Web Parts - A file Server

These are out of the box comparisons and obviously from a very general
overview point of view. But needless to say they are not fundamentally the
same products , in fact they are very different products but melted together
with clever Glue if you buy portal.

Steve Smith

UK Sharepoint Training
http://www.combined-knowledge.com


"Dan" <Daniel.hogsed> wrote in message
news:3980
[..]

In article <#RPfaKxEGHA.1464>, Steve Smith wrote:
> But needless to say they are not fundamentally the
> same products , in fact they are very different products but melted together
> with clever Glue if you buy portal.
>
Beware of smart Glue! When the glue becomes smarter than you, you are in deep
doo doo.

Hollis D. Paul [MVP - Outlook]
Mukilteo, WA USA

:) , or if it decides to unstick and then re-apply itself but in a
completely different manner <grin>

Steve Smith


"Hollis D. Paul" <noone> wrote in message
news:6b97
[..]

I'm just wondering about your definition of "taxonomy" if you think you
can't do this in WSS.

Engelbert

"Steve Smith" <steve> wrote in message
news:1464
[..]

Hi Engelbert , I am not saying a taxonomy of say content could not be done
in WSS , just out of the Box it would be very difficult without some heavy
customization wheras all the needed components such as Topics and Areas are
all there ready to use in Portal , and the ability to publish information to
that portal is also built in to the WSS element of Portal Server. Someone
would have to re-create this within standalone WSS by coding , or buy 3rd
party products or consultants. Thats why I stated out of the box comparisons
at the end of my sentence

Steve Smith

UK Sharepoint Training
http://www.combined-knowledge.com


"Engelbert" <Engelbert> wrote in message
news:1088
[..]

Hi, Steve,

<grinning> you're still ducking the question on your definition of taxonomy
!

I've seen it used for instance to mean a site structure and that for
instance you can get with WSS out-of-the-box

Engelbert

"Steve Smith" <steve> wrote in message
news:4084
[..]

I think what Steve is referring to is the ease and flexibility that Portal
Server gives you for managing a taxonomy. Let's back up a second to catch
others up to speed.

Formally a taxonomy is simply a classification of items into groupings of
some sort. WSS sites are the items we want to group into functional
categories (such as personnel, management, production, etc.) or
organizational categories (such as HR, IT, Sales, etc.). Taxonomies
generally take the form of either one-to-many classifications (such as the
taxonomy for species) or many-to-many classifications (such as the card
catalog system in a library).

WSS sites present a problem because they are organized into a physical
structure of sibling or parent-child relationships which do NOT necessarily
represent a categorical classification. For example, users in the Sales
department may create new WSS sites for each new contract they sign. The
sites are physically located under Sales but probably need to be classified
under the department that will be fulfilling the contract. Moving the sites
after they are created is not the solution.

Portal makes it easy for us to re-classify sites by creating links to one or
more Areas in the portal when a WSS site is created. The links represent
entries in a taxonomy based on the ways users will typically navigate to
find items. So if a new employee is looking for the Widget contract she's
been assigned to she can navigate to the Area that corresponds to her
department and should be able to find a link to the Widget WSS site. Areas
have the added advantage that you can rearrange their taxonomical structure
very easily without breaking any links.

So this begs the question, do you really need Portal Server to do this? If
you are willing to do some extra work then the answer is no. You could
create a single "Home" WSS site that would act as the portal for all your
other WSS sites. Then, using multiple Links lists, you could create a
taxonomy of hyperlinks that point to each of the WSS sites. It wouldn't
provide the same depth of navigation flexibility as Portal areas and would
take more work to maintain but, technically, it would be a taxonomy.

Hope this helps.

hehe :) , That is my classroom experience coming out <g>.
In a nutshell I would say as information has got continuously more complex
and scattered there is an ever growing need to make this information
available to users ( readers ) from a central point of access who need to
find that content. A Taxonomy is a way to organise this information by a
category ( index ) structure that should lead the readers ( users ) down to
a more detailed index structure of that particular category.

The Trick here though is that in the classroom I find that a simple taxonomy
explanation is just the basis in which to define how to use Topics , Areas
and Site Directories and this has to be explained in many different ways to
help all those listening understand this from their own perspective. ' How
can I use this taxonomy as a power company , or a County Council or a
Government body , all see it in a completely different which is based on
their own needs.

Hope this answers your question , but it is just my opinion on the subject
and I am sure others do see it in a completely different way.

Steve Smith



"Engelbert" <Engelbert> wrote in message
news:a376
[..]

I agree, but the largest issue is enforcing behaviour when saving files to
sharepoint. Its a huge paradigm shift, just try getting all/most of your
users to use file -> properties inside their docs, so that the information
returned when searching is meaningful, just download a handfull of tech docs
or presentations from microsoft and you will find they are still having
issues. I would like to see more metadata applied automatically when docs
are saved to a site, based on the site taxonomy.

ias

"Steve Smith" <steve> wrote in message
news:a532
[..]

Thanks, Milan, for taking the trouble to write this.

A nice explanation !

Engelbert

"Milan Gross" <techhelp> wrote in message
news:2704
[..]

Thanks to you all, this sheds much light on a shady topic. I guess my
biggest concern is the control of this beast.
As it stands now I inherited a train wreck of a Portal that has content
scattered about in many areas which were poorly defined and organized.
Until last week I thought the site was practically empty but could not
figure out why the DB was so large, I downloaded an app that allowed me
to browse and extract docs stored in the SITE DB and recovered hundreds
of docs nobody knew existed. I cannot allow this to happen again.
The customer is very interested in using the portal but I want to be
sure it is structured correctly so that the content (Sites and docs)
are stored in a manner that allows the users to not only be able to
browse it in a Parent/Child tree view but be able search the entire
site for documents that were uploaded by practically anybody.
In our environment we are not so much concerned with collaboration as
we are archiving of documents and events that can be easily found.
Anyway I will drive on and do my best with it. Again I appreciate all
the help.

Take Care

hello Dan,

in a nutshell

"SPS == Product"
"WSS == Platform"
and you can find more in the folloing blog
http://mindsharpblogs.com/todd/archi...12/22/923.aspx

and about architecture ou can review the following article
http://www.microsoft.com/technet/pro...c0561881x.mspx
welcome any time





"Dan" wrote:
[..]