Comments & questions below.
Simon Pigot wrote:
> Francois-Xavier Prunayre wrote:
>> Hi all, this is not yet a proposal for GeoNetwork but we're currently
>> working on adding harvesting GetCapabilities document from WMS/WFS
>> service and will be glad to get comments/inputs on that topic. It will
>> harvest capabilities from service supporting WMS, WFS or WCS spec.
>>
>> A mapping from the GetCapabilities document is defined to produce :
>> - one metadata for the service (using ISO19119)
>> - n metadata for all layers/FeatureType/Coverage available in that
>> service (ISO19139)
>>
>> It will use the same mechanism as the harvesting for other sources
(ie.
>> CSW, OAI, WebDav ...).
>>
>> On the R&D section of the trac you could access to a draft document
>> http://trac.osgeo.org/geonetwork/wiki/ISO19119impl presenting :
>> - use cases
>> - GUI
>> - mapping
>>
>> This development is made in the context of GeoSciML & OneGeology
>> projects with BRGM.
>>
>> Comments & inputs welcomed.
>>
>> Ciao. Francois
>>> Hi Francois,
>
> Looks good! We've also been working on this but you're further down the
> track than us in setting up the harvester - I have a few questions:
>
> 1. How are we going to deal with the difference between the capabilities
> statements (vendors and OGC versions)? I'm looking at deegree's 1.3.0
> wms capabilities for example (as its our use case) and its a bit
> different to the mapping you've defined (its one that we're working on a
> mapping for now). I thought we could use or pinch some of this from OGC
> client toolkits like GeoTools which seem to deal quite nicely with
> different vendors/OGC versions?
I made test with mapserver, geoserver version 1.1.1 for now. Will have a
look to deegree (do you have any public URL for test ?) ... and other
spec also.
>
> 2. I think we've done the same as you for integrating 19119 into GN -
> but just to check - 19139 has a MD_ServiceIdentification element which
> doesn't display as a choice in GN 2.1 but does under the modified schema
> parsing code I've worked on (it says see 19119 for more detail) which
> seems to indicate to me that the best way to integrate 19119 and 19139
> is to make SV_ServiceIdentification a member of the substitution group
> for MD_AbstractIdentification - 19119 doesn't appear as a separate
> schema then its just part of 19139. If you're building a metadata record
> with service metadata you use (or choose) srv:SV_ServiceIdentification
> in place of gmd:MD_DataIdentification. You don't need a separate tab in
> the editor then either - everything appears under 'Identification'.
I think that's what Pierre did. Did you work on the xsl for the
presentation of all 19119 section (OperateOn, Operations, ...) ? I've
one which is not nice for the time being ... so inputs are welcomed on
that 
> 3. Is there more that can be done with the Operations metadata mapping?
> I thought we could map parameters including layer names etc as part of
> this section but I haven't worked it out completely yet.
We certainly could do a lot in that area, but I'm not really convinced
by duplicate all technical details comming from the capabilities to the
metadata on each operations, protocols, mime-type, ...
Ciao. Francois
>
> Cheers,
> Simon