Difference between revisions of "ISO Distribution Information"
| (One intermediate revision by the same user not shown) | |||
| Line 12: | Line 12: | ||
The final approach (right column in Figure) is becoming available in the revision of 19115 (19115-1). This revision adds a distributionFormat role to the MD_DigitalTransferOptions object which allows a single MD_Distributor to unambiguously describe multiple transferOptions each of which has an associated format. | The final approach (right column in Figure) is becoming available in the revision of 19115 (19115-1). This revision adds a distributionFormat role to the MD_DigitalTransferOptions object which allows a single MD_Distributor to unambiguously describe multiple transferOptions each of which has an associated format. | ||
| + | |||
| + | ==Distribution Vs. Services== | ||
| + | |||
| + | Many data providers are using standard data services (WMS, WCS, SOS, ...) and need to provide information about those services in 19115(-2) metadata. Historically this type of inormation has been provided in the Distribution section of the metadata. In many cases, tools trying to identify standard services had to parse the URLs for hints about what type of service the URL might reference. | ||
| + | |||
| + | These problems have been addressed to some extent with the creation of the ISO 19119 Metadata Standard for Services. This standard extends 19115 with the addition of several objects that hold information specifically related to services, including the ULRs that can be used to invoke those services. | ||
| + | |||
| + | It seems reasonable to take advantage of the 19119 extensions when describing standard services associated with a dataset. This brings the capabilities of 19119 to bear on the problem they are designed to solve and avoids the ambiguity described above. | ||
| + | |||
| + | The records created this way will include a gmd:MD_DataIdentification object that describes the dataset and srv:SV_ServiceIdentification objects that describes each standard service that is available for that dataset. | ||
| + | |||
| + | <pre> | ||
| + | <gmd:identificationInfo> | ||
| + | <gmd:MD_DataIdentification id="DataIdentification"> | ||
| + | ... | ||
| + | </gmd:MD_DataIdentification> | ||
| + | </gmd:identificationInfo> | ||
| + | <gmd:identificationInfo> | ||
| + | <srv:SV_ServiceIdentification> | ||
| + | <srv:operatesOn xlink:href="#DataIdentification"/> | ||
| + | </srv:SV_ServiceIdentification> | ||
| + | </gmd:identificationInfo> | ||
| + | </pre> | ||
| + | |||
| + | In this example the MD_DataIdentification object has an id="DataIdentification" so that it can be referenced with an internal link (xlink:href="DataIdentification") from the srv:operatesOn element of the service metadata. | ||
| + | gmd:HierarchyLevel | ||
| + | |||
| + | The MD_ScopeCode code list includes dataset and service as valid codes. The 19115 standard allows a single record to have multiple scope codes (gmd:HierarchyLevel) and level names (gmd:hierarchyLevelName) so it is possible and valid to give a record two scope codes: | ||
| + | |||
| + | <pre> | ||
| + | <gmd:hierarchyLevel> | ||
| + | <gmd:MD_ScopeCode codeList="http://www.isotc211.org/2005/resources/Codelist/gmxCodelists.xml#MD_ScopeCode" codeListValue="dataset">dataset</gmd:MD_ScopeCode> | ||
| + | </gmd:hierarchyLevel> | ||
| + | <gmd:hierarchyLevel> | ||
| + | <gmd:MD_ScopeCode codeList="http://www.isotc211.org/2005/resources/Codelist/gmxCodelists.xml#MD_ScopeCode" codeListValue="service">service</gmd:MD_ScopeCode> | ||
| + | </gmd:hierarchyLevel> | ||
| + | </pre> | ||
Latest revision as of 14:38, September 29, 2017
MD_Distribution
The ISO MD_Distribution Object provides information about where users can get data, the formats available, and the processes for ordering the data. Distribution Organization. The MD_Distribution object includes any number of distributors, distributionFormats, and transfer options. This flexibility is good, but the many-to-many relationships between these objects can make it difficult to unambiguously specify distribution information. Three approaches to organizing this information are shown in the Figure to the right.
The first approach (left column in Figure) works well in situations wherer the data are available in a single format from a single distributor. In that case the distributor, distributionFormat, and transferOptions roles can be used directly from the MD_Distribution object.
In more complex situations where the data are available from multiple distributors (center column in Figure), a MD_Distributor object must exist for each distributor and each would have associated distributorFormats and distributorTransferOptions. This approach actually requires a separate MD_Distributor for each unique combination of distributorFormat and distributorTransferOptions in order to unambiguously associate the correct transferOption with each distributionFormat.
The final approach (right column in Figure) is becoming available in the revision of 19115 (19115-1). This revision adds a distributionFormat role to the MD_DigitalTransferOptions object which allows a single MD_Distributor to unambiguously describe multiple transferOptions each of which has an associated format.
Distribution Vs. Services
Many data providers are using standard data services (WMS, WCS, SOS, ...) and need to provide information about those services in 19115(-2) metadata. Historically this type of inormation has been provided in the Distribution section of the metadata. In many cases, tools trying to identify standard services had to parse the URLs for hints about what type of service the URL might reference.
These problems have been addressed to some extent with the creation of the ISO 19119 Metadata Standard for Services. This standard extends 19115 with the addition of several objects that hold information specifically related to services, including the ULRs that can be used to invoke those services.
It seems reasonable to take advantage of the 19119 extensions when describing standard services associated with a dataset. This brings the capabilities of 19119 to bear on the problem they are designed to solve and avoids the ambiguity described above.
The records created this way will include a gmd:MD_DataIdentification object that describes the dataset and srv:SV_ServiceIdentification objects that describes each standard service that is available for that dataset.
<gmd:identificationInfo>
<gmd:MD_DataIdentification id="DataIdentification">
...
</gmd:MD_DataIdentification>
</gmd:identificationInfo>
<gmd:identificationInfo>
<srv:SV_ServiceIdentification>
<srv:operatesOn xlink:href="#DataIdentification"/>
</srv:SV_ServiceIdentification>
</gmd:identificationInfo>
In this example the MD_DataIdentification object has an id="DataIdentification" so that it can be referenced with an internal link (xlink:href="DataIdentification") from the srv:operatesOn element of the service metadata. gmd:HierarchyLevel
The MD_ScopeCode code list includes dataset and service as valid codes. The 19115 standard allows a single record to have multiple scope codes (gmd:HierarchyLevel) and level names (gmd:hierarchyLevelName) so it is possible and valid to give a record two scope codes:
<gmd:hierarchyLevel> <gmd:MD_ScopeCode codeList="http://www.isotc211.org/2005/resources/Codelist/gmxCodelists.xml#MD_ScopeCode" codeListValue="dataset">dataset</gmd:MD_ScopeCode> </gmd:hierarchyLevel> <gmd:hierarchyLevel> <gmd:MD_ScopeCode codeList="http://www.isotc211.org/2005/resources/Codelist/gmxCodelists.xml#MD_ScopeCode" codeListValue="service">service</gmd:MD_ScopeCode> </gmd:hierarchyLevel>
