JiscMail Logo
Email discussion lists for the UK Education and Research communities

Help for RECORDS-MANAGEMENT-UK Archives


RECORDS-MANAGEMENT-UK Archives

RECORDS-MANAGEMENT-UK Archives


RECORDS-MANAGEMENT-UK@JISCMAIL.AC.UK


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Proportional Font

LISTSERV Archives

LISTSERV Archives

RECORDS-MANAGEMENT-UK Home

RECORDS-MANAGEMENT-UK Home

RECORDS-MANAGEMENT-UK  July 2009

RECORDS-MANAGEMENT-UK July 2009

Options

Subscribe or Unsubscribe

Subscribe or Unsubscribe

Log In

Log In

Get Password

Get Password

Subject:

Re: Advice wanted on use of EDRMS in Local Government

From:

Richard Archer <[log in to unmask]>

Reply-To:

Richard Archer <[log in to unmask]>

Date:

Fri, 31 Jul 2009 10:20:29 +0100

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (138 lines)

Martin,

Before I respond to specific questions on metadata I should point out that
the LGCS is not, as far as we are aware, intended as a schema for
structuring information. The LGCS is a taxonomy that should be used in
conjunction with subject metadata items to classify / index information. The
information structure, or file plan, should be designed in a way that is
easy for staff to use on a daily basis whilst at the same time facilitating
the organisation’s need to exercise control over its information.

With regards your comment on metadata rendering the file plan pointless, you
are correct except that, in order to operate without a file plan, you would
need to load every piece of information with so much metadata, to facilitate
its later retrieval, that it would not be practical. The file plan and
metadata, as well as the information naming convention, should complement
each other so that the file plan is not overly complex and difficult to
navigate whilst at the same time staff are not required to record too much
metadata on a document.
 
Clearly a file plan is a two dimensional structure and therefore can never
satisfy everyone’s requirements in terms of how they want to structure
information. It is the metadata that provides additional dimensions which
allow staff to interrogate the information within the EDRM repository in a
way that meets their particular needs.

Take your example of the address versus service. If you have the address as
the parent folder in your file plan, with service folders below it, you can
see from the structure what services are being supplied to any particular
address and all service related documentation associated with that address
will be held together. However, if you wanted to see a particular service
related document, for example the original application form, for all
households currently receiving a specific service you will have to go
through each address folder to see if it has a sub-folder for the service in
question and then look in that folder for the application form. Not
particularly useful from a service department perspective. Using metadata
can resolve the problem. Each document within the service folder would need
two metadata items, one that records what service the document relates to,
e.g. housing benefit, and another that records what type of information the
document contains, e.g. application. This would enable you to search for all
housing benefit applications across all address folders.

In answer to your specific questions:

1. There should be a common scheme for the whole organisation which will
contain metadata items that are common across the organisation plus some
that are specific to each business area. There are various mechanisms to
automatically apply metadata values; some depend on which EDRM product you
use. With Wisdom you can pull values from the document properties, default
values and inherit values from the folder in which you store the document.
In the address versus service example above you could inherit the service
value from the service folder.

2. I am not aware that Wisdom can pull metadata from document filenames as
standard but it is likely that a script could be developed to do so.

3. Metadata requirements need to be determined through requirements
investigation and analysis in order to define a metadata library; as well as
information types and the metadata allocation across those information types

4. There is a government metadata standard – eGMS (eGovernment Metadata
Standard) – which is part of the eGIF (Government Interoperability
Framework) standard. The objective of the standard is to have a common
vocabulary in order to facilitate the electronic exchange of information
across government: http://www.govtalk.gov.uk/schemasstandards/egif.asp 

5. There is also a basic standard called Dublin Core: http://dublincore.org 

6. As mentioned above, it would not be advisable to base your file plan on
the LGCS. In order to get a structure that is fit for purpose you need to
gain an understanding of the information you have, how that relates to the
work your organisation undertakes and how staff need to use and share that
information both internally and with external partners.

7. We have considerable collateral from previous design work with local
government clients that would be suitable for reuse, if you are interested.

I hope this is helpful.

Kind regards,
Richard Archer
Bramble.cc
[log in to unmask]
----------------
On Sun, 26 Jul 2009 19:42:36 +0100, Martin Anderson <[log in to unmask]>
wrote:

>This is a copy of a query put on the relevant esd tollkit forum (in case 
>anyone recognises it). I am just opening the question out to a wider 
>pool of expertise.
>
>We are in the process of implementing and EDRMS [Wisdom by 
>Diagonal (now Morse)] in a local government borough. 
>At the moment we have a file plan based on the LGCS but I am a little 
>concerned about how the file structure should be set up below this 
>level. At present each individual service area which works on address-
>based cases seems to be creating a separate folder for each address in 
>the borough which seems a little ungainly to me. I have heard mention 
>of possibly putting the address level of the structure above the service 
>level, but I think this would interfere with the LGCS and would still 
>represent a huge file structure. All the reading I have done on EDRMS 
>etc indicates that the metadata is critical and that without it an EDRMS 
>will become unusable.
>I already notice a significant amount of irrelevant returns on searches 
>from a system which contains relatively little data as yet, but this could 
>be due to not having narrowed down the search string properly.
> 
>I have noted comments which concur with my own understanding that if 
>you have good metadata then the file structure becomes largely 
>irrelevant, but the problem with the creation of all the required 
>metadata is that it probably even more onerous than creating large 
>numbers of folders. 
>I wonder if someone could answer a few questions for me: 
>
>1. Is it necessary to have a standardised metadata scheme across all 
>departments contributing to the EDRMS data and are there automated 
>or semi automated ways of applying it to the documents? 
>2. Would it be possible to extract the metadata automatically from a 
>well structured file name protocol? 
>3. What is the basic minimum metadata required for functions such as 
>Housing, Environmental Health and Planning/ Building Control? 
>4. Is the extent of such metadata laid down in standards? (ie: do eGov 
>metadata standards extend to this level of detail?) 
>5. If not has anyone developed a standardised set and what are they? 
>6. Below LGCS, is a simple folder structure based on "Year" a 
>reasonable solution or should it be more complex and if so how and 
>why?
>7. Does anyone please have an example of their own or of best practice 
>relating to these questions?
>
>Many thanks in advance, 
>Martin
>
>For any technical queries re JISC please email [log in to unmask]
>For any content based queries, please email
[log in to unmask]

For any technical queries re JISC please email [log in to unmask]
For any content based queries, please email [log in to unmask]

Top of Message | Previous Page | Permalink

JISCMail Tools


RSS Feeds and Sharing


Advanced Options


Archives

April 2014
March 2014
February 2014
January 2014
December 2013
November 2013
October 2013
September 2013
August 2013
July 2013
June 2013
May 2013
April 2013
March 2013
February 2013
January 2013
December 2012
November 2012
October 2012
September 2012
August 2012
July 2012
June 2012
May 2012
April 2012
March 2012
February 2012
January 2012
December 2011
November 2011
October 2011
September 2011
August 2011
July 2011
June 2011
May 2011
April 2011
March 2011
February 2011
January 2011
December 2010
November 2010
October 2010
September 2010
August 2010
July 2010
June 2010
May 2010
April 2010
March 2010
February 2010
January 2010
December 2009
November 2009
October 2009
September 2009
August 2009
July 2009
June 2009
May 2009
April 2009
March 2009
February 2009
January 2009
December 2008
November 2008
October 2008
September 2008
August 2008
July 2008
June 2008
May 2008
April 2008
March 2008
February 2008
January 2008
December 2007
November 2007
October 2007
September 2007
August 2007
July 2007
June 2007
May 2007
April 2007
March 2007
February 2007
January 2007
December 2006
November 2006
October 2006
September 2006
August 2006
July 2006
June 2006
May 2006
April 2006
March 2006
February 2006
January 2006
December 2005
November 2005
October 2005
September 2005
August 2005
July 2005
June 2005
May 2005
April 2005
March 2005
February 2005
January 2005
December 2004
November 2004
October 2004
September 2004
August 2004
July 2004
June 2004
May 2004
April 2004
March 2004
February 2004
January 2004
December 2003
November 2003
October 2003
September 2003
August 2003
July 2003
June 2003
May 2003
April 2003
March 2003
February 2003
January 2003


WWW.JISCMAIL.AC.UK

Secured by F-Secure Anti-Virus CataList Email List Search Powered by the LISTSERV Email List Manager