# Presentation: 548840

## OPeNDAP/OGC Gateway to support Regional IOOS interoperability

- 	Opportunity to implement an interoperability approach presented by the OPeNDAP community: Semantic Mapping Framework, developed by Benno Blumenthal @ Columbia’s IRI.
- Using Namespaces in DAP attributes to explicitly label which convention it belongs to, and multiple (partially redundent) conventions can be carried by the transport mechanism.
- Take advantage of newer rule-based systems for writing down translations that could simplify maintaining and testing of translations
- Resource Description Language (RDF) and its associated semantic conventions such as Web Ontology Language (OWL) provide a way of writing down metadata structures and such mappings.
- The basic strategy in RDF/OWL is that instead of creating a super-schema, you just have all the metadata in multiple namespaces attached to the data, and standard rules/engines for creating metadata in one scheme from metadata in another scheme. And if a standard engine does not work, you can always write a specialized one until the standard ones becomes more complete.

## Carrying Semantics in the DAP

- Precisely stating which attributes belong to which conventions makes understanding the entire set of attributes much easier when multiple conventions are used to add semantics to DAP variables. Slight change in conventional usage allows semantics to be carried in the current version of the DAP.
- Extend usage of Conventions attribute to allow namespace  specification, .i.e. use strings of the form **ns=URI**, .e.g. cfatt=http://iridl.columbia.edu/ontologies/cf-att.owl
- Then use namespace abbreviation in attributes, .e.g. cfatt:standard _name
- Use URL attribute types for URIs
- We should additionally specify what the proper URI for each entity in a DAP data set should be, .i.e., **dods_url#variable_name** or **urn:opendap:variable_name** so that DAP variables can be consistently referred to by RDF.OWL and/or XML files.
- Establishing URIs for the elements within an OPeNDAP data set means that outside documents/software can refer to those elements and make semantic statements about them. This allows use semantic translation, where an outside program can translate the use semantics of a variable into different conventions, e.g. CF or OpenGIS or GRIB or any of the many lesser-known systems for adding some metadata to data.

## Explicitly recognizing that the URL type should be used to refer to standard concepts, while not literally a change to OPeNDAP, provides a way to transport semantics external to OPeNDAP. 

-     URL sos:observedProperty "http://marinemetadata.org/cf#sea_surface_temperature";
-     URL sos:units "urn:OGC:unit:degree";
-     URL sos:featureOfInterest "urn:mmi.feature#bodyOfWater";
-     String cfatt:units "degree_Celsius";
-     String cfatt:long_name "sea surface temperature";
-     String cfatt:standard_name "sea_surface_temperature";
-     URL term:isDescribedBy "http://iridl.ldeo.columbia.edu/ontologies/iridl.owl#NOAA",
-         "http://sweet.jpl.nasa.gov/ontology/data_center.owl#National_Oceanic_and_Atmospheric_Administration",
-         "http://marinemetadata.org/2005/08/gcmd-keyw#Oceans";
-     URL iridl:hasDocumentation "http://iridl.ldeo.columbia.edu/ontologies/ReferenceList.owl#Reynolds_Smith1994";
- }
- NC_GLOBAL {
-     String Conventions "sos=http://www.opengis.net/sos/0",
-         "cfatt=http://iridl.ldeo.columbia.edu/ontologies/cf-att.owl#",
-         "iridl=http://iridl.ldeo.columbia.edu/ontologies/iridl.owl#",
-         "term=http://iridl.ldeo.columbia.edu/ontologies/iriterms.owl#";
- }

- Explicitly recognizing that the URL type should be used to refer to standard concepts, while not literally a change to OPeNDAP, provides a way to transport semantics external to OPeNDAP.
- <sos:observedProperty xlink:href="http://marinemetadata.org/cf#sea_water_temperature"/>
- <sos:units href="urn:OGC:unit:degree" />
- <sos:featureOfInterest xlink:href="urn:mmi.feature#bodyOfWater" />
- can be transported (adding some more attributes)

## Server Architecture (Hyrax)

- DAP2

- HTML

- THREDDS

- OGC WxS

- XML encapsulated object

- BES Commands

- Optional THREDDS Catalogs

- _Server Architecture (Hyrax)_

## Server Architecture (Hyrax)

- DAP2

- HTML

- THREDDS

- OGC WxS

- BES Commands

- _Server Architecture (Hyrax)_

- Module-based Architecture where separate modules support different application-level protocols.
-  Handles inbound requests
-  Determines how a response should be built.
- Communicates with BES using a stateful, conversational, protocol.
-  May ask BES to access different data sources, return information on filesystem, or return different (DAP) responses.

## Server Architecture (Hyrax)

- XML encapsulated object

- _Server Architecture (Hyrax)_

- Module-based Architecture, where run-time loadable modules are used to build response objects.
-  Format Handlers
-  Write data into DAP response objects
-  Response Handlers
-  Read data from DAP response objects
- Ancillary Information Service (AIS) - DDX

## Kickoff Meeting
	Fall AGU Meeting - Dec. 2007
Generating Use Cases 
	Driven by OGC Interface Specification
Developing OWL descriptions for DAP, CF, WxS
	Module for DDX -> RDF, and RDF -> DDX
Refining the design, focus on modularization for development and test as standalone elements.

DM Issues
	Interface Specification Revision to support
	Aggregating file-based collections

- 	Fall AGU Meeting - Dec. 2007
- Generating Use Cases
- 	Driven by OGC Interface Specification
- Developing OWL descriptions for DAP, CF, WxS
- 	Module for DDX -> RDF, and RDF -> DDX
- Refining the design, focus on modularization for development and test as standalone elements.
- DM Issues
- 	Interface Specification Revision to support
- 	Aggregating file-based collections

- _OPeNDAP/OGC Gateway to support Regional IOOS interoperability_