[mapguide-dev] Metadata

Jason Birch Jason.Birch at nanaimo.ca
Tue Sep 19 18:56:35 EDT 2006

I was thinking that you could have a superset database model, and then
the site could choose whether to use the FGDC subset, the ISO subset, or
a personalised subset that meets internal needs.  This could be done on
the database level with something like:
  SchemaID, Name
  1, FGDC
  2, ISO
  5, CityOfNanaimo
  ElementID, Name
  1, Organisation
  2, Contact
  3, Description
  4, Scale
  5, Source Path
  6, MapGuide Layer Resource ID
  SchemaID, ElementID, Required
  1, 1, True
  1, 2, True
  1, 3, True
  1, 4, False
  4, 1, True
  4, 2. True
  4, 3, True
  4, 6, True
Then the organisation could easily flip a switch to choose which schema
to use, or build their own.
As far as translating between them...  I was thinking interoperability.
In Canada we're more likely to use the ISO standard than FGDC (though
hopefully there will be some kind of convergence there) but it would
also be desirable to be able to provide FGDC metadata when sharing data
on cross-border initiatives.  For geospatial portals there would be a
benefit to maintaining the attributes required for both and being able
to output either based on the request parameters.  Also, for MapGuide
hosting providers, there will be a need to be able to provide metadata
services in the format requested by their clients.  Maybe I'm thinking
too far ahead, or for a need that isn't there but...


From: Carsten Hess [mailto:carsten.hess at autodesk.com] 
Sent: Tuesday, September 19, 2006 15:02
To: dev at mapguide.osgeo.org; dev at mapguide.osgeo.org
Subject: RE: [mapguide-dev] Metadata

ah this is indeed an interesting read - I haven't look at that yet at
all. Thanks for pointing it out.
When I looked at metadata I mainly focused on FGDC and ISO and there
simply doesn't seem to be a true common metadata storage we could do
that we translate to the different standards. Both of them have fields
that are required the other standard doesn't seem to have. So ... a
common metadata storage would have to have even more required fields
(and frankly there are already too many if you ask me). 
So the way I was looking at this is to use XSL stylesheets to convert
between the two standards if we really need to. 
Honestly though I doubt we do ... I think whoever sets up a data
repository will work in one standard and rather have all metadata in the
same standard. I don't really see where a MapGuide site needs to be more
then one standard at a time. 

Then there are benefits of storing the native standards format: We can
make use of the tools around it (e.g. the FGDC compiler to verify
compliant FGDC) and often people already have written some code to
create the standards they need from files or at least help it. Being
able to just upload the standard files into MapGuide seems like a great
way to use these tools.
At the same time it is pretty clear that different sites want different
standards and if a site does support one standard they want it all the
way and not some subset of it.
If I were to dream it would be great to see multiple API's ontop of the
one I added, one for ISO and one for FGDC and when you create your
mapguide site you use one API or the other. 
Ultimately I think full compliance is what most people really will want.
I have not heard or seen anyone yet trying to convert between different
standards, have you?

	-----Original Message----- 
	From: Jason Birch [mailto:Jason.Birch at nanaimo.ca] 
	Sent: Tue 9/19/2006 4:28 PM 
	To: dev at mapguide.osgeo.org 
	Subject: RE: [mapguide-dev] Metadata
	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 other
	- 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/7bae4dd5/attachment.html

More information about the Mapguide-internals mailing list