the present invention now will be described more fully hereinafter with reference to the accompanying drawings , which are intended to be read in conjunction with both this summary , the detailed description and any preferred and / or particular embodiments specifically discussed or otherwise disclosed . this invention may , however , be embodied in many different forms and should not be construed as limited to the embodiments set forth herein . instead , these embodiments are provided by way of illustration only and so that this disclosure will be thorough , complete and will fully convey the full scope of the invention to those skilled in the art . the invention is directed to a system and a method to be used in connection with the playing of fantasy sports and , more specifically , a fantasy depth chart system and management assistant for use when playing fantasy sports . the system and method according to the present invention is a computerized process for assisting users / agents with managing their fantasy sports teams and lineups . referring to fig1 , data will be collected by retrieving information from a variety of sources relating to real life sports participants . it should be noted that the sports participants referenced here and throughout includes professional athletes and amateur athletes , but need not be limited to only athletes . fantasy sports should be thought of throughout this disclosure as fantasy competitions ( some of which relate to sports , but others could certainly be non - sport related while still be fantasy competitions ). this being the case , the participants are any members of real life events whose performance in some capacity can have a fantasy scoring related affect in a fantasy game . one could imagine a game in which the scoring does not always rest entirely on the athletes ( coaches could receive fantasy points for any points scored on a possession following a time out or for missed fieldgoals after a strategic “ icing of the kicker ”, onside kick recoveries , wins / losses , and so on ) and fantasy games that do not even involve athletes can also be easily foreseen and serviced by the system described here . in this particular implementation , the data collected is illustrated to be player projections from experts who predict the likely output of participants ( also called players even though in certain embodiments the participants may not be athletes or playing sports , but may be contestants , such as american idol contestants and the like ), which is then stored in the system . the information collected does not need to be limited to player projections , but for illustration purposes player projections are shown in the flow char and are not intended to be limiting . upon collecting the player projections from a variety of sources the user &# 39 ; s fantasy roster is retrieved and the player projections may be applied to the fantasy roster in order to give the fantasy owner and / or system useful information that can be used to set an optimal fantasy lineup . in this embodiment , if the fantasy owner has set his / her settings to “ auto ” the system will compare either or both the fantasy owner &# 39 ; s roster or lineup with the recommendations created as a result of the retrieved information . if the lineup is optimal , then no changes are made . if the lineup is not optimal , then the system automatically adjusts the lineup and submits the lineup . in the event the fantasy owner does not select the auto setting , the recommendations created are output in the form of recommendations for consideration , as desired by the fantasy owner . “ optimal ,” as used herein , relates to a lineup that passes all the rules / tests that are in affect for the user utilizing the system . rules and / or tests that are used to determine whether or not a lineup is optimal may , for example , be stored on a database , and may be user defined rules / tests , or rules / tests that are set by , for example , a system administrator . optimal may , for example , be defined as “ all spots on a fantasy roster that can be filled are filled .” also for example , optimal may be defined as “ all spots on a fantasy roster are filled with the best possible player ” or it might be “ all spots on a fantasy roster are filled that are possible , but with the worst possible players ,” as may be desired in certain variations of the present invention . this last situation where optimal is defined by the worst players , could come up in a keeper - league in which a team &# 39 ; s draft positions are based on where they finished the season . by their league rules , all members might be required to set a lineup , but losing teams may still want to lose games to get a better pick the following year while still following league rules of the league . this , of course , assumes that the team which finishes with the worst record obtains the first pick in the coming draft . thus , what is “ optimal ” may well be in the eye of the beholder and may be customizable by the fantasy owner at the discretion of the overall league settings . therefore , an infinite array of what is “ optimal ” and what may be a allowed as “ optimal ” exists as a function of fantasy owner desires and league configurable settings . fig1 a and fig1 b were intended to capture the situation where information is collected and then made available to the fantasy owner ( user ) through output reports or through a search interface . they could be available just for the fantasy roster or for all players , as per the daily draft implementation . referring to fig2 , this implementation of the present invention advantageously retrieves a plethora of data of different sorts , including , but not limited to , news articles , blog articles , rumors ( as generally reported in many sports reports ), twitter updates , team announcements , league announcements and any other information that relates the sports participant . the information may then be passed through a contextual analysis routine where settings filter the information so it can be used to create unique recommendations not solely based on expert projections . as will be discussed later with respect to fig6 , this synthesis of information can advantageously create a system defined projection and a probability of play for each player being considered on a fantasy roster and , more importantly , for each player that is eligible for an owner , for example , to use on their fantasy roster . the fantasy owner may modify those system created projections and alter the probability of play as desired to customize a recommendation based on their own beliefs and information , thereby allowing the fantasy owner to act as a coach would generally act by accepting information and weighing the information differently to arrive at unique determinations . in this embodiment of the present invention , the recommendations formed through the efforts of the system , which may be modified by fantasy owner input , seek to generate a player ranking based on position played . again , if the fantasy owner has set the system to auto the system can take over and optimize the lineup . fig2 a is also intended for the daily draft scenario . here , unlike in fig1 a and 1b , the contextual analysis routine is employed to sift through the information collected and apply the system specific recommendations created . this version is similar to fig2 , but here , if the fantasy owner has their system set to auto , the players that will maximize the lineup are selected . an example of this version would be for fantasy play where owners need to fill a roster of players without going over an identified salary cap . each player may be assigned a salary cap value and all slots must be filled without going over the pre - set salary cap . fig2 b is a more basic version whereby the contextual analysis routine is employed . the data collected is run through the contextual analysis routine to generate a system specific recommendation . this system specific recommendation may be applied to the fantasy roster and then output to the fantasy owner either in the form of a report or made searchable . fig3 shows an embodiment similar to that discussed in fig2 , but in this embodiment there is also an optional user defined depth chart . if the fantasy owner has set a custom depth chart for one or more positions that depth chart ranking assigned by the fantasy owner can be taken into consideration . the optional user depth chart can merely be for informational purposes or to record thoughts and not set to have any primary affect in determining the optimal lineup in the auto setting . the optional user defined depth chart can be set to override the current lineup in place , in which case comparisons with the player rankings would be made against the user defined depth chart rather than against the roster or lineup . in either situation the ultimate desire is to analyze the rankings against either the user created depth chart , the full roster or the lineup in order to determine the optimal lineup within the customized settings selected by the fantasy owner . fig3 a is similar to the implementation shown in fig2 a , but here the fantasy owner is given the ability to adjust assumptions that were generated in the contextual analysis routine and then have the system specific recommendations recalculated based on the manipulation of inputs as defined by the fantasy owner . fig3 b is similar to the implementation shown in fig2 b , but here the system specific recommendation is applied to all players and then output to the fantasy owner either in the form of a report or made searchable . fig4 demonstrates another implementation that could be considered to fall between the implementation shown in fig1 and the implementation shown in fig2 . here there is no contextualized data that is being considered , but the fantasy owner does have the option to create a user defined depth chart that may or may not be ultimately considered during an auto lineup adjust phase . fig5 illustrates another implementation that is similar to that illustrated in fig4 , but here if the fantasy owner does have a depth chart set , it will not be viewed as potentially superfluous with respect to setting an optimal lineup when in auto mode . it should also be noted that here , and in fig9 , the output of recommendations ( or suggestions ) may be identified as possibly being satisfied by making the output searchable . this is intended to convey and cover the output of lists , tables or charts , for example , as well as making the recommendations / suggestions accessible to the fantasy owner through searching the stored data , thus making the recommendations / suggestions accessible through pulling information from storage rather than by pushing the information to the fantasy owner in the form of a reporting of some kind by various means . thus , here , and elsewhere , when outputted information is mentioned , it is intended to , and does , in fact , cover both the pushing ( via display or report ) as well as the pulling ( through search or customizable fetch of a designed subset of players ). fig6 illustrates the aforementioned contextual analysis process . here player news , information , rumors and projections of any and all varieties can be collected and stored . this information , collectively referred to as “ news ,” may be filtered to identify critical key terms . these critical key terms can manifest themselves through system defined pre - set configurations , or can be user defined or supplemented in conjunction with system pre - set configurations . any number of terms can be accounted for . in addition to identifying the number of times any particular key term has been located , a reliability score can optionally be applied , perhaps giving more weight to sources such as espn or sports illustrated over lesser known , smaller operations . a proximity score can also be arrived at which , through weighted rules , ( either system defined , user defined or a combination of the both ) may be configured to give preference to those key term combinations that appear in close proximity to one another based upon a reality that , for example , the word “ injured ” appearing several paragraphs away from the player name likely does not mean that the particular player is injured . the term “ injured ,” however , appearing within a few words of the player name , on the other hand , may suggest that the player is injured , which can be important information to consider when setting a starting lineup . the incident count , reliability score and proximity score , among other information that can be deciphered from the located key terms is considered to be contextual data . this contextual data can be analyzed by the system to generate a recommendation that is based on the projected scoring output of the player , as well as the probability that the player will actually play . with respect to the contextual analysis shown in fig6 , the system allows for natural language processing and other text analysis / knowledge extraction methodologies to be utilized to further enhance the analysis of retrieved news / data . furthermore , as also illustrated in fig6 , once the contextual data is analyzed , it may be stored . this will , in some embodiments , allow the fantasy owner to , at a later time , modify the underlying assumptions so as to have customized the analyzed contextual data used to generate recommendations . fig7 shows another variation of embodiments of the present invention wherein the user is provided with the ability to select the optimal lineup that is based solely on the user defined depth chart , should one exist . as in any of the embodiments , the optional user defined depth chart can be modified by the fantasy owner from time to time , or the fantasy owner can set up their depth chart one time , and from then on can have their lineup automatically populated either using information derived from the user defined depth chart . in this and other embodiments the depth chart can be filtered to remove any players that are ineligible to participate , whether as a result of a bye week , off day , suspension , injured reserve status , or other limiting factors . in this and other embodiments the user defined depth chart can also filter player who are not on the active roster when such rosters are announced prior to game - time . here , with respect to the implementation specifically disclosed in fig7 , the user defined depth chart alone may be considered after filtering ineligible players when the fantasy owner has selected auto mode . more specifically , fig7 is intended to illustrate a situation where the fantasy owner has set his / her control module to auto and has created a depth chart by one means or another ( i . e ., manually or through the use of system facilitation ). in this embodiment , the user defined depth chart is filtered to remove any players that are ineligible to play for whatever reason ( i . e ., bye week , no game that week / day , suspension , injured reserve , etc .). if the resulting lineup is optimal based on projections then the lineup may be submitted . if , however , the resulting lineup is not optimal , the lineup may be adjusted to play the optimal lineup . for example , and in no way meant to be limiting , if the fantasy owner were playing in a two quarterback league they might set his / her depth chart as follows : ( 1 ) peyton manning ; ( 2 ) tony romo ; ( 3 ) eli manning ; and ( 4 ) kyle orton . if peyton manning was ineligible then the two starters would be slated to be tony romo and eli manning . in this implementation the system would ask whether those two starters are optimal . if , for example , in a particular week kyle orton might be projected to score more than either tony romo or eli manning , then he could be substituted ahead regardless less of the fact that the originally created user depth chart would suggest otherwise . the fantasy owner could rely on this adjust lineup feature under a variety of circumstances , such as but not limited to only having the projections trump the previously defined depth chart in the event that the projection for the player would not start ( i . e ., kyle orton ) is a certain percentage higher than one of the starters dictated by the user defined depth chart . fig8 illustrates an implementation similar to what is shown in fig4 , but here the user defined depth chart is filtered for ineligible players and then the lineup is set without asking whether the lineup is optimal . in this implementation once the ineligible players are removed the lineup is set using the pre - defined depth chart preferences . for example , and not meant to be limiting in any way , if a fantasy owner can play two running backs and has 4 running backs on his roster the fantasy owner might set his / her depth chart as follows : ( 1 ) adrian peterson ; ( 2 ) deangelo williams ; ( 3 ) felix jones ; and ( 4 ) brandon jacobs . if both adrian peterson and deangelo williams are eligible to play they would be the two starters . if one were not eligible to play , perhaps adrian peterson because of a bye week , felix jones would become a starter along deangelo williams . if both adrian peterson and deangelo williams were ineligible , perhaps because of a bye week for peterson and williams being placed on injured reserve , then the two starters would be felix jones and brandon jacobs . the system and associated invention described herein have been described in terms of fantasy sports . that is intended to be illustrative and not limiting . the described invention and the various embodiments and alternative can be deployed for any fantasy game or competition . there could be fantasy american idol , fantasy stacker broker , fantasy corporation or any other type of endeavor where there exists a participant pool . in fact , the described invention and its various embodiments and options can be deployed to facilitate the creation of a fantasy team comprised of team members that collects wins or points based on quantifiable comparison between / among one or more teams . the concepts of how the game would be played are similar and the utility of the described invention would be as well . now referring to fig9 , shown is a roster suggestion module . the functionality works much like the lineup setting functionality . rosters are retrieved from the provider ( or entered by the user ). as new data , such as but not limited to news , injury information and the like , is added to the system the roster of each team utilizing this functionality will be reviewed . if , for example , a member of the fantasy team is injured and analysis reveals that the player is likely “ out for the season ” then the system will automatically try to find the best available player ( s ) to replace the injured player . it will then notify the user of the suggestion and make the information available via user interfaces , either in the form of providing a report , list , table or some other kind of display or made searchable . in addition , if the system has been given the autonomy to do so then it can automatically make the roster move on behalf of the user . another way the roster suggestion functionality will be applicable is that it can regularly find “ weak spots ” in a fantasy team and suggest changes . fantasy managers are notoriously confident in their own abilities and will often not have the time to seek about better players unless a player is injured . the roster suggestion module can identify weak members ( via statistical analysis and / or projected statists comparisons ) of a fantasy team , notify the manager that opportunities exist to improve the fantasy roster , and suggesting exactly how the manager modify the roster to obtain maximum production . this information can be made available through various display techniques or made searchable . in some embodiments the system can be given the autonomy to make modifications automatically , thereby automatically making the roster move on behalf of the user . referring now to fig1 , an overview of a depth chart manager according to the present invention is now described in greater detail . the function of the depth chart manager is to automate certain data crunching and to set lineups for , adjust the rosters of , and provide general assistance to fantasy managers relating to their duties involving management of their fantasy sports teams . as indicated above , the depth chart manager receives input from several different locations and uses that input to manage the depth chart of a fantasy sports team . initially , the depth chart manager determines league position settings . for example , depending on the sport , various leagues may have various settings depending on the positions . data is received from fantasy providers which may include rosters , lineups , league settings ( such as positions ), and other fantasy relevant rules . fantasy depth chart data , which may be defined as data that the user has set or was automatically generated by the analyzer , is then received . this data may , for example , be retrieved from outside sources , or may be stored on an internal database . result of an analysis of the fantasy depth chart data is also received , and the team depth chart and ranking data may further be retrieved . thereafter , the current rosters and the current lineup may be retrieved from a database , along with additional data from fantasy providers . the lineups may then be analyzed , and data that may be received from a database containing contextualized data may also be used to analyze those lineups . as the lineups are analyzed , depth chart settings are also analyzed . thereafter , it is determined if the lineup is optimal . if the lineup is not optimal , then the lineup is adjusted , along with the rosters , according to the user settings and , in some embodiments , the contextualized data ( which will be discussed in greater detail below ). this may include a notification to be sent to the user of the updates made to the lineup , as well as providing the data via external tools . if , however , the lineup is optimal , then use of the depth chart manager is considered complete at that point . those skilled in the art will appreciate , however , that the depth chart manager may continuously check for whether or not the lineup is optimal , i . e ., it is to be understood that the depth chart manager and the system according to the present invention , is a continuous analysis system . referring now additionally to fig1 , a contextual analyzer , according to the present invention , is now described in greater detail . it is to be understood that the contextual analyzer may stand alone apart from the depth chart manager system , but also can be used in connection with the depth chart manager system , as indicated above . data storage associated with the contextual analyzer can be databases , flat files , objects , etc . those skilled in the art will appreciate that there are many ways to store data , and the means of storing data for this application can include any number of known data storage means . the contextual analyzer illustratively includes a data event collector . the data event collector collects data and event information from various sources such as , for example , press conferences , news conferences ( voice sources ), videos , textural sources ( blogs , twitter , e - mail ), as well as any number of other sources as may be understood by those skilled in the art . since these sources can be both user - defined or system defaults , it is anticipated that information relating to these sources are stored on a predetermined storage location . the predetermined storage location may , for example , be an internal memory , a disk , “ the cloud ,” or any number of other storage locations . for example , the system may not automatically choose to analyze the dallas morning news , but a user that resides in dallas may place a high level of trust in such a publication and may set that publication to be one of the data elements to be retrieved and analyzed with respect to data to be collected by the data event collector . it is thereafter determined if the information in the data event collector is an item of interest . if it is determined that the information in the data event collector is an item of interest , then the information is analyzed by a data / event analyzer . the contextual analyzer may include an information relevancy indicator which , for example , weighs key words that may be recognized in the data stored in the data event collector , and weigh those key words . the key words may , for example , include player names , proximity , incident , or any other various key words that may be desired to be analyzed when reviewing data . these key words may be weighted in order to determine whether or not data collected by the data event collector is an item of interest . after the data that is filtered into the data / event analyzer has been analyzed , analysis results are outputted . the analysis results are used by the contextualizer to provide contextualized data . the contextualized data is stored in contextualized data storage . the contextualizer takes in data as well as other configurations , and creates a set of information that is placed into a context relating to the events of a particular user &# 39 ; s actual fantasy needs . it is to be understood that a particular user may include the system itself , another software process , an agent , or anything else that looks to define a set of fantasy players that may know as much as there is to know about it , pre - filtered , analyzed , ranked , projected stats , etc . as indicated above , after the data is processed by the contextualizer , the contextualized data is stored in the contextualized data storage . thereafter , a notification manager may be used to provide a notification regarding the contextualized data . this may be provided via e - mails , texts , twitter updates , or any other type of known notification mechanism . the notification manager may use any number of various settings to provide notifications . for example , the notification manager may check for new data stored in the contextualized data storage based on a predetermined timeframe , or may use push notifications to provide notifications based on the detection of new information in the contextualized data storage . those skilled in the art will also appreciate that the contextualized data storage may include an interface so that users may query and review information stored in the contextualized data storage . information stored in the contextualized data storage may be fed to the depth chart manager , as illustrated , for example , in fig1 . now referring to fig1 , a sample of a depth chart user interface is shown . the illustration is not meant to limit the interfaces described in this patent to only this specific example ; rather it is intended to provide an example of such an interface . it is an extremely simple example of the depth chart interfaces and it should enable someone skilled in the art to quickly get an understanding of what will happen behind the scenes once the user is finished setting their depthchart through the provided screen and when the other systems discussed in the patent execute against this data . the example interface of fig1 is based on a fantasy basketball league , but any sport or event could be easily configured along the same lines using different positions relevant to those sports . basketball positions are pg ( point guard ), sg ( shooting guard ), sf ( small forward ), pf ( power forward ), c ( center ) and sometimes certain positions are lumped into groups ; pg and sg may be lumped into a single group called guards ( g ), sf and pf may be lumped into a single group called forwards ( f ). how positions are grouped in fantasy leagues is simply a game variable . in the case of the example in fig1 the league that this team is a member is set up so that the two guard types are in a single group ( g ), the forwards are in a single group ( f ), and the centers in their own group ( g ). it is also common in fantasy sports to allow users to set anybody they want to in certain lineup spots . these types of spots are referred to as utility spots and are in the case of this diagram referred to using the abbreviation util . typically , all players on a fantasy team qualify as util . all of the fantasy team &# 39 ; s players are listed under each of the lineup positions for which the player is eligible . so , since all players can play the util position , then in the illustration the entire roster of the fantasy team is listed within the util position ranking area . likewise , any players that are eligible to play in the forward position are listed within the f position ranking area and those that have guard eligibility are in the guard position ranking area . in this example , the fantasy league commissioner has chosen settings such that the only positions are g , f , c , util . for that reason , the user is not presented with options to rank their pg in the pg area . all of the pgs are in the g area only . for the same reason the user is not presented with options to rank their sgs , sfs , or pfs . each player who is eligible at one of those specific positions is also automatically eligible at the appropriate broader position as mentioned above and they need only be ranked there for this particular fantasy league . the user can alter the rankings of the players in each position ranking area by selecting the players they want to re - rank and clicking the up and down arrows so that the players that they prefer to be in their lineups at each position are higher ranked . the user can then save their rankings when they are satisfied and the system will remember these rankings and then utilize them when reviewing / setting the lineup through systems and methods previously discussed . it is worth mentioning that this same screen , or a similar one , can be used to simply view the current depth chart settings for a given fantasy team . it is also worth mentioning that for those skilled in the art there are multitudes of different ways to give users the same type of configuration options ( among many others previously discussed ) and that the example in fig1 is simply one of those ways and is shown this particular way for illustration and discussion purposes only . while the present invention has been described above in terms of specific embodiments , it is to be understood that the invention is not limited to these disclosed embodiments . many modifications and other embodiments of the invention will come to mind of those skilled in the art to which this invention pertains , and which are intended to be and are covered by both this disclosure and the appended claims . it is indeed intended that the scope of the invention should be determined by proper interpretation and construction of the appended claims and their legal equivalents , as understood by those of skill in the art relying upon the disclosure in this specification and the attached drawings .