Hi All,
I agree that this is a long email. I can't remember the content of the start
of the email when I get to the end of it. ;--) However, am I right in saying
that the concept is to not only manage the metadata but also manage the data?
If this is so the ebRIM is an ideal model to do this.
I think that OGC is developing a draft ISO 19115 implementation of ebRIM for
CSW. This would seem the perfect model for GeoNetwork to link data to
metadata and visa versa. Is anyone interested in this?
Thanks.
John
-----Original Message-----
From: geonetwork-devel-bounces@lists.sourceforge.net
[mailto:geonetwork-devel-bounces@lists.sourceforge.net] On
Behalf Of Jeroen Ticheler
Sent: Friday, 19 October 2007 12:34 AM
To: Jo Walsh
Cc: Pedro Goncalves; michael gould;
geonetwork-devel@lists.sourceforge.net; okfn-discuss@anonymised.com
Subject: Re: [GeoNetwork-devel] Metadata registries too
domain specific or too general - how to fill in the gaps?Hi Jo,
That's a long mailOn Oct 17, 2007, at 11:39 PM, Jo Walsh wrote:
> In the GIS software world there is an overfocus on standards. Given
> several different domain models + XML serialisations, etc,
> all differingly mandatory in regional government data policies, what
> is an implementor to do? The GN answer is to use XML
templates (or XML
> documents as prototype templates) and to store per-package
metadata in
> BLOBs of XML in a database - extracting a few key properties for
> indexing.
>
> But it becomes harder to re-use, and get a 'network effect' from the
> re-use of, descriptions of people or organisations;The workflow should be more driven by the data; I mean that when the
data changes, metadata (that possibly sits with the data) is updated
automatically. The problem is/was that many people just had a
problem
to publish data with metadata anyway. As such the web based
editor is
a solution to them, even if not ideal. I hope that we get more
integration with the data processing applications (like ESRI
products, gvSIG, uDig and others). There's several initiatives that
attempt to further improve the automatic metadata generation
process.
It would be cool to see them evolve into powerful tools that many
users can benefit from through a simple to install and configuration
process.> the *internal
> structure* of these data sets can't often be expressed by the
> prevalent standards (ISO 19115, FGDC, etc). The information models,
> domain models for geographic data have a lot of specific
details in
> them
> that I don't necessarily want to fill out, or see on the screen.I think we see the network services like W*Ss provide the detail to
the client app, and as such hide it from the screen. This may need
further evolvement, but I would say "leave it as close to the
data as
possible, only provide the metadata you need to find the
resource and
make a first assessment".>
> I wrote a bit back when about the extrapolation of a "core model"
> from the current standards prevalent in geo-metadata; and also about
> what i perceive as structural flaws in some of the
information models
> designs that are byproducts of a "metadata first, data later" view.
> http://wiki.osgeo.org/index.php/Why_DCLite4G
> http://frot.org/terradue/minimal_metadata.htmlFrom what I see, metadata is almost always an afterthought. I can
understand although I disagreeIt should be something that is
done during and at the end of a data creation process. Usually
creating metadata after data results in other people writing
it, lots
of copying or duplication of metadata content etc... etc...
It indeed
shows that metadata should be part of the normal workflow and should
be really easy to do. I think we're fully aware that a web based
metadata editor from that perspective is not very useful, but eh,
remember the afterthought... It helps to get stuff published in a
consistent manner.>
> But implementation-wise this needs more than a generic CKAN, though.
> Foremost is ability to add spatial properties of data sets
- typically
> an envelope described by two X,Y points showing what area
of space the
> data set covers. This bleeds into wanting more things:
>
> - The ability to store and query geometry objects in the backend
> (for the postgres database this is supplied by PostGIS)
> - The ability to spatially filter search results from the frontend
> - "Semi-automatic" grabbing of a data set and extracting the spatial
> extents from the metadata in the file (usually possible)
> and post-facto inserting that into the metadata record.We're working on that here. Martin Seiler is writing a Python script
that does some nice things using GDAL/OGR
Also in Valencia the gvSIG guys are breeding on things. Not sure how
far they are. (copied Mike)>
> Last year it made sense to DIY with some homegrown geo extensions to
> sqlobject. Then GeoDjango came along and rendered all that obsolete,
> and I ported across in a couple of hours.Can you describe in simplistic language what that means for
me/us not
knowing Django?
>
> But now development-wise I feel i am stuck between two stools.
> GeoNetwork is doing a great job on both search UI and on support for
> standard "harvesting" protocols like old-school OAI-PMH and
> new-fangled OpenSearch.
>
> One interesting byproject there is the MEF data package format.
> This is a structured zipfile containing metadata about the data,
> metadata about the contents of the package, potentially accompanying
> screenshots and thumbnails, potentially the data itself.
> http://frot.org/terradue/explore_mef.html is an excerpt of the GN
> manual that describes MEF. Again it is geospatially specific in
> some assumptions about the detail, but this could be a useful way to
> think of delivering data from CKAN in something more approaching the
> "apt-get install london" dream.Would be cool to see something like a MEF be stored in CKAN and
deployed like that
without
data if data is too big and just point to the services or data.> MEF originated as part of an
> *interchange protocol between GN nodes* e.g. was a mechanism for
> registry/repositories to share data amongst one another.
>
> Now client-side software is getting into the act, e.g. the gvSIG
> graphical view and analysis program is getting a plugin that will
> generate stubs of MEFs, extract the spatial properties, i *assume*
> walk through filling in the more useful/mandatory fields, and POST
> the resulting metadata/data package off to a GeoNetwork instance.Ciao,Jeroen
>
> cheers,
>
>
> jo
>
> --
>
>
--------------------------------------------------------------
--------
> ---
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a
> browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> GeoNetwork-devel mailing list
> GeoNetwork-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
> GeoNetwork OpenSource is maintained at http://sourceforge.net/
> projects/geonetwork--------------------------------------------------------------
-----------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and
a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
GeoNetwork-devel mailing list
GeoNetwork-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at
http://sourceforge.net/projects/geonetwork
