Print

Print


Hi Marc - I really appreciate your quick responses.  I believe that you may
be endorcing the approach that I have (you may think how !!!!)

The folder structure (you mentioned MoReq doesn't recognise) I am happy with
that - we however *would* use a folder structure to create different types
of information structures
- class related structure (what the Records Managers like)
- a subject based structure (what is quite typical in organisations) i.e.
people
- a case based / project based structure
We would store our 'RM folders' at the top level within these structures.
Beneath these then Subfiles / Volumes etc. So far I am happy...... These
would be in an EDMS.

We would have a ERMS with our MoReq functionality typically containing the
levels Class / Class / Class .  The RM folder (in the folder structure)
would be registered against a class to create Class / Class / Class / RM
folder / SubFile / Volume. However the RM folder would actually be the RM
folder within the folder structure.

This RM folder could be navigated to through the ERMS and the EDMS.  For the
user, the properties of the RM folder / Subfolder / Volume would be
identicle i.e. permissions / open / closed.  The RM folder would receive
it's lifecycle through the class.

The advantage of this approach is that the ERMS would be totally
class/class/class based.  The EDMS would be where the flexibility is built
in - we could have a case file / project with many different series of
information -  The series however would be registered in different classes
in the ERMS.

Ant thoughts

Edgar




On 12/20/07, Marc Fresko <[log in to unmask]> wrote:
>
> Edgar
>
> The trite answer is that MoReq and MoReq2 do not recognise "folders" or
> "folder structure".  Nor "view" for that matter.  So before answering we
> would have to agree what you mean.
>
> The more helpful (?) answer is:  I don't think so, if you are talking
> about data structures within the ERMS repository.  Unless Folder=Class, then
> the "Folder" in your structure is not something MoReq or MoReq2 will
> support.
> Alternatively, if by "Folder Structure" you mean a hierarchy of Windows
> folders outside the ERMS while the class structure is defined in the ERMS
> and mapped to specific folders in the folder structure, then I imagine that
> would conform.  I am not sure you'd find software that can do this though,
> and it is likely to be difficult to administer if you do; and I suspect that
> the need to link the metadata to the Windows folders would make the whole
> thing "fragile".
>
> Nothing prevents any vendor from building MoReq2-compliant software and
> then extending it in any direction.  Such an extension could, for example,
> include functionality to link classes to external folders held in a Windows
> file system, in effect using Windows as a structure for its
> repository.  MoReq2 does not include this functionality (and nor can it, as
> it has to be technology neutral)..
>
> As a detail, MoReq2 allows for sub-files, but MoReq does not.
>
> Marc Fresko
>
> ________________________________
>
> From: The UK Records Management mailing list on behalf of Edgar McCulloch
> Sent: Thu 20/12/2007 14:28
> To: [log in to unmask]
> Subject: MoReq and RM folders
>
>
>
> Can someone clarify if the following model is feasible wrt MoReq
>
>
>
> CLASS STRUCTURE
>
> Class 1
>
> --Class 1.1
>
> ----Class 1.1.1
>
> ------(RM Folder A - A view)
>
> --------(Subfile - A view)
>
>
>
> FOLDER STRUCTURE
>
> Folder
>
> --Folder
>
> ----Folder
>
> ------RM Folder A (1.1.1.1 <http://1.1.1.1/> )
>
> --------Subfile
>
> --------Subfile
>
> ----------Volume
>
> ------RM Folder F (2.3.2.2 <http://2.3.2.2/> )
>
> --------etc
>
>
>
> Whereby RM folder A is created in the 'folder structure' and classified.
>
> Within this environment, the RM folder and Subfiles / Volumes) are
>
> - permissioned
>
> - contributed to /
>
> - closed
>
> - receive metadata
>
> - the RM folder always remains in the folder structure and is preserved
>
>
>
> Edgar
>
>
>