oodt-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mattmann, Chris A (398J)" <chris.a.mattm...@jpl.nasa.gov>
Subject Re: Generic MetaData Column
Date Wed, 24 Jul 2013 14:10:44 GMT
Hi Sanjaya,

I would strongly recommend against a single field with key val pairs
delimited by comma.

Use multiple met fields. If your point is that you won't know the met
upfront, I'd ask you the following things:

1. Why can't you model your met up front? Your workflows having a good
idea of what input/output met fields they will generate is one of the
keys to provenance.

2. If you still can't satisfy #1, then there is always the
that you can use that skips met field and element validation and lets you
any met. You can use this but since you were thinking about provenance I'd
urge you
to consider #1 first.


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@nasa.gov
WWW:  http://sunset.usc.edu/~mattmann/
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA

-----Original Message-----
From: Sanjaya Medonsa <sanjayamrt@gmail.com>
Reply-To: "dev@oodt.apache.org" <dev@oodt.apache.org>
Date: Monday, July 22, 2013 10:33 PM
To: "dev@oodt.apache.org" <dev@oodt.apache.org>
Subject: Generic MetaData Column

>In OODT it is possible to store new Metadata items by either introducing
>new product type or adding new items to existing product type. Basically
>you need to update the three policy files with required configuration
>(elements.xml, product-type-element-map.xml and product-types.xml). With
>this approach, Metadata items that needs to be stored should be set up
>prior to metadata ingestion. I need to understand best way to support
>following behavior.
>Ex: As I discussed in other email thread, I am planning to store input as
>metadata together with output for Airavata integartion. Depending on task
>number of inputs could be vary. So it is not possible to setup metadata
>column such as Input1 and Input2. I guess best way to support this
>requirement is to have one metadata field called Input and store all
>as key value pair. Is there any other standard mechanism available to
>handle these sort of situation ?
>Best Regards,

View raw message