From: Jeroen T. <Jer...@fa...> - 2005-09-28 07:50:55
|
Hi Luis, > > Yes, this is a right assesment, but my concerns are that the main > part of metadata isn't on the files, and on all your drafts of the > metadata harvesting you seemed to ignore this aspect. Technical > medatada authomatic extraction from file and services it's the > lesser part of metadata creation, and also it's the less > conflicting ones. > It seemed to me than this harvest was more the start of a kind od > 'metadata creation wizard', than a creator one. In fact it is, let me give you some more background on the use of this; Spatial data comes in very rapidly after a major disaster and needs to be catalogued in such a way that it requires the minimal time as possible in the early stages of the start of an emergency relief operation. Many versions of the same data may come in and data are updated frequently changing some of its data properties. At the same time it is critical that there is some kind of structure in how these data can be found again by others involved in the relief operations. At a later stage, when time permits, more time ca be taken to update the catalogued metadata. At that point it can also be decided more carefully what data to publish and what not on e.g. the internet. The data will be first catalogued in a set directory structure (this is how they work already). My idea is that we would use the template functionality GeoNetwork and an additional text file and/or fixed directory structure to generate a metadata record based on one of the templates, the information on the data set itself (including time of update) and the information as extracted from the text file (or another form of minimal metadata file with e.g. title, abstract and source) and with the directory structure. Someone coming in to deliver new data is required to fill out a minimum of metadata creating the file mentioned before. Such a form should not have more than two to four fields, otherwise it will just take too much time at first. > > For creation of services MapServices seem more suited, but again > this seem to me the lesser of the problems (maybe for my ignorance > or for a a selfish looking to the problem). Administering of map > services publication on our project it's a really challenging task, > due to the amount of info being served, and the variety of > formats. The search of optimization for this servers setups takes > a lot of time, and havind a kind of 'geoervices central > adminstration' would became, surely, the key feature for an 'easy > of deploy' FOSS SDI. Agreed. It would be great to see those server use metadata for their configuration. At the same time they could update their status in the metadata record so a user can see if the service is actually up and running for instance. > > But, on my thinking, both this GeoServices central admistration > service, and the semi-authomatic metadata creation need a good > definition as a problem, before of thinking of doing a prototype > (or even proof of concept) implementation Yes, hope this discussion helps in defining the problem related to the semi-automated creation of metadata at least. Ciao, Jeroen |