See also Section 8 of the Strategic Plan
TWS Information Model
utilizes an evolved
that distinguished between different types of
information entities (Websites/Portals, Topics, Resources, Metadata, etc.) and defines formal relationships
between them. The goal of the TWS Informatio
n Model is to provide a framework
information mapping and user interaction, as well as to provide a robust foundation for
General Market Requirements
Key goals for the TWS information model are:
easier for Portal/Website and content developers to organize information in an intelligent
manner without requiring extensive training in information theory
Reduce the complexity of taxonomic structures needed to map and navigate large quantities of
ation across broad domains of knowledge
Facilitate the reuse of information resources for different types of activities (e.g. reference look
up, learning, teaching, listening, watching, playing, blogging, mapping, trading, etc.)
Provide a robust foundation
capabilities within the TWS platform.
Provide for interoperability with leading
, including full compatibility
and partial compatibility with
Topics, Resources, Websites/Portals and Resource Categories
The TWS information model relies on key concepts such as
, as described below.
information model has the following generalized "information hierarchy":
though Topics and Resources are represented in the TWS model along "orthogonal" information "axes"
Each of the
se information types include metadata, which will
provide TWS with powerful
semantic capabilities for searching, viewing and relating information.
Topics vs. Resources (and Resource Categories)
A fundamental concept within the TWS data mode
l is the formal delineation between Topics and
(or "subject matter") is an entity that exists apart from any specific piece of information
about it. A topic can be a person, an organization, a physical object, a theoretical concept, a
of study, an event, etc.
is an information entity that pertains to one or more Topics. A resource can be an
article, a book, a web page, a news article, a photo, an album, a video, a map, a lesson, a data
record, metadata record, etc. Thes
e different types of resources may in turn be grouped
For example, a
is a resource in the category "
" that pertains
to topic "
". Similarly, a photo of
is a photo resource that pertains to both the topic "
By building this distinction directly into the data model, the 1
dimensional information ontologies that are
y found on popular web sites (such as
) may be trivially transformed to a 2
> 2D transformation has several advantages:
Greater efficiency in terms of ontological nodes that need to be uniquely defined: the number of
uniquely defined taxonomic nodes required for 2
dimensional information model is
for a 1
dimensional mapping, where
. While this may not make a significant difference for sites with a very
narrow range of resource types (such as
, which is essentially limited to encyclopedia
articles), it can make a very significant difference (an order of magnitude or more) for sites that
cover broad range of content types (e.g. witness the extremely
complex and "spaghetti
taxonomies of sites such as
Similarly, by segregating topics and resources onto orthogonal "information axis," the task of
developing rigorous knowledge ontologies may be greatly simplified, since the ontology is
"cleaner" (e.g. no m
ixing topics and resources) and only the Topic axis needs to be uniquely
defined (i.e. the Resource Category axis is reused across topics).
A simpler and more consistent user experience: since the "resource" categorization axes is reused
(with only additio
ns and subtractions) across all topics, users do not need to re
categorization scheme as they navigate across topic domains.
Provides a framework for building "activity
centered" capabilities, where users are focused on a
particular activity (suc
h as teaching, learning, watching, keeping up with the latest news, etc.) the
cut across multiple topic domains.
As a corollary to point 4, the 2
D ontology is an important foundational structure for enabling
future semantic web capabilities envisioned for
the TWS platform.
Resources are grouped into categories of similar types. In some cases, the category corresponds to a strict
media type definition (such as "Videos" "Photos", "Audio" and "Links"). In other cases, the category is
ed by the intended usage (such as "News" and "Encyclopedia"). In many cases, the category is a
combination of both (such as "Blog", "Forum", "Events" and "Music").
In the current TWS, resource categories are listed as tabs across the top of the page,
clicking on a particular resource category tab shows all resources for the current topic and all sub
topics below (within the current Portal/Website). While there is a standard list of Resource
Categories, users will only see those categories that hav
e content within them. In
TWS project, administrators will be able to add "soft categories."
+ Soft Categories
Websites/Portals vs. Topics
Groups of Topics may be aggregated into TWS Websites/Portals, which allow related Topics (and
associated resources) to be managed and viewed as cohesive units. Typically
but not always
Websites/Portals coincide with
major Topics that
include a number of sub
organized hierarchically). To see how this works, consider the following 4 Websites, which a
topic taxonomic relationships (note here that this example uses the family tree metaphore for
the relationships could similarly be organizational or other ontologies such
" includes several topics and sub
topics. The topic "
" includes 5 topics, each
corresponding to a family member of Bob (content within the
such as photos of family
would get tagged with the appropriate family member "topic"). Two of these family member
" and "
are native to Bob's Portal/Website and are administrated as part of the
al/Website. Three of the other family member "topics"
" and "
exist as separate portals, and are administered directly by those family members (these family
members may grant "contributor" privileges to other
so the family members may add
content to each others' portals
while withholding "publisher" rights so that they can review content new
content contributions before making it public on their Portal/Website).
In the above diagram, "
" has been shown in detail, including a topic
hierarchy that is analogous to "
". Note that the the "
" topic links right back to
", indicating a
. There is nothing
wrong with having recursive relationships, and is in fact necessary in order to accurately represent certain
types of topic ontologies.
Note also that "
" and "
" portals each have two ascended topic linkages
and thus are "
" (note that
term refers to the topic/Portal/Website
and should not to be confused with the fact that in the
specific example above the portals in question
correspond to Bob's parents). Again, there is nothing wrong
with having multi
parented Portal/Website/topic relationships, and is in fact necessary in order to
accurately represent certain types of topic ontologies.
It is clear from the example that the f
ollowing statement is true: in the TWS information
. This statement is the
justification for showing
Types of Websites/Portals
TWS Websites/Portals may be be managed by groups of people
a single individuals. Websites/Portals
managed by several people are marketed by
Websites/Portals managed by single individual are marketed as "
" (in essence, a
Personal Portal/Website is a Community Portal/Website with a
Websites/Portals managed (or "stewarded") by experts certified by the
known as "
" (or Stewarded Websites/Portals). A special case are "
", which are Digital Universe Websites/Portal
s that do not yet have a
certified expert assigned to manage (or "steward") the Portal/Website.
In the most gene
ralized sense, all types of portals may be interlinked, as shown in the following graphic:
Trunity Community Websites/Portals
Community Websites/Portals may be created by any or organization or individual, and includes the ability
to assign different individuals (called "Members") different levels of privileges for contributing, authoring
and publishing content within the Portal/
Website. Community Websites/Portals include a simple content
managing work flow, that divides the responsibility of contributing/authoring content from
approving/publishing content to the public.
Community Websites/Portals may build out their own Topic Tre
es according the above described schema.
They may also interconnect with one another in the following manner:
Websites/Portals may be attached to other portals as direct children visible at the top level of the
Navigator within the parent Portal/Website. A
Portal/Website may have "multiple parents" in the
sense that the Portal/Website may appear within the Navigator of several different portals.
Circular lineages, where the parent/child Portal/Website relationship eventually loops back on
itself, are also a
Websites/Portals may also be attached to a specific Topic within another Portal/Website, making
that Portal/Website visible further down within the parent Portal/Website's topic tree. However
(for the time being), Topics may not be directly attache
d (i.e. without going through it's parent
Portal/Website lineage) to another Portal/Website or Portal/Website's topic (though this
restriction may eventually removed)
Community Websites/Portals may be assigned to one or more Digital Universe Websites/Porta
and/or Topics, which will make the Community Portal/Website visible as "children" of the
"Communities" branch of the corresponding Digital Universe Portal/Website or Topic.
Trunity Personal Websites/Portals
Personal Websites/Portals are identical in fun
ction to Community Websites/Portals, with the only
difference that Personal Websites/Portals may
assign different levels of privileges for contributing,
authoring and publishing content to Members. As a result, Personal Websites/Portals have a simplifi
workflow for creating and publishing content.
Digital Universe Websites/Portals
Digital Univere Websites/Portals are
identical to Trunity Community Websites/Portals in
Features and Functionality, with following exceptions:
Websites/Portals and Topics show up in the mainline Navigation taxonomy, and
replace the functionality of Trunity Topics (they also show up in the "Topic Picker" within the
Digital Universe Websites/Portal
s and Topics retain the "Subportals and Communities" listing of
the current Trunity Topics
Later on, Digital Universe will have the following additional functionality:
A skin theme and branding that is different from Trunity Websites/Portals
A "unique name
" identifier that ensures that only one Portal/Website on a particular topic exists
within the Digital Universe of portals
The ability to directly assign Topics from one Portal/Website to Sub
Topics of another
An "Encyclopedia" content tab i
n addition to the other tabs
are Digital Universe Websites/Portals that do not yet have a
expert assigned to manage (or "steward") the Portal/Website. Genesis portals will be
the first type of Digital Universe Portal/Website available within the TWS, and have two primary
Provide a "topic" to which Trunity Personal and Community
Websites/Portals my be listed (thus
"Genesis Websites/Portals" replace the functionality of Trunity Topics)
Generate interest and build communities of involvement around the possibility of building the
finest place on the web.
Place to fin
d links to the best content on the web within the topic of the Genesis Portal/Website
Depending on feasibility and work involved, we may want to automatically post certain messages and
highlight certain standard Portal/Website functionality (such as blogs
and links) across all Genesis
Websites/Portals in order to achieve objectives #2
Taxonomy & Navigation
The TWS driven taxonomic framework has the following characteristics:
The TWS taxonomy is inherently "multi
parented": that is, a
Portal/Website may have multiple
"parents", one of which is designated the default or "primary" parent. Users my browse the
taxonomy using the
(link broken), which will eventually take many forms
(depending on audience and user preference).
The Topic taxonomy comes into play within two different domains:
portals. Within a Portal/Website, the Portal/Website administrator(s) have complete
control over their taxonomy. Across portals, taxonomic relationships must be mutually agreed
upon by administrators for both portals involved.
In general, Topics and Websi
tes/Portals are not unique: the same name can be used for any
number of portals and topics. There is, however, and exception: within the Digital Universe
taxonomy, Portal/Website names are unique (similar to any encyclopedia, where there is a
e for any given topic).
The global "canonical" taxonomy is determined by Digital Universe stewards, who create the
Digital Universe taxonomy collaboratively via mutual agreement across Digital Universe portals
(using the same request/allow/deny linking sys
tem available to Trunity Personal and Community
Trunity Personal and Community Portal/Website administrators may assign their Portal/Website
to one or more Digital Universe Websites/Portals/Topics via the Topic Picker. If th
ey do so, their
Portal/Website will be listed within the "Community Websites/Portals" branch of a the particular
Digital Universe Portal/Website/Topic they selected. This also applies to Trunity topics (see next
While there is a single canonical Dig
ital Universe taxonomy, any Portal/Website or Topic within
this taxonomy may be lifted to the top level and featured as a canonical "Favorite" branch of the
taxonomy. Currently, this is accomplished in a global default manner via Digital Universe
ta structure, which is visible at the
Websites/Portals and Topics may be navigated via the Navigator, with the following characteristics
, the Navigator shows the top level Digital Universe topics, as well
as Digital Universe Websites/Portals attached to these Trunity Topics (Community/Personal
Websites/Portals are visible under the "Communities"
branches of Trunity Topics and Digital
Universe Websites/Portals/Topics (see section above for details)
When viewing a Portal/Website, the root level topics are visible within the Navigator, with the
Name of the Portal/Website concoctinated with the word "
Topics" in the Navigator Header.
Clicking on the Navigator Header returns to the home of the Portal/Website.
Clicking on the "up" button of the Navigator when in it's default state reveals the Name of the
Portal/Website immediately above the top
, as well as (above the Portal/Website
Name) a linear list of all Parent Websites/Portals and Topics Websites/Portals that this
Portal/Website belongs to (including both Digital Universe and Community/Personal
Bread Crumb Trail
"Cookie Crumb Trail" is listed near the top of each page to give users a "reference frame" within the
TWS information map.
There are two "approaches" in doing "bread crumbs"
Show the location of the current page within the sitemap/taxonomy of the site
Show the browsing history
There are pros/cons of each approach, but the TWS uses Approach #1 for the following reasons:
The browser already keeps track of the browsing history: if the user want to see their
browsing history, all they need to do is to click
on the down arrow by the back/forward
buttons in the browser
While the Topic Browser could be used for this purpose, in it's current implementation
there is no "bird's eye view" that includes the path w.r.t. other portals (it only gives view
for the topic
tree *within* the Portal/Website).
Detailed specifications may be found in the document
All informational entities
with the TWS framework have metadata associated with them. The type of
Metadata depends on the type of information: Topics and Resources require distinctly different types of
Metadata, and thus the
(link broken) includes two broad classes: Topic Metadata
and Resource Metadata (see
(link broken) for a comprehensive introduction and
overview to the
(link broken)). A comprehensive listing of future desired TWS
rce metadata may be found in the document
Links and Namespaces
Future directions for TWS link and namespace functionality may be
found in the document