[Esip-discovery] Datacasting custom elements proposal

Mattmann, Chris A (388J) chris.a.mattmann at jpl.nasa.gov
Wed Mar 23 04:44:28 EDT 2011


Hi Bob,

> Sigh.  This is why I hate jumping in to an ongoing thread...

No worries.

> 
> So let's take a step back.  My understanding here is that we're trying 
> to collectively decide the best way to describe custom metadata elements 
> in a *casting feed.

Well that's part of it. Moreover, this conversation is related to the development of a specification for an ESIP Discovery Feed:

http://wiki.esipfed.org/index.php/Discovery_OpenSearch_Services

Datacasting is one example that Sean McCleese put forward to think about in the context of this discussion.

> 
> Assuming it is correct, then please allow me to reframe the question. 
> There are two separate but related topics:
> 
> 1) How to represent the custom metadata itself.
> 2) How to represent the description of the custom metadata 
> (metadata-about-metadata, or m-a-m).
> 
> For topic 1, there are two methods that seem viable:
> 
> 1a) Use the metadata keyword as the actual XML element (or possibly 
> attribute) name.
> 1b) Use name=xxx value=yyy attributes.
> 
> For topic 2, there are three potential locations for the m-a-m:
> 
> 2a) In the XML schema.
> 2b) In the channel portion of the feed.
> 2c) In the item itself.

To clarify, 2b/2c don't preclude the inclusion of XMLSchema since it may be inlined too.

> 
> We can probably safely rule out 2c.  2a more or less requires 1a.
> 
> Is that an accurate restatement of the topic?

Yep and in 2 contexts:

1. in the context of the ESIP Discovery Feed work
2. in the context of the Datacasting project as an example of that.

I think #1 is the more pertinent topic here. Some feel (e.g., based on Ruth's comments) that #2 must conform to #1. 

I'm less interested in mandating that then working on #1. 

As for #2, since Sean brought up the topic on this list, I thought I'd weigh in.

>> 
>> That's not true. They expect changes all the time. New missions define new elements and extensions of the existing PDS data model.
> 
> I meant that changes do not occur quickly or often.

Gotcha.

>  Of course each 
> mission can be different.  But within a mission, once the metadata is 
> defined, it pretty much does not change.  There may be updates or errata 
> from time to time, but it's not constantly in flux.  I claim that's not 
> the case with us; within one feed I would hope the metadata is augmented 
> often.

Why is that? If datacasting expects to serve Earth science missions, and/or DAACs, etc., then I would say they are in a similar to boat as to PDS -- that is, once the metadata is defined it pretty much does not change. This has been my experience working with e.g., AIRS, MLS, MISR, and TES data, at the least.

Cheers,
Chris

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: chris.a.mattmann at nasa.gov
WWW:   http://sunset.usc.edu/~mattmann/
Phone: +1 (818) 354-8810
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++



More information about the Esip-discovery mailing list