[Esip-discovery] Relating services to datasets served, and datasets to available services

[Wilson, Brian D (335G)]

Chris,

The reason (I  think) that it relates to DCP-2 is that we need to consistently use the
<link> tag in all of the casting/discovery standards.  I would like to have all the power
of the two attributes (rel to express purpose and protocol to express plumbing semantics)
in designing solutions like my proposed idea to "relate" service and dataset casts.

If any solution besides choice 5 wins for DCP-2, then I'll still want to use the two-attribute
technique, but other folks will be doing it differently.

Also, the "collection" rel in DCP-1 is already defined to point to a collection cast in the
documentation.  This is exactly what I need.

But let me return to the "point to a data file" case that DCP-2 is directly about.

I would argue that putting the DAP URI in the rel attribute doesn't properly solve the problem.

Eventually, people will have to write scripts to automatically process, display, and use the casts.
In DCP-1, multiple "generic" purposes were defined in the ESIP-discovery namespace for what
might appear in the 'rel' attribute of a <link> tag.  Like, this points to a 'browse' image, or a
'data' file, or a 'collection'.  I think this a great and proper use of the rel attribute.

So, any script can look for a <link> tag with rel='data' and know that they have found the link
that points to a data item.  Of course, the data item might be a file pointed to by ftp or http,
or a DAP URL, or an OGC/WCS GetCoverage call.

If we let all of the possibilities for how a data item might be accessed slip into the 'rel' attribute
as separate values, then to find the data item the script will have to look for a potentially
open-ended list of 'rel' values and see if one of them is DAP, OGC/WMS, OGC/WCS, webification,
etc.  It will never be certain or easy to find the linked-to data item.

I hope we are all in agreement that if there is a data item to be pointed to then it should be
the link with rel='data'.

Given that basis, then the protocol to be used to get the data item, if not already
completely specified by the scheme in the HREF, can be specified with a versioned URI in
the second ('esip:protocol') attribute.

The other alternative of jamming the DAP specifier at the end of the 'data' URI both violates
the proper of use fragments in URI's, and precludes the *hooks* that both the rel and
esip:protocol URI's could be de-referenceable in the future to provide additional information
and support extensions or additional purposes.

These decisions are important since currently in DCP's 1 and 2 we are standardizing some
ground rules and reusable techniques that will be used in the design of all thecasting standards.
We need a consistent and powerful set of design conventions.

 -- Brian




________________________________________
From: Lynnes, Christopher S. (GSFC-6102) [christopher.s.lynnes at nasa.gov]
Sent: Wednesday, August 31, 2011 6:14 AM
To: Wilson, Brian D (335G)
Cc: 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

Brian,
  Yes, that all makes a lot of sense.  But how do you see it impacting the DCP-2 proposal, which was targeted at alternate access methods (specifically) for individual files, not collections?

On Aug 30, 2011, at 8:07 PM, Wilson, Brian D (335G) wrote:

>
> Folks,
>
> I'd like to float a solution to two problems that are related to DCP-2:
>
> - how to have a service cast entry specify what datasets it "serves"
> - how to have a dataset (or collection) cast specify what services are
>    available to query, access, or transform each dataset.
>
> The proposed solution is to reuse the two casting standards and the
> OpenSearch protocol.
>
> The list of datasets that a particular service allows access to might be
> lengthy and computed using a search or semantic lookup process.
> Trying to 'name' datasets in the service cast is problematic since one
> has the problem of what names to use.
>
> So the idea is to hide this 'lookup' behind a URL, which could be
> an OpenSearch URL for example.
>
> So the scast entry would contain a <link> tag as follows:
>
> <link rel="http://esipfed.org/ns/discovery/1.1/collection#"
>     type="application/atom+xml"
>     xmlns:esip="http://esipfed.org/ns/discovery/1.1/"
>     esip:protocol="http://a9.com/-/spec/opensearch/1.1/"
>     href="<specific OpenSearch URL that does the appropriate search>" />
>
> Here I've reused the "collection" URI that has already been defined, but
> we could define a more specific one like "collectionsServed".  Either way,
> this is the known link (with rel=) to answer that question.
>
> The fact that this <link> is an OpenSearch is expressed in the 'protocol'
> attribute using the usual URI for versioned opensearch protocol.
> Of course, the <link> could be of some other type; e.g. a direct link to
> a collection cast.
>
> And this is why I think we need both the 'rel' and 'protocol' attributes.
> One needs to specify both that the link's purpose is to answer collectionsServed
> question, and the protocol for getting the answer is an OpenSearch yielding a
> feed (the collection cast). By using two attributes, each of these URI's could
> also be de-referenceable and point to some additional information.
>
> The beauty of hiding the collectionsServed question behind a search link
> is that it nicely reuses the OpenSearch protocol and the collection cast format.
> The list of collectionsServed is available on demand, it can change without
> having to alter and re-publish the service cast, and metadata describing the
> collections is immediately available in the usual feed format.
>
> A GUI that wants to present metadata about the collections served has it
> immediately available.  But service metadata and dataset metadata are
> strictly separated into their respective casts, and reuse known formats.
>
> Behind the OpenSearch link, the collectionsServed lookup might be a
> SQL dbase lookup, or a SPARQL query, or involve some semantic reasoning.
> Implementers are free to innovate any way they want to, but in the meantime
> we can move forward with standardizing the casting formats.  If they don't
> want to use OpenSearch for this link, they can also choose an alternate
> protocol, at the risk of requiring users to understand additional request &
> response formats (besides OS and collection cast).
>
> The reverse problem can be solved in the same way.
>
> A link to 'servicesAvailable' could appear in each entry in a collection
> cast, as in:
>
> <link rel="http://esipfed.org/ns/discovery/1.1/service#"
>     type="application/atom+xml"
>     xmlns:esip="http://esipfed.org/ns/discovery/1.1/"
>     esip:protocol="http://a9.com/-/spec/opensearch/1.1/"
>     href="<specific OpenSearch URL that does the appropriate search>" />
>
> This time the opensearch yields a service cast listing the services available
> for that dataset, with the usual metadata in a known format.
>
> This also explains why I have been arguing for standardizing two attributes
> in the <link> tag:  rel and esip:protocol.  Given this flexibility and extra
> power, we can design solutions to thorny problems like above.  And all of
> our URI's will be cleanly defined or reused from W3C, and ultimately
> could be de-referenceable for more information if that serves additional
> purposes.
>
> It occurs to me that we might think about defining 'vendor-specific'
> MIME types for the casting (extended Atom) formats.  For example:
> "application/vnd.esip.discovery.cast.collection" and
> "application/vnd.esip.discovery.cast.service".  However, this seems a
> bit ugly and perhaps counterproductive.  For most purposes, it
> will be better to use the generic Atom or RSS mime type that more
> software will know.
>
> -- Brian
>
>
>
> _______________________________________________
> Esip-discovery mailing list
> Esip-discovery at lists.esipfed.org
> http://www.lists.esipfed.org/mailman/listinfo/esip-discovery

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