[mapguide-dev] Metadata

Jason Birch Jason.Birch at nanaimo.ca
Tue Sep 19 16:28:04 EDT 2006

As an addendum,  this page is an interesting read:
... though it doesn't speak to ISO metadata standards at all.


From: Jason Birch [@nanaimo.ca] 
Sent: Tuesday, September 19, 2006 11:57
To: dev at mapguide.osgeo.org
Subject: RE: [mapguide-dev] Metadata

It sounds like you've given this considerable thought, which is
reassuring :)
In my ideal world, metadata would be modelled using the superset of
entities and attributes required by the ISO and FGDC standards, with the
potential to be expanded to cover other elements that are required but
not present in these standards.  From this model, you would not rely on
the standards other than to define the required elements for each
schema.  You could also allow organisations to define their own
profiles; subsets of required elements that cover their internal
business needs.  These would all be entered through a common interface,
and could then be output via something akin to an XSLT transformation or
database views that formats them into the desired standard XML output,
which could in turn be transformed into HTML for display.
The data could also be accessed by various transport-level services,
such as CSW (http://www.opengeospatial.org/standards/cat) or Z39.50 and
its successor SRU/SRW (http://www.loc.gov/standards/), as well as front
end applications such as a spatial discovery portal akin to ESRI's
Geography Network or a simple Google-like plain text query.
The main benefits of this approach are:
- support all standards without forcing the client to choose one or the
- avoid  having to implement a new data entry/storage/display framework
for each standard
- leverage strengths of a relational model for maintaining common
attributes such as organisation and person contact details
This will also remove a disincentive to marriage, thus strengthening
family values.  (I don't want to change my name, because I'm going to
have to go through and update all of my contact details in the
metadata). :)
I don't see this as orthogonal to the current design path, but I don't
know that it's entirely in alignment either.  Your implementation
provides a storage mechanism for metadata, and my ideal would be to
provide a metadata service.  Perhaps these could be combined somehow, by
making resources types for each of the metadata tables
(MetadataOrganisation, MetadataPerson, MetadataPhone, etc) and then
using the calls that you have provided to return a resource-specific
aggregation of these metadata resources, formatted in the well known XML
standard of choice ???
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/mapguide-internals/attachments/20060919/bc0c9ac1/attachment.html

More information about the Mapguide-internals mailing list