Hi All,
I tend to agree with some of the comments being sent about this development.
Here are some of mine:
1. The metadata record for the 'service' should be an ISO 19119 format with a
hierarchyLevel of "service" and a hierarchyLevelName of "service". This is
mandatory. The hierarchyLevelName could be "service - web map service" or
"service - WMS".
2. It is quite possible that the capabilities file already has references to
metadata records for each of the layers. Will this be harvested and
registered rather than create more metadata?
3. This metadata record should have aggregates of the layers that this
service provides. There is no reason to have a web map service if it doesn't
deliver layers. The documentation shows the connection using 'operates on'
which is probably fine. As long as there is some connection between them.
4. The metadata for each of these layers should be in ISO 19115 format (as
identified) with appropriate hierarchyLevels. Eg. "feature", "dataset" etc.
The only time whey you don't have to enter a hierarchyLevel or a
hierarchyLevelName is when it is a 'dataset'.
5. There should be distribution information ( as identified in the document)
in each of these metadata records that provide the URL for the service
including the parameters for the layer or feature. This will allow a user to
select the URL in metadata record and immediately show the image or
getFeatureInfo for that layer.
6. There should also be aggregate information for each of these metadata
records that show they are part of the WMS.
7. Why not include the URL of the service in the MD_Metadata/dataSetURI
element? This will allow very quick access to the service.
8. TopicCategory is not necessary for the WMS ('service') metadata .
9. TopicCategory is only necessary in the metadata with a hierarchyLevel of
"dataset" or "series".
10. The contact details are identified in the documentation but it seems to
indicate that this information is not available from the getCapabilities
file. The contact details are not necessary for the resource. They are only
necessary for the metadata and that can be generally determined during the
harvesting process. If the contact information is not available then don't
show it. It will be more efficient if there are no or minimal necessary
operations by a human during the creation of the metadata during the
harvesting process.
In general I am very supportive of this proposal. Not that I have any say in
it. ;--) However, I was also considering that a GN "Category" should be
"Services" or "Layers known by this CSW". This will allow a user to easily
list the layers (if there aren't too many of them) that can be added to the
interactive map.
Thanks.
John
-----Original Message-----
From: geonetwork-devel-bounces@lists.sourceforge.net
[mailto:geonetwork-devel-bounces@lists.sourceforge.net] On
Behalf Of "RIVIERE Robert - CETE Méditerr./DI/ETER"
Sent: Tuesday, 11 December 2007 9:55 PM
To: geonetwork-devel@lists.sourceforge.net
Cc: Robert.Riviere@anonymised.com
Subject: Re: [GeoNetwork-devel] OGC:GetCapabilities document
to produceme tadata for services and layers in ISO19119/139Hello François,
very interesting work. Thanks a lot to bring it back to us.
For a first read, I've focused on the "Data Mapping" and the
WMS capabilities side, I had worked on it some time ago.
I've got a few remarks / questions about this part :- why do you map "Layer identification" root element to a
gmd:indentificationInfo/srv:SV_ServiceIdentification ?
Couldn't you map it to a
gmd:indentificationInfo/gmd:MD_DataIdentification ? So you
shouldn't have to use the 19119 to describe the data layers,
just stay in 19115 ?- I guess there is a typo in the "Abstract" 19115 path :
shouldn't it just be : gmd:abstract/gco:CharacterString ?- about the scale : I think we'll rather often find a
ScaleHint in capabilities. Perhaps some work needed to
convert it to a gmd:RS_Identifier- for projection : you've got of course the /ROOT/SRS on the
GetCapabilities side- I've also seen some WMS capabilities embedding a
KeywordList which could be mapped on 19115 gmd:MD_Keywords- and on a higher level I can't see yet how to organize
things between : W*S Service identification / "1st level"
layer in capabilities / layer/layer items in capabilities.
Are you going to build only one gmd:MD_Metadata hierarchy
describing all of these ? Or will you have several ones ?Unfortunately I work on this subject a very small part of my
time. But I'd be glad to participate to a working group on
this subject if there exists one.Cheers,
Robert Rivière
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
>--------------------------------------------------------------
-----------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
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