Latest revision as of 16:45, December 13, 2011

Summary

The addition of namespace-specific attributes (e.g., esip:subrel) is problematic because mass-market tools (e.g., Firefox, OpenLayers) will not understand them and have little motivation for changing to understand them.

If we confine ourselves to the IANA names, then data service protocols like OPeNDAP present a problem because they can present the data in a number of forms. This leaves only the mime-type to work with as a standard attribute.

There may be some way of working out these options at the <entry> level, but we need an example to demonstrate how this might be done.

Alternatively, perhaps we could put enough information in the mime-type using the '+'. Following the Open Search Description Document, which is "application/opensearchdescription+xml", we would have, e.g., "application/opendap+x-netcdf".

Does anyone else have any other ideas?

OSGeo background

Started off in similar fashion to ESIP federated search. Have centers with lots of collections at different levels. Also federating non-space research communities (seadatanet?). Looking to reuse, used OpenSearch, linked up with OGC to document it. Looking to join our efforts.

Pretty much at the same level; initiatives with OpenLayers widgets and mass-market tools.

Principle: don't break mass-market tool. If Atom field resolves, needs to still work in Google Maps, Bing maps, etc. True, "enclosure", "icon" isn't really what we mean, but on the other hand, it does work in mass-market tools.

Try not to use community namespaces. Maybe get new values accepted by IANA.

Site has information only about OpenSearch engines, with links to OpenSearch Description Documents. Then query to discover their granules. Then look for metadata and/or enclosure.

Will send working examples.

Sentinel launching over next few years. Have reqt that mass-market interface is an OpenSearch with Geo and Time extensions.

Have critical mass of data available...

Also, cf. CWIC, will put OpenSearch interface on top of CWIC.

Differences between OGC and ESIP OpenSearch

Recursive OpenSearch

using rel="search" and type="opensearchdescription+xml"

Actually, this seems similar to OSGeo search for search engines.

Extra attributes

esip:subrel
esip:serviceProtocol

collections link

Used for datacasting...

Convergence

Add new rel values to IANA?
Can we get mass market tools to pick up new rel values? PG: may have critical mass to get them to do it.
The real problem is Row 4 in the table in DCP-3 (OPeNDAP)...
- Can we use categories at the <entry> level?
- Overload mime-type like application/opendap+x-netcdf?
- Or do we need a new rel type for enclosures that are really services? (rel="service" is already taken for other purposes in the Atom spec)

@@ Line 1: / Line 1: @@
+= Summary =
+# The addition of namespace-specific attributes (e.g., esip:subrel) is problematic because mass-market tools (e.g., Firefox, OpenLayers) will not understand them and have little motivation for changing to understand them.
+# If we confine ourselves to the IANA names, then data service protocols like OPeNDAP present a problem because they can present the data in a number of forms. This leaves only the mime-type to work with as a standard attribute.
+# There may be some way of working out these options at the <entry> level, but we need an example to demonstrate how this might be done.
+# Alternatively, perhaps we could put enough information in the mime-type using the '+'.  Following the Open Search Description Document, which is "application/opensearchdescription+xml", we would have, e.g., "application/opendap+x-netcdf".
+# Does anyone else have any other ideas?
 = OSGeo background =
 Started off in similar fashion to ESIP federated search. Have centers with lots of collections at different levels. Also federating non-space research communities (seadatanet?).  Looking to reuse, used OpenSearch, linked up with OGC to document it. Looking to join our efforts.

Difference between revisions of "Discovery Telecon 2011-12-13 OGC"