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

[Matt Jones]

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
>>>
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/eml-dev/attachments/20091110/3e839351/attachment-0001.html>