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

[Lynnes, Christopher S. (GSFC-6102)]

On Sep 6, 2011, at 12:30 PM, Stephen Richard wrote:

> 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

I think we were looking for something a bit more specific here, like "DAP" or "WMS".  ftp and http are unnecessary to specify, because they are in the href itself.  Though if we use serviceType, then perhaps we do not esip:protocol at all.


> (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
> <MachineActionableWebLinking.docx>

--
Dr. Christopher Lynnes     NASA/GSFC, Code 610.2    phone: 301-614-5185