The problem of data integration can be looked at from several angles: technologies, workflows, standards, etc. Within the context of each viewing angle a diagram can be drawn at varying levels of detail focusing on any component of the data integration technology stack.
This "technology map" uses the data management/integration technology elements, servers, services, and data as grouping themes. It attempts to give an overview of the entire existing data integration technology stack. These items are intended to be top levels of organization for documentation developed by the TSWG and collaborators. These will each be a link to a sub-wiki space containing other pages and content about the items.
Collaboration Tools: Listing and evaluation of a number of things like wikis that are used to help geographically distributed groups of people have conversations and share ideas.
Examples of Integration: Information on the use of one or more of the technology components listed below within a single system.
Technology Components: Some of the major building blocks that the TSWG sees as being useful for making data and services readily usable to scientists and the public in a networked environment.
Sub-pages discussing individual components are being added--if you know about one, please add to a pre-existing page or create a new one!
Servers | Services/ | Standards | Software Packages |
|---|---|---|---|
File | Visualization | Storage | Scripting |
Matlab | |||
ESRI REST? | R | ||
Most OGC standards (WCS, WFS, etc) | RDBMS, File Geodatabase, shapefile | ||
Database | JDBC /SQL | S+ | |
Transport Encodings | GIS | ||
ArcGIS Server | ESRI REST? | OGC-XML (O&M, WaterML, GWML, GMLSF, KML, SWE) | |
MySQL (http:--www.mysql.com-) | Feature | OPeNDAP-Binary | QGIS |
Oracle | Enterprise Standard-XML | GRASS | |
PostGRES (http:--www.postgresql.org-) | SOS | GDAL | |
SQLServer | ESRI Rest |
| Productivity |
Server Applications | Processing | Code | Microsoft Office |
Web Applications | |||
Uploader | ESRI REST |
| |
ESRI GeoPortal (Metadata Server) | MetaData Server |
| eXcat |
| Metadata | ||
ESRI Metadata |
| ||
Enterprise Systems | RSS/GeoRSS (http:--www.georss.org-Main_Page) |
|
|
things to fit in:
- Distributed File Systems: Windows "shared" folders/DFS, WebDAV, SAMBA/SMB, LDAP
- OpenSearch, Implementation guide from ESIP.
Glossary
Server:
File Server:
Database Server:
Other Server:
Services:
Visualization Services:
Grid Services:
Feature Services:
Processing Services:
Data Standards:
Data Storage Standards:
Data Transport Encoding Standards:
Overview
Community Forums
Content Tools
Tasks
U.S. Department of the Interior
| DOI Inspector General | White House | No Fear Act
DOI and USGS link policies apply
1 Comment
Unknown User (jagui@usgs.gov)
great ideas. this is very challenging to organize. because Confluence is label-based, then I think it's okay to have some duplication in the navigation structure, but we should try to minimize. Here's a really REALLY rough cut based on the ideas above. It's not super-well thought out, so I already see some issues... Feel free to edit. I didn't want to put it in the main page until it gets cleaned up.
My thinking is if we set this up as a test structure and configured each node to automatically load content with the applicable labels, then the structure would be dynamic. Maybe we need a "Master Docs" directory node where folks can create content and label it accordingly so it gets picked up by this dynamic structure? For actual leaf nodes, we don't need to statically include each child I listed above... e.g., we don't need to include ArcGIS, GRASS, QGIS, uDig,... under GIS->Desktop... as long as content is labeled "GIS desktop", then it will automatically appear under this node.
Farial's been experimenting with this stuff in Confluence, so I think she can configure this to work. Maybe just start with one sub-node first to make sure it works the way we think.