[eml-dev] objectname in eml when morpho imports a text file

Jing Tao tao at nceas.ucsb.edu
Tue Nov 10 10:07:47 PST 2009


Thanks, Matt. I will do this way.

Jing

Jing Tao
National Center for Ecological
Analysis and Synthesis (NCEAS)
735 State St. Suite 204
Santa Barbara, CA 93101

On Tue, 10 Nov 2009, Matt Jones wrote:

> This sounds like a great approach Jing -- it puts the information in the
> document without polluting the EML fields with application-specific state
> information.  And you should indeed remove it when you publish the EML
> document to metacat.
>
> Matt
>
> On Tue, Nov 10, 2009 at 8:56 AM, Jing Tao <tao at nceas.ucsb.edu> wrote:
>
>> Hi, matt:
>>
>> Yeah, I forgot Metacat would use it even though I fixed bug the objectName
>> was wrong in morpho and metacat couldn't recognize it :(
>>
>> I am working setPageData(OrderedMap map) method in DataLocation page. This
>> method wasn't implemented. Now when we open an incomplete document, we need
>> this method.
>>
>> When we save incomplete document, I already add a block of
>> additionalMetadata to describe the status. The block looks like:
>>
>> <additionalMetadata>
>>  <metadata>
>>    <enityWizard>
>>     <index>1</index>
>>       <class>
>>
>>  <name>edu.ucsb.nceas.morpho.plugins.datapackagewizard.pages.DataLocation</name>
>>       </class>
>>       <class>
>>
>> <name>edu.ucsb.nceas.morpho.plugins.datapackagewizard.pages.TextImportEntity</name><
>>        /class>
>>     </enityWizard>
>>   </metadata>
>> </additionalMetadata>
>>
>> So I can add an another element textFilePath there:
>>
>> <additionalMetadata>
>>   <metadata>
>>     <enityWizard>
>>       <index>1</index>
>>       <class>
>>
>> <name>edu.ucsb.nceas.morpho.plugins.datapackagewizard.pages.DataLocation</name>
>> <textFilePath>c:\data\rainfall-2007.txt</textFilePath>
>>       </class>
>>       <class>
>>
>> <name>edu.ucsb.nceas.morpho.plugins.datapackagewizard.pages.TextImportEntity</name>
>>       </class>
>>     </enityWizard>
>>   </metadata>
>> </additionalMetadata
>>
>> This element will be used to store the full path. Moreover, the entire
>> additionalMetadata part is only temporary. When user saves package locally
>> or remotely, they will be removed.
>>
>> What do you think about this approach?
>>
>> Thanks,
>>
>>
>> Jing
>>
>>
>> Jing Tao
>> National Center for Ecological
>> Analysis and Synthesis (NCEAS)
>> 735 State St. Suite 204
>> Santa Barbara, CA 93101
>>
>> On Mon, 9 Nov 2009, Matt Jones wrote:
>>
>>  Hi Jing --
>>>
>>> We've used objectName for just the filename in the past, so that objects
>>> that are stored in metacat and other apps can properly name downloaded
>>> files.  So changing it to use the full path there would potentially break
>>> metacat and other apps, although it is technically allowed in EML. Storing
>>> the full path of a specific machine in the metadata seems like a fragile
>>> approach anyways, highly subject to getting out of date as people
>>> rearrange
>>> their hard drives. Lets discuss on IRC what you are trying to accomplish
>>> with this and some possible alternatives.
>>>
>>> Matt
>>>
>>> On Mon, Nov 9, 2009 at 4:58 PM, Jing Tao <tao at nceas.ucsb.edu> wrote:
>>>
>>>  Hi, devs:
>>>>
>>>> When morpho imports a text file into an eml package, currently it stores
>>>> the file name as objectName rather thank the full path. For instance,
>>>> morpho
>>>> will store "rainfall-2007.txt" as objectName rather than
>>>> "C:\data\rainfall-2007.txt".
>>>>
>>>> I am working on a morpho module, which can reload existed eml to entity
>>>> wizard. So in DataLocation page, I need the information of the full text
>>>> file path. I propose that morpho will store the full path rather than the
>>>> file name as the objectName in eml. In our case, morpho will store
>>>> "C:\data\rainfall-2007.txt" as objectName. I am just wondering if this
>>>> approach violates eml's practice.
>>>>
>>>> Any comments and suggestions will be really appreciated.
>>>>
>>>> Regards,
>>>>
>>>> Jing
>>>>
>>>>
>>>>
>>>> Jing Tao
>>>> National Center for Ecological
>>>> Analysis and Synthesis (NCEAS)
>>>> 735 State St. Suite 204
>>>> Santa Barbara, CA 93101
>>>> _______________________________________________
>>>> Eml-dev mailing list
>>>> Eml-dev at ecoinformatics.org
>>>> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/eml-dev
>>>>
>>>>
>>>
>


More information about the Eml-dev mailing list