EML for Mere Mortals

[Chad Berkley]

David,

I'd like to know exactly which recommendations that I made you think "do 
not track".

I would be interrested to hear some other opinions on this from other 
eml-dev list members.  If anyone has any comments, please submit them to 
the eml-dev list for everyone to read.  This document will reflect on 
everyone envolved in the project and I think it's important to make it 
publication quality.  I think this can only be done through involvment 
of more people in the group.  Matt, would you mind resubmitting your 
comments to eml-dev since the first attempt bounced?

thanks,
chad

David Blankman wrote:
> Chad and Matt,
> 
> Thanks for your comments. Matt made similar comments. Some of the 
> comments are right on target and others do not track with the reactions 
> from the target audience.
> 
> Chad Berkley wrote:
> 
>> Hello David,
>>
>> I've been meaning to write a review of your document for a month or so 
>> but I've been on vacation and at various meetings.  I apologize for 
>> the delay...but better late than never.  I'm going to start out with 
>> what I see as being wrong with the document then try to give you some 
>> suggestions on how it should be rewritten.
>>
>> If I understand correctly, this document is supposed to be a high 
>> level look at EML that a scientist or data manager could use to fill 
>> out EML fields and to understand the granularity and purpose behind 
>> those fields.  I have to say that "EML for Mere Mortals" as it 
>> currently exists falls short of this goal.
>>
>> If we are truly trying to give the scientist a top level overview, 
>> then why is there so much discussion of XML structure and syntax?  I 
>> think this document could be written without mentioning the acronym 
>> "XML" a single time.  The sentence "...EML has been designed as a form 
>> of XML..." is completely wrong and I think this is the wrong thesis 
>> statement to base this document on. EML is a content model that 
>> happens to be implemented in XML.
> 
> *Yes, I agree with this statement. I haven't done a thorough review 
> myself or I would have caught that.*
> 
>> It could be implemented in any number of other markup languages or 
>> binary formats.  The content model itself (not the implementation) is 
>> truly what should be the center of the discussion in this document.  
>> Possibly as an appendix, some implementation details on how to write 
>> an EML document marked up in XML would be useful, but it does not 
>> belong in the body of this document. 
> 
> *Based on EML presentations that I have done for LTER researchers, I 
> have decided that we will develop two versions of the EML Handbook. One 
> version will focus more on the conceptual issues, the other will look 
> like this one. *
> 
>>
>> As far as your discussion of the content model goes, I do not think 
>> referring to it as a "Taxonomy" is at all intuitive or correct.
> 
> *Based on EML presentations that I have done for LTER researchers, the 
> "taxonomy" metaphore is useful and well received.
> *
> 
>> In fact, it's downright confusing because of the actual sub-module of 
>> EML that deals with biological taxonomy.  It took me several re-reads 
>> to figure out exactly what you were trying to do with the taxonomy 
>> analogy (and I'm still not completely sure I understand).  I just 
>> don't think it's leading in an easy-to-understand direction.
>>
>> The premise behind the the conversations between Pat, emlMaven and Eco 
>> Informatics, while well intentioned, frankly made me queasy.  I think 
>> this device has been over used and not well executed in this document. 
>> The names of the characters themselves insult me. I think the purpose 
>> of this device (to give some real world problems and use EML to solve 
>> them) is a sound one, however I think it would be better to have a set 
>> of scenarios maybe with multiple implementations and multiple outcomes 
>> than to have three imaginary characters with less-than-normal names 
>> conversing.  The "Metalog" device also fails in the same respect. 
> 
> *Information managers as opposed to developers have approeciated the 
> metalogs and found them useful and enjoyable.*
> 
>>
>>
>> What I would like to see come out of this document is a generalized 
>> map of the content model cross-linked to different types of ecological 
>> research projects. It could have sections like "Spatially referenced 
>> time series research project" and show what parts of EML would be used 
>> to correctly document this type of project.  There may be some overlap 
>> in the sections, but I think that is ok because it will show how many 
>> parts of EML are generalized for multiple purposes.  I don't think 
>> using the XML Spy images of the schema is very useful for someone not 
>> used to it.  It may be painful for you, but I think that some other 
>> program (Illustrator or the like) should be used to create a nice form 
>> view of the EML document that is being created for the given 
>> scenario.  Ths form view does not have to show the entire document (or 
>> even document segment) in one image, it could be broken up in a 
>> visually pleasing way.
> 
> *This seems like a good suggestion*. *The version that you saw is very 
> preliminary and had little formatting. *
> 
>>
>> I think that the extraneous cheese should be removed from the 
>> document.  It is distracting to the reader and really just adds more 
>> white noise though which the reader must sort.  I think a softened 
>> professional tone should be used throughout.  Not as professional as 
>> an IBM AS-400 manual but not as soft as Winnie the Pooh either.  
>> Something like the tone in an Oreilly book would do nicely. 
> 
> *The O'Reilly books are not the right tone. Most of the non-developers 
> who have read this like the tone. *
> 
>>
>>
>> In a document like this, it is extremely important not to give the 
>> reader the idea that he is being talked down to.  No one likes to be 
>> talked down to.  For this reason, I would recomend changing the title 
>> to something less patronizing.  The tone of the introductory 
>> paragraphs could also use some work in this area. 
> 
> 
>>
>>
>> A few more tidbits....The XML tags should also be removed.  I don't 
>> think they are appropriate in this document.  Also, the phrase 
>> "computer literate" *Good point *should never be used.  It is a 
>> cliche` with basically no meaning.  I would also like to see an 
>> acknowledgements section as many people have worked on EML and deserve 
>> to be recognized (NSF should probably also be recognized as the 
>> grantor...ask Matt or James about that).  Also, I don't think that 
>> ripping NSF with one-liners in an NSF funded grant is a super good 
>> idea. *Yes. I agree, it is just a little too cutesy and will be changed.*
>>
>> Hope this helps.  I'm not trying to be overly-critical just calling it 
>> like I see it.  Let me know if you want me to clarify anything that 
>> I've said. 
> 
> *I appreciate the thoroughness of your comments.*
> 
>>
>>
>> chad
>>
> 
> -- 
> David E. Blankman
> Database Integration Developer
> Long Term Ecological Research Network Office
> University of New Mexico
> 801 University, SE #104
> Albuquerque, NM 87106
> (505) 272-7346 / (505) 272-7080 FAX
> 


-- 
-----------------------
Chad Berkley
National Center for
Ecological Analysis
and Synthesis (NCEAS)
berkley at nceas.ucsb.edu
-----------------------