[Esip-discovery] Service Casting and Data Casting confusion

[Sky Bristol]

Greetings,

Following the ESIP meeting, I'm poking around at the DataCasting and ServiceCasting concepts as presented from the Discovery Cluster wiki page. I'm looking over the following two takes on the concept:

http://datacasting.jpl.nasa.gov/xml_specification/
http://sciflo.jpl.nasa.gov/scast/

I'm looking to add some stuff to the existing ATOM feed from our USGS ScienceBase catalog. ScienceBase has cataloged records of downloadable data and web services along with other artifacts such as publication citations, descriptions of science projects, and other information pertinent to the inner workings of science teams and their information management pursuit. I'd like to be able to offer up what makes sense for the community involved in these casting experiments to see how the information can be more broadly discovered and used.

The two approaches seem to be quite different, and I'm resonating a lot more with the ServiceCasting approach that seems to only rely on the rel attribute of links to advertise particular access points for services. There seems to be a lot of stuff in the datacasting namespace that would seem to indicate a pretty specialized use and a fairly highly customized consumer application to really use. My initial reaction is that the datacasting method and its associated namespace and elements are so highly customized as to constitute a completely custom application as opposed to an implementation of RSS or ATOM. I'm sure there are reasons behind that, so I don't mean to disparaging.

The ServiceCasting approach seems to make quite a bit more sense from the standpoint of what we can easily fit into ScienceBase. However, the documentation still leaves me with some questions:

- The implementation guidelines seem to be focused on service specifications like SOAP where we would have an interfaceDescription like a WSDL. However, the documentation talks about all kinds of other services, including human interface web sites. So, is the interfaceDescription not expected except for anything that doesn't use that type of mechanism?

- The documentation says that at least three typed links are needed and then lists 5 (including none and alternate). So, what are the expected link types for any applications currently being pursued, and what are the applications of the ServiceCasting method currently being worked?

From the ScienceBase perspective, we are going to have items with numerous end points, some of which will be web services and some of which will be a way to download a file. The latter is more inline with the data casting idea, I guess, but that approach seems a bit more cumbersome than we would want to deal with right now. We have items described in the catalog that have been uploaded as file-based data by science teams to our "ScienceBase Repository" where we have a link to download the original form of the data along with services that have been provided from the repository depending on the type of data (WMS, WFS, WCS, KML, OpenDAP, etc.). Our desire would be to serve these up for experimentation from other ESIP members to help scientists find data items via search, read enough about those items in their abstracts to see if they are interested, click a link to visit ScienceBase for more in depth documentation if desired, and see all the ways they can go about obtaining/using the data from either the ATOM feed or by visiting the ScienceBase UI.

I'm about to enter a comment to some existing work for our developers to tell them how to toss in a couple of additional typed links to our ScienceBase ATOM feed, and I would love some thoughts on how we might contribute some resources to the ESIP pool.

Note on future direction...

The overall discovery process of having data providers cast out their stuff seems pretty sound. The bar for entry with an ATOM feed is pretty low, and the specification really has most of what is needed to facilitate basic discovery and understanding of a pretty wide variety of items. Links to access points or further information are one of the most important parts of working with an item, and the service casting method seems pretty well founded for that dynamic. An alternate approach we might consider would be to use URIs in place of the "scast" convention on rel and then facilitate some form of URI library or registry (perhaps using ESIP as the coordinator). The registry would then provide further information on the meaning and purpose of various types of links and could cross between standards and protocols beyond ATOM/RSS.

For instance, I might want to include a URI that points to something more specific that tells an application that the link is specifically to an OGC-WMS version 1.1.1 instead of the generic scast:serviceEndpoint. I might also want to include a link to the ISO19137 XML rendering of an item's metadata so that an application could go get that view of the item if needed.

<.(((<<<~~~~<.(((<<<~~~~<.(((<<<
     Sky Bristol
     sbristol at usgs.gov
     Office: 303-202-4181
     Cell: 303-241-4122
<.(((<<<~~~~<.(((<<<~~~~<.(((<<<

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.esipfed.org/pipermail/esip-discovery/attachments/20110726/b791428a/attachment.html>