Publication Date: 2018-01-08
Approval Date: 2017-12-07
Posted Date: 2017-11-15
Reference number of this document: OGC 17-040
Reference URL for this document: http://www.opengis.net/doc/PER/t13-UG002
Category: Public Engineering Report
Editor: Stephen McCann, Roger Brackin, Gobe Hobona
Title: OGC Testbed 13: DCAT/SRIM Engineering Report
COPYRIGHT
Copyright © 2018 Open Geospatial Consortium. To obtain additional rights of use, visit http://www.opengeospatial.org/
WARNING
This document is not an OGC Standard. This document is an OGC Public Engineering Report created as a deliverable in an OGC Interoperability Initiative and is not an official position of the OGC membership. It is distributed for review and comment. It is subject to change without notice and may not be referred to as an OGC Standard. Further, any OGC Engineering Report should not be referenced as required or mandatory technology in procurements. However, the discussions in this document could very well lead to the definition of an OGC Standard.
LICENSE AGREEMENT
Permission is hereby granted by the Open Geospatial Consortium, ("Licensor"), free of charge and subject to the terms set forth below, to any person obtaining a copy of this Intellectual Property and any associated documentation, to deal in the Intellectual Property without restriction (except as set forth below), including without limitation the rights to implement, use, copy, modify, merge, publish, distribute, and/or sublicense copies of the Intellectual Property, and to permit persons to whom the Intellectual Property is furnished to do so, provided that all copyright notices on the intellectual property are retained intact and that each person to whom the Intellectual Property is furnished agrees to the terms of this Agreement.
If you modify the Intellectual Property, all copies of the modified Intellectual Property must include, in addition to the above copyright notice, a notice that the Intellectual Property includes modifications that have not been approved or adopted by LICENSOR.
THIS LICENSE IS A COPYRIGHT LICENSE ONLY, AND DOES NOT CONVEY ANY RIGHTS UNDER ANY PATENTS THAT MAY BE IN FORCE ANYWHERE IN THE WORLD. THE INTELLECTUAL PROPERTY IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AND NONINFRINGEMENT OF THIRD PARTY RIGHTS. THE COPYRIGHT HOLDER OR HOLDERS INCLUDED IN THIS NOTICE DO NOT WARRANT THAT THE FUNCTIONS CONTAINED IN THE INTELLECTUAL PROPERTY WILL MEET YOUR REQUIREMENTS OR THAT THE OPERATION OF THE INTELLECTUAL PROPERTY WILL BE UNINTERRUPTED OR ERROR FREE. ANY USE OF THE INTELLECTUAL PROPERTY SHALL BE MADE ENTIRELY AT THE USER’S OWN RISK. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR ANY CONTRIBUTOR OF INTELLECTUAL PROPERTY RIGHTS TO THE INTELLECTUAL PROPERTY BE LIABLE FOR ANY CLAIM, OR ANY DIRECT, SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES, OR ANY DAMAGES WHATSOEVER RESULTING FROM ANY ALLEGED INFRINGEMENT OR ANY LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR UNDER ANY OTHER LEGAL THEORY, ARISING OUT OF OR IN CONNECTION WITH THE IMPLEMENTATION, USE, COMMERCIALIZATION OR PERFORMANCE OF THIS INTELLECTUAL PROPERTY.
This license is effective until terminated. You may terminate it at any time by destroying the Intellectual Property together with all copies in any form. The license will also terminate if you fail to comply with any term or condition of this Agreement. Except as provided in the following sentence, no such termination of this license shall require the termination of any third party end-user sublicense to the Intellectual Property which is in force as of the date of notice of such termination. In addition, should the Intellectual Property, or the operation of the Intellectual Property, infringe, or in LICENSOR’s sole opinion be likely to infringe, any patent, copyright, trademark or other right of a third party, you agree that LICENSOR, in its sole discretion, may terminate this license without any compensation or liability to you, your licensees or any other party. You agree upon termination of any kind to destroy or cause to be destroyed the Intellectual Property together with all copies in any form, whether held by you or by any third party.
Except as contained in this notice, the name of LICENSOR or of any other holder of a copyright in all or part of the Intellectual Property shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Intellectual Property without prior written authorization of LICENSOR or such copyright holder. LICENSOR is and shall at all times be the sole entity that may authorize you or any third party to use certification marks, trademarks or other special designations to indicate compliance with any LICENSOR standards or specifications.
This Agreement is governed by the laws of the Commonwealth of Massachusetts. The application to this Agreement of the United Nations Convention on Contracts for the International Sale of Goods is hereby expressly excluded. In the event any provision of this Agreement shall be deemed unenforceable, void or invalid, such provision shall be modified so as to make it valid and enforceable, and as so modified the entire Agreement shall remain in full force and effect. No decision, action or inaction by LICENSOR shall be construed to be a waiver of any rights or remedies available to it.
None of the Intellectual Property or underlying information or technology may be downloaded or otherwise exported or reexported in violation of U.S. export laws and regulations. In addition, you are responsible for complying with any local laws in your jurisdiction which may impact your right to import, export or use the Intellectual Property, and you represent that you have complied with any regulations or registration procedures required by applicable law to make this license enforceable.
- 1. Summary
- 2. References
- 3. Terms and definitions
- 4. Conventions
- 5. Overview
- 6. Introduction
- 7. SRIM applicability to USGS and NGA metadata
- 8. SRIM Best Practices
- 9. SHACL
- 10. Pub/Sub Support
- 11. Controlled Vocabularies
- 12. Design of the Controlled Vocabulary Ontology
- 13. Semantic Registry API
- 14. Findings and Recommendations
- Appendix A: Mappings
- Appendix B: ISO 19139 to ISO 19115-3 Transformations
- Appendix C: Revision History
- Appendix D: Bibliography
1. Summary
This engineering report captures the requirements, solutions, and implementation experiences of the Semantic Registry work package in Testbed-13. The engineering report describes the implementation of a RESTful Semantic Registry that supports the Semantic Registry Information Model (SRIM) which is based on the Data Catalog (DCAT) specification. A discussion of the applicability of the SRIM to the United States Geological Survey (USGS) and the National Geospatial Intelligence Agency (NGA) metadata is also presented, including an analysis of a set of controlled vocabularies from both organizations. Best Practice guidelines for the use of SRIM are also provided. The engineering report discusses the application of Shapes Constraint Language (SHACL) to aspects of Linked Data. Recognizing the benefits that asynchronous access has to offer web services, a description of the work undertaken by the testbed in implementing publish/subscribe functionality between a Semantic Registry and a Catalogue Service for the Web (CSW) is also presented.
1.1. Requirements
The work presented in this engineering report addresses the following requirements:
-
SRIM applicability to USGS and NGA metadata: Testbed-13 was tasked with investigating the applicability of SRIM to a number of sponsor-provided metadata sets.
-
SRIM Best Practices: Testbed-13 was tasked with producing a Best Practice document for creating metadata for datasets and services by mapping ISO 19115 to SRIM.
-
SHACL: Testbed-13 was tasked with investigating the application of SHACL shapes for defining application profiles, form generation and data entry, data validation, and quality control of linked data information.
-
Pub/Sub Support: Testbed-13 was tasked with extending the Semantic Registry concept with publish/subscribe support for harvested catalogues or other instances of Semantic Registries.
-
Controlled Vocabularies: Testbed-13 was tasked with exploring in detail the kind of metadata needed to enable search on controlled vocabularies by defining an ontology that addresses all aspects listed above.
-
Registry Application Programming Interface (API): Testbed-13 was tasked with developing a Representational State Transfer (REST) API to search and access vocabulary metadata and their terms.
1.2. Key Findings and Prior-After Comparison
Previous work on the semantic registry was carried out as part of the Semantic Portrayal, Registry and Mediation Engineering Report for Testbed 12. This designed a Semantic Registry data model using the W3C Data Catalog Vocabulary (DCAT), Dublin Core Metadata Terms vocabulary and the W3C Provenance, Authoring and Versioning ontology.
Under Testbed 13, the extensibility of the Semantic Registry data model has been demonstrated by developing a Map and Layer profile of SRIM. This profile was used to demonstrate the applicability of SRIM to ISO 19139 and ISO 19115-3 metadata.
In addition, SHACL has been used for the first time to describe the data model and perform validation, ensuring data integrity.
1.3. What does this ER mean for the Working Group and OGC in general
This engineering report is important to the OGC Geosemantics Domain Working Group because it advances the semantic enablement of geospatial catalogues, potentially providing a bridge between the geospatial, Linked Data and semantic web communities. The work presented in the ER will also inform the development of a Best Practice specification for DCAT and GeoDCAT within the OGC.
1.4. Document contributor contact points
All questions regarding this document should be directed to the editor or the contributors:
Name | Organization |
---|---|
Stephen McCann |
Envitia |
Roger Brackin MSc |
Envitia |
Gobe Hobona PhD |
Open Geospatial Consortium |
Chih-Wei 'Will' Kuan |
Feng Chia University |
Chen-Yu 'How' Hao |
Feng Chia University |
1.5. Future Work
This engineering report concludes that a standard for a RESTful semantic registry service, that uses SHACL for validation at data-ingest, is feasible and needed. Future OGC testbeds therefore should advance this concept by designing the requirements and test suites for a RESTful semantic registry service standard, that also uses SHACL for validation at data-ingest. With regard to PubSub CSW, this testbed demonstrated how the OGC PubSub specification could be implemented alongside an OGC Catalogue Service. Future OGC testbeds should therefore explore the potential for developing further bindings in addition to those already supported by the PubSub 1.0 standard.
1.6. Foreword
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. The Open Geospatial Consortium shall not be held responsible for identifying any or all such patent rights.
Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the standard set forth in this document, and to provide supporting documentation.
2. References
The following normative documents are referenced in this document.
-
OGC 12-168r6, OGC® Catalogue Services 3.0 - General Model, June 2016
-
OGC 07-006r1, OpenGIS Catalogue Service Implementation Specification 2.0.2, February 2007
-
OGC 16-137r2, OGC Testbed-12 PubSub / Catalog Engineering Report
-
OGC 16-059, OGC Testbed-12 Semantic Portrayal, Registry and Mediation Engineering Report
3. Terms and definitions
For the purposes of this report, the definitions specified in Clause 4 of the OWS Common Implementation Standard [OGC 06-121r9] shall apply. In addition, the following terms and definitions apply.
3.1. interoperability
capability to communicate, execute programs, or transfer data among various functional units in a manner that requires the user to have little or no knowledge of the unique characteristics of those units [ISO 19119]
4. Conventions
4.1. Abbreviated terms
-
CSW Catalogue Service for the Web
-
DCAT Data Catalogue
-
eb-RIM electronic business Registry Information Model
-
OGC Open Geospatial Consortium
-
OWL Web Ontology Language
-
OWS OGC Web Services
-
RDF Resource Description Framework
-
SDI Spatial Data Infrastructure
-
SQL Structured Query Language
-
SRIM Semantic Registry Information Model
-
UML Unified Modeling Language
5. Overview
This engineering report is organized into the following main sections:
-
Introduction: This section introduces the Semantic Registry, OGC Catalogue Services and the architecture adopted for the semantics part of Testbed-13.
-
SRIM applicability to USGS and NGA metadata: This section presents a cross walk from capabilities metadata of a Web Map Service (WMS) Layer (as described by the schema of a GetCapabilities response) to properties of an SRIM Item. The section proposes a Layer and Map Profile Design and makes recommendations for changes to the SRIM.
-
SRIM Best Practices: This section presents best practices for the use of SRIM. The best practices cover the use of identifiers, documentation of lineage and recording of associations.
-
SHACL: This section provides an overview of SHACL and presents examples.
-
Pub/Sub Support: This section describes the Testbed-13 implementation of a Publish-Subscribe solution involving the Semantic Registry and CSW.
-
Controlled Vocabularies: This section presents a classification of vocabulary types, and discusses various aspects of controlled vocabularies; using sponsor-provided controlled vocabularies as a reference. Aspects discussed include relationships between vocabularies, statistical information about vocabularies, schema encoding, expressiveness, preferred prefixes, preferred namespaces, governance metadata and versioning information.
-
Design of the Controlled Vocabulary Ontology: This section proposes an ontology for describing controlled vocabularies.
-
Semantic Registry API: This section describes the RESTful API of the Semantic Registry.
-
Appendix A presents mappings between DCAT and SRIM.
-
Appendix B presents example GetRecord requests/responses in ISO 19139 and ISO 19115-3 format.
6. Introduction
6.1. Semantic Registry
Amongst the achievements of Testbed-12 was the development of a new ontology called the Semantic Registry Information Model (SRIM). SRIM is a superset of DCAT and some of its derivatives namely DCAT-AP and GeoDCAT-AP. It draws on aspects of ISO 19135, the ISO item registration standard, to extend the dcat:Dataset class by offering an extension of this class called the srim:Item which addresses limitations of DCAT such as support for services. SRIM also leverages other well-known metadata standards such as Dublin Core and ISO 19115. It also offers detailed metadata to facilitate semantic search of geospatial data, schema, schema mappings, and other artifacts.
Another achievement was development of an initial version of the Semantic Registry Service (initially referred to as DCAT REST API) with the purpose of enabling metadata interchange between multiple catalogues. The Semantic Registry Service implemented a RESTful API based on the Hypermedia Application Language (HAL) with JSON-LD as the payload. HAL is a draft specification of the Internet Engineering Task Force (IETF). The Semantic Registry Service REST API followed the principle that every endpoint of the API should offer and SRIM-based Linked Data representation of the resources.
6.2. OGC Catalogue Service
The OGC Catalogue Services specification provides a general interface model that describes a set of abstract service interfaces that support the discovery, access, maintenance and organization of catalogues of geospatial information resources (OGC 12-168r6). The interfaces are designed to enable client applications or end-users to find information that exists in distributed computing environments. Amongst the bindings offered by the Catalogue Service standard is HTTP, which is arguably the most widely adopted of the Catalogue Service bindings. The HTTP binding is more commonly referred to as Catalogue Services for the Web (CSW).
6.3. Architecture
To integrate components within this work package, the architecture presented in Figure 1 was implemented. The illustration shows how a CSW was deployed and extended to act as a notification publisher. The illustratration also shows how a Semantic Registry was deployed and configured to act as a subscriber.
7. SRIM applicability to USGS and NGA metadata
Testbed-13 was tasked with investigating the applicability of SRIM to a number of sponsor-provided metadata sets. To support this investigation, an SRIM Layer and Map Profile was developed.
Layers and Maps are very commonplace, but there is no standard way to describe their metadata. While Layer and Map instances can both be described at a high level through dcat:Dataset, they have their own specific metadata.
Within the context of a WMS, the relationship between a map and a layer is that a map is the result of a request to portray information represented by a layer.
Testbed-13 sought to investigate a profile for Layer and Map that extends the Registry Item and relates to Datasets, Services and Portrayal Information developed for the Semantic Registry and Semantic Portrayal Service.
In order to design a Layer and Map profile that extends the Registry Item, it is necessary to first determine how well an SRIM Item can describe layers and maps. The following sections describe the approach taken to design the Layer and Map profile.
7.1. Layer to SRIM Item cross walk
To assess how well an SRIM Item can describe a Layer, the testbed designed a cross walk from capabilities metadata of a WMS Layer (as described by the schema of a GetCapabilities response) to properties of an SRIM Item. Table 1 presents the cross walk.
WMS Layer property |
Definition |
SRIM Equivalent |
Name |
A unique label given to a layer to enable it to be requested as a resource |
@id |
Title |
A human-readable string for presentation in a menu |
dct:title |
Abstract |
A narrative description of the map layer |
dct:description |
KeywordList |
A list of words or phrases to aid in catalogue searches |
dcat:keyword |
CRS |
Coordinate Reference System |
dct:spatial |
EX_GeographicBoundingBox |
The minimum bounding latitude and longitude coordinates of the data represented in the layer |
dct:spatial |
BoundingBox |
One or more minimum bounding rectangles enclosing the data represented by the layer |
dct:spatial |
Dimension |
An indication of the dimensions supported by the data. Any new Dimension declaration in the child with the same name attribute as one inherited from the parent replaces the value declared by the parent. |
dct:spatial |
Attribution |
Provides a way to identify the source of the geographic information used in a Layer or collection of Layers. |
prov:qualifiedAttribution |
AuthorityURL |
A reference to the definition document for Identifier values |
dct:rightsHolder |
Identifier |
An identifier for the layer. |
dct:identifier |
MetadataURL |
A reference to descriptive information (metadata) about the layer |
|
DataURL |
A reference to the data that is rendered by the layer |
|
FeatureListURL |
A reference to the list of features represented in a Layer. |
|
Style |
Zero or more Styles may be advertised for a Layer or collection of layer |
|
MinScaleDenominator |
The MinScaleDenominator defines the lower bound of the range of scale denominators of maps for which a Layer is appropriate. |
|
MaxScaleDenominator |
The MaxScaleDenominator defines the upper bound of the range of scale denominators of maps for which a Layer is appropriate. |
|
Layer |
a layer nested within another |
|
queryable |
An indicator of whether the layer can be queried, for example through the WMS GetFeatureInfo operation |
|
cascaded |
A Layer is said to have been “cascaded” if it was obtained from an originating server and then included in the service metadata of a different server. |
|
opaque |
An indication of whether the layer fills no-data areas or presents them as transparent regions |
|
noSubsets |
An indicator of whether the layer can be clipped to a subset of the full Bounding Box |
|
fixedWidth |
An indicator of whether the layer can be rendered with an arbitrary width |
|
fixedHeight |
An indicator of whether the layer can be rendered with an arbitrary height |
7.2. Modeling the concept of a Map
The testbed participants considered how a Map could be modelled. The WMS standard defines a layer as a basic unit of geographic information that may be requested as a map from a server. The WMS standard defines a map as a portrayal of geographic information as a digital image file suitable for display on a computer screen. These definitions lead to the following assumptions in relation to how a Map might be modelled:
-
A map can be uniquely identifiable, to enable it to be retrieved from servers and catalogues.
-
A map can be composed of one or more layers
-
A map can have a legend, typically derived from the styles of the layers from which the map is built
-
A map covers a spatial extent in a specified coordinate reference system
-
A map can cover a specific temporal extent
-
A map can have a maximum scale denominator
-
A map can have a minimum scale denominator
Historically essential map elements have been the data frame, legend, title, North arrow, scale and citation. Taking each of these in turn, the SRIM represents each as follows:
-
A map title can be represented through the dct:title element
-
A map citation can be represented through the dct:description
-
The scale of a map is represented in the WMS and WMTS specifications but is not currently represented in the SRIM.
-
The North arrow (or orientation) is not currently represented in the SRIM.
-
The legend of a map is represented in the WMS and WMTS specifications but is not currently represented in the SRIM.
The testbed also reviewed the Web Map Context standard and observed that it introduces the concept of the Window Size which presents the size in pixels of the map the Context document describes.
7.3. Layer and Map Profile Design
Based on the cross walk and analysis presented in this chapter, the testbed designed a Layer and Map profile as shown in Figure 2.
7.4. Recommendations for changes to the SRIM
This section presents recommendations based on work done to apply the SRIM to USGS and NGA metadata.
-
It was observed that the multiplicity of the modification date property of an SRIM Item is zero-to-one. Given that an item can be modified multiple times, the SRIM should be changed to allow the multiplicity of an SRIM Item to be zero-to-many.
-
The dct:identifier property is labelled as a "Third party identifier" but described as "the main identifier for the register item, e.g. the URI or other unique identifier in the context of the Register". The label appears to contradict the description of this property. The SRIM Item definition should be revised to label the dct:identifier as "the main identifier for the register item".
-
The dct:identifier property has a multiplicity of zero-to-one. As this property is the main identifier of the register item, it should be mandatory and have a multiplicity of one.
-
SRIM Item has the multiplicity of pav:hasVersion as zero-to-one. However pav:hasVersion is described as referring to "a version of the register item, and stores a version number and release notes in addition to other version information". As the register item can have multiple previous versions, the multiplicity of the pav:hasVersion property should be revised to zero-to-many.
-
SRIM Item has the multiplicity of pav:hasCurrentVersion as zero-to-many. However, pav:hasCurrentVersion is described as referring to "the current version of the register item". It would be unusual for there to be multiple current versions of the same item. The multiplicity should therefore be revised to zero-to-one.
8. SRIM Best Practices
Testbed-13 was tasked with identifying best practice for producing metadata for datasets and services through mapping ISO 19115 to SRIM. This section presents the best practice guidelines, which have been informed by work carried out during the testbed as well as related literature.
The ISO 19139 namespace prefixes used in the section include:
-
gmd = "http://www.isotc211.org/2005/gmd"
The ISO 19115-3 namespace prefixes used in the section include:
-
mdb = "http://standards.iso.org/iso/19115/-3/mdb/1.0"
-
mri = "http://standards.iso.org/iso/19115/-3/mri/1.0"
-
cit = "http://standards.iso.org/iso/19115/-3/cit/1.0"
8.1. Use of resolvable URIs as identifiers
Each registered item, register or other resource should be identifiable through a Uniform Resource Identifier (URI) that is resolvable.
The justification is to enable applications to uniquely identify resources without risk of ambiguity.
This guidance relates to transformation of the following ISO 19139 metadata fields to SRIM:
-
gmd:MD_Metadata/gmd:fileIdentifier
-
gmd:MD_Metadata/gmd:identificationInfo/gmd:MD_DataIdentification/gmd:citation/gmd:Citation/gmd:identifier
This guidance relates to transformation of the following ISO 19115-3 metadata fields to SRIM:
-
mdb:MD_Metadata/mdb:metadataIdentifier
-
mdb:MD_Metadata/mdb:identificationInfo/mri:MD_DataIdentification/mri:citation/cit:CI_Citation/cit:identitier
8.2. Adopt a consistent scheme for URIs
A consistent scheme should be used for specifying the URIs used with SRIM encoded metadata.
The justification is that consistency in URI patterns allows collections of metadata records to be copied or moved between networks. For example, in organizations that have multiple air-gapped networks, a consistent URI scheme allows for the base of a URI to be replaced without affecting the rest of the URIs and thus is path relative to other resources.
This guidance relates to transformation of the following ISO 19139 metadata fields to SRIM:
-
gmd:MD_Metadata/gmd:fileIdentifier
-
gmd:MD_Metadata/gmd:identificationInfo/gmd:MD_DataIdentification/gmd:citation/gmd:Citation/gmd:identifier
This guidance relates to transformation of the following ISO 19115-3 metadata fields to SRIM:
-
mdb:MD_Metadata/mdb:metadataIdentifier
-
mdb:MD_Metadata/mdb:identificationInfo/mri:MD_DataIdentification/mri:citation/cit:CI_Citation/cit:identitier
8.3. Use of controlled vocabularies
Controlled vocabularies should be used to tag the registered item if such vocabularies are available. Such controlled vocabularies should be represented in RDF-based languages (e.g. OWL, SKOS etc).
The justification is that controlled vocabularies facilitate search and discovery of resources.
This guidance relates to transformation of the following ISO 19139 metadata fields to SRIM:
-
gmd:MD_Metadata/gmd:identificationInfo/gmd:MD_DataIdentification/gmd:descriptiveKeywords/gmd:MD_Keywords/gmd:keyword
This guidance relates to transformation of the following ISO 19115-3 metadata fields to SRIM:
-
mdb:MD_Metadata/mdb:identificationInfo/mri:MD_DataIdentification/mri:descriptiveKeywords
8.4. Use of Item Classes
The type of registered item should be specified, through Item Classes to enable an application to group similar registered items together.
The justification for this is that in some cases an application or user may require a single type of registered item (e.g. services only, dataset only). In such situations the Item Class would help to filter out those registered items that are not of that type, thus improving the speed of discovery.
This guidance relates to transformation of the following ISO 19139 metadata fields to SRIM:
-
gmd:MD_Metadata/gmd:hierarchyLevel
-
gmd:MD_Metadata/gmd:hierarchyLevelName
This guidance relates to transformation of the following ISO 19115-3 metadata fields to SRIM:
-
mdb:MD_Metadata/mdb:metadataScope/mdb:MD_MetadataScope/mdb:resourceScope
-
mdb:MD_Metadata/mdb:metadataScope/mdb:MD_MetadataScope/mdb:name
8.5. Capture lineage and provenance of items
The provenance of the registered item and other lineage information should be recorded, with changes and version information specified.
The justification for this is that change control and versioning are key aspects of any registry. Deletion of registered items should be avoided and instead version and status information should be captured.
This guidance relates to transformation of the following ISO 19139 metadata fields to SRIM:
-
gmd:MD_Metadata/gmd:dataQualityInfo/gmd:DQ_DataQuality/gmd:lineage
-
gmd:MD_Metadata/gmd:identificationInfo/gmd:MD_DataIdentification/gmd:citation/gmd:Citation/gmd:edition
-
gmd:MD_Metadata/gmd:identificationInfo/gmd:MD_DataIdentification/gmd:citation/gmd:Citation/gmd:editionDate
This guidance relates to transformation of the following ISO 19115-3 metadata fields to SRIM:
-
mdb:MD_Metadata/mdb:metadataScope/mdb:MD_MetadataScope/mdb:resourceLineage
-
mdb:MD_Metadata/mdb:identificationInfo/mri:MD_DataIdentification/mri:citation/cit:CI_Citation/cit:edition
-
mdb:MD_Metadata/mdb:identificationInfo/mri:MD_DataIdentification/mri:citation/cit:CI_Citation/cit:editionDate
8.6. Recording of associations between related items
Associations between registered items should be identified and the type of relationship specified.
The justification is that typed associations in the form of predicates in an RDF graph can be traversed in support of inference. This improves the precision of searches.
This guidance relates to transformation of the following ISO 19139 metadata fields to SRIM:
-
gmd:MD_Metadata/gmd:parentIdentifier
-
gmd:MD_Metadata/gmd:identificationInfo/srv:SV_ServiceIdentification/srv:operatesOn
This guidance relates to transformation of the following ISO 19115-3 metadata fields to SRIM:
-
mdb:MD_Metadata/mdb:parentMetadata/cit:CI_Citation/cit:identitier
9. SHACL
SHACL is a language for describing RDF graph structures such that they can be validated against a set of conditions that are provided as "shapes" and other constructs serialized in RDF. SHACL is a standard of the World Wide Web Consortium (W3C).
The RDF graphs used to validate other graphs through SHACL are referred to as "shapes graphs" and those that are validated against a shapes graph are referred to as "data graphs". An RDF shape can therefore be considered to be a formal specification of how data is, how data should be, or how data must be.
A shapes graph is an RDF graph containing zero or more shapes that is used within a SHACL validation process to validate a data graph. A shapes graph specifies classes, properties, their associated cardinalities, data-types and range of expressions that are allowed in a valid dataset.
Just as shape graphs can be used as a validation tool, they can also be viewed as a description of the data graphs that comply with the conditions set out in the shapes graphs. Such a descriptive ability can potentially be used in non-validation functions such as user interface building, code generation and data integration.
A shape is a collection of constraints that may be applied to certain nodes. Shapes can be used to constrain the classes and properties used in an RDF graph. A shape determines how to validate a node in a graph based on the values of properties and other characteristics of the node.
9.1. sh:Shape
A shape adopts the following properties.
property name | description | range |
---|---|---|
sh:deactivated |
If set to true for a shape then the shape is deactivated and all nodes conform to it. |
xsd:boolean |
sh:targetClass |
Links a shape to a class, indicating that all instances of the class must conform to the shape. |
rdfs:Class |
sh:targetNode |
Links a shape to individual nodes, indicating that these nodes must conform to the shape. |
sh:Target |
sh:targetObjectsOf |
Links a shape to a property, indicating that all objects of triples that have the given property as their predicate must conform to the shape. |
rdf:Property |
sh:targetSubjectsOf |
Links a shape to a property, indicating that all subjects of triples that have the given property as their predicate must conform to the shape. |
rdf:Property |
sh:message |
A human-readable message (possibly with placeholders for variables) explaining the cause of the result |
xsd:string |
sh:severity |
Defines the severity that validation results produced by a shape must have. Defaults to sh:Violation. |
sh:Severity |
9.2. Examples
To demonstrate the application of SHACL to data validation, the testbed prepared a SHACL document that describes part of the SRIM schema. Each property of an SRIM class is described in terms of its qualified identifier, data type, the minimum number of occurrences and the maximum number of occurrences.
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix schema: <http://schema.org/> .
@prefix sh: <http://www.w3.org/ns/shacl#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix srim: <http://www.opengis.net/ont/testbed12/srim#> .
@prefix dct: <http://purl.org/dc/terms/> .
@prefix dcat: <http://www.w3.org/ns/dcat#> .
@prefix vcard: <http://www.w3.org/2006/vcard/ns#> .
@prefix pav: <http://purl.org/pav/> .
srim:ItemShape
a sh:NodeShape ;
sh:targetClass srim:Item ;
sh:property [
sh:path dct:identifier;
sh:minCount 1 ;
sh:maxCount 1 ;
] ;
sh:property [
sh:path rdf:type;
sh:minCount 1 ;
sh:maxCount 1 ;
] ;
sh:property [
sh:path dct:title;
sh:minCount 1 ;
] ;
sh:property [
sh:path dct:description;
sh:minCount 1 ;
] ;
sh:property [
sh:path dcat:contactPoint;
sh:node vcard:VCardShape ;
] ;
sh:property [
sh:path dct:created;
sh:maxCount 1 ;
] ;
sh:property [
sh:path dct:issued;
sh:maxCount 1 ;
] ;
sh:property [
sh:path dct:modified;
sh:maxCount 1 ;
] ;
sh:property [
sh:path pav:hasVersion;
sh:node srim:ReleaseShape ;
] ;
.
vcard:VCardShape
a sh:NodeShape ;
sh:property [
sh:path vcard:fn ;
sh:minCount 1 ;
sh:maxCount 1 ;
sh:datatype xsd:string ;
] ;
sh:property [
sh:path vcard:hasEmail ;
sh:minCount 1 ;
] .
srim:ReleaseShape
a sh:NodeShape ;
sh:property [
sh:path rdf:id ;
sh:minCount 1 ;
sh:maxCount 1 ;
] ;
sh:property [
sh:path pav:version ;
sh:minCount 1 ;
sh:maxCount 1 ;
] ;
sh:property [
sh:path dct:issued ;
sh:maxCount 1 ;
] ;
sh:property [
sh:path pav:versionOf ;
sh:maxCount 1 ;
] .
The SHACL document was applied to the following SRIM example document. The example document describes an instance of an SRIM Item. In this case the registered item is a dataset on "U.S. Widget Manufacturing Statistics".
@prefix dash: <http://datashapes.org/dash#> .
@prefix schema: <http://schema.org/> .
@prefix pav: <http://purl.org/pav/> .
@prefix org: <http://www.w3.org/ns/org#> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix voaf: <http://purl.org/vocommons/voaf#> .
@prefix skos: <http://www.w3.org/2004/02/skos/core#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix vcard: <http://www.w3.org/2006/vcard/ns#> .
@prefix dct: <http://purl.org/dc/terms/> .
@prefix madsrdf: <http://www.loc.gov/mads/rdf/v1#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix srim: <http://www.opengis.net/ont/testbed12/srim#> .
@prefix dctype: <http://purl.org/dc/dcmitype/> .
@prefix vann: <http://purl.org/vocab/vann/> .
@prefix dcat: <http://www.w3.org/ns/dcat#> .
@prefix prov: <http://www.w3.org/ns/prov#> .
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
[
a srim:Item ;
dct:accrualPeriodicit "R/P1Y" ;
dct:description "This dataset provides national statistics on the production of widgets" ;
dct:identifier "http://dx.doi.org/10.7927/H4PZ56R2" ;
dct:issued "2011-11-22"^^xsd:dateTime ;
dct:language <http://id.loc.gov/vocabulary/iso639-1/en> ;
dct:modified "2011-11-19T12:00:00Z"^^xsd:dateTime ;
dct:publisher [ a foaf:Organization ;
foaf:name "\n\t\t\t\t\tWidget Services\n\t\t\t\t"
] ;
dct:spatial "United States" ;
dct:temporal "2009-09-01T12:00:00Z/2010-05-31T12:00:00Z"^^xsd:dateTime ;
dct:title "U.S. Widget Manufacturing Statistics" ;
dcat:contactPoint [ a vcard:Individual ;
vcard:fn "Jane Doe" ;
vcard:hasEmail "mailto:jane.doe@agency.gov"
] ;
dcat:distribution [ a dcat:Distribution ;
dct:description "Widgets data as a CSV file" ;
dct:format "CSV" ;
dct:title "widgets.csv" ;
dcat:downloadURL "https://data.agency.gov/datasets/widgets-statistics/widgets.csv"
] ;
dcat:distribution [ a dcat:Distribution ;
dct:description "A fully queryable REST API with JSON and XML output" ;
dct:format "API" ;
dct:title "Widgets REST API" ;
dcat:accessURL "https://data.agency.gov/api/widgets-statistics/"
] ;
dcat:distribution [ a dcat:Distribution ;
dct:description "Widgets data as a zipped CSV file with attached data dictionary" ;
dct:format "Zipped CSV" ;
dct:title "widgets-all.zip" ;
dcat:downloadURL "https://data.agency.gov/datasets/widgets-statistics/widgets-all.zip"
] ;
dcat:distribution [ a dcat:Distribution ;
dct:description "Widget data as a JSON feed" ;
dct:format "JSON" ;
dct:title "widgets-all.json" ;
dcat:downloadURL "http://www.agency.gov/feeds/widgets-all.json"
] ;
dcat:distribution [ a dcat:Distribution ;
dct:license "http://creativecommons.org/publicdomain/zero/1.0/" ;
dct:rights "This dataset has been given an international public domain dedication for worldwide reuse"
] ;
dcat:keyword "manufacturing" , "factory" , "widget" ;
dcat:landingPage "http://agency.gov/widgets/data" ;
dcat:theme [ a skos:Concept ;
skos:prefLabel "manufacturing"
]
].
The result of validating the data graph against the shapes graph is a validation report. The validation report presents the result of the validation and can report on the conformance of the SRIM document to the constraints specified in the SHACL document.
An example of a validation report where the data graph conforms to the shapes graph is shown below.
[ a sh:ValidationReport ;
sh:conforms true ;
] .
An example of a validation report where the data graph does not conform to the shapes graph is shown below. The validation report was triggered by removing the title property from the data graph. The removal violates the minimum occurrence constraint of the title property stated in the shapes graph.
[ a sh:ValidationReport ;
sh:conforms false ;
sh:result [
a sh:ValidationResult ;
sh:resultSeverity sh:Violation ;
sh:sourceConstraintComponent sh:MinCountConstraintComponent ;
sh:sourceShape _:n2815 ;
sh:focusNode _:n2939 ;
sh:resultPath dct:title ;
sh:resultMessage "Less than 1 values" ;
]
] .
10. Pub/Sub Support
The OGC Publish/Subscribe (PubSub) standard is an interface specification for the core components and concepts of the Publish/Subscribe message exchange pattern within OGC Web Services. It is intended to complement and not to replace the request-reply message exchange pattern that is adopted by most OGC web service standards. The standard enables subscription management capabilities such as creation, renewing and canceling of subscriptions. The standard is independent of message delivery protocols such as Atom [IETF RFC 5023] and binding technologies such as REST. Testbed-12 introduced a PubSub extension for CSW, focused primarily on CSW 2.0.2 but also taking into consideration implications for the ISO Application Profile, the ebRIM Application Profile, the OpenSearch extension, the SOAP binding, and DCAT. Testbed-13 was tasked with implementing publish/subscribe support to support harvesting between CSW and Semantic Registries.
The process supported by the PubSub standard recognizes roles that include a subscriber, publisher, sender and receiver. Within this workflow a Subscriber first creates a subscription on behalf of a Receiver by transmitting a subscribe request to a Publisher. The subscription may include a filter criteria that evaluates to a boolean when an event occurs that meets its criteria. Each time or at some client-configurable interval when the filter criteria is met, the Publisher instructs the Sender to transmit a notification to the Receiver. The Sender then sends the notification to the Receiver. An illustration of this workflow is presented in Figure 3. It is important that the aforementioned roles are not mutually exclusive and it is possible for components to assume two roles in one. For example, it is possible for a single component to assume the roles of both subscriber and receiver. It is also possible for a component to assume the roles of both a publisher and sender.
10.1. Testbed-13 Implementation of PubSub
The publish/subscribe model of interaction was implemented in Testbed-13. As illustrated in Figure 4, the implementation included a CSW, extended with pubsub support to serve in the roles of a publisher and a sender. The implementation also included a Semantic Registry, enabled to serve in the roles of a subscriber and a receiver.
OGC PubSub 1.0.0 offers a core model which can be implemented using a variety of bindings. The SOAP/WSDL binding of OGC PubSub 1.0.0, which is a separate OGC standard, applies the OASIS WS-Notification standard for transmitting notifications. WS-Notification is a family of related specifications creating and transmitting notifications through web services and using a topic-based publish/subscribe pattern. As a key requirement of testbed-13 was to explore the potential for a RESTful semantic registry, it was decided not to adopt the SOAP/WSDL binding of the PubSub specification but to focus on sending notifications in the form of ISO 19139 MD_Metadata (as returned by the subscription filter) instead.
10.2. ISO 19115-3 Metadata
One of the requirements of this testbed was to demonstrate the ability to return GetRecords responses in the ISO 19115-3 format. To do this, a servlet filter was placed in front of the CSW-ISO endpoint which performed an XSLT transformation on the ISO 19139 metadata already held within the catalogue in order to convert it into ISO 19115-3 metadata. The XSLT scripts were provided by the International Organization for Standardization (ISO).
10.2.1. Transformation Filter
For the data to be transformed into ISO 19115-3, several criteria must be met:
-
The request must be a GetRecords request.
-
The request method must be HTTP POST, and contain the XML GetRecords query in the request body.
-
The
outputSchema
attribute of the GetRecords must behttp://standards.iso.org/iso/19115/-3/mdb/1.0
If the request meets these criteria, the response is intercepted and an XSLT transformation performed on the original GetRecordsResponse. The new ISO 19115-3 elements replace the original ISO 19139 elements and the response continues back to the client.
A sequence diagram showing this flow is shown below.
All request/response cycles pass through the transformation filter, but only those that meet the criteria are intercepted, processed, and the response transformed.
10.2.2. XSLT Transformation Scripts
The XSLT transformation scripts can be found as a resource on the ISO web site.
XSLT Script Changes
The scripts were successfully tested using the commercially available XML Spy application, but when it came to running them within a Java application it was found that errors were reported causing the transformation to fail. Specifically, the import
and include
statements were causing issues because the Saxon XSLT engine failed if a stylesheet was imported more than once.
To resolve this problem, all import
and include
statements were removed from sub-scripts and placed in the root script. This meant that each stylesheet was imported only once and the issue was resolved successfully.
XSLT Stylesheet Hierarchy
The stylesheets were organized into the following folders:
xslt | fromISO19139.xsl | toISO19139.xsl | +---mapping | CI_Citation.xsl | CI_ResponsibleParty.xsl | core.xsl | defaults.xsl | DQ.xsl | SRV.xsl | \---utility create19115-3Namespaces.xsl dateTime.xsl multiLingualCharacterStrings.xsl
The import
and include
statements were moved into the fromISO19139.xsl
stylesheet.
Example GetRecords requests and the corresponding responses can be found in Appendix B.
11. Controlled Vocabularies
A controlled vocabulary can be defined as an organized collection of terms used to index content in order to facilitate information retrieval. In a cross community environment, various users may prefer to use different terms to refer to concepts. Without a controlled vocabulary it can be difficult for users to retrieve documents and other resources if they are completely unfamiliar with the terminology used to catalogue information resources. Controlled vocabularies provide guidance to users by labelling information resources with terms that users within a specific domain are likely to be familiar with. Such terms are organized into an index that includes preferred and alternate terms to allow for variation.
In the Linked Data community, controlled vocabularies are designed to be machine-processable. Over the years a number of approaches have emerged for implementing controlled vocabularies with different levels of machine-interpretability. Examples of such standards include codelists, ontologies, taxonomies and thesauri. A number of specifications have also emerged to standardize how some of the aforementioned approaches are implemented, for example the Resource Description Framework (RDF), Web Ontology Language (OWL) and Simple Knowledge Organization System (SKOS). Whereas some of the standards can be considered emerging or domain-specific, others have become mainstream through endorsement in major government programs (e.g. data.gov.uk) and used by mass market services (e.g. Google Search and LinkedIn).
As the popularity of controlled vocabularies has grown, so has the need to find efficient ways of searching them. There remains however several issues that limit search on controlled vocabularies, for example:
-
Some controlled vocabularies are not publicly available on the World Wide Web. Testbed-12 observed that the USGS National Map Theme Thesaurus was such an example.
-
Unique identification schemes are not always applied to terms in the controlled vocabulary.
-
Overlap and duplication of some terms.
Testbed-12 recommended that to address some of the aforementioned issues, it is necessary to define concepts in SKOS encoding with unique identifiers that are resolvable. The testbed also recommended grouping alternate labels under the same concept and providing SKOS mappings to other vocabularies to enable semantic search across taxonomies. Once the concepts have been encoded in SKOS, it is necessary for them to be made publicly available to encourage uptake and reuse. The testbed also observed that controlled vocabularies without an assigned authority are at risk of not being reused.
To address the aforementioned issues, Testbed-13 was tasked with defining an ontology that explores in detail the type of metadata needed to enable search on controlled vocabularies. The ontology, which we have named the Controlled Vocabulary Ontology (CVO) is presented later in this section. The following subsections describe aspects of controlled vocabularies that were explored during the testbed. The subsections also make reference to the following existing specifications:
-
SKOS provides a model for expressing the basic structure and content of concept schemes such as thesauri, classification schemes, subject heading lists, taxonomies, folksonomies, and other similar types of controlled vocabulary.
-
The PROV (short for provenance) Family of Documents defines a model, corresponding serializations and other supporting definitions to enable the inter-operable interchange of provenance information in heterogeneous environments such as the Web.
-
Vocabulary of a Friend (VOAF) is a vocabulary specification providing elements allowing the description of vocabularies (RDFS vocabularies or OWL ontologies) used in the Linked Data Cloud.
11.1. Classification of vocabulary types
There are several different types of controlled vocabularies. Many different, though consistent, definitions have been proposed for the types of controlled vocabularies. In this section, we present some of the definitions.
-
A controlled list is a list of terms used to control terminology [1].
-
A taxonomy is a hierarchical arrangement of entities in which there is a formal relationship, typically one of derivation, between every pair of terms [2].
-
A synonym ring is a set of terms considered equivalent for the purpose of information retrieval [1].
-
An authority file is a set of established names or headings and cross-references to the preferred form from variant or alternate forms [1].
-
An ontology is a formal specification of concrete or abstract things, and the relationships among them, in a prescribed domain of knowledge [ISO/IEC 19763-1:2015]
-
Alphanumeric classification schemes are controlled codes (letters or numbers, or both letters and numbers) that represent concepts or headings [1].
-
A folksonomy is a neologism referring to an assemblage of concepts represented by terms and names (called tags) that are compiled through social tagging [1].
-
A thesaurus is a controlled and structured vocabulary in which concepts are represented by terms, organized so that relationships between concepts are made explicit, and preferred terms are accompanied by lead-in entries for synonyms or quasi-synonyms [ISO 25964-1:2011]
Given that there are different types of controlled vocabularies within and outside of the sponsor community, it can be inferred that the CVO should offer a property that specifies the type of controlled vocabulary.
11.2. Relationships to other vocabularies
To determine the namespaces of concepts imported by the referenced controlled vocabularies, the testbed used Apache Jena’s RDFCat facility to convert the supplied controlled vocabularies into Turtle format. The following observations were made.
The NCV imports concepts from the following namespaces
The NGA NTAX imports concepts from the following namespaces
-
ISO 19150-2: http://def.isotc211.org/iso19150-2/2012/base#
-
Dublin Core terms: http://purl.org/dc/terms/
The USGS SWO imports concepts from the following namespaces
The USGS Thesaurus imports concepts from the following namespaces
The USGS USTopographic ontology imports concepts from the following namespaces
-
cegis ontology: http://cegis.usgs.gov/Ontology#
-
dcterms: http://purl.org/dc/terms/
None of the controlled vocabularies were observed to extend others, however the following relevant observations were made:
-
Feature, Function, Flow, SpatialExtent, SurfaceWaterNetwork and Temporality from the USGS SWO are specializations of owl:Thing. All other concepts have been modeled as specializations of these six concepts or their subclasses.
-
Documentation and Topography from the USGS USTopographic ontology are specializations of owl:Thing. All other concepts have been modeled as specializations of these two concepts or their subclasses.
-
GIS-NHD from the USGS GIS-NHD ontology is a specialization of owl:Thing. All other concepts have been modeled as specializations of this concept or its subclasses.
-
Most of the concepts in the NTAX are specializations of the Entity abstract class or its subclasses, for example FeatureEntity, InformationEntity, ActorEntity and others.
These observations suggest there are some differences between the approach taken for the NTAX and the approach taken for the USGS controlled vocabularies. The USGS controlled vocabularies are modularized, with individual modules focusing on specific domains (e.g. topography, hydrography, surface water). In contrast, the NTAX describes concepts across multiple domains.
To enable the search and discovery of controlled vocabularies, the CVO should therefore provide an indicator of whether a controlled vocabulary extends, imports, specializes other vocabularies.
11.3. Statistical information about vocabularies
The testbed examined statistical information for each of the referenced controlled vocabularies. The review of the statistics was intended to provide an indicator of the types of axioms that are typically used by the referenced controlled vocabularies, this would enable the identification of the statistics that are optional though recommended. Using the Ontology metrics view of Protege version 5.0.0 beta, the following statistics can be extracted.
-
AnnotationAssertion axiom count
-
AnnotationAssertion count
-
Axiom count
-
Class count
-
ClassAssertion axiom count
-
Data property count
-
DataPropertyDomain axiom count
-
DataPropertyRange axiom count
-
DifferentIndividuals axiom count
-
DisjointClasses axiom count
-
Individual count
-
Logical axiom count
-
Object property count
-
ObjectPropertyDomain axiom count
-
ObjectPropertyRange axiom count
-
SubClassOf axiom count
Such statistical information can help a user decide whether to make use of a controlled vocabulary, for example if the user is operating in austere environments with intermittent connectivity. The CVO should therefore provide such statistical information.
11.4. Schema encoding
The referenced controlled vocabularies are distributed in the following encodings and schema:
-
NCV is distributed as SKOS and serialized in both RDF/XML and N3 Triples.
-
NTAX is distributed as OWL with some predicates from SKOS and serialized in both RDF/XML and N3 Triples.
-
SWO is distributed as RDF Turtle
-
USGS thesaurus is distributed as SKOS and serialized in both RDF/XML
-
USGS USTopographic is distributed as RDF Turtle
-
USGS NHD is distributed as RDF Turtle
11.5. Expressiveness
The testbed observed that the Protege application describes expressivity in terms of Description Logic (DL). Using the Ontology metrics facility within Protege, the testbed determined that the DLs adopted by the referenced controlled vocabularies included AL, ALC, AL(D), ALCH and ALCH(D). The DL AL (Attributive Language) was introduced by Schmidt-Schauß and Smolka [3] as a minimal language. The DL ALC was introduced by Schmidt-Schauß and Smolka [3] as the “smallest” DL that is propositionally closed, i.e., that provides for all Boolean connectives. The DL AL(D) extends AL with a concrete domain concept constructor. ALCH extends ALC with role hierarchies. ALCH(D) extends AL with functional roles, concrete domain roles, role hierarchies and a concrete domain concept constructor. Table 2 presents a summary of the expressivity of the referenced vocabularies.
vocabulary | Expressivity |
---|---|
USGS USTogographic |
ALCH(D) |
NCV |
ALCO |
NTAX |
ALC |
USGS Thesaurus |
AL |
USGS GIS NHD |
AL(D) |
USGS SWO |
ALCH |
To facilitate search and discovery of controlled vocabularies, the CVO should therefore offer a property that indicates the expressivity of the vocabulary.
11.6. Preferred prefix and namespace URI
It is good practice for ontologies to adopt consistent prefixes for representing their namespaces. Information modelling initiatives typically specify a preferred prefix for each namespace that is used. The base namespace URI used by the referenced controlled vocabularies are:
-
USGS thesaurus http://www.usgs.gov/science/USGSThesaurus
-
USGS USTopographic http://cegis.usgs.gov/Ontology
The CVO should therefore offer a property for specifying the preferred prefix and namespace URI of a controlled vocabulary.
11.7. Governance metadata
Simperl and Tempich (2009) observed that governance frameworks cover the organization, control, steering and diffusion aspects of corporate system development. Organizational aspects describe the different roles and their responsibilities required for the development and maintenance of a system in an organization. Steering involves the definition of processes and activities performed by roles in order to achieve the overall goals of the system. Control involves the definition and application of indicators required to monitor a system. In the case of controlled vocabularies such indicators could include metrics on concepts or other statistics, for example. Diffusion involves the definition of suitable mechanisms for making the system (in this case a controlled vocabulary) available to all intended users.
The sub-organization within NGA that is responsible for the governance of the NCV and NTAX is the Geospatial Intelligence Standards Working Group (GWG). Proposed additions or changes to the NCV are reviewed by the GEOINT Content Standards Board (GCSB), which serves as a steering board within this context. Editions of both the NTAX and NCV are disseminated through the NSG Standards Registry. Changes to the NCV are registered in a spreadsheet with the fields shown in Table 3.
Field name | Description | SKOS/PROV/VOAF equivalent |
---|---|---|
(Previous) Description |
The pre-change statement of the nature, properties, scope, or non-essential qualities of the Enumerated Type Term that are not specified by the definition. |
dct:description |
Event |
The Control Body decision event at which this Enumerated Type Term was revised. |
None |
Action |
The type of change made to the Enumerated Type Term; one of: Add, Clarify (changes that are "editorial" in nature and do not change the essence of the Enumerated Type Term), Supersede (replacement of the Enumerated Type Term by another Enumerated Type Term), or Retire. |
None |
Justification |
An explanation of the basis for the change to the Enumerated Type Term. |
None |
Change |
A description, if applicable, of the specifics of the change. |
None |
Item Identifier |
A positive integer (i.e., greater than zero) that is used to uniquely denote the Enumerated Type Term within the register and is intended for information processing. |
URI of resource |
Label |
A textual value that is used to denote the Enumerated Type Term in data interchange. |
skos:altLabel |
(Revised) Name |
The post-change compact and human-readable designator that is used to denote the Enumerated Type Term. |
skos:prefLabel |
(Revised) Definition |
The post-change precise statement of the nature, properties, scope, or essential qualities of the Enumerated Type Term. |
skos:definition |
(Revised) Description |
The post-change statement of the nature, properties, scope, or non-essential qualities of the Enumerated Type Term that are not specified by the definition. |
dct:description |
Values Complete? |
A Boolean that identifies post-change that the set of specified domain values is complete. |
None |
(Previous) Name |
The pre-change compact and human-readable designator that is used to denote the Enumerated Type Term. |
skos:prefLabel |
(Previous) Definition |
The pre-change precise statement of the nature, properties, scope, or essential qualities of the Enumerated Type Term. |
skos:definition |
The table presented above shows that there are several fields that do not have equivalents in SKOS, PROV or VOAF. The CVO will therefore need to introduce properties where there no equivalent fields and to reuse properties where equivalent fields exist.
The RDF serialization of the NCV introduces the following predicates to support governance. None of the ontologies reviewed were found to offer properties that were equivalent to these fields. Therefore the CVO will have to apply the NCV fields as they are. The fields are presented in Table 4.
Predicate | Description |
---|---|
regx:dateAccepted |
An attribute stating the date on which the concept was accepted |
regx:itemStatus |
An attribute stating whether the concept is valid or not |
11.8. Versioning information
This section presents predicates relating to versioning that were identified in the referenced controlled vocabularies.
NTAX at Ontology level
-
owl:versionIRI "http://api.nsgreg.nga.mil/taxonomy/ntax/base17Feb" ;
-
owl:versionInfo "base17Feb" ;
USTogographic at Ontology level
-
owl:versionIRI
At concept level
-
owl:versionInfo
None of the other controlled vocubalaries were found to offer versioning information.
12. Design of the Controlled Vocabulary Ontology
Having reviewed the controlled vocabularies provided by the testbed sponsors, the CVO was designed as shown in Figure 6. This ontology addresses the requirement to define "an ontology that explores in detail the type of metadata needed to enable search on controlled vocabularies" which is stated in the Testbed-13 CFP. As illustrated the CVO imports SKOS, PROV and VOAF.
12.1. Classes and Properties
12.1.1. ogc:VocabularyStatistics
The properties of the ogc:VocabularyStatistics class are presented in Table 5.
Name | Description | Range | Cardinality |
---|---|---|---|
ogc:wasApprovedAt |
the name of the event or organization at which the controlled vocabulary was approved |
xsd:string |
0..1 |
ogc:annotationAssertionAxiomCount |
number of annotation assertion axioms |
xsd:integer |
0..1 |
ogc:annotationAssertionCount |
number of annotation assertions |
xsd:integer |
0..1 |
ogc:axiomCount |
number of axioms |
xsd:integer |
0..1 |
ogc:classCount |
number of classes |
xsd:integer |
0..1 |
ogc:dataPropertyCount |
number of data properties |
xsd:integer |
0..1 |
ogc:dataPropertyDomainAxiomCount |
number of data property domain axioms |
xsd:integer |
0..1 |
ogc:dataPropertyRangeAxiomCount |
number of data property range axioms |
xsd:integer |
0..1 |
ogc:differentIndividualsAxiomCount |
number of differentIndividuals axioms |
xsd:integer |
0..1 |
ogc:disjointClassesAxiomCount |
number of disjointClasses axioms |
xsd:integer |
0..1 |
ogc:expressivity |
an indicator of the breadth of ideas that can be represented through the controlled vocabulary |
xsd:string |
0..1 |
ogc:individualCount |
number of individuals |
xsd:integer |
0..1 |
ogc:logicalAxiomCount |
number of logical axioms |
xsd:integer |
0..1 |
ogc:objectPropertyCount |
number of object properties |
xsd:integer |
0..1 |
ogc:objectPropertyDomainAxiomCount |
number of object property domain axioms |
xsd:integer |
0..1 |
ogc:objectPropertyRangeAxiomCount |
number of object property range axioms |
xsd:integer |
0..1 |
ogc:preferredNamespaceURI |
the URI of the preferred namespace of the controlled vocabulary |
xsd:string |
0..1 |
ogc:preferredPrefix |
the prefix of the preferred namespace of the controlled vocabulary |
xsd:string |
0..1 |
ogc:subClassOfAxiomCount |
number of subClassOf axioms |
xsd:integer |
0..1 |
12.1.2. ogc:DecisionEvent
The properties of the ogc:DecisionEventclass are presented in Table 6.
Name | Description | Range | Cardinality |
---|---|---|---|
regx:change |
A description, if applicable, of the specifics of the change. |
xsd:string |
1..1 |
ogc:actionTaken |
Derived from the NSG Core Vocabulary Changes register. Described as the type of change made to the Enumerated Type Term; one of: Add, Clarify (changes that are "editorial" in nature and do not change the essence of the Enumerated Type Term), Supersede (replacement of the Enumerated Type Term by another Enumerated Type Term), or Retire. |
xsd:string |
1..1 |
ogc:justification |
An explanation of the basis for the change to the Enumerated Type Term. |
xsd:string |
1..1 |
12.1.3. ogc:Vocabulary
The properties of the ogc:Vocabularyclass are presented in Table 7.
Name | Description | Range | Cardinality |
---|---|---|---|
regx:itemStatus |
An attribute stating whether the concept is valid or not. Adopted from the NSG Core Vocabulary Changes register. |
xsd:string |
0..1 |
dct:description |
An abstract of the resource. |
xsd:string |
0..1 |
dct:issued |
The date the vocabulary was issued. |
xsd:date |
0..1 |
dct:title |
A name given to the vocabulary. |
xsd:string |
0..1 |
ogc:expressivity |
The expressiveness of the vocabulary. This would typically be based on but not limited to Description Logic. |
xsd:string |
0..1 |
ogc:preferredNamespaceURI |
The preferred namespace for use in serializations of the vocabulary. |
xsd:string |
0..1 |
ogc:preferredPrefix |
The preferred prefix for use in serializations of the vocabulary. |
xsd:string |
0..1 |
ogc:type |
The type of vocabulary (e.g. thesaurus, taxonomy etc). |
skos:Concept |
0..* |
regx:dateAccepted |
An attribute stating the date on which the concept was accepted. Adopted from the NSG Core Vocabulary Changes register. |
xsd:date |
0..1 |
13. Semantic Registry API
Testbed-13 was tasked with developing a REST API to enable search and access of vocabulary metadata and their terms. Following guidelines from Testbed-12 REST User Guide (OGC 16-057) and the Testbed-12 REST Architecture Engineering Report (OGC 16-035), the testbed implemented a Semantic Registry API that allowed for artifacts to be registered and published using the SRIM. This section presents the API.
The starting point of the work was to refer to the Semantic Registry API implemented in testbed-12. It was observed however that the testbed-12 implementation was based on the draft IETF HAL specification, which has since expired [https://datatracker.ietf.org/doc/draft-kelly-json-hal/]. It was therefore decided to avoid any HAL-specific requirements, while abiding to the REST principles recommended by the Testbed-12 REST User Guide and the Testbed-12 REST Architecture Engineering Report.
To support the design and implementation of the Semantic Registry API, the testbed deployed an instance of Apache Fuseki - an open source implementation of a REST-style SPARQL Service.
13.1. Semantic Registry Implementation
The Semantic Registry API was implemented as a RESTful API which supports SPARQL queries. The implementation was based on the specification described in the Testbed-12 Semantic Portrayal, Registry and Mediation Engineering Report (OGC 16-059), however some additional details were required to supplement those in the specification which caused some difficulties during implementation. For example, it was very helpful to read the W3C Data Catalog Vocabulary (DCAT) Recommendation (2014) as there are many concepts common to both SRIM and DCAT but which use different terms, such as "register" vs. "catalog" , and "item" vs. "dataset".
In this testbed, GIS.FCU used the open source RDF database, BrightStarDB, which is a non-SQL based, triple store database. It supports Microsoft’s .NET Framework and has rich APIs allowing good integration into applications.
Several components were implemented during this testbed:
-
USGS Metadata transformation template.
-
CSW Data Publish transformation API.
-
RDF Triple Store.
-
RESTful SPARQL endpoint supporting registry operations.
The semantic registry API may be accessed using the endpoint URL, http://140.134.48.46/SRIM/testbed13/.
The metadata held within the registry was derived from metadata downloaded from the U.S. Open Data Portal (https://catalog.data.gov/dataset).
-
Metadata HTML Page, https://catalog.data.gov/harvest/object/6e1b7728-d106-44e4-9f2b-b24bf0d50416/html.
-
Metadata XML Page, https://catalog.data.gov/harvest/object/6e1b7728-d106-44e4-9f2b-b24bf0d50416/.
13.2. REST Principles
Representational State Transfer (REST) is a hybrid architectural style for network-based hypermedia systems. The architectural style is characterized by a set of principles which conforming applications abide by, though to different degrees. These principles include:
-
Uniquely identifiable resources: The concept of a resource is the key abstraction in REST. Any information that can be named is considered a resource and should be identifiable by a URI; with each REST server locatable through a Uniform Resource Locator (URL).
-
Manipulation of resources through representations: Resource representations held by the client should be sufficient to enable the client, if authorized, to manipulate the resource.
-
Messages are self-descriptive: Each message should have enough information about itself to enable an application to process it, without requiring additional information.
-
Client-Server: This principle relates to the separation of concerns, particularly with regard to the user interface and server-side data storage concerns.
-
Stateless: Communication between clients and servers should be stateless, without reliance on any storage capabilities of the server nor dependence on any previous requests.
-
Cache: Data within a response should be implicitly or explicitly labelled as cacheable or non-cacheable, such that a client may reuse the data later for similar requests.
-
Layered System: This principle requires that an application is built from hierarchical layers (i.e. tiers) such that the behavior of a component is only visible to the component it interacts with in the next layer.
-
Hypermedia as the engine of application state (HATEOAS): This principle requires that client applications navigate an application through hypermedia links. The response to each request provides links through which the client may interact with the server further or navigate further into the application.
The above-listed principles have a number of implications for the Semantic Registry. First, the use of URIs to identify resources is consistent with resource identification in semantic web and linked data applications, such as the Semantic Registry. Second, the requirement for self-describing messages is consistent with the increasing adoption of JSON-LD in semantic web applications. Third, separation of client and server concerns is consistent with the approach taken by the Semantic Registry in that the service does not rely or dictate any client behavior. Finally, semantic web applications such as the Semantic Registry are implemented to allow placement within a multi-tier (layered) system.
13.2.1. SPARQL Queries
The metadata RDF in SRIM/DCAT vocabulary can be generated via the SPARQL endpoint, http://140.134.48.13/SRIM/testbed13/sparql.
An example of a SPARQL query is http://140.134.48.46/SRIM/testbed13/sparql?query=CONSTRUCT%20{?s%20?p%20?o}%20WHERE%20{?s%20?p%20?o}
The RDF result includes the namespace addresses and dataset information. In this testbed, there are only nine attributes (URI, Creator, Description, Issued date, Language, Modified date, Title, Distribution, and keyword) transformed from ISO 19139 to SRIM. The keywords of the datasets from the USGS website were not clearly typed, which caused difficulty when implementing the transformation. In this testbed, we used an XML String to define the RDF type of each keyword, due to the vague understanding of the concept of keyword. However, it could be improved through use of skos:concept
to define the links between each keyword and outside vocabularies and resources.
RDF namespace declarations:
<rdf:RDF xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
xmlns:xsd="http://www.w3.org/2001/XMLSchema#"
xmlns:foaf="http://xmlns.com/foaf/0.1/"
xmlns:owl="http://www.w3.org/2002/07/owl#"
xmlns:org="http://www.w3.org/ns/org#"
xmlns:skos="http://www.w3.org/2004/02/skos/core#"
xmlns:gr="http://purl.org/goodrelations/v1#"
xmlns:vcard="http://www.w3.org/2006/vcard/ns#"
xmlns:dct="http://purl.org/dc/terms/"
xmlns:prov="http://www.w3.org/ns/prov#"
xmlns:dcat="http://www.w3.org/ns/dcat#"
xmlns:srim="http://www.opengis.net/ont/testbed12/srim#"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
data-livestyle-extension="available">
Dataset information generated from USGS metadata:
<srim:Item rdf:about="http://www.opengeospatial.org/testbed-13/Item/01ba6dc5-2e23-4fc9-a314-b5cb6694bc35">
<dct:created rdf:datatype="http://www.w3.org/2001/XMLSchema#string">2017/10/3</dct:created>
<dct:description rdf:datatype="http://www.w3.org/2001/XMLSchema#string">LEFT(T23,1000)</dct:description>
<dct:issued rdf:datatype="http://www.w3.org/2001/XMLSchema#string">2016/11/29</dct:issued>
<dct:language rdf:datatype="http://www.w3.org/2001/XMLSchema#string">eng</dct:language>
<dct:modified rdf:datatype="http://www.w3.org/2001/XMLSchema#string">2017/10/3</dct:modified>
<dct:title rdf:datatype="http://www.w3.org/2001/XMLSchema#string">Geochemical Database for the Brackish Groundwater Assessment of the United States</dct:title>
<dcat:distribution rdf:resource="http://www.opengis.net/ont/testbed13/distribution/0202cc39-2aae-476f-89e7-54a1a999bf31"/>
<dcat:keyword rdf:datatype="http://www.w3.org/2001/XMLSchema#string">USGS Science Data Catalog (SDC)</dcat:keyword>
</srim:Item>
This testbed used the following mapping rule to transform the USGS metadata from ISO 19139 into SRIM.
USGS Field | SRIM Class 1 | SRIM Field 1 | SRIM Class 2 | SRIM Field 2 | SRIM Field 3 |
---|---|---|---|---|---|
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
||||
|
|
|
|||
|
|
||||
|
|
||||
|
|
|
|
|
|
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
|
|
||
|
|
||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
||||
|
|
||||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
||||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
||||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
||||
|
|
|
|||
|
|
|
|||
|
|
||||
|
|
||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
|
|||
|
|
||||
|
|
||||
|
|
||||
|
|
|
|||
|
|
||||
|
|
||||
|
|
|
|||
|
|
||||
|
|
||||
|
|
|
|||
|
|
||||
|
|
||||
|
|
|
|||
|
|
||||
|
|
||||
|
|
|
|||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
|
|||
|
|
||||
|
|
||||
|
|
||||
|
|
|
13.3. Semantic Registry API Resources
In this testbed, six operations were implemented for metadata insert, update, delete and query.
-
Capability
-
Registers
-
Register
-
Items
-
Item
-
SPARQL
13.3.1. Capabilities
The capabilities
endpoint describes and provides access to the capabilities metadata of the registry service.
HTTP Method |
GET |
---|---|
Endpoint |
|
Response |
|
13.3.2. Registers
The registers endpoint presents all controlled collections of items of information.
HTTP Method |
GET |
---|---|
Endpoint |
|
Response |
|
HTTP Method |
POST |
---|---|
Endpoint |
|
Request Body |
|
Response |
|
13.3.3. Register
The register endpoint enables the retrieval, update, and deletion of an instance of a single controlled collection of items of information.
HTTP Method |
GET |
---|---|
Endpoint |
|
Response |
|
HTTP Method |
PUT |
---|---|
Endpoint |
|
Request Body |
|
Response |
|
HTTP Method |
DELETE |
---|---|
Request |
|
Response |
HTTP/1.1 200 OK |
13.3.4. Items
The items endpoint enables the creation and listing of collections of items of information.
HTTP Method |
GET |
---|---|
Endpoint |
|
Response |
|
HTTP Method |
POST |
---|---|
Endpoint |
|
Request Body |
|
Response |
|
13.3.5. Item
The item endpoint enables the creation and description of a single item of information.
HTTP Method |
GET |
---|---|
Endpoint |
|
Response |
|
HTTP Method |
PUT |
---|---|
Endpoint |
|
Request Body |
|
Response |
|
HTTP Method |
DELETE |
---|---|
Request |
|
Response |
HTTP/1.1 200 OK |
13.3.6. SPARQL
The SPARQL endpoint provides the ability to search the semantic registry using SPARQL queries.
HTTP Method |
GET |
---|---|
Request |
|
Response |
|
Endpoint |
|
Response |
|
13.4. Semantic Registry to PubSub Integration
A series of manual steps were used to demonstrate the ability of the semantic registry to harvest from a PubSub CSW.
13.4.1. 1. Confirm registry is empty
The registry was first shown to be empty by using the Postman REST client to send an HTTP request to the semantic registry.
13.4.2. 2. Subscribe to notifications from the PubSub
The Postman tool was next used to send a Subscribe request to the PubSub. The Subscribe request contained the endpoint (DeliveryLocation) where notifications were to be sent.
The SubscriptionResponse
received from the PubSub showed that the subscription was successful. The response contains the unique identifier of the subscription, as well as confirmation of the delivery location and filter.
The lower half of the screenshot shows that a valid SubscriptionResponse was received, confirming that the SRIM will be notified of any content changes in the PubSub CSW.
13.4.3. 3. Notification Received
As content was added to the PubSub CSW, notifications were received by the middle tier transformer which parsed the ISO 19139 metadata. The metadata was transformed into SRIM and inserted into the back-end triple store.
13.4.4. 4. Confirmation
The original request from Step 1 above was repeated using Postman. This demonstrated that items from the PubSub had been successfully received, transformed from ISO 19139 into SRIM, and inserted into the registry.
A SPARQL query can also be used to retrieve the items from the registry.
13.5. Status codes
The Semantic Registry uses response status codes defined in HTTP to indicate the success or failure of an operation. The response body of a successful request has a 2XX response (e.g. 200, 202 etc). 4XX or 5XX HTTP response codes (e.g. 404, 500 etc) indicate a failed operation.
The following table shows a list of status codes commonly used by RESTful applications.
Code | Name | Description |
---|---|---|
200 |
OK |
The request operation has succeeded. |
201 |
Created |
The request operation successfully resulted in creation of a new resource. |
202 |
Accepted |
The request has been accepted for processing, but the processing is on-going. |
204 |
No Content |
The server has fulfilled the request but does not need to return an entity-body, and might want to return updated metainformation. |
304 |
Not Modified |
If the client has performed a conditional GET request and access is allowed, but the document has not been modified, the server SHOULD respond with this status code. |
400 |
Bad Request |
Due to malformed syntax, the request could not be understood by the server. |
401 |
Unauthorized |
The request requires user authentication. |
403 |
Forbidden |
The server understood the request, but is refusing to fulfill it. |
404 |
Not Found |
The server has not found anything matching the Request-URI. |
409 |
Conflict |
Due to a conflict with the current state of the resource, the request could not be completed. |
500 |
Internal Server Error |
The server encountered an unexpected condition which prevented it from fulfilling the request. |
14. Findings and Recommendations
This testbed found that the SRIM offers a viable model for implementing a semantic registry that is accessible through a RESTful API. The testbed also found that SHACL offers capability that could allow documents based on SRIM, DCAT or other Linked Data specifications to be validated. This engineering report concludes that a standard for a RESTful semantic registry service, that uses SHACL for validation at data-ingest, is feasible and needed.
Familiarization with a number of technologies would be beneficial to any future implementor of a semantic registry including RDF/XML, Turtle, SPARQL, ISO 19115 and ISO 19139, as well as SRIM and DCAT.
This testbed only implemented the first level of SRIM - Register, Item and Distribution. Interoperability would be improved if more vocabularies were included in the future, such as foaf:agent, org:organization, and other linked data vocabularies.
The back-end database, BrightStarDB, was chosen because of the development environment used to implement the semantic registry (C# .NET Framework).
14.1. Recommendation 1
Future OGC testbeds should design the requirements and Abstract Test Suites for a RESTful semantic registry service standard, that also uses SHACL for validation at data-ingest.
14.2. Recommendation 2
The work presented in this engineering report successfully demonstrated how the OGC PubSub specification could be implemented alongside an OGC Catalogue Service in order to enable the catalogue service to support publish, subscribe and notification capabilities. It was observed that other than the OGC PubSub core standard, which is based on XML, the only other binding offered is SOAP. Future work should explore the possibility of implementing alternative bindings such as Linked Data Notifications which is based on REST and encoded in JSON for Linked Data (JSON-LD). This engineering report therefore recommends that future OGC testbeds should explore the potential for a binding of the OGC PubSub standard based on Linked Data Notifications.
14.3. Recommendation 3
The successful implementation of a PubSub Extension to CSW in Testbed-13, by building on the lessons learnt in Testbed-12, also demonstrates that there is sufficient understanding of the requirements and issues involved in offering PubSub support through CSW. This engineering report therefore recommends that the OGC Catalogue SWG should develop an extension standard for Catalogue Services version 3.0 to support PubSub.
14.4. Recommendation 4
Testbed-13 has been the first testbed to implement ISO 19115-3 support in CSW. This has been achieved through use of XSLT scripts provided by ISO. This enabled participants to better understand the requirements for catalogue services to support this relatively new ISO standard. Testbed participants noted that Section 6.3.1 of the Catalogue Services version 3.0 standard makes references to ISO 19115:2003, ISO 19115-1:2014, ISO/TS 19139:2007 and ISO 19119 without making any reference to ISO 19115-3:2016. The Catalogue Services version 3.0 standard also states that "Where a catalogue service advertises such application schemas, catalogues that handle geographic dataset descriptions should conform to published metadata standards and encodings, e.g. ISO 19115:2003, and support XML encoding per ISO 19139 or profiles thereof. Service metadata elements should be consistent with ISO 19119[6] or 19115:2014". This means change requests for updating the Catalogue Services version 3.0 general model (OGC 12-168r6) are required. In light of the release of ISO 19115-3 and its successful testing, this engineering report recommends that the Catalogue SWG should begin to design modifications to the Catalogue Services standard and its profiles that are currently based on ISO 19139 in order to upgrade them to ISO 19115-3.
14.5. Recommendation 5
The CVO that is proposed in this engineering report brings together several concepts that have not previously been supported in metadata specifications, for example statistics and expressivity of controlled vocabularies. Providing such information could improve the resource discovery and retrieval experience. This engineering report therefore recommends that the Geosemantics DWG develops a Best Practice document for the use of CVO to describe controlled vocabularies.
Appendix A: Mappings
This section presents mappings between SRIM and related metadata specifications.
DCAT to SRIM
DCAT Class | DCAT Attribute | SRIM Class | SRIM Attribute |
---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
||
|
|
||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
SRIM to DCAT
SRIM Class | SRIM Attribute | DCAT Class | DCAT Attribute |
---|---|---|---|
|
|
||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
||
|
|
||
|
|
||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
||
|
|
||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
||
|
|
||
|
|
|
|
|
|
|
|
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
||
|
|
||
|
|
||
|
|
||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
|
|
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
||
|
|
|
|
|
|
|
|
|
|
||
|
|
|
|
|
|
||
|
|
|
|
|
|
|
|
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
Appendix B: ISO 19139 to ISO 19115-3 Transformations
This section presents an example of a GetRecordsResponse
in ISO 19139 before and after transformation into ISO 19115-3.
GetRecordsResponse (ISO 19139)
GetRecords Request
The GetRecords query below requested the response to contain the data in ISO 19139 format by specifying the outputSchema
attribute value as the GMD namespace:
outputSchema="http://www.isotc211.org/2005/gmd"
<?xml version="1.0" encoding="UTF-8"?>
<csw:GetRecords
xmlns:ogc="http://www.opengis.net/ogc"
xmlns:csw="http://www.opengis.net/cat/csw/2.0.2"
xmlns:gml="http://www.opengis.net/gml"
xmlns:gmd="http://www.isotc211.org/2005/gmd"
service="CSW" version="2.0.2" resultType="results" outputFormat="application/xml" outputSchema="http://www.isotc211.org/2005/gmd" startPosition="1" maxRecords="200">
<csw:Query typeNames="gmd:MD_Metadata">
<csw:ElementSetName>full</csw:ElementSetName>
<csw:Constraint version="1.1.0">
<ogc:Filter>
<ogc:PropertyIsEqualTo>
<ogc:PropertyName>Title</ogc:PropertyName>
<ogc:Literal>Ice Cores of the National Ice Core Laboratory</ogc:Literal>
</ogc:PropertyIsEqualTo>
</ogc:Filter>
</csw:Constraint>
</csw:Query>
</csw:GetRecords>
GetRecordsResponse
<?xml version="1.0" encoding="UTF-8"?>
<csw:GetRecordsResponse xmlns:csw="http://www.opengis.net/cat/csw/2.0.2" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:dct="http://purl.org/dc/terms/" xmlns:env-ebrim="http://www.envitia.com/schemas/georegistry/ebrim-ext" xmlns:gmd="http://www.isotc211.org/2005/gmd" xmlns:gml="http://www.opengis.net/gml" xmlns:ogc="http://www.opengis.net/ogc" xmlns:ows="http://www.opengis.net/ows" xmlns:wrs="http://www.opengis.net/cat/wrs/1.0" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:xmime="http://www.w3.org/2005/05/xmlmime">
<csw:SearchStatus timestamp="2017-09-07T04:25:01.712-07:00"/>
<csw:SearchResults elementSet="full" nextRecord="0" numberOfRecordsMatched="1" numberOfRecordsReturned="1" recordSchema="http://www.isotc211.org/2005/gmd">
<gmd:MD_Metadata id="M1501170734777" uuid="a6799c19-c831-434f-8b6a-33699300bca8" xmlns:gco="http://www.isotc211.org/2005/gco" xmlns:gts="http://www.isotc211.org/2005/gts" xmlns:mgmp="http://mod.uk/spatial/ns/mgmp/2.0" xmlns:srv="http://www.isotc211.org/2005/srv">
<gmd:fileIdentifier>
<gco:CharacterString>1501170734777</gco:CharacterString>
</gmd:fileIdentifier>
<gmd:language>
<gco:CharacterString>eng</gco:CharacterString>
</gmd:language>
<gmd:hierarchyLevel>
<gmd:MD_ScopeCode codeList="http://www.isotc211.org/2005/resources/codeList.xml#MD_ScopeCode" codeListValue="dataset"/>
</gmd:hierarchyLevel>
<gmd:contact>
<gmd:CI_ResponsibleParty>
<gmd:organisationName>
<gco:CharacterString>Envitia</gco:CharacterString>
</gmd:organisationName>
<gmd:role>
<gmd:CI_RoleCode codeList="http://www.isotc211.org/2005/resources/codeList.xml#CI_RoleCode" codeListValue="publisher"/>
</gmd:role>
</gmd:CI_ResponsibleParty>
</gmd:contact>
<gmd:dateStamp>
<gco:Date>2017-07-27</gco:Date>
</gmd:dateStamp>
<gmd:identificationInfo>
<gmd:MD_DataIdentification>
<gmd:citation>
<gmd:CI_Citation>
<gmd:title>
<gco:CharacterString>Ice Cores of the National Ice Core Laboratory</gco:CharacterString>
</gmd:title>
<gmd:date>
<gmd:CI_Date>
<gmd:date>
<gco:Date>2013-03-08</gco:Date>
</gmd:date>
<gmd:dateType>
<gmd:CI_DateTypeCode codeList="http://www.isotc211.org/2005/resources/codeList.xml#CI_DateTypeCode" codeListValue="revision"/>
</gmd:dateType>
</gmd:CI_Date>
</gmd:date>
</gmd:CI_Citation>
</gmd:citation>
<gmd:abstract>
<gco:CharacterString>The U.S. National Ice Core Laboratory (NICL) is a facility for storing, curating, and studying ice cores recovered from the polar regions of the world. It provides scientists with the capability to conduct examinations and measurements on ice cores, and it preserves the integrity of these ice cores in a long-term repository for current and future investigations.</gco:CharacterString>
</gmd:abstract>
<gmd:pointOfContact>
<gmd:CI_ResponsibleParty>
<gmd:organisationName>
<gco:CharacterString>USGS</gco:CharacterString>
</gmd:organisationName>
<gmd:contactInfo>
<gmd:CI_Contact>
<gmd:phone/>
<gmd:address>
<gmd:CI_Address>
<gmd:deliveryPoint/>
<gmd:city/>
<gmd:postalCode/>
<gmd:electronicMailAddress>
<gco:CharacterString>sbristol@usgs.gov</gco:CharacterString>
</gmd:electronicMailAddress>
</gmd:CI_Address>
</gmd:address>
<gmd:onlineResource>
<gmd:CI_OnlineResource>
<gmd:linkage>
<gmd:URL>http://www.usgs.gov</gmd:URL>
</gmd:linkage>
</gmd:CI_OnlineResource>
</gmd:onlineResource>
</gmd:CI_Contact>
</gmd:contactInfo>
<gmd:role>
<gmd:CI_RoleCode codeList="http://www.isotc211.org/2005/resources/codeList.xml#CI_RoleCode" codeListValue="originator"/>
</gmd:role>
</gmd:CI_ResponsibleParty>
</gmd:pointOfContact>
<gmd:descriptiveKeywords>
<gmd:MD_Keywords>
<gmd:keyword>
<gco:CharacterString>Collection</gco:CharacterString>
</gmd:keyword>
<gmd:keyword>
<gco:CharacterString>USGS Science Data Catalog (SDC)</gco:CharacterString>
</gmd:keyword>
<gmd:type>
<gmd:MD_KeywordTypeCode codeList="http://metadata.dgiwg.org/codelistRegistry?MD_KeywordTypeCode" codeListValue="theme"/>
</gmd:type>
</gmd:MD_Keywords>
</gmd:descriptiveKeywords>
<gmd:resourceConstraints>
<gmd:MD_SecurityConstraints>
<gmd:classification>
<gmd:MD_ClassificationCode codeList="http://www.isotc211.org/2005/resources/codeList.xml#MD_ClassificationCode" codeListValue="unclassified"/>
</gmd:classification>
</gmd:MD_SecurityConstraints>
</gmd:resourceConstraints>
<gmd:language>
<gco:CharacterString>eng</gco:CharacterString>
</gmd:language>
<gmd:topicCategory>
<gmd:MD_TopicCategoryCode>environment</gmd:MD_TopicCategoryCode>
</gmd:topicCategory>
<gmd:extent>
<gmd:EX_Extent>
<gmd:geographicElement>
<gmd:EX_GeographicBoundingBox>
<gmd:westBoundLongitude>
<gco:Decimal>-179.99999999994</gco:Decimal>
</gmd:westBoundLongitude>
<gmd:eastBoundLongitude>
<gco:Decimal>179.999988540844</gco:Decimal>
</gmd:eastBoundLongitude>
<gmd:southBoundLatitude>
<gco:Decimal>-89.0000000000073</gco:Decimal>
</gmd:southBoundLatitude>
<gmd:northBoundLatitude>
<gco:Decimal>83.6235961786649</gco:Decimal>
</gmd:northBoundLatitude>
</gmd:EX_GeographicBoundingBox>
</gmd:geographicElement>
</gmd:EX_Extent>
</gmd:extent>
</gmd:MD_DataIdentification>
</gmd:identificationInfo>
<gmd:distributionInfo>
<gmd:MD_Distribution>
<gmd:distributor>
<gmd:MD_Distributor>
<gmd:distributorContact>
<gmd:CI_ResponsibleParty>
<gmd:organisationName>
<gco:CharacterString>USGS</gco:CharacterString>
</gmd:organisationName>
<gmd:positionName/>
<gmd:role>
<gmd:CI_RoleCode codeList="http://www.isotc211.org/2005/resources/codeList.xml#CI_RoleCode" codeListValue="distributor"/>
</gmd:role>
</gmd:CI_ResponsibleParty>
</gmd:distributorContact>
</gmd:MD_Distributor>
</gmd:distributor>
<gmd:transferOptions>
<gmd:MD_DigitalTransferOptions>
<gmd:onLine>
<gmd:CI_OnlineResource>
<gmd:linkage>
<gmd:URL>https://www.sciencebase.gov/catalog/item/513a2eaae4b09608cc166c1b</gmd:URL>
</gmd:linkage>
</gmd:CI_OnlineResource>
</gmd:onLine>
</gmd:MD_DigitalTransferOptions>
</gmd:transferOptions>
</gmd:MD_Distribution>
</gmd:distributionInfo>
<gmd:metadataConstraints>
<gmd:MD_SecurityConstraints>
<gmd:classification>
<gmd:MD_ClassificationCode codeList="http://www.isotc211.org/2005/resources/codeList.xml#MD_ClassificationCode" codeListValue="unclassified"/>
</gmd:classification>
</gmd:MD_SecurityConstraints>
</gmd:metadataConstraints>
</gmd:MD_Metadata>
</csw:SearchResults>
</csw:GetRecordsResponse>
GetRecordsResponse (ISO 19115-3)
GetRecords Request
The GetRecords query below requested the response to contain the data in ISO 19115-3 format by specifying the outputSchema
attribute value as the MDB namespace:
outputSchema="http://standards.iso.org/iso/19115/-3/mdb/1.0"
<?xml version="1.0" encoding="UTF-8"?>
<csw:GetRecords
xmlns:ogc="http://www.opengis.net/ogc"
xmlns:csw="http://www.opengis.net/cat/csw/2.0.2"
xmlns:gml="http://www.opengis.net/gml"
xmlns:gmd="http://www.isotc211.org/2005/gmd"
service="CSW" version="2.0.2" resultType="results" outputFormat="application/xml" outputSchema="http://standards.iso.org/iso/19115/-3/mdb/1.0" startPosition="1" maxRecords="200">
<csw:Query typeNames="mdb:MD_Metadata">
<csw:ElementSetName>full</csw:ElementSetName>
<csw:Constraint version="1.1.0">
<ogc:Filter>
<ogc:PropertyIsEqualTo>
<ogc:PropertyName>Title</ogc:PropertyName>
<ogc:Literal>Ice Cores of the National Ice Core Laboratory</ogc:Literal>
</ogc:PropertyIsEqualTo>
</ogc:Filter>
</csw:Constraint>
</csw:Query>
</csw:GetRecords>
GetRecordsResponse
<?xml version="1.0" encoding="UTF-8"?>
<csw:GetRecordsResponse
xmlns:csw="http://www.opengis.net/cat/csw/2.0.2"
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:dct="http://purl.org/dc/terms/"
xmlns:env-ebrim="http://www.envitia.com/schemas/georegistry/ebrim-ext"
xmlns:gmd="http://www.isotc211.org/2005/gmd"
xmlns:gml="http://www.opengis.net/gml"
xmlns:ogc="http://www.opengis.net/ogc"
xmlns:ows="http://www.opengis.net/ows"
xmlns:wrs="http://www.opengis.net/cat/wrs/1.0"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns:xmime="http://www.w3.org/2005/05/xmlmime">
<csw:SearchStatus timestamp="2017-09-07T04:25:01.928-07:00"/>
<csw:SearchResults elementSet="full" nextRecord="0" numberOfRecordsMatched="1" numberOfRecordsReturned="1" recordSchema="http://www.isotc211.org/2005/gmd">
<mdb:MD_Metadata
xmlns:cat="http://standards.iso.org/iso/19115/-3/cat/1.0"
xmlns:cit="http://standards.iso.org/iso/19115/-3/cit/1.0"
xmlns:gco="http://standards.iso.org/iso/19115/-3/gco/1.0"
xmlns:gcx="http://standards.iso.org/iso/19115/-3/gcx/1.0"
xmlns:gex="http://standards.iso.org/iso/19115/-3/gex/1.0"
xmlns:gml="http://www.opengis.net/gml/3.2"
xmlns:lan="http://standards.iso.org/iso/19115/-3/lan/1.0"
xmlns:mac="http://standards.iso.org/iso/19115/-3/mac/1.0"
xmlns:mas="http://standards.iso.org/iso/19115/-3/mas/1.0"
xmlns:mcc="http://standards.iso.org/iso/19115/-3/mcc/1.0"
xmlns:mco="http://standards.iso.org/iso/19115/-3/mco/1.0"
xmlns:mda="http://standards.iso.org/iso/19115/-3/mda/1.0"
xmlns:mdb="http://standards.iso.org/iso/19115/-3/mdb/1.0"
xmlns:mdq="http://standards.iso.org/iso/19157/-2/mdq/1.0"
xmlns:mds="http://standards.iso.org/iso/19115/-3/mds/1.0"
xmlns:mdt="http://standards.iso.org/iso/19115/-3/mdt/1.0"
xmlns:mex="http://standards.iso.org/iso/19115/-3/mex/1.0"
xmlns:mmi="http://standards.iso.org/iso/19115/-3/mmi/1.0"
xmlns:mpc="http://standards.iso.org/iso/19115/-3/mpc/1.0"
xmlns:mrc="http://standards.iso.org/iso/19115/-3/mrc/1.0"
xmlns:mrd="http://standards.iso.org/iso/19115/-3/mrd/1.0"
xmlns:mri="http://standards.iso.org/iso/19115/-3/mri/1.0"
xmlns:mrl="http://standards.iso.org/iso/19115/-3/mrl/1.0"
xmlns:mrs="http://standards.iso.org/iso/19115/-3/mrs/1.0"
xmlns:msr="http://standards.iso.org/iso/19115/-3/msr/1.0"
xmlns:srv="http://standards.iso.org/iso/19115/-3/srv/2.0"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<mdb:metadataIdentifier>
<mcc:MD_Identifier>
<mcc:code>
<gco:CharacterString>1501170734777</gco:CharacterString>
</mcc:code>
</mcc:MD_Identifier>
</mdb:metadataIdentifier>
<mdb:defaultLocale>
<lan:PT_Locale>
<lan:language>
<lan:LanguageCode codeList="codeListLocation#LanguageCode" codeListValue="eng">eng</lan:LanguageCode>
</lan:language>
<lan:characterEncoding gco:nilReason="unknown"/>
</lan:PT_Locale>
</mdb:defaultLocale>
<mdb:metadataScope>
<mdb:MD_MetadataScope>
<mdb:resourceScope>
<mcc:MD_ScopeCode codeList="codeListLocation#MD_ScopeCode" codeListValue="dataset">dataset</mcc:MD_ScopeCode>
</mdb:resourceScope>
</mdb:MD_MetadataScope>
</mdb:metadataScope>
<mdb:contact>
<cit:CI_Responsibility>
<cit:role>
<cit:CI_RoleCode codeList="codeListLocation#CI_RoleCode" codeListValue="publisher">publisher</cit:CI_RoleCode>
</cit:role>
<cit:party>
<cit:CI_Organisation>
<cit:name>
<gco:CharacterString>Envitia</gco:CharacterString>
</cit:name>
</cit:CI_Organisation>
</cit:party>
</cit:CI_Responsibility>
</mdb:contact>
<mdb:dateInfo>
<cit:CI_Date>
<cit:date>
<gco:DateTime>2017-07-27T00:00:00</gco:DateTime>
</cit:date>
<cit:dateType>
<cit:CI_DateTypeCode codeList="codeListLocation#CI_DateTypeCode" codeListValue="creation">creation</cit:CI_DateTypeCode>
</cit:dateType>
</cit:CI_Date>
</mdb:dateInfo>
<mdb:identificationInfo>
<mri:MD_DataIdentification>
<mri:citation>
<cit:CI_Citation>
<cit:title>
<gco:CharacterString>Ice Cores of the National Ice Core Laboratory</gco:CharacterString>
</cit:title>
<cit:date>
<cit:CI_Date>
<cit:date>
<gco:DateTime>2013-03-08T00:00:00</gco:DateTime>
</cit:date>
<cit:dateType>
<cit:CI_DateTypeCode codeList="codeListLocation#CI_DateTypeCode" codeListValue="revision">revision</cit:CI_DateTypeCode>
</cit:dateType>
</cit:CI_Date>
</cit:date>
</cit:CI_Citation>
</mri:citation>
<mri:abstract>
<gco:CharacterString>The U.S. National Ice Core Laboratory (NICL) is a facility for storing, curating, and studying ice cores recovered from the polar regions of the world. It provides scientists with the capability to conduct examinations and measurements on ice cores, and it preserves the integrity of these ice cores in a long-term repository for current and future investigations.</gco:CharacterString>
</mri:abstract>
<mri:pointOfContact>
<cit:CI_Responsibility>
<cit:role>
<cit:CI_RoleCode codeList="codeListLocation#CI_RoleCode" codeListValue="originator">originator</cit:CI_RoleCode>
</cit:role>
<cit:party>
<cit:CI_Organisation>
<cit:name>
<gco:CharacterString>USGS</gco:CharacterString>
</cit:name>
<cit:contactInfo>
<cit:CI_Contact>
<cit:address>
<cit:CI_Address>
<cit:deliveryPoint/>
<cit:city/>
<cit:postalCode/>
<cit:electronicMailAddress>
<gco:CharacterString>sbristol@usgs.gov</gco:CharacterString>
</cit:electronicMailAddress>
</cit:CI_Address>
</cit:address>
<cit:onlineResource>
<cit:CI_OnlineResource>
<cit:linkage>
<gco:CharacterString>http://www.usgs.gov</gco:CharacterString>
</cit:linkage>
</cit:CI_OnlineResource>
</cit:onlineResource>
</cit:CI_Contact>
</cit:contactInfo>
</cit:CI_Organisation>
</cit:party>
</cit:CI_Responsibility>
</mri:pointOfContact>
<mri:topicCategory>
<mri:MD_TopicCategoryCode>environment</mri:MD_TopicCategoryCode>
</mri:topicCategory>
<mri:extent>
<gex:EX_Extent>
<gex:geographicElement>
<gex:EX_GeographicBoundingBox>
<gex:westBoundLongitude>
<gco:Decimal>-179.99999999994</gco:Decimal>
</gex:westBoundLongitude>
<gex:eastBoundLongitude>
<gco:Decimal>179.999988540844</gco:Decimal>
</gex:eastBoundLongitude>
<gex:southBoundLatitude>
<gco:Decimal>-89.0000000000073</gco:Decimal>
</gex:southBoundLatitude>
<gex:northBoundLatitude>
<gco:Decimal>83.6235961786649</gco:Decimal>
</gex:northBoundLatitude>
</gex:EX_GeographicBoundingBox>
</gex:geographicElement>
</gex:EX_Extent>
</mri:extent>
<mri:descriptiveKeywords>
<mri:MD_Keywords>
<mri:keyword>
<gco:CharacterString>Collection</gco:CharacterString>
</mri:keyword>
<mri:keyword>
<gco:CharacterString>USGS Science Data Catalog (SDC)</gco:CharacterString>
</mri:keyword>
<mri:type>
<mri:MD_KeywordTypeCode codeList="http://metadata.dgiwg.org/codelistRegistry?MD_KeywordTypeCode" codeListValue="theme"/>
</mri:type>
</mri:MD_Keywords>
</mri:descriptiveKeywords>
<mri:resourceConstraints>
<mco:MD_SecurityConstraints>
<mco:classification>
<mco:MD_ClassificationCode codeList="http://www.isotc211.org/2005/resources/codeList.xml#MD_ClassificationCode" codeListValue="unclassified"/>
</mco:classification>
</mco:MD_SecurityConstraints>
</mri:resourceConstraints>
<mri:defaultLocale>
<lan:PT_Locale>
<lan:language>
<lan:LanguageCode codeList="codeListLocation#LanguageCode" codeListValue="eng">eng</lan:LanguageCode>
</lan:language>
<lan:characterEncoding gco:nilReason="unknown"/>
</lan:PT_Locale>
</mri:defaultLocale>
</mri:MD_DataIdentification>
</mdb:identificationInfo>
<mdb:distributionInfo>
<mrd:MD_Distribution>
<mrd:distributor>
<mrd:MD_Distributor>
<mrd:distributorContact>
<cit:CI_Responsibility>
<cit:role>
<cit:CI_RoleCode codeList="codeListLocation#CI_RoleCode" codeListValue="distributor">distributor</cit:CI_RoleCode>
</cit:role>
<cit:party>
<cit:CI_Organisation>
<cit:name>
<gco:CharacterString>USGS</gco:CharacterString>
</cit:name>
<cit:individual>
<cit:CI_Individual>
<cit:positionName/>
</cit:CI_Individual>
</cit:individual>
</cit:CI_Organisation>
</cit:party>
</cit:CI_Responsibility>
</mrd:distributorContact>
</mrd:MD_Distributor>
</mrd:distributor>
<mrd:transferOptions>
<mrd:MD_DigitalTransferOptions>
<mrd:onLine>
<cit:CI_OnlineResource>
<cit:linkage>
<gco:CharacterString>https://www.sciencebase.gov/catalog/item/513a2eaae4b09608cc166c1b</gco:CharacterString>
</cit:linkage>
</cit:CI_OnlineResource>
</mrd:onLine>
</mrd:MD_DigitalTransferOptions>
</mrd:transferOptions>
</mrd:MD_Distribution>
</mdb:distributionInfo>
<mdb:metadataConstraints>
<mco:MD_SecurityConstraints>
<mco:classification>
<mco:MD_ClassificationCode codeList="http://www.isotc211.org/2005/resources/codeList.xml#MD_ClassificationCode" codeListValue="unclassified"/>
</mco:classification>
</mco:MD_SecurityConstraints>
</mdb:metadataConstraints>
</mdb:MD_Metadata>
</csw:SearchResults>
</csw:GetRecordsResponse>
Appendix C: Revision History
Date | Release | Editor | Primary clauses modified | Descriptions |
---|---|---|---|---|
June 15, 2016 |
0.1 |
G. Hobona |
all |
initial version |
September 30, 2017 |
1.0 |
S. McCann |
all |
Draft ER |
Appendix D: Bibliography
[1] Harping, P.: Introduction to Controlled Vocabularies: Terminology for Art, Architecture, and Other Cultural Works. Getty Publications, (2010)
[2] White, M.: Making Search Work: Implementing Web, Intranet and Enterprise Search. Facet Publishing, (2007)
[3] Schmidt-Schauß, M. and Smolka, G.: Attributive concept descriptions with complements, Artificial Intelligence,48, pp. 1-26 (1991)
[4] Vatant, B., Rozat, L., Vandenbussche, P.: Vocabulary of a Friend (VOAF) - version 2.3, Open Knowledge International, http://lov.okfn.org/vocommons/voaf/v2.3, (2013)