Task #2308

MIWP-8 (J) Metadata for SDS Quality of service

Added by Ine de Visser over 5 years ago. Updated over 5 years ago.

Status:SubmittedStart date:17 Sep 2014
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:-
Proposed change or action:

Description

Quality of service (TG SDS 4.6.2)

Metadata to document the availability of the Spatial Data Service shall be provided. The availability describes the percentage of time the service is available for immediate consumption.

Metadata to document the performance of the Spatial Data Service shall be provided. The performance of a service represents how fast a service request can be completed.

Metadata to document the capacity of the Spatial Data Service shall be provided. In this context it could be understood as the maximum number of simultaneous requests with the performance criteria defined above.

Actions:

  1. Update TG MD X.Y.Z with Quality of service performance
  2. Update TG MD X.Y.Z with Quality of service availability
  3. Update TG MD X.Y.Z with Quality of service capacity
  4. Give examples, explain conition,...
  5. Provide a codelist for the QualityOfServiceCriteriaType
  6. ...

 


Related issues

Copied from MIWP-8: Metadata - Task #2307: MIWP-8 (J) Metadata for SDS Coordinate reference system Submitted 17 Sep 2014

History

#1 Updated by Ine de Visser over 5 years ago

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

Quality of Service This is the minimum quality of service estimated by the spatial data service responsible party and expected to be valid over a period of time.

4.1. Criteria These are the criteria to which the measurements refer. The value domain of this metadata element is as follows:

4.1.1. Availability (availability) It describes the percentage of time the service is available.

4.1.2. Performance (performance) It describes how fast a request to the spatial data service can be completed.

4.1.3. Capacity (capacity) It describes the maximum number of simultaneous requests that can be completed with the declared performance.

4.2. Measurement

4.2.1. Description It describes the measurement for each criterion. The value domain of this metadata element is free text. 11.12.2014 L 354/13 Official Journal of the European Union

4.2.2. Value (value) It describes the value of the measurement for each criterion. The value domain of this metadata element is free text.

4.2.3. Unit (unit) It describes the Unit of the measurement for each criterion. The value domain of this metadata element is free text.

 

Possible solutions;

  1. As suggested in TG SDS exend ISO 19119  SV_ServiceIdentification with qualityOfService :SV_QualityOfService [0..*] and add the class SV_QualityOfService with + criterion :SV_QualityOfServiceCriteria+ value :CharacterString+ measurementDescription :CharacterString+ unit :CharacterString
  2. Use the DQ_DataQuality with DQ_Scope/level with value service. Extend ISO 19115 with a DQ_Element   DQ_ServiceUsability<<Abstract>> with subclass DQ_minimumQuality. Use the DQ_Element elements to describe the measurements and DQ_QuantitativeResult elements to report the values
  3. Use the DQ_DataQuality with DQ_Scope/level with value service. Use DQ_ConceptualConsistency or DQ_FormatConsistency. Use the DQ_Element elements to describe the measurements and DQ_QuantitativeResult elements to report the values
  4. Use the DQ_DataQuality with DQ_Scope/level with value service. Use lineage/statement to describe the minimum quality of service estimated
  5. ...other?

Extending the standards has not the preference, all current tools have to be extended with an Inspire-specific extension to fulfil requirements. Since we are in the middle of two versions of (ISO19115 and ISO19115-1).  Creating a new extension for the “old” ISO19115 could generate some protests. 

Using exsisting elements as in possible solution 3 and 4 have some disadvantages, it's not exactly conform the ISO standards. On other points the TG MD also derive a little from the standards, so the question is, is this acceptable.

 

 

#2 Updated by Ine de Visser over 5 years ago

An example of the Quality of service elements using exsisting ISO 19115 metadata elements (solution 3);

 

<gmd:dataQualityInfo>
   <gmd:DQ_DataQuality>
      <gmd:scope>
         <gmd:DQ_Scope>
             <gmd:level>
                <gmd:MD_ScopeCode
                  codeList="http://www.isotc211.org/2005/resources/codeList.xml#MD_ScopeCode"
                  codeListValue="service"/>
             </gmd:level>
         </gmd:DQ_Scope>
      </gmd:scope>
      <gmd:report>
         <gmd:DQ_ConceptualConsistency>
            <gmd:nameOfMeasure>
               <gco:CharacterString>Performance</gco:CharacterString>
            </gmd:nameOfMeasure>
            <gmd:measureDescription>
               <gco:CharacterString>Average response time, expressed as seconds</gco:CharacterString>
            </gmd:measureDescription>
            <gmd:result>
                <gmd:DQ_QuantitativeResult>
                    <gmd:valueUnit gco:nilReason="inapplicable"/>
                    <gmd:value>
                       <gco:Record>0.5</gco:Record>
                    </gmd:value>
               </gmd:DQ_QuantitativeResult>
            </gmd:result>
         </gmd:DQ_ConceptualConsistency>
      </gmd:report>
      <gmd:report>
          <gmd:DQ_ConceptualConsistency>
             <gmd:nameOfMeasure>
                <gco:CharacterString>Availability</gco:CharacterString>
             </gmd:nameOfMeasure>
             <gmd:measureDescription>
                <gco:CharacterString>Availability on yearly basis, expressed as percentage of time</gco:CharacterString>
             </gmd:measureDescription>
             <gmd:result>
                <gmd:DQ_QuantitativeResult>
                   <gmd:valueUnit gco:nilReason="inapplicable"/>
                   <gmd:value>
                       <gco:Record>83</gco:Record>
                   </gmd:value>
                </gmd:DQ_QuantitativeResult>
            </gmd:result>
        </gmd:DQ_ConceptualConsistency>
    </gmd:report>
    <gmd:report>
       <gmd:DQ_ConceptualConsistency>
          <gmd:nameOfMeasure>
              <gco:CharacterString>Capacity</gco:CharacterString>
          </gmd:nameOfMeasure>
          <gmd:measureDescription>
              <gco:CharacterString>Maximum number of simultaneous requests per second meeting the performance criteria, expressed as number of requests per second</gco:CharacterString>
          </gmd:measureDescription>
          <gmd:result>
              <gmd:DQ_QuantitativeResult>
                  <gmd:valueUnit gco:nilReason="inapplicable"/>
                  <gmd:value>
                     <gco:Record>5</gco:Record>
                  </gmd:value>
             </gmd:DQ_QuantitativeResult>
        </gmd:result>
    </gmd:DQ_ConceptualConsistency>
</gmd:report>

#3 Updated by Martin Seiler over 5 years ago

Suggested solutions 1 and 2 involve an extension of the data model. Between those two options I am clearly in favour of the first one, as this extends the datamodel for describing services.

We should point out consequences of this schema extensions. What does it means for existing software and the timeline for SDS?

 

In order to evaluate options 3 and 4 it would be useful if we could have a mapping in a table between 'elements requested in the IR' (availability, performance, ...) and an XPath-expression.

#4 Updated by Ine de Visser over 5 years ago

For the  proposal "Use the DQ_DataQuality with DQ_Scope  level with value service", In conformance to INSPIRE Directive 2007/2/EC, the metadata shall include information on the degree of conformity with the implementing rules on interoperability of spatial data sets and services. The INSPIRE Metadata Regulation 1205/2008/EC defines in Part D 5 “When the conformity to any specification has been evaluated, it shall be reported as a domain consistency element (i.e. an instance of DQ_DomainConsistency) in ISO 19115 metadata.” For service metadata, the dataquality scope level “service” (existing ISO code) is used to report the conformity with DQ elements, to fulfil this requirement. According to this, the SDS quality of service metadata could also reported with DQ elements.

The other SDS  metadata elements can also use existing ISO elements, so we see no need to extend the ISO standards. Extending the standards is technical possible, but will ask  lot more effort  implementing SDS, because portals, editors and validators of all dataproviders, should be extended with a new schema.  An easy implementation based on existing ISO elements as proposed, not violating ISO and INSPIRE requirements more than at this moment, is in our opinion more preferable

Option 3, is worked out below;

1.1 Quality of service

This is the minimum quality of service estimated by the spatial data service responsible party and expected to be valid over a period of time. There should be three quality of service elements reported; availability, performance and capacity.

1.1.1 Criteria

Metadata element name

Criteria

Reference

Annex VI Part B 4.1

Definition

These are the criteria to which the measurements refer.

ISO 19115 number and name

100. nameOfMeasure

ISO/TS 19139 path

dataQualityInfo/*/report/DQ_ConceptualConsistency/nameOfMeasure

INSPIRE obligation / condition

Mandatory

INSPIRE multiplicity

[1..*]

Data type (and ISO 19115 no.)

Free text

Domain

Availability

Performance

Capacity

Example

availability

Comments

DQ_DataQuality/scope/DQ_Scope/level/MD_ScopeCode with the value “service” should be used

 

 

 

 

 

 

 

 

 

 

 

1.1.1 Measurement

Metadata element name

Description

Reference

Annex VI Part B 4.2.1

Definition

It describes the measurement for each criterion.

ISO 19115 number and name

102.  measureDescription

ISO/TS 19139 path

dataQualityInfo/*/report/DQ_ConceptualConsistency/measureDescription

INSPIRE obligation / condition

Mandatory

INSPIRE multiplicity

[1]

Data type (and ISO 19115 no.)

Free text

Domain

 

Example

Average response time, expressed as seconds

Comments

DQ_DataQuality/scope/DQ_Scope/level/MD_ScopeCode with the value “service” should be used

 

 

 

 

 

 

 

 

 

 

Metadata element name

Value

Reference

Annex VI Part B 4.2.2

Definition

It describes the value of the measurement for each criterion.

ISO 19115 number and name

137. value

ISO/TS 19139 path

dataQualityInfo/*/report/DQ_ConceptualConsistency/result/DQ_QuantitativeResult/value

INSPIRE obligation / condition

Mandatory

INSPIRE multiplicity

[1..*]

Data type (and ISO 19115 no.)

Record

Domain

Described in ISO 19103

Example

1

Comments

DQ_DataQuality/scope/DQ_Scope/level/MD_ScopeCode with the value “service” should be used

 

 

 

 

 

 

 

 

 

 

 

Metadata element name

Unit

Reference

Annex VI Part B 4.2.3

Definition

It describes the Unit of the measurement for each criterion.

ISO 19115 number and name

135. valueUnit

ISO/TS 19139 path

dataQualityInfo/*/report/DQ_ConceptualConsistency/result/DQ_QuantitativeResult/valueUnit

INSPIRE obligation / condition

Mandatory

INSPIRE multiplicity

[1]

Data type (and ISO 19115 no.)

UnitOfMeasure

Domain

Described in ISO 19103

Example

<gmd:valueUnit xlink:href="http://www.opengis.net/def/uom/OGC/1.0/unity"/>

Comments

DQ_DataQuality/scope/DQ_Scope/level/MD_ScopeCode with the value “service” should be used

 

 

#5 Updated by Age Sild over 5 years ago

I must say, that I don't have new ideas, but

I would prefer choosing the way, that makes less trouble for users. The solution could fit currently into existing infrastructure (INSPIRE tools) (but maby that thought is too short-sighted?).

In that case it feels that Ine's solution 3 (DQ_DataQuality with DQ_Scope/level with scope=service) is suitable - countries will be able to implement this metadata element quite easily by that way.

 

Problem is that solution 1 has been announced in TG for SDS already...How big problem is that?

Do we have the right to change, what Network service drafting team has worked out for TG for SDS and has got approval?

And problem is also that solution 3 is not semantically ideal. Useing DQ_ConceptualConsistency or DQ_FormatConsistency might not be very clear or understandable.

#6 Updated by Peter Kochmann over 5 years ago

I think Ine's proposal to take DataQuality elements is absolutely right, because they are already used (abused?) by INSPIRE for documenting service conformity with specifications. The occurrence of DQ_Element as DQ_DomainConsistency taken there is as good (and bad the same time) as the proposed occurrence as DQ_ConceptualConsistency or DQ_FormatConsistency. We won't find one that fits exactly. It's important to take one that fits most. The encoding in DQ_...Consistency or DQ_...Accuracy will only be seen in XML and vanish behind user interfaces of catalogue software. There ist can be named in a more appropriate way to flag the use for SDS quality statements.

So I agree to solution #3!

Looking up the coming ISO 19157 (where the today's data quality elements will be when using ISO 19115-1) didn't help at all: Nothing new that could influence the decision. None of the elements in favour will be cancelled and no new one that fits better will be there.

Also available in: Atom PDF