[GeoNetwork-devel] INSPIRE view of metadata for services

dear all, this is a followup to a chat with Jeroen at the recent gvSIG
user meeting, and i got to ask Max Craglia this question too,
about what advice the INSPIRE (European SDI) project is offering about
common ways of referring to web service protocols with URLs or similar
identifiers.

The short answer is - no guidance yet, more of a request for feedback.
On the one hand, there's a felt need for common identifiers for OGC,
KML, etc web services standards that exist now. On the other, there is
concern about 'futureproofing' an effort designed to extend over the
next 5-10 years. The INSPIRE IRs plan to mandate a service
classification code list created "in collaboration with the
stakeholder community". That includes us!

... more detail on the draft legislative fine print + process ...

I had a look at what the draft INSPIRE IRs now say about sharing
descriptions of web service interfaces (something that will be key to
any "compliance-o-matic" regarding Network Services Implementing Rules.)

This is Annex B.3 from the draft Implementing Rules:

  B.3 Classification of spatial data services
  The values are based on the geographic services taxonomy of EN ISO
  19119 and will be developed further with input of stakeholder
  communities. This taxonomy is organized in categories, the
  subcategories defining the value domain of the classification of
  spatial data services.

The informative document mapping ISO 19915/9 to the INSPIRE metadata
model says this:

  2.2.2.2 Classification of spatial data services For classification of
  spatial data services, the Implementing Rules mandate the use of the
  value domain of Annex B.3. This value domain does not exist within any
  existing code list of EN ISO 19115 or EN ISO 19119. The class
  SV_ServiceType in 19119 is undefined. Following the requirement from
  the Implementing Rules, Annex B.3 of the IRs shall be the basis for a
  new code list IR_ServiceClassificationCode that needs to be created in
  collaboration with the stakeholder community as indicated in the IRs,
  section 2.4. Subsequently, the code list can be used by the EN ISO
  19119 metadata element serviceType as described below...
  MD_Metadata.identification.SV_ServiceIdentification...

This implies, though does not dictate, that a *numeric classification
code list* should, and does not yet, exist to define types of web service.
Below is section 2.4 of the IRs *in full*, which should tell us how to
get involved in contributing prior art or best practise to this process:

  2.4 Guidelines and instructions for implementation
  The European Commission shall establish, in collaboration with
  stakeholders and relevant standardisation organisations, detailed
  guidelines and instructions for implementation to ensure
  interoperability of metadata. These will include instructions on how
  the European standards EN ISO 19115 and EN ISO 19119 shall be used to
  disseminate INSPIRE metadata, should one chose to use these standards.

In short, the INSPIRE process is asking for, rather than requiring,
guidance on the subject of web services descriptions, right now.
The approved route will be through CEN and ISO advisory committees.

cheers,

jo

----- End forwarded message -----

Hi Jo,
After a good discussion on several mailing lists in parallel, one idea that came out as kind of the nicest solution was to use a standard ATOM link for the URL and mimetypes for the type of service. I am very much tempted to use that scheme to describe service URLs and service types in ISO19115's online resource section (the linkage and protocol fields). It makes for a fairly clean way of understanding what type of content one has to deal with and mimetypes for OGC services, KML, KMZ, PDF and what not have all already been defined and are registered. Most web servers (if not all!?) know about mimetypes and can be configured to deal with new mimetypes.

It would look like:

<link type="application/vnd.ogc.wms" href="http://geonetwork3.fao.org/ows/1&quot;/&gt;

Not sure how 19119 deals with this, but such schema would also work for Dublin Core or other small metadata schemas.

See for the full post:
http://lists.eogeo.org/pipermail/georss/2007-October/001689.html

Opinions appreciated.
Ciao,
Jeroen

On Nov 17, 2007, at 9:25 AM, Jo Walsh wrote:

dear all, this is a followup to a chat with Jeroen at the recent gvSIG
user meeting, and i got to ask Max Craglia this question too,
about what advice the INSPIRE (European SDI) project is offering about
common ways of referring to web service protocols with URLs or similar
identifiers.

The short answer is - no guidance yet, more of a request for feedback.
On the one hand, there's a felt need for common identifiers for OGC,
KML, etc web services standards that exist now. On the other, there is
concern about 'futureproofing' an effort designed to extend over the
next 5-10 years. The INSPIRE IRs plan to mandate a service
classification code list created "in collaboration with the
stakeholder community". That includes us!

... more detail on the draft legislative fine print + process ...

I had a look at what the draft INSPIRE IRs now say about sharing
descriptions of web service interfaces (something that will be key to
any "compliance-o-matic" regarding Network Services Implementing Rules.)

This is Annex B.3 from the draft Implementing Rules:

  B.3 Classification of spatial data services
  The values are based on the geographic services taxonomy of EN ISO
  19119 and will be developed further with input of stakeholder
  communities. This taxonomy is organized in categories, the
  subcategories defining the value domain of the classification of
  spatial data services.

The informative document mapping ISO 19915/9 to the INSPIRE metadata
model says this:

  2.2.2.2 Classification of spatial data services For classification of
  spatial data services, the Implementing Rules mandate the use of the
  value domain of Annex B.3. This value domain does not exist within any
  existing code list of EN ISO 19115 or EN ISO 19119. The class
  SV_ServiceType in 19119 is undefined. Following the requirement from
  the Implementing Rules, Annex B.3 of the IRs shall be the basis for a
  new code list IR_ServiceClassificationCode that needs to be created in
  collaboration with the stakeholder community as indicated in the IRs,
  section 2.4. Subsequently, the code list can be used by the EN ISO
  19119 metadata element serviceType as described below...
  MD_Metadata.identification.SV_ServiceIdentification...

This implies, though does not dictate, that a *numeric classification
code list* should, and does not yet, exist to define types of web service.
Below is section 2.4 of the IRs *in full*, which should tell us how to
get involved in contributing prior art or best practise to this process:

  2.4 Guidelines and instructions for implementation
  The European Commission shall establish, in collaboration with
  stakeholders and relevant standardisation organisations, detailed
  guidelines and instructions for implementation to ensure
  interoperability of metadata. These will include instructions on how
  the European standards EN ISO 19115 and EN ISO 19119 shall be used to
  disseminate INSPIRE metadata, should one chose to use these standards.

In short, the INSPIRE process is asking for, rather than requiring,
guidance on the subject of web services descriptions, right now.
The approved route will be through CEN and ISO advisory committees.

cheers,

jo

----- End forwarded message -----

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
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

Dear all,

I agree with Jo’s point.
We’re now establishing an SDI that will comply with INSPIRE (among other standards).
Hence, we’re directly involved in the INSPIRE drafting as a registered entity (so-called SDIC).

The INSPIRE process, which still has quite a lot of way to go, is indeed one that
incorporates the various stakeholders from the beginning.

In general, you can:

  1. provide “experts” to help write the IR, consolidate relevant docs, etc.
  2. provide input/review comments on the IRs (either as SDIC/LMO or as part of the “general public”)
  3. provide documents that describe how you implement this and what you
    consider as “good practice”.
    So, no “guidance”, only requests for helping to establish & refine the IRs (bottom-up approach).

Please also consider that INSPIRE is at first only intended for
-environmental data
-data exchange between the national and EU level SDI(s) and can thus at most
be considered as a “recommendation” for other SDIs.

In general, though, I agree that the MIME-type approach looks promising.

Cheers,

Tim


Date: Sat, 17 Nov 2007 00:25:13 -0800
From: jo@anonymised.com
To: geonetwork-devel@lists.sourceforge.net
Subject: [GeoNetwork-devel] Fw: INSPIRE view of metadata for services

dear all, this is a followup to a chat with Jeroen at the recent gvSIG
user meeting, and i got to ask Max Craglia this question too,
about what advice the INSPIRE (European SDI) project is offering about
common ways of referring to web service protocols with URLs or similar
identifiers.

The short answer is - no guidance yet, more of a request for feedback.
On the one hand, there’s a felt need for common identifiers for OGC,
KML, etc web services standards that exist now. On the other, there is
concern about ‘futureproofing’ an effort designed to extend over the
next 5-10 years. The INSPIRE IRs plan to mandate a service
classification code list created “in collaboration with the
stakeholder community”. That includes us!

… more detail on the draft legislative fine print + process …

I had a look at what the draft INSPIRE IRs now say about sharing
descriptions of web service interfaces (something that will be key to
any “compliance-o-matic” regarding Network Services Implementing Rules.)

This is Annex B.3 from the draft Implementing Rules:

B.3 Classification of spatial data services
The values are based on the geographic services taxonomy of EN ISO
19119 and will be developed further with input of stakeholder
communities. This taxonomy is organized in categories, the
subcategories defining the value domain of the classification of
spatial data services.

The informative document mapping ISO 19915/9 to the INSPIRE metadata
model says this:

2.2.2.2 Classification of spatial data services For classification of
spatial data services, the Implementing Rules mandate the use of the
value domain of Annex B.3. This value domain does not exist within any
existing code list of EN ISO 19115 or EN ISO 19119. The class
SV_ServiceType in 19119 is undefined. Following the requirement from
the Implementing Rules, Annex B.3 of the IRs shall be the basis for a
new code list IR_ServiceClassificationCode that needs to be created in
collaboration with the stakeholder community as indicated in the IRs,
section 2.4. Subsequently, the code list can be used by the EN ISO
19119 metadata element serviceType as described below…
MD_Metadata.identification.SV_ServiceIdentification…

This implies, though does not dictate, that a numeric classification
code list
should, and does not yet, exist to define types of web service.
Below is section 2.4 of the IRs in full, which should tell us how to
get involved in contributing prior art or best practise to this process:

2.4 Guidelines and instructions for implementation
The European Commission shall establish, in collaboration with
stakeholders and relevant standardisation organisations, detailed
guidelines and instructions for implementation to ensure
interoperability of metadata. These will include instructions on how
the European standards EN ISO 19115 and EN ISO 19119 shall be used to
disseminate INSPIRE metadata, should one chose to use these standards.

In short, the INSPIRE process is asking for, rather than requiring,
guidance on the subject of web services descriptions, right now.
The approved route will be through CEN and ISO advisory committees.

cheers,

jo

----- End forwarded message -----


This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/


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


Connect to the next generation of MSN Messenger Get it now!

Jeroen Ticheler wrote:

Hi Jo,
After a good discussion on several mailing lists in parallel, one
idea that came out as kind of the nicest solution was to use a
standard ATOM link for the URL and mimetypes for the type of service.
I am very much tempted to use that scheme to describe service URLs
and service types in ISO19115's online resource section (the linkage
and protocol fields). It makes for a fairly clean way of
understanding what type of content one has to deal with and mimetypes
for OGC services, KML, KMZ, PDF and what not have all already been
defined and are registered. Most web servers (if not all!?) know
about mimetypes and can be configured to deal with new mimetypes.

It would look like:

<link type="application/vnd.ogc.wms" href="http://geonetwork3.fao.org/
ows/1"/>
  

looks nice and simple :slight_smile:

Not sure how 19119 deals with this, but such schema would also work
for Dublin Core or other small metadata schemas.
  

I guess for ISO19119 or ISO19139 it will be the same. Do we need to
update protocol list (OGC:WMS-1.1.1-http-get-map, ...)? The @type will
be in the protocol element of an srv:connectPoint for 119 and gmd:onLine
for 139
gmd:CI_OnlineResource/gmd:linkage
+ /gmd:URL = link/@href
+ /gmd:protocol/gco:CharacterString = link/@type

Using mime type can we make distinction between a WMS GetMap and a WMS
GetCapabilities as we do using the list of protocol ? Maybe this is not
necessary, we only need the entry point of the service.

Francois

See for the full post:
http://lists.eogeo.org/pipermail/georss/2007-October/001689.html

Opinions appreciated.
Ciao,
Jeroen

On Nov 17, 2007, at 9:25 AM, Jo Walsh wrote:

dear all, this is a followup to a chat with Jeroen at the recent gvSIG
user meeting, and i got to ask Max Craglia this question too,
about what advice the INSPIRE (European SDI) project is offering about
common ways of referring to web service protocols with URLs or similar
identifiers.

The short answer is - no guidance yet, more of a request for feedback.
On the one hand, there's a felt need for common identifiers for OGC,
KML, etc web services standards that exist now. On the other, there is
concern about 'futureproofing' an effort designed to extend over the
next 5-10 years. The INSPIRE IRs plan to mandate a service
classification code list created "in collaboration with the
stakeholder community". That includes us!

... more detail on the draft legislative fine print + process ...

I had a look at what the draft INSPIRE IRs now say about sharing
descriptions of web service interfaces (something that will be key to
any "compliance-o-matic" regarding Network Services Implementing
Rules.)

This is Annex B.3 from the draft Implementing Rules:

  B.3 Classification of spatial data services
  The values are based on the geographic services taxonomy of EN ISO
  19119 and will be developed further with input of stakeholder
  communities. This taxonomy is organized in categories, the
  subcategories defining the value domain of the classification of
  spatial data services.

The informative document mapping ISO 19915/9 to the INSPIRE metadata
model says this:

  2.2.2.2 Classification of spatial data services For
classification of
  spatial data services, the Implementing Rules mandate the use of the
  value domain of Annex B.3. This value domain does not exist
within any
  existing code list of EN ISO 19115 or EN ISO 19119. The class
  SV_ServiceType in 19119 is undefined. Following the requirement from
  the Implementing Rules, Annex B.3 of the IRs shall be the basis
for a
  new code list IR_ServiceClassificationCode that needs to be
created in
  collaboration with the stakeholder community as indicated in the
IRs,
  section 2.4. Subsequently, the code list can be used by the EN ISO
  19119 metadata element serviceType as described below...
  MD_Metadata.identification.SV_ServiceIdentification...

This implies, though does not dictate, that a *numeric classification
code list* should, and does not yet, exist to define types of web
service.
Below is section 2.4 of the IRs *in full*, which should tell us how to
get involved in contributing prior art or best practise to this
process:

  2.4 Guidelines and instructions for implementation
  The European Commission shall establish, in collaboration with
  stakeholders and relevant standardisation organisations, detailed
  guidelines and instructions for implementation to ensure
  interoperability of metadata. These will include instructions on how
  the European standards EN ISO 19115 and EN ISO 19119 shall be
used to
  disseminate INSPIRE metadata, should one chose to use these
standards.

In short, the INSPIRE process is asking for, rather than requiring,
guidance on the subject of web services descriptions, right now.
The approved route will be through CEN and ISO advisory committees.

cheers,

jo

----- End forwarded message -----

----------------------------------------------------------------------
---
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
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: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
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
  
--
Francois Xavier Prunayre
Camptocamp France SAS
Savoie Technolac, BP 352
73377 Le Bourget du Lac Cedex
Tel : + 33 (0)6 34 11 71 75
http://www.camptocamp.com
francois-xavier.prunayre@anonymised.com

Hi Francois,

On Nov 20, 2007, at 9:39 AM, Francois-Xavier Prunayre wrote:

It would look like:

<link type="application/vnd.ogc.wms" href="http://geonetwork3.fao.org/
ows/1"/>

looks nice and simple :slight_smile:

Not sure how 19119 deals with this, but such schema would also work
for Dublin Core or other small metadata schemas.

I guess for ISO19119 or ISO19139 it will be the same. Do we need to
update protocol list (OGC:WMS-1.1.1-http-get-map, ...)? The @type will
be in the protocol element of an srv:connectPoint for 119 and gmd:onLine
for 139
gmd:CI_OnlineResource/gmd:linkage
+ /gmd:URL = link/@href
+ /gmd:protocol/gco:CharacterString = link/@type

Using mime type can we make distinction between a WMS GetMap and a WMS
GetCapabilities as we do using the list of protocol ? Maybe this is not
necessary, we only need the entry point of the service.

Yes, I think it wouldn't be necessary. Normally a server should not do a GetMap request instantly. If a ful GetMap request URL was put in the metadata, the mime type would actually be something like image/png, image/jpeg or so, since that's what it produces :slight_smile:

For MEF files we could introduce a new mime type :slight_smile:

Ciao,
Jeroen