[Freegis-list] Re: metadata storage and fgdc
Robert Maki
robert.maki at dnr.state.mn.us
Wed Apr 3 20:20:24 CEST 2002
Greetings:
Interesting discussion. We have made a commitment to managing our GIS
metadata resources within a relational data model (Oracle-based) to meet
database objectives of normalization, etc, and are currently operational
with metadata descriptions from broad (layer) levels to detailed table
and valid value domains. Our model further differentiates between data
optimized for maintenance and derivative data. Metadata reports for
derivative data draw partly on descriptive elements associated with the
maintenance data sources. We are an FGDC node but have not yet begun
writing (ISITE) indexable XML documents from the database yet (we are
still limping along with a legacy technology in that area). Our
approach is certainly not generic but may offer some ideas to folks who
are working in this area. I can make a model (visio) available if
anyone is interested.
A couple of comments. To my mind, the biggest drawback of the FGDC
metadata effort was their failure to design a workable physical data
transfer format. The mp file format was really inadequate. The SGML
format was a better idea but was not codified as a standard. Both of
those approaches took a *document* view of the subject while what was
really needed was an *element*-based method. Could someone educate me
as to whether the current efforts feature this type of flexibility in
their approach?
Regarding ArcCatalog, we have found few advantages to their approach in
that ESRI seems to view metadata as a document storage problem, rather
than an enterprise data problem.
Regarding metadatabases, we borrowed a fragment of ISO11179 (metadata
registry) for storage of value domains, permissible values, and value
meanings and have found it to be pretty robust (as long as you write an
application to manage the content).
Thanks for the discussion.
Robert
Robert J. Maki 500
Lafayette Road
GIS Data and Infrastructure Supervisor Saint Paul, Minnesota
55155
Management Information Services (651) 297-2329
Minnesota DNR
robert.maki at dnr.state.mn.us
>>> "Dieter Lehmann" <Dieter.Lehmann at sbg.ac.at> 04/03/02 09:23AM >>>
Hello,
thanks for this wonderful discussion about metatdata.
But what should the enduser do? For example - we (EU-project) are now
in the
stage to define, which metadata-standard we should use.
And - we want to share our files - so, in my opinion, a very simple
solution
is necessary.
I must admit, that the problem of standardisation (like address should
be)
should be considered. But what happens, if you change even simple
ESRI-Shape
files - you are very happy, if you could read all stuff, and don't have
to
bother with any normalisation that could not be restructured...
We think (because our partners have sometimes very little knowledge
about
GIS and metadata..) to build a very easy web-interface, like the
minimal
FGDC-standard, look at
http://www.fgdc.gov/clearinghouse/metadataesystem/metaform.html, this
seems
to fulfil our needs.
I have short question concerning standard of projections.... is there
a
common projection for working with EU-wide data? - thanks!
Dieter
----------------------------------------------------------------------------
------
Dieter Lehmann
Center for Geoinformation Processing Salzburg ZGIS
Institute for Geography and Geoinformation
University of Salzburg
Hellbrunnerstr. 34 A-5020 Salzburg Austria
phone +43-662-8044-5263
Dieter.Lehmann at sbg.ac.at
-----Ursprüngliche Nachricht-----
Von: Stefan F. Keller <sfkeller at hsr.ch>
An: freegis-list at intevation.de <freegis-list at intevation.de>
Datum: Mittwoch, 3. April 2002 16:32
Betreff: [Freegis-list] Re: metadata storage and fgdc
>Dear Alfred (Alfred de Jager <alfred.de-jager at jrc.it>),
>
>In freegis-list-request at intevation.de you wrote:
>
>> Date: Tue, 02 Apr 2002 18:09:01 +0200
>> From: Alfred de Jager <alfred.de-jager at jrc.it>
>> Organization: Joint Research Centre
>> To: freegis-list at intevation.de
>> Subject: [Freegis-list] Re: Freegis-list digest, Vol 1 #337 - 4
msgs
>>
>> Dear Alexander,
>>
>> Regarding your geodatabase metadata storage and fgdc metadata
collectors.
Please
>> take care before using these tools. They are merely conceived to
collect
in one
>> moment metadata not to update or relate between them. In order to do
the
latter
>> you better throw away all those flat-file models and start over with
a
>> 'normalized' model containing only the essentials.
>
>I completely agree!
>
>> Hint, try to update the phone number of your 'contact person' using
ArcGIS.
>> The problem of the whole GI metadata hype is that we do not apply
the
normal IT
>> rules of data normalization (no redundancy) and essentialization
(store
the
>> minimum and derive what is derivable).
>
>That's what we also try to do: take the most important thing of
geodata,
>that's the geodata schema (precisely described in INTERLIS
(=>UML=>XML)
>and derive from that what you can for metadata purposes. There is also
a
>object catalog (data dictionary) needed (in XML; there are papers on
>this methodology, see e.g. http://www.integis.ch, some are also in
>english available). The object catalog and the remainder needs
>definitely to be defined in a metadata/catalogueing model. That
what's
>ISO 19115 is doing.
>
>As a matter of fact, there is no sw around (I know of) to do this
>derivation and metadata management job.
>
>> GI Metadata is still an enduser wish list
>> and in any implementation I have seen thus far the whole thing is
mixed
and end
>> user perspective driven. Apperently nowbody cares about the
managebility
of
>> these data! I think we now know what the end user wants! We have
around 3
>> official committees writing down cryptic definitions for field names
like
>> 'title', 'author' etc. What we now need to do is to define which
information is
>> derivable and which is not. From what is not derivable you need to
check
if it
>> is essential (is my faxnumber essential to know at the level of
metadata?) if
>> not skip it.
>>
>> The remaining information needs to be normalized and stored in a
database
out of
>> which you generate (perhaps xml) information sheets. One does not
store
XML
>> sheets!!!!!!!
>
>Why not? XML is always better than .doc-Files, i.e. for explanatory
>text! An also better than ORACLE dumps. Depends what is in the XML!
>
>>Normalization means that every repeated piece of information (eg a
>> contact person) results in a separated relatable table. Such a
database
does not
>> exist in a generic way since the essentialization must result for
any
>> organization in a slightly different model. To exchange information
between
>> organizations both organizations must not only agree on a physical
protocol like
>> Z39 but more on the identification of their objects (contact
persons,
>> organizations, placenames, keywords, reference systems and the
whole
bunch).
>>
>
>I again completely agree! This is exactly why we developed INTERLIS
for
>defining geodata and data models. In addition - as a free side effect
-
>we can derive formats automatically - even GML if this is needed.
>Currently GML is not enough so that we use an own INTERLIS/XML-format
>(see www.interlis.ch for free documentation, ask interlis at lt.admin.ch
>for an official englisch version of this standard).
>
>> Conclusion.
>> Metadata systems when seriously applied do not come out of the box,
you
ought to
>> develop yourself a model and if you what to exchange metadata with
organizations
>> outside your model you should first agree on object identifiers
before
even
>> bothering on exchanging.
>
>With this INTERLIS geolanguage we are able to define and exchange
even
>metadata and catalogues. There is a working group to define a Swiss
>profile if ISO 19115 Metadata! There are some papers on this at
>http://www.kogis.ch.
>
>You have mentioned FGDC and ArcGIS/ArcCatalog. These models are
>outdated! We recommend the ISO Core (or even a subset of if like you
>suggest). Even OGC and ESRI is expected to change to ISO Metadata
>(because the project leader of the ISO group moved to ESRI, as I
heard
>from my ISO expert colleagues!).
>
>> My Hints:
>> Most databases contain a 'comment' field for any object,
unstructured
metadata
>> (definition of what it is, what units are used) can be stored best
in
there,
>> close to the data. For organisational information you just use the
contact
>> administration of e.g. your browser in which an email address can be
an
unique
>> identifier. Most browsers allow in various modes to 'share' that
information and
>> make it searchable. Note that browser contact information is not
normalized.
>> Thus if your organisation is large you better buy a contact
administration
>> package. Most GI metadata is derivable from the dataset themselves
and
using
>> simple batch programs you should be able to make that searchable as
well.
>> Geodatabase does the latter, partly, and if convenient for you, you
can
use
>> that. In Oracle (and other databases) the whole database structure
is
stored in
>> the database dictionary and thus using Geodatabase on top of Oracle
is a
little
>> bit double (understatement).
>>
>> What then remains is the creation of one table containing.... two
fields:
>>
>> "contactperson email", "physical dataset location"
>
>Perhaps a little too small list (:->)? I'd suggested in addition a
>"prize indicator".
>
>> Just imagine the simplicity.
>
>The message of N. Wirth and thus of INTERLIS was similar: "The Art of
>Simplicity".
>
>> Ciao
>> --
>> Drs. Alfred de Jager
>> Geographer, GIS and Database Consultant
>>
>> Portal for European Landscape Research
>> http://www.aris.sai.jrc.it/en/search-tools
>
>Regards
>-- Stefan Keller
>___________________________________________________________________
>Prof. Stefan F. Keller, Dozent fuer Informatik
>Center für integrierte Geo-Informationssysteme (int>e>gis)
>am Institut ITA-HSR der Hochschule fuer Technik Rapperswil (HSR)
>CH-8640 Rapperswil, Tel. 055 222 47 46, Fax 055 222 44 00
>mailto:sfkeller at hsr.ch, http://www.hsr.ch und http://integis.ch
>___________________________________________________________________
>HSR, der schönste Campus der Schweiz... siehe http://netcam.hsr.ch/
>
>_______________________________________________
>Freegis-list mailing list
>Freegis-list at intevation.de
>https://intevation.de/mailman/listinfo/freegis-list
_______________________________________________
Freegis-list mailing list
Freegis-list at intevation.de
https://intevation.de/mailman/listinfo/freegis-list
More information about the Freegis-list
mailing list
This site is hosted by Intevation GmbH (Datenschutzerklärung und Impressum | Privacy Policy and Imprint)