[Esip-discovery] Datacasting custom elements proposal
Bob.Deen at jpl.nasa.gov
Thu Mar 24 21:05:07 EDT 2011
Okay glad we're on the same page. As a Datacasting co-I, I'm obviously
more concerned with your context #2. What is the relationship between
these two contexts? How does datacasting relate to ESIP Discovery Feeds?
Resetting the discussion a little... let's consider what happens if we
put the m-a-m in the schema.
I'm far from an expert on schema (and I mean *far*), but it looks like
if we wanted to describe additional m-a-m, say for example
conforms-to-standard, the only option is to put it in an
annotation/appInfo group. So it might look something like this:
<xsd:element name="windSpeed" type="xsd:decimal">
The important point here is that the standard we're conforming to is
specified in the *schema* - i.e. it applies to all instances of this
element being used, just like the name or data type - rather than
something that's put in the actual XML document being described.
What confuses me about this is that it seems like the contents of
appInfo are not defined - any well-formed XML is okay. So can you
impose a schema on the schema, that would define what the m-a-m items in
appInfo are, so the schema itself could validate? Or is appInfo simply
Also, pardon my schema ignorance. But if you have a well-defined
schema, say for datacasting, can that be augmented via additional
schemas (namespaces?) *without* changing the datacasting schema itself
and still be validateable? (which is really the same as the question
above, about having a schema just for the additions to the schema's
schema (did I really just write that sentence??))
In other words if I have a document like this:
which is described by a schema, is it possible to create a schema that
defines an additional element, one which drops in to the middle of the
above, *without* modifying the original schema? When the original
schema was not designed with such in mind? e.g.
Put another way, are schemas subclassable in an object-oriented sense?
The goal is for the above to still be a valid a, with additions
specified by b, without modifying or duplicating a's schema, yet still
be fully validateable.
On 3/23/11 1:44 AM, Mattmann, Chris A (388J) wrote:
> 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:
> 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.
>> 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
> 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.
> 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