From David.Poirier at oit.edu Tue Nov 3 09:38:02 2009 From: David.Poirier at oit.edu (David Poirier) Date: Tue, 3 Nov 2009 09:38:02 -0800 Subject: [eml-dev] Differences between eml-dataTable & eml-entity Message-ID: <8CC32141E8BE6448B098DFE65DFC5E82236EABA6@Techmail2.oit.edu> Hi, We?re developing an application that extracts EML documents from a relational database. I?m curious about the differences between an eml-dataTable and an eml-Entity. Any clarification would be much appreciated. Thanks, Dave -------------- next part -------------- An HTML attachment was scrubbed... URL: From sheldon at uga.edu Tue Nov 3 10:07:17 2009 From: sheldon at uga.edu (Wade Sheldon) Date: Tue, 03 Nov 2009 13:07:17 -0500 Subject: [eml-dev] Differences between eml-dataTable & eml-entity In-Reply-To: <8CC32141E8BE6448B098DFE65DFC5E82236EABA6@Techmail2.oit.edu> References: <8CC32141E8BE6448B098DFE65DFC5E82236EABA6@Techmail2.oit.edu> Message-ID: <4AF07155.2050502@uga.edu> David, I'm sure others will chime in, but as another person who generates EML from RDBMS systems I think I can clear up your confusion.Eml is a highly modular set of schemas, as you've undoubtedly noticed, and eml-entity is the base resource type used for all eml tabular data representations. It is imported into the eml-dataTable schema, and can only be used as a stand alone spec when describing "otherEntity" structures (basically user-defined data representations). So the short answer is that you want to use dataTable for SQL tables, view for SQL views, and storedProcedure for SP when mapping a RDBMS information system to EML metadata. Regards, Wade Sheldon GCE-LTER Information Manager David Poirier wrote: > > Hi, > > We?re developing an application that extracts EML documents from a > relational database. I?m curious about the differences between an > eml-dataTable and an eml-Entity. Any clarification would be much > appreciated. > > Thanks, > > Dave > > ------------------------------------------------------------------------ > > _______________________________________________ > Eml-dev mailing list > Eml-dev at ecoinformatics.org > http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/eml-dev > -- ____________________________________ Wade M. Sheldon GCE-LTER Information Manager/SIMO Database Administrator School of Marine Programs University of Georgia Athens, GA 30602-3636 Email: sheldon at uga.edu WWW: http://gce-lter.marsci.uga.edu/public/app/personnel_bios.asp?id=wsheldon From tao at nceas.ucsb.edu Mon Nov 9 17:58:26 2009 From: tao at nceas.ucsb.edu (Jing Tao) Date: Mon, 9 Nov 2009 17:58:26 -0800 (PST) Subject: [eml-dev] objectname in eml when morpho imports a text file Message-ID: 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 From jones at nceas.ucsb.edu Mon Nov 9 18:08:09 2009 From: jones at nceas.ucsb.edu (Matt Jones) Date: Mon, 9 Nov 2009 17:08:09 -0900 Subject: [eml-dev] objectname in eml when morpho imports a text file In-Reply-To: References: Message-ID: 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 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: From tao at nceas.ucsb.edu Tue Nov 10 09:56:10 2009 From: tao at nceas.ucsb.edu (Jing Tao) Date: Tue, 10 Nov 2009 09:56:10 -0800 (PST) Subject: [eml-dev] objectname in eml when morpho imports a text file In-Reply-To: References: Message-ID: 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: 1 edu.ucsb.nceas.morpho.plugins.datapackagewizard.pages.DataLocation edu.ucsb.nceas.morpho.plugins.datapackagewizard.pages.TextImportEntity< /class> So I can add an another element textFilePath there: 1 edu.ucsb.nceas.morpho.plugins.datapackagewizard.pages.DataLocation c:\data\rainfall-2007.txt edu.ucsb.nceas.morpho.plugins.datapackagewizard.pages.TextImportEntity 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 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 >> > From tao at nceas.ucsb.edu Tue Nov 10 10:07:47 2009 From: tao at nceas.ucsb.edu (Jing Tao) Date: Tue, 10 Nov 2009 10:07:47 -0800 (PST) Subject: [eml-dev] objectname in eml when morpho imports a text file In-Reply-To: References: Message-ID: 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 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: >> >> >> >> >> 1 >> >> >> edu.ucsb.nceas.morpho.plugins.datapackagewizard.pages.DataLocation >> >> >> >> edu.ucsb.nceas.morpho.plugins.datapackagewizard.pages.TextImportEntity< >> /class> >> >> >> >> >> So I can add an another element textFilePath there: >> >> >> >> >> 1 >> >> >> edu.ucsb.nceas.morpho.plugins.datapackagewizard.pages.DataLocation >> c:\data\rainfall-2007.txt >> >> >> >> edu.ucsb.nceas.morpho.plugins.datapackagewizard.pages.TextImportEntity >> >> >> >> > >> 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 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 >>>> >>>> >>> > From jones at nceas.ucsb.edu Tue Nov 10 09:59:52 2009 From: jones at nceas.ucsb.edu (Matt Jones) Date: Tue, 10 Nov 2009 08:59:52 -0900 Subject: [eml-dev] objectname in eml when morpho imports a text file In-Reply-To: References: Message-ID: 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 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: > > > > > 1 > > > edu.ucsb.nceas.morpho.plugins.datapackagewizard.pages.DataLocation > > > > edu.ucsb.nceas.morpho.plugins.datapackagewizard.pages.TextImportEntity< > /class> > > > > > So I can add an another element textFilePath there: > > > > > 1 > > > edu.ucsb.nceas.morpho.plugins.datapackagewizard.pages.DataLocation > c:\data\rainfall-2007.txt > > > > edu.ucsb.nceas.morpho.plugins.datapackagewizard.pages.TextImportEntity > > > > > 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 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: From David.Poirier at oit.edu Wed Nov 11 15:32:04 2009 From: David.Poirier at oit.edu (David Poirier) Date: Wed, 11 Nov 2009 15:32:04 -0800 Subject: [eml-dev] eml-dataTable Values Message-ID: <8CC32141E8BE6448B098DFE65DFC5E82236EABC3@Techmail2.oit.edu> Hello, I have a question about the eml-dataTable module. If the eml-dataTable module describes the characteristics of an entity, where should the entity values be placed? Thanks in advance for any help. Dave -------------- next part -------------- An HTML attachment was scrubbed... URL: From sheldon at uga.edu Wed Nov 11 15:52:08 2009 From: sheldon at uga.edu (Wade Sheldon) Date: Wed, 11 Nov 2009 18:52:08 -0500 Subject: [eml-dev] eml-dataTable Values In-Reply-To: <8CC32141E8BE6448B098DFE65DFC5E82236EABC3@Techmail2.oit.edu> References: <8CC32141E8BE6448B098DFE65DFC5E82236EABC3@Techmail2.oit.edu> Message-ID: <4AFB4E28.4080407@uga.edu> David, Do you mean attributes (columns)? Those details are described using dataTable/attributeList/attribute. Take a look at the eml-attribute docs for the respective elements you can use to define column characteristics. Note that it's important to read the normative docs carefully for that module and study the schema, because if you go the route of defining data table attributes you need to understand the complexities of dealing with measurementScale and units, which have been stumbling blocks for many folks implementing eml in the LTER network (particularly units). Regards, Wade Sheldon GCE-LTER David Poirier wrote: > Hello, > > I have a question about the eml-dataTable module. If the eml-dataTable > module describes the characteristics of an entity, where should the > entity values be placed? > > Thanks in advance for any help. > > Dave > > > ------------------------------------------------------------------------ > > _______________________________________________ > Eml-dev mailing list > Eml-dev at ecoinformatics.org > http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/eml-dev -- ______________________________________________________________________________ Wade M. Sheldon GCE-LTER Information Manager/SIMO Database Administrator School of Marine Programs University of Georgia Athens, GA 30602-3636 Email: sheldon at uga.edu WWW: http://gce-lter.marsci.uga.edu/public/app/personnel_bios.asp?id=wsheldon From bohms at msu.edu Wed Nov 11 18:17:09 2009 From: bohms at msu.edu (sven bohm) Date: Wed, 11 Nov 2009 21:17:09 -0500 Subject: [eml-dev] does url in eml-physical imply a get? Message-ID: <9226FD83-9754-4003-BE69-CADCCF21D5AA@msu.edu> Hi, In the online element in eml-physical: does the url element imply that the data can be retrieved with an HTTP GET or should a client parsing the definition try both a GET and a POST? Thanks, -- Sven Bohm -.- ..-. ---.. .- KBS-LTER Information Manager -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2409 bytes Desc: not available URL: From jones at nceas.ucsb.edu Wed Nov 11 18:27:18 2009 From: jones at nceas.ucsb.edu (Matt Jones) Date: Wed, 11 Nov 2009 17:27:18 -0900 Subject: [eml-dev] does url in eml-physical imply a get? In-Reply-To: <9226FD83-9754-4003-BE69-CADCCF21D5AA@msu.edu> References: <9226FD83-9754-4003-BE69-CADCCF21D5AA@msu.edu> Message-ID: Hi Sven, >From my perspective, the HTTP spec is really what rules here. Under HTTP, the GET verb implies access to a url resource that will not modify that resource (i.e., calling GET on the resource is always safe). In contrast, a POST to a url for a resource is used to access that resource in a way that might modify it. So it is not safe to call POST on a resource URL unless you understand the application semantics of the POST call for that particular application. So, in the general case, you probably should only use HTTP GET to retrieve the contents of a url referenced in an EML document -- the POST could be dangerous (plus, presumably there is some access control mechanism protecting against POST requests that are unwanted). Matt On Wed, Nov 11, 2009 at 5:17 PM, sven bohm wrote: > Hi, > > In the online element in eml-physical: does the url element imply that the > data can be retrieved with an HTTP GET or should a client parsing the > definition try both a GET and a POST? > > Thanks, > -- > Sven Bohm -.- ..-. ---.. .- > KBS-LTER Information Manager > > > > > > > > > _______________________________________________ > 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: From mob at msi.ucsb.edu Fri Nov 20 09:03:38 2009 From: mob at msi.ucsb.edu (Margaret O'Brien) Date: Fri, 20 Nov 2009 09:03:38 -0800 Subject: [eml-dev] EML, and JRN Rangeleand Monitoring project Message-ID: <4B06CBEA.5000305@msi.ucsb.edu> Hi Christine - I'm terribly sorry - this email slipped through the cracks. SBC had its site review in late October, and things got a little hectic. I visited the Rangeland Monitoring website - this sounds like a really interesting project, and seems to encompass areas of knowledge representation and semantics. Given the scope and goals, Jason should be in touch with the EML development group and also with ecoinformatics programmers working on tools for that schema. So I am forwarding your email and Jason's summary to them. Since he mentions Morpho, I am assuming that Jason is already familiar with the ecoinformatics programming projects, but if not, more material and links can be found at the NCEAS web site (http://nceas.ucsb.edu). Also, I think that NCEAS already has collaborations with both the Nature Conservancy and USDA. Again, sorry again for the delay in responding. Best, Margaret -------- Original Message -------- Subject: EML Date: Fri, 16 Oct 2009 11:57:29 -0600 From: Christine Laney To: Margaret O'Brien CC: Jason Karl Hi Margaret, Jason Karl, a new postdoc with our USDA ARS collaborators at the Jornada, is investigating EML as a potential way to document data, data collection protocols or methods, and software. He would like to learn more about the most recent developments and since I know you've been active in this arena, I thought I would put him in touch with you. Please see his attached introduction to the project he has been working on for the past several years. I'm not sure what the best avenue for him would be to further explore EML and perhaps participate in future developments - could you point him down the correct path? Thank you, Christine *~~~*~~~*~~~*~~~*~~~*~~~ Christine Laney Jornada Experimental Range/Jornada Basin LTER NMSU, MSC 3JER Las Cruces, NM 88003 http://www.ecotrends.info/ http://www.p2erls.net/ http://jornada-www.nmsu.edu/ chrlaney at nmsu.edu 575-646-3478 -- ======================== Margaret O'Brien Information Management Santa Barbara Coastal LTER Marine Science Institute University of California Santa Barbara, CA 93106-6150 805-893-2071 mob at msi.ucsb.edu http://sbc.lternet.edu ======================== -------------- next part -------------- A non-text attachment was scrubbed... Name: Methods_Guide_EML_Potential_Description.101309[1].doc Type: application/msword Size: 30208 bytes Desc: not available URL: