| |
|
|
Taxonomy Notes
Below are excerpts from several emails about the taxonomy features in CommonSpot and how we would like to extend and use them for our college intranet.
Fig Leaf's Taxonomy tool for CommonSpot
Fig Leaf developed a very user friendly Taxonomy tool for CommonSpot when they developed the Voice of America web site. They have developed it as a product and describe it in the breese presentation at http://figleaf.mmalliance.breezecentral.com/p92413677/. The presentation halts several times. You have to press the play button when this happens.
FigLeaf's Taxonomy model is not quite as rich as what I've been talking with PaperThin about in that it doesn't allow us to use the taxonomy model to control how roles or organizational location impact what people see. That said, there are other ways to address those issues. I really liked the flash based taxonomy creation User Interface. We probably wouldn't get that from CommonSpot.
PaperThin's response to Fig Leaf's product is at the end of this document (after the description of what they have to offer).
PaperThin's Offer to Develop Taxonomy Model in CommonSpot
PaperThin has offered to add functionality to their taxonomy model.
I've written a lot of emails about this but this summary to Mark Mara and Mark Anbinder is the probably the best overall summary:
Mark and Mark,
I've got all the materials for our intranet rfp posted at http://intranet.engr.cornell.edu/intranet/it/collegeIntranet/
I've been talking about extending the taxonomy tools currently in CommonSpot with Todd Peters, the CEO of PaperThin. In particular we want to be able to use three facets to drive the navigation of our site (each facet is essentially a separate dimension to locate a node): Topic (defined as a problem a user would want to address from broader to narrower), Role (people can have more than one role, possibly dozens, this will be a shallow but broad taxonomy, a path to a role might be CornellCommunityMember : Staff : FinancialStaff), and organizational location. I've included my communication with Todd below where we tried to nail down the taxonomy API based on our functional need.
This is not unlike the work Vivo has been doing. They have an ontology based model. Ours is based on a taxonomy, a somewhat simpler model. We have broader terms, narrower terms, synonyms and related terms. An ontology allows for any arbitrary relationship (membership in department, for instance. "term verb term", our verbs are limited to narrower, broader, synonym, related). Vivo doesn't address the dimensions of role or organizational location driving what you see. This is in keeping with their mission, but an intranet is different.
Intranets often have problems with people getting overwhelmed with information they will never need. For instance, only the dean's office staff need to know the procedures for phone coverage. The Organizational location taxonomy will address this.
Here are some more general examples. Financial staff will see stuff about financial processing that the broader role staff won't see. CALS may have policies that don't apply or that narrow university policies. Procedures in business units in different colleges may be different so we'll want to direct people to the right page for their organizational location. (If they are in two colleges they will see pages for both org locations.)
You can see the beginnings of the definition of this model in our RFP, especially in the metadata description in the functional spec, but the discussion with Todd about enhancing the taxonomy model happened more recently so it hasn't been incorporated in the spec. We may go forward with the given spec, or take the risk of negotiating a change in the scope and working with pre-beta code from paperthin in phase 1.
We will certainly use CommonSpot to create the content but exactly how we do the navigation may change. For instance we may eventually decide to do the navigation using the vivo engine (if we can integrate it with the metadata and publishing process in commonspot).
The big risk I want to retire at the end of phase 1 is getting people to create content. We need a good enough navigation model to exercise that risk, but it doesn't have to be excellent (yet). For one thing, we won't have enough content to worry about finding it initially.
Below is the email exchange with Todd, CEO of PaperThin. Todds original text is black, my response is in blue:
Email exchange with Todd Peters, CEO of PaperThin:
If you haven't seen this in CommonSpot the way a page or content object
is associated with one or more terms, is through the taxonomy field
type. This field type can be used on metadata forms or in custom
elements. The author of the page (or anybody else with proper
permissions) can assign the page/contentobject to one or more
(controllable by the designer) terms in the taxonomy.
My thought in reading your spec was that there were really four types of
pages: Home Page, Choice pages, Answer pages and Navigation pages.
Depending on how many levels there are in the taxonomy tree, certain
branches might not show any choices. Also depending on whether you
allow sub-braches and leaves at the same level you may have a
combination of a links to answer pages and links to sub-branches in the
tree.
I think our choice pages would be replaced by the navigation pages you describe.
The Navigation pages would be built dynamically based on the selected
facet.
If you allow a document to be associated with multiple terms in the
page's metadata, then the page would show-up under the appropriate
navigation/choice pages -- I believe giving you what you want. By
binding the page to multiple terms you are specifying where in the
hierarchy you want the page to be displayed. If the user wanted to make
the page show up in the ' new employee orientation section' they would
just need to change the metadata for the one page to now include the
appropriate term under the 'new employee orientation' term.
--------------
On a side note we also had talked about having multiple facets and being
able to navigate both at the same time. I wanted to show you what I was
thinking. Not really knowing examples of your facets, let me use the
wine example again. Say we had two facets 'By Region' and 'By
Varietal'. The UI might start out looking something like this:
Browse Varietal
----------------
Red Wines (192), White Wines (156)
Browse Region
----------------
French (71), New Zealand (34), USA (212)
If the user clicked on USA the UI would be updated to show breadcrumbs
along with the details of USA wines and the same Varietal options
(except the list/count may now be smaller because of the USA selection).
For example
You are here:
> Region > USA
Browse Varietal
----------------
Red Wines (124), White Wines (95)
Browse Region
----------------
Californian (180), Oregon (20), Washington (12)
If the user then clicked on Red Wines, you might see
You are here:
> Varietal > Red Wines
> Region > USA
Browse Varietal
----------------
Cabernet (34), Merlot (17), Petite Sirah (16), Pinot Noir (20)
Browse Region
----------------
Californian (79), Oregon (11), Washington (5)
I could see the UI having an outline character as below. But presumably this would be easy to implement if you build out the narrower terms API so you can get one level down.
Browse Region > USA
----------------
Californian (79)
Sanoma Valley (24)
Napa Valley (47)
...
New York
Finger Lakes (21)
...
Oregon (11), Washington (5)
Obviously you can render out the navigation with more detail as shown
here. In your case they might be displayed vertically with a description
under each option. I was think that the taxonomy browser would allow
you (the designer) to determine how may facets you would like to
include, and would show the appropriate breadcrumbs and navigation
items.
What do you think?
This sounds like it will work well in many cases and it is a great way to narrow the topic being addressed.
In our case the two facets are topic (like the one facet in the Yahoo directory of old) and role.
The topic facet is straightforward and works just as you describe.
The role facet is more complicated for two reasons. People may have more than one role, and Broader terms (broader roles) shouldn't necessarily include the pages associated with narrower terms (narrower roles).
Maureen manages both finance and HR for a small department. The paths to her roles are as follows:
Role Staff->Finance
Role Staff->HR
Role Staff->Payroll
She should see all pages marked Staff, and Finance, HR, and Payroll.
The kicker is that someone with the following role
Role Staff
Would not see the pages associated with the Finance, HR or Payroll, just the pages associated with Staff. As you get to narrower terms in the taxonomy the number of pages to be displayed is expanded.
Organizational location is another facet we will be adding. Again, we have a taxonomy of department names, but we are expanding the content as we go down the taxonomy to narrower terms. (University polices and procedures apply to everyone, but departments may add policies and augment procedures...very much like inheritance in OOP.) We have some other oddities as well. We may have some content that applies to all colleges except one. I'd like to assign the special content the value of the college. For everyone else, the material at the highest level applies.
I'm also wondering if it easier to limit associating a page only with
leaves in the taxonomy tree so that you never have a combination of
navigation and end-point documents in the same page? I guess this could
be an option.
Yahoo gives us a good example to work with. In their case they have both leaves and stems on many nodes. This is almost certainly what we will want to do as well.
Scope we're purchasing from PaperThin:
Below is the scope we're contracting with PaperThin to have added to CommonSpot. We'll get the full tech spec from them shortly.
In general, PaperThin has based their taxonomy model on the Z39 standard named "Guidelines for the Construction, Format, and Management of Monolingual Thesauri"(see http://www.niso.org/standards/resources/Z39-19.html ) and they have documented it in their Administrator's guide available at http://www.paperthin.com/support/knowledgebase/doclibrary/index.cfm . Check out page 341 of the administrator's guide for the XML definition. (You can get the password you need to view this documentation at www.commonspot.cornell.edu.)
One of our first tasks will be to deliver a test taxonomy to PaperThin to work on. They will be developing the navigation elements first, then the user interface to edit the taxonomy.
-Paul
1. Taxonomy API
PaperThin will develop a ColdFusion cfc-based API that allows developers to programmatically retrieve information regarding terms in a defined taxonomy. This API along with the Facet Based Navigation Element, can be used to rendered the desired contextual navigation and sitemap for accessing the numerous answer pages.
The API will support numerous methods that will return information regarding related terms in the taxonomy (i.e. narrower terms, broader terms), pages or content objects that are bound to the selected term or related terms, other associative, equivalence or scope note relationships.
2. Taxonomy Management User Interface
Version 4.5 of CommonSpot allows only for the import of an existing taxonomy via a defined XML schema. This XML document will need to be created and maintained outside of CommonSpot. In order provide a more seamless tool for the definition and ongoing maintenance of the sites navigational structure, PaperThin recommends adding an interface to the taxonomy module which will provide direct editing capabilities. As such PaperThin will develop an interface and security controls that will allow designated users to create taxonomies, associated facets and terms, thus enabling users to directly define, edit, delete and move terms within a defined facet. For each term the user may defined other relationships (associative, equivalence, ScopeNote, etc. as per the ANSI Z39 standard). This functionality will allow the user to build one or more navigational facets for access answer pages. The ability to control security permission will be added to control a users access to the interface for managing taxonomies and terms. Additionally a user (based on permission) will be able to set security at an individual term so that the facet may be dynamic based on the users permissions.
3. Facet Based Navigation Element
PaperThin will provide an out-of-the-box element that will render navigation links based on selected (one or more) taxonomy facets, and on design time rendering options selected by the content contributor or template developer. The Facet Based Navigation element will support several out of the box rendering styles and will provide the ability to invoke a render handler for customized rendering. Based on the type of navigation selected the element may render a series of links and/or breadcrumbs. From the mocked up templates provided as part of the function specification we envision that the navigation pages would include the Facet-based Navigation. The developer/partner will implement a custom render handler that will in turn call the Taxonomy API to retrieve the detailed information needed to render the navigation according to your specification. This development would be routine for a ColdFusion developer familiar with CommonSpot.
The Page Index and Custom Elements will also be updated to work in conjunction with the results set of the Facet-based Navigation element, similar to the way they renders results for the Query-by-example element.
Possible additional functionality:
We have not contracted for the following functionality as I wasn't sure we needed it, but it would be relatively easy to add if we do (and I have held back enough money should we need it). My thought is that we'll nail down whether we need this scope during discovery in the next week or two.
4. Term Relationship Element
In order to implement the desired results in the navigation via a taxonomy, additional relationships will need to be assigned to each term one such relationship might be a see-also relationship which might be used to link related pages/objects The new Term Relationship Element will provide an interface allowing contributors to define display templates for rendering related information. For example, a scope note relationship might be associated with a specific term which provides a detailed overview of the topic. The Term Relationship element will display such ScopeNote (or long description). It is unclear from the specification whether this is required functionality for phase 1.
Mockups of Taxonomy Settings Panels
Layout
Properties
Font and Color 1
Font and Color 2
Style
Structure of Intranet Taxonomy
Email sent 7/21/05
Todd and John, et.al.,
Here are my estimates of the sizes and depths of the facets we'll be using in phase one. I've also included some comments on how I anticipate we'll be using them.
We're anticipating using three facets initially:
Org location:
- Each page will be codes with the broadest organizational location(s) it applies to. Example terms might include: University, Ithaca Campus, Engineering College, Electrical and Computer Engineering, Engineering Dean's front office, etc.
- 5 levels deep with about 50 terms in phase 1.
- No change for scaling to all of Engineering content.
- Will grow to about 600 if our intranet is eventually adopted by University.
- The majority of the content will be tied to the top 2 levels (University wide or college levels) with the rest being tied at the very lowest level.
- Very few pages will be tied to more than one term.
- We will want to be able to choose more than one org location to navigate to (this could have important implications for the navigation element). (People are often affiliated with more than one department.)
- Each page is coded for the broadest audience it applies to. This produces the paradoxical result that we want you to be able to choose narrower terms to see more content, not less. You see all the content from your location on the taxonomy tree back to the root of the tree, not the more normal way around of limiting what you see to the branches further down the taxonomy.
- Basis for the estimate:
- The university incorporates about 300 terms (about 235 departments with their parent orgs). Engineering will be using about 30 in phase 1.
- Typical depth of about 4 levels (though campus allows up to 8 levels). By allowing sub department groups, we may use 5 levels in phase 1 and double our number of terms.
- It's possible that we will allow people to create org locations for themselves for their personal work documentation in which case we will have about 600 terms and 6 levels in phase 1 with very few pages at the bottom level (except for people like me who have hundreds). We'll know more about this after our discovery meetings.
- Example: University/Endowed Colleges/Engineering College/Engineering Dean's Office/Engineering Dean's Front Office
Job Function:
- Each page will be coded with the broadest affiliation and job function it applies to. Example terms include are Alumni, faculty, staff, Financial staff, active employees, etc.
- 4 levels deep with about 40 terms.
- These numbers should stay the same as we scale.
- They will grow slightly if the intranet is adopted university wide.
- The majority of the content will be spread pretty evenly between the first, second, and third level.
- Many pages will be tied to more than one term.
- Also we will want to be able to select more than one job function to navigate to. People are often affiliated with more than one job function. HR and finance duties are often, but not always performed by one person in smaller departments.
- Basis for estimate:
- We'll be augmenting the job family list. It has about 38 terms which we'll augment with about 6 or 8 parent terms.
- Typically it will be 4 levels deep
- Example: Active affiliate/Staff/Financial staff/Lead
Content Organization (topics):
- Each page will be coded with the topics it applies to. This is very similar to traditional metadata driven navigation. Pages may be associated with multiple topics.
- 2-4 levels & 150 terms in phase 1,
- 360 terms once scaled for all of Engineering's content.
- If the University takes this project on it will scale to probably 5 or 10 times this number and we'll probably go another level or two deeper.
- Most (but not all) of the pages will be tied to the bottom levels of the taxonomy. Importantly we'll want to be able to display deeper levels of the taxonomy along with pages tied to this level of the taxonomy.
- We will never want to choose more than one topic to navigate to at a time.
- Basis for estimate:
- This will be by far the largest and this estimate is probably the least accurate of the three.
- We can estimate this by looking at a site map and cutting one or two levels off the site map tree. Our site maps as they stand are posted at http://intranet.engr.cornell.edu/INTRANET/IT/COLLEGEINTRANET/RFPDOCS/WEBSITE%20DEFINITION%20DOCS/site%20maps/
- Our grad student administration draft site map is about 2-4 levels deep and it is one level down to start with. When we take off one level for the end pages, the taxonomy will be typically 2-4 levels deep.
- Their site map isn't done very consistently, but I'm guessing it's about 30 terms. They are one of 5 areas we're addressing in this phase, so we may have 150 terms in phase 1. Once all the content is written (in several years) we'll have 5-15 pages per term or about 1,000 pages. Eventually we'll have about 12-13 areas resulting in about 360 terms.
- Example: How Do I.../Finance/Buy Something/
Hope this is what you were looking for,
-Paul
Questions
Can we set up visual dividers in the taxonomy generated lists?
|
|
