Data about data – metadata

In the last post, I spoke about the way we are developing the information architecture to ensure that content is easily discoverable, relevant and able to be sliced and diced a number of ways.

But these aren’t the only issues regarding content on the site.  In reviewing the focus group information and brainstorming ourselves, we came up with content questions such as:

• I need to drive this policy forward internally. What’s the basis of the compliance rating?
• Is this content still relevant?
• Who do I go to for help on this topic?
• That IA structure we came up with: how are we going to implement it when we don’t have a sophisticated Content Management System (CMS)?

 Coming to our aid is, of course, metadata.

The perennial issue on metadata is balancing the need for information about the content versus the ongoing operational burden of reviewing and maintaining it.  There are a number of elements within the AGLS scheme which are mandatory, so these need to be included in our site.  Then there are elements which we want to include in order to answer the above style of questions.  But we didn’t want to include too many.

Mandatory elements include:

• Title – the name given to the page
• Identifier – an unambiguous reference to the page (URI)

Unique elements to our site include:

• Compliance – level of required compliance for the topic
• Lifecycle – classification within the website lifecycle

There are a number of different elements and schemes available for use, the main one being AGLS.  However, sometimes those elements and schemes don’t contain the things we want. When there is no previously published work we can use, we create them ourselves. So for example, we made up new metadata element – <meta scheme=”WGwebsiteLifecycle” content=”<scheme value>” />, with the scheme values of:

• Plan
• Build
• Review / Maintain
• Decommission / Archive

Note that where we made up a metadata element, we create a WGTERMS type.

But in some cases, there was an existing AGLS scheme for a metadata element. For example DCTERMS.Audience already has a scheme within AGLS offering audience types.  But these were too general to meet our needs.  So, we created our own scheme for that metadata element <meta scheme=” WGwebsiteProfessions” content=”<scheme value>” />.  Note that we include the fact that we created the scheme in the scheme=” WGwebsiteProfessions” portion of the code.

Putting this back to the questions we came up with:

• I need to drive this policy forward internally, what’s the basis of the compliance rating?

<meta scheme=” WGcomplianceRating” content=”<scheme value>” />

• Is this content still relevant? <meta scheme=” dcterms.ISO8601″ content=”<Date_Last_Reviewed>” />

  All we need to do is expose the metadata on the page and we can provide more information to help our users.  On the page, you’ll see:

• I need to drive this policy forward internally, what’s the basis of the compliance rating?

Compliance rating – Mandatory

• Is this content still relevant?

Date last reviewed:  13^th April 2010

Authors and contributors

For this question, we thought of trying something a little different.  For much of the content on the site, we are not the subject matter experts (SMEs).  The topic is controlled by one agency; however a number of other agencies might need to be consulted in providing information on the topic.

Currently the ‘Who Can Help?’ section on each page is static content, which is another element we have to review regularly to ensure the contact information is up to date.  Which is an operational burden we would like to avoid.

A possible answer came from the whole of government directory – the Government Online Directory (GOLD).  On this site, departments and agencies update their information when either internal or machinery of government changes happen.  It seems likely that this source would be more up to date than our static information.  So we could include links to the appropriate section of the site within our metadata, giving up to date information.

• Who do I go to for help on this topic?

<meta name=”DCTERMS.Creator” scheme=”GOLD” content=” ou=Office of the Privacy Commissioner; o=Prime Minister and Cabinet;o=Portfolios; o=Commonwealth of Australia; c=AU” />, which would show up as a link – Office of the Privacy Commissioner

We tested it. It didn’t work. The lowest level on GOLD is at the Director or Branch Manager level. We didn’t think it a good idea for us to send branch managers problems that their staff should be dealing with. Possibly this might be a better option longer term – there’s nothing to say that GOLD shouldn’t have topic related hotlines or group email addresses in it. But for now, we going with the AGLSTerms.AglsAgent tag.

If you are interested, we can post up all the metadata elements we are using and what how we are going to use them to expose meaning– let us know.

Implementation

We don’t have a sophisticated CMS, so trying to implement faceted navigation in our new site is an interesting challenge. Metadata certainly gives us the groups and classifications we need for each page, but it doesn’t provide the whole story. 

We’re planning on using an external search engine to crawl the site and serve up the results in a way that will be seamless to our users.  More on this soon.