[Esip-discovery] Relating services to datasets served. Draft material for a DCP-3

Stephen Richard steve.richard at azgs.az.gov
Tue Sep 6 12:30:00 EDT 2011


Brian, Hua--
Based on the discussion from last week, I spent some time researching this
issue in the context of some other projects I've been following or involved
in  (OWS context Standards Working Group, energy industry ISO19115 metadata
profile, and USGS CGI Web Application Integration Framework group). I would
like to see this considered in a larger context to come up with a solution
that can be used in these various contexts, because it's essentially the
same problem. 
Brian came up with a 3-attribute solution, but I think there are 4 important
facets. Here' s the gist of the proposal:

href	the link URL
type	MIME type of response. Specifies encoding and optionally the native
software application environment 
rel	URI from IANA rel vocabulary for consistency with IETF5988
title	free text to label link in GUI
esip:protocol	ftp, http, other. Default is http if attribute not specified
(ietf registry at 
      http://www.rfc-editor.org/rfcxx00.html). Equivalent to property in
19115 CI_OnlineResource
esip:serviceType	URI that identifies a service protocol and version
(one attribute or two?). 
          ISO19119 property, needs registry of 'standard' URIs.
esip:purpose	analogous to ISO19115 function, specified by
CI_OnlineFunctionCode
esip:outputscheme	profile for content of message retrieve by href URL;
may be WFS feature name, 
            URI for xml schema or JSON scheme, other description of data
structure and 
           content? Need conventions, clear definition.

The attached word doc is a concept development document. The first three
sections could be the basis for a DCP-3 to supersede DCP-2 (and incorporate
DCP-1). The rest is supplemental information and background.

steve

Stephen M. Richard
Arizona Geological Survey
416 W. Congress St., #100
Tucson, Arizona, 85701   USA
phone: 520 209-4127
AZGS Main: (520) 770-3500.  FAX: (520) 770-3505
email: steve.richard at azgs.az.gov

> -----Original Message-----
> From: esip-discovery-bounces at lists.esipfed.org [mailto:esip-discovery-
> bounces at lists.esipfed.org] On Behalf Of Hua, Hook (388C)
> Sent: Friday, September 02, 2011 9:33 AM
> To: Gallagher James; Lynnes, Christopher S. (GSFC-6102)
> Cc: Wilson, Brian D (335G); esip-discovery at lists.esipfed.org; Manipon,
Gerald
> John M (335H-Affiliate)
> Subject: Re: [Esip-discovery] Relating services to datasets served, and
datasets
> to available services
> 
> 
> 
> On 9/2/11 9:23 AM, "Gallagher James" <jgallagher at opendap.org> wrote:
> 
> >
> >On Sep 2, 2011, at 10:16 AM, Lynnes, Christopher S. (GSFC-6102) wrote:
> >
> >> On Sep 1, 2011, at 6:19 PM, Wilson, Brian D (335G) wrote:
> >>
> >>>
> >>> Chris,
> >>>
> >>> You imply that you somehow feel queasy about going further.  I think
> >>>this is a good idea  in order to maximize compatibility with vanilla
> >>>Atom feeds and OpenSearch, while having  the fully specific
> >>>attributes we need for ESIP and Earth Science purposes.
> >>
> >> OK, then let's get cracking on DCP-3.
> >
> >Will DCP-3 invalidate DCP-2? Supersede?
> 
> 
> We can do either way. DCP-3 could even define an updated representation
> covering DCP-1's baseline conventions.
> 
> The governance process leaves it open.
> 
> --Hook
> 
> _______________________________________________
> Esip-discovery mailing list
> Esip-discovery at lists.esipfed.org
> http://www.lists.esipfed.org/mailman/listinfo/esip-discovery
-------------- next part --------------
A non-text attachment was scrubbed...
Name: MachineActionableWebLinking.docx
Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Size: 69049 bytes
Desc: not available
URL: <http://www.lists.esipfed.org/pipermail/esip-discovery/attachments/20110906/a8aacf74/attachment-0001.docx>


More information about the Esip-discovery mailing list