MIWP-8: Metadata - Task #2304 MIWP-8 (J) Metadata for SDS Category

Transcription

1 MIWP-8: Metadata - Task #2304 MIWP-8 (J) Metadata for SDS Category 08 Jan :21 am - Ine de Visser Status: Submitted Start date: 17 Sep 2014 Priority: Normal Due date: Assignee: % Done: 0% Category: Estimated time: 0.00 hour Proposed change or action: Description Category (TG SDS 4.5.1) A metadata element "category" as specified in Annex A shall indicate if the spatial data service is Invocable, Interoperable or Harmonised. In order to describe the Spatial Data Service Conformity Class in a machine readable way, the standard [ISO 19115]/[ISO 19119] has to be extended. Therefore, this element has to be provided if the Spatial Data Service is invocable, interoperable or harmonised. Actions: 1. Update TG MD with this element, 2. give examples, explain relation with service type,explain condition, provide a codelist Related issues: Copied from MIWP-8: Metadata - Task # 2219: MIWP-8 (J) Metadata for SDS Submitted 17 Sep 2014 Copied to MIWP-8: Metadata - Task # 2305: MIWP-8 (J) Metadata for SDS Resourc... Submitted 17 Sep 2014 History #1-14 Jan :38 pm - Ine de Visser For this metadata element the following is written down; COMMISSION REGULATION (EU) No 1312/2014 of 10 December 2014 amending Regulation (EU) No 1089/2010 implementing Directive 2007/2/EC of the European Parliament and of the Council as regards interoperability of spatial data services The new metadata describing the spatial data service shall comprise the metadata elements or groups of metadata elements listed; Category Metadata Element 1. Category This is a citation of the status of the spatial data service versus invocability. The value domain of this metadata element is as follows: 1.1. Invocable (invocable) The spatial data service is an invocable spatial data service Interoperable (interoperable) The invocable spatial data service is an interoperable spatial data service 1.3. Harmonised (harmonised) The interoperable spatial data service is a harmonised spatial data service. On the other hand in; 23 Jan /10

2 COMMISSION REGULATION (EC) No 1205/2008 of 3 December 2008 implementing Directive 2007/2/EC of the European Parliament and of the Council as regards metadata 2.2. Spatial data service type This is a classification to assist in the search of available spatial data services. A specific service shall be categorised in only one category. The value domain of this metadata element is defined as; SPATIAL DATA SERVICE TYPE 3.1. Discovery Service (discovery) Services making it possible to search for spatial data sets and services on the basis of the content of the corresponding metadata and to display the content of the metadata View Service (view) Service that makes it possible, as a minimum, to display, navigate, zoom in and out, pan or overlay viewable spatial data sets and to display legend information and any relevant content of metadata Download Service (download) Service that enables copies of spatial data sets, or parts of such sets, to be downloaded and, where practicable, accessed directly Transformation Service (transformation) Service that enables spatial data sets to be transformed with a view to achieving interoperability Invoke Spatial Data Service (invoke) Service that allows defining both the data inputs and data outputs expected by the spatial service and a workflow or service chain combining multiple services. It also allows defining the external web service interface of the workflow or service chain Other Service (other) Proposed change in TG MD; To extend the value domain of spatial data service type with two values, interoperable and harmonised as below; 23 Jan /10

3 SPATIAL DATA SERVICE TYPE Discovery Service (discovery) View Service (view) Download Service (download) Transformation Service (transformation) Invoke Spatial Data Service (invoke) Interoperable Spatial Data Service (interoperable) Harmonised Spatial Data Service (harmonised) Other Services (other) #2-18 Jan :30 pm - Age Sild Hi. I see a conflict in adding SDS Category elements under SDS Type metadata. In Draft Technical guidelines for SDS at page 10 (3.1 Terms) are definitions: (3) Invocable spatial data service means the following: a) a spatial data service with metadata according to Regulation (EU) No 1205/2008, b) a spatial data service with at least one resource locator that is an access point, c) and a spatial data service in conformity with a documented and publicly available set of technical specifications providing the information necessary for its execution. (4) Interoperable spatial data service: an invocable spatial data service in conformity with the annex VII of the proposed amendment to [INT SDS]. (5) Harmonised spatial data service: an interoperable spatial data service in conformity with the annex VIII of the proposed amendment to [INT SDS]. In consideration of Invocable SDS definition I think I can say for example that some dowload service or transformation service can meet invocable SDS criteria as well. But multiplicity of SDS Type is 1 and SDS Category has I may chose only one service type. 23 Jan /10

4 #3-21 Jan :31 pm - Ine de Visser A downloadservice (conform the network services regulation) has requirements on the quality of the service and the service itself. An inokable service has no requirements on that point, other that the service provider must report the minimum quality and the service spacification used. If a invokable service meets those requirents of Quality of service and download service specification, it's a download service. But the definitions of spatial data services can be interpretated in other ways. My point is that I can't explain to dataproviders there are two classifications of spatial data services required in the metadata, both containing spatial data service types both with the value invoke. We have a problem here with definitions of invoke in two different regulations. Metadata regulation; 3.5. Invoke Spatial Data Service (invoke) Service that allows defining both the data inputs and data outputs expected by the spatial service and a workflow or service chain combining multiple services. It also allows defining the external web service interface of the workflow or service chain. versus SDS regulation; 33. "Invocable spatial data service" means all of the following: (a) a spatial data service with metadata which fulfils the requirements of Commission Regulation (EC) No 1205/2008 (*), (b) a spatial data service with at least one resource locator that is an access point, (c) a spatial data service in conformity with a documented and publicly available set of technical specifications providing the information necessary for its execution, I think we need a change in definition(s) so they are clear and inline with each other. #4-21 Jan :02 pm - Ine de Visser In TG SDS they also recognize the different definitions of invoke; TG SDS; "1. Invocable spatial data service. The invocability is an intrinsic property of the spatial data services that following the definition in article 3 (4) of [INS DIR] provides invocable operations. Here, as detailed in 4.5, the invocability is understood in a more restricted sense including the availability of an access point on the Internet. This sub-set is defined to explicitly list the minimum set of properties a spatial data service must possess for invocability. " They aslo see the invoke, interoperable and harmonised spatial services types next to the network spatial services types, view, download, 23 Jan /10

5 transformation, discovery; "Once a spatial data service is described by INSPIRE metadata (as requested in article 5 (1) of [INS DIR] and detailed in [INS MD]) it becomes an INSPIRE spatial data service through the INSPIRE Network Service of type discovery (as requested in article 11 (1) of [INS DIR] and technically specified in [NS]). As stated in Article 18 of the proposed amendment to [INT SDS], this Technical guidance are not applicable to the network services that have their own set of implementing rules in Regulation No 976/2009" #5-21 Jan :54 pm - Marc Leobet Dear colleagues, I feel some misunderstanding between regulations, am I wrong? There is a clear discrimination between network services and SDS : the firsts are outside the second scope. Please see Commission Regulation n 1312/2014, art. 1.2 : "This Regulation does not apply to the network services falling within the scope of Commission Regulation (EC) No 976/2009." It means that Download services (and all NS, and Invoke services) are not in the scope of SDS metadata. That is why, in Fig. 2 of SDS TG (v 3.0), the NS are outside the box You will note that Invoke services are not regulated by one or the other regulation; they are just quoted in the directive itself. This is not an oblivion. We met an impossibility to draft something consistent. We have just adopted something about "invokable" services. So, following a legal point of view, Invoke services are a possibility with no frame. Best regards #6-22 Jan :39 am - Michael Östling The legal framework for SDS should be quite clear, but I maybe fully grasp the details. The following Amendment desrcibes the legal framework. COMMISSION REGULATION (EU) No 1312/2014 of 10 December 2014 amending Regulation (EU) No 1089/2010 implementing Directive 2007/2/EC of the European Parliament and of the Council as regards interoperability of spatial data services The Inspire SDS are as I see it, Spatial data services operating on Inspire data themes, that are not Network services. The following illustration from Draft TG on SDS shows that. So we should have no service that are both a Inspire SDS and a Network service. /system/rich/rich_files/rich_files/000/000/037/original/inspire_sds.png 23 Jan /10

6 #7-22 Jan :37 pm - Ine de Visser Thanx for the explanation on invoke and invocable. So the codelist should also contain invocable. Proposed change in TG MD; To extend the value domain of spatial data service type with two values, interoperable and harmonised as below; SPATIAL DATA SERVICE TYPE Discovery Service (discovery) View Service (view) Download Service (download) Transformation Service (transformation) Invocable Spatial Data Service (invocable) Interoperable Spatial Data Service (interoperable) Harmonised Spatial Data Service (harmonised) Invoke Spatial Data Service (invoke) Other Services (other) #8-06 Feb :34 pm - Martin Seiler I think this is a good solution and agree that the network services are out of scope here. Howerver I think as a consequence we would need an update of the Metadata IR (1205/2008), as it reads in section 2.2: Spatial data service type This is a classification to assist in the search of available spatial data services. A specific service shall be categorised in only one category. The value domain of this metadata element is defined in Part D.3. So if we extend the value domain this has to be changed in the IR. My suggestion would be to propose this change in the TG and file a change request for the IR to the MIG-T/P. #9-19 Feb :25 pm - Marc Leobet Thanks Martin to highlight this point. I passed too fast over the Ine's comment #7. 23 Jan /10

7 It would be better to stay regulations unchanged. Legal process is heavy and uncontrolable. And we have avoided to change Metadata regulation when adopting SDS's one less than one year ago. The Regulation n 1209/2008 requires a mandatory element in a codelist - the five network services (following Art. 13 of the directive) in black in Ine's comment #7 and "Other Services (other)". I propose to use the "Other Services (other)" value for SDS in SPATIAL DATA SERVICE TYPE codelist. In parallel, the "Category Metadata Element" was created to describe the type of "other services". I spent one hour to look back seriously to all that crossed-regulations, although I have voted them. No way for a developper to understand anything. A good point for dedicated chapter for SDS in the future TG. #10-24 Feb :16 pm - Peter Kochmann Am I right to assume that all metadata describing SDS (invocable, interoperable, harmonised) have to fulfil IR Metadata 1205/2008 as well? In my opinion there's no chance other than to expand the values given in Part D.3 as Martin mentioned in #8! I would agree to that and propose to have a clarifying statement in IR Metadata 1205/2008 that the values discovery, view, download, transformation and invoke only apply to INSPIRE network services and that the values invocable, interoperable, harmonised only apply to INSPIRE SDS. To have an additional element out of ISO just to avoid a change of regulations is a high price considering all the disadvantages following that! I looked up ISO and also the future ISO with the integrated service metadata elements again: There's no alternative element that could be used in an appropriate way. The element servicetype itself will still be not multiple. #11-25 Feb :40 am - Peter Kochmann I wasn't aware that the draft of TG SDS contains details on metadata. I assumed to find functional issues only. What status does this document have? Do we have to follow it? Then the question of expanding a codelist or have an additional element instead would be needless, because the drafting team documented a designated extension of ISO here. #12-02 Mar :38 pm - Age Sild OK. We can distinguish INSPIRE Network services and Spatial Data Services (SDS). Regulation 1312/2014 is about Spatial Data Services (does not apply to Network Services falling within the scope of Regulation 976/2009). Metadata regulation 1205/2008 has a metadata element 2.2. Spatial data service type and domain value in chapter 3. Is this classification INSPIRE network services classification? I think no. Also in MD Implementing rules is: Spatial data service type Jan /10

8 If the service is also an INSPIRE Network Services, then it is necessary to include in the Metadata element Specifications, reference to the relevant INSPIRE Network Service Implementing Rule or amendment (see also 2.8.2) What I want to say, is that If my service is for example view service, it does not have to be Inspire Network Services. It may be network services, but it may not also. And if it is not Insprie network services, then regulation 1312/2014 is fitting on that specific view service. In that case my service might be concurrently a view service and also an invocable SDS. Do I understand wrong? I think we can't put together into one domain Spatial Data Service type and Spatial Data Services Category like is described in #7 if multiplicity is 1. #13-03 Mar :51 pm - Ine de Visser In my opinion, if a service is not a INSPIRE network service it's also not a view service because thats an INSPIRE network service type... see the regulation on network services; Article 3 Requirements for Network Services The Network Services shall be in conformity with the requirements concerning the quality of services set out in Annex I. In addition, each type of the Network Services shall be in conformity with the following: (a) as concerns the Discovery Services, the specific requirements and characteristics set out in Annex II; (b) as concerns the View Services, the specific requirements and characteristics set out in Annex III. and in the amendment; (c) as concerns the Download Services, the applicable specific requirements and characteristics set out in Annexes I and IV; (d) as concerns the Transformation Services, the applicable specific requirements and characteristics set out in Annexes I and V. #14-03 Mar :29 pm - Age Sild In metadata regulation (1205/2008) as I see it, spatial data service type is a wider classification. There is not said, that 3.1. Discovery Service (discovery) is Inspire Network services discovery service or 3.2. View Service (view) is Inspire Network services View service etc. 23 Jan /10

9 #15-03 Mar :14 pm - Ine de Visser Sorry it takes my more time to understand where you refer to; In the metadata regulation there are no network services mentioned, only spatial data services, with the same type as the INSPIRE network services. It could be a wider classification. Is that in reality the case? Do you have view/download services on an INSPIRE theme not being an INSPIRE network service? #16-04 Mar :59 pm - Michael Östling I would interpret the distinction between a Spatial Data service and Network services as Ine describes above. A view-service is a Network service. If the service for viewing map images is not a Network service it is just a WMS. Outside the Inspire-community the servicetype should then instead maybe have value OGC:WMS When checking how its interpreted in other systems like Esri Geoportal and Geonetwork (not saying these are reference-implementations) The value used for this kind of service would be OGC:WMS. So the use of ServiceType has its drawbacks. I see also an other possible option used in profiles for solving such an issue. Adding "Inspire Service Category" as a thesaursname for descriptive keywords, with the three possible values Invocable, Interoperable, Harmonized I know there are disagreement on this use of keywords. Can we have a discussion on this so we can get pro's and con's for such a solution? Or the clear reason for not using such a solution. We already handle Service Classification as keywords. I think a similar approach is done by WMO that has defined a thesaurus for WMO_DistributionScopeCode with three values from a controlled vocabulary GlobalExchange, RegionalExchange and OriginatingCentre. I thinks this is also implemented as keywords to avoid extending ISO19115 #17-08 Mar :27 pm - Michael Östling This is just for the discussion. The IR demands us to use a specific element for Category. If not that have been so explicitly defined in IR we could maybe have used conformance reports to report the category for a service. 23 Jan /10

10 When comparing to how we will be able to report conformance on different levels for dataspecifications (eg section for protected sites version 3.2) We could have used same approach for reporting conformity to the TG metadata like storing a conformance report in metadata reporting the level of conformity. gmd:dq_conformanceresult> gmd:specification href=" /> gmd:explanation> (...) gmd:explanation> gmd:pass> (...) gmd:pass> gmd:dq_conformanceresult> I think something related to this have to be done when we are adding the ATS in TG Metadata Metadata conforms to Implementing rules for metadata gmd:specification href= /> Metadata conforms to Implementng rules for metadata + Invocable requirements for SDS gmd:specification href= /> Metadata conforms to Implementng rules for metadata + Interoperability requirements for SDS gmd:specification href= /> Metadata conforms to Implementng rules for metadata + Harmonization requirements for SDS gmd:specification href= /> 23 Jan /10

11