Re: Pages concept

["Shawn Callahan" <Shawn.Callahan@sms.com.au>]

Kate

Thanks for you clarification of points.  I must admit I was getting
confused.  Some of the points did strike a cord with me however.  I'm
certain that focussing on the content rather than the structure is
beneficial.  We don't want to travel the path of the FGDC standard
(ironically terms a content standard) which suffers from over prescribed
structure requirements.  A nightmare to implement.

Having said the above, however, there is a natural hierarchy of information
(by the way metadata is much closer to information that it is to data)
starting from personal information and progressing through project,
organisation, national and international.  People and organisation need a
strategy to handle all types and each has its own requirements (more and
different fields).  I always thought ANZLIC was providing the core elements
upon which we could build our own requirements.  The core would then be
used to interchange metadata.  Of course new fields would be added to the
core but this would be an evolutionary process (not in the Darwinian sense
- ie randomly).

Shawn

----------
> From: Kate Ord <kateo@erin.gov.au>
> To: ozmeta-l@erin.gov.au
> Subject: Pages concept
> Date: Thursday, 28 November 1996 12:46
> 
> 
> Firstly let me introduce myself. I work in ERIN in the Regional
Information 
> Section focussing on Comprehensive Regional Assessements on Australia's 
> forests. I have a keen interest in metadata and am a new member of the
ANZLIC 
> Working Group on Metadata.
> 
> John Hockaday and Kim Finney have both written to the discussion list
with
> criticsms of the "pages concept" 
>  
> > I believe that this "pages" method is NOT the right structure for users
> > to add extra fields to the metadata.
> ...
> > It would become too confusing to have to go down through many pages to
> > find an extra field related to the same category just because it was
> > not an ANZLIC field. 
> 
> I believe there is a misunderstanding of the "Pages" concept.  The pages 
> concept does not refer to actual pages of a report either on the Web or
in 
> hardcopy of the text. Perhaps the use of the word "page" is not
appropriate.
> 
> I believe the concept refers to a hierarchy of metadata fields to reflect

> different directory and management requirements, not the actual structure

> of how the metadata is stored or reported.
> 
> > 
> > I believe that the extra data would probably be related to the current
> > ANZLIC categories (eg dataset, description, data currency etc) and
> > therefore would be more useful if they were included in these areas.
> > If the extra metadata did not fall into one of these categories then
> > an extra category could be added at the end of the metadata report. 
> >
> 
> "This additional information may be in the form of sub-elements of
Specific 
> Page 0 core metadata elements or entirely new and unrelated metadata
elements."
> 
>         Page 11, Metadata Guidelines Version 1 July 1996
> 
> The text of the Guidelines agree completely with John's suggestion to
include 
> other "page" metadata where it most appropriately fits and not in some
spurious 
> category at the end of the metadata report.
> 
> John and Kim have raised important issues about how the core metadata
fits 
> within existing metadata collected for theme and internal directory use
and
> what this means in terms of supplying metadata to one another.  The
Working 
> Group is examining a variety of proposals for a national directory.  
> One of these includes a distributed directory where custodians store
metadata 
> in whatever form they wish and mark up SGML documents for each record
which 
> can be indexed and searched at different locations across the Web (much
like 
> the "Blue Pages").
> 
> As part of this proposal, the Working Group is attempting to define an
agreed 
> structure for these SGML files.  A draft proposal will be sent to the
list 
> shortly explaining what SGML is, why it is useful, a document type
definition 
> (DTD) for a standard ANZLIC SGML format and worked examples. 
> 
> The issue John has raised is being examined for these SGML files.
> SGML allows the user to have a number of different fields for different 
> purposes in the one document. They are just tagged appropriately. This
means 
> you need only write one SGML file and query scripts can be written to
extract
> only the metadata fields appropriate to that directory.
> 
> Looking forward to more opinions on this one.
> 
> Cheers,
> 
> Kate
> 
> **************************************************
> 
> Kate Ord
> Scientific Coordinator
> ERIN Regional Information Section
> Environment Forest Taskforce
> Environment Australia
> GPO Box 787
> Canberra  ACT 2601
> 
> ph:	(06) 274 1111	Int. ph:    +61-6-274 1111
> fax:	(06) 274 1333	Int. fax:   +61-6-274 1333
> email:	kateo@erin.gov.au
> 
> **************************************************