Jason.Birch at nanaimo.ca
Tue Sep 19 14:57:02 EDT 2006
It sounds like you've given this considerable thought, which is
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
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 ???
From: Carsten Hess [mailto:carsten.hess at autodesk.com]
Sent: Monday, September 18, 2006 17:45
To: dev at mapguide.osgeo.org
Subject: RE: [mapguide-dev] Metadata
Sorry for joining this discussion so late, I just didn't get around to
typing an answer about it sooner. Let me share with all of you the
thinking behind why I chose the signatures for the stubs in the
MapGuide Web API the way they are.
Metadata indeed is a tricky topic - I totally agree with you Jason.
There are several standards and most of them are used by a variety of
countries but none of them in all. In the US we have this law that asks
all government agencies to create FGDC metadata for all data they
create. As a result almost everyone in the US is mainly concerned about
native FGDC support.
If you go to Europe things are different, no one cares about FGDC, they
all want ISO ... Then there is the OGC standard which is gaining
So, no matter what standard we would choose to add to the MapGuide API,
it would be the wrong one ...
The only thing they all have in common is that they have a well defined
XML schema representation. So if in the MapGuide API we support a
general XML schema storage for Metadata we support the most common (if
not all) of the standards out there and applications can use the schema
information in the XML content to decide what kind of metadata they are
Then there was the question of whether we should make metadata its own
resource type or add a special API like I did. The reason why I chose a
new API ultimately is exactly your concern Jason. Storing metadata as a
xml blob may not be the right decision as it won't scale and all
resource data is stored as blob.
Ideally metadata could be indexed in a server so it can be searched
quickly. Since we are using DbXML indexing XML files is really easy.
Also different MapGuide applications could implement the metadata xml
differently and still it would sclae up which is much harder if we were
to choose making it a resource type or hardcode a specific metadata
So ... anyways ... that is where I am at with my thinking ... what do
you all think?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Mapguide-internals