Hi all,
My contribution to the mapping document. The most update is the addition of the attribute coupledResource, mandatory to link data and WxS service correctly (without distribution tip)!
SERVICE - OPERATION :
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"
+1 for hierarchyLevel and hierarchyLevelName
Identifier.
I don't really understand Getcapabilites proposition. "WxS = uuid" ?
StandardName
We integrate only (cf. blow the answer of simon question) the ISO API profile. So I prefer ISO19119/2005
Date (mandatory in the 19115 core)
I proposed to use the escape solution defined in 19139. Use of attribute nilReason with 'unknown' value in /gmd:citation/gmd:CI_Citation/gmd:date
Status.
Why do you want to map thise optional information in 19139, in particular without any corresponding getcapabilities value ?
AccessConstraint
Add gco:CharacterString in 19139 mapping
8. TopicCategory is not necessary for the WMS ('service') metadata .
I just checked but TopicCategory doesn't be defined in 19119 API profile.
CRS
Getcapabilities mapping is /Root/Capabilities/Layer[1]/SRS for WMS but I'm not sure about the use of [1] or [*] (in other words, the first layer in WMS defined all generic information for all layers - if I remember the specification)? Fo WFS, I don't check.
Operation
Ok
coupledResource
In API profile, the information included in coupledResource is essential because it's the only solution to do the link between the a service operation (getMap/getFeatureInfo/...), the data and the name of the data in the WxS call (=Name of the layer)
For WMS :
For each layer with queryable = "1" and for /ROOT/Capability/Request/*[name()!='getCapabilities']
srv:coupledResource/srv:SV_CoupledResource/srv:OperationName <----> /ROOT/Capability/Request/child::name()
srv:coupledResource/srv:SV_CoupledResource/srv:identifier <--> UUID of the data metadata
srv:coupledResource/srv:SV_CoupledResource/gco:ScopedName --> Layer/Name (that's the tip (
For each layer with queryable = "0" and for /ROOT/Capability/Request/*[name()!='getCapabilities' and name!='GetFeatureInfo']
Idem
For WFS
TODO.
DATA
identifier
Create a unique identifier with uuid generator. But I don't know if it's possible with XSL ?
For coverage, hierarchyLevel is "dataset" ?
I think so.
Date
Same solution than service
Projection
Layer/SRS in WMS 1.1.1 - GetCapabilities (or Layer/CRS in WMS 1.3.0 !)
Scale
The iso standard doesn't allow to manage to min and max scale. I proposed to have to gmd:spatialResolution, the first for minscale and the second for maxscale.
9. TopicCategory is only necessary in the metadata with a hierarchyLevel of "dataset" or "series".
I agree with simon. Add topicategory in the data sheet.
CONTACT
No comments.
Very good job ! Just to add now the mapping with owsCommon standars (;-))
Pierre
-----Message d'origine-----
De : geonetwork-devel-bounces@lists.sourceforge.net [mailto:geonetwork-devel-bounces@lists.sourceforge.net] De la part de Francois-Xavier Prunayre
Envoyé : mercredi 12 décembre 2007 08:25
À : geonetwork-devel@lists.sourceforge.net
Objet : Re: [GeoNetwork-devel] OGC:GetCapabilities document to produceme tadata for services and layers in ISO19119/139 [SEC=UNCLASSIFIED]
Thanks for your comments Simon, Robert & John
John.Hockaday@anonymised.com wrote:
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?
Yes if a metadataUrl element with format set to xml in a Layer of the capabilities, GeoNetwork will try to load this xml doc first.
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'.
For coverage, hierarchyLevel is "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.
The harvesting process will try to generate thumbnails for each layers also. The interactive map feature will also work to view the 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.
Ok
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.
The main goal is to have no operations by human. And metadata harvested are in general read-only.
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"Hello 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
?
Yep, that's wrong in the wiki.
- I guess there is a typo in the "Abstract" 19115 path :
shouldn't it just be : gmd:abstract/gco:CharacterString ?
Yes it is.
- 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
Not really clear for me. Maybe more worked required here.
- 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
Do you mean for Layer elements ?
- 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 ?
Only Layer having no child Layer will be define with metadata (ie no group of layers).
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.
Thanks for your input.
Cheers,
Robert Rivière
-------------------------------------------------------------------------
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
**********************************************************************************************
Pensez à l'environnement avant d'imprimer ce message
Think Environment before printing
Le contenu de ce mél et de ses pièces jointes est destiné à l'usage exclusif du (des) destinataire(s) désigné
(s)
comme tel(s).
En cas de réception par erreur, le signaler à son expéditeur et ne pas en divulguer le contenu.
L'absence de virus a été vérifiée à l'émission, il convient néanmoins de s'assurer de l'absence de
contamination à sa réception.
The contents of this email and any attachments areconfidential. They are intended for the named recipient
(s)
only.
If you have received this email in error please notifythe system manager or the sender immediately and do
not
disclose the contents to anyone or make copies.
eSafe scanned this email for viruses, vandals and malicious content.
**********************************************************************************************