--- layout: post title: Nutch Patch published: true meta: posterous_60e8ef2b7d9ddd23e14a941a8878b49c_post_id: "24893611" _searchme: "1" posterous_60e8ef2b7d9ddd23e14a941a8878b49c_permalink: http://maxlynchmadison.posterous.com/nutch-patch tags: [] type: post status: publish ---
I'm officially a patch contributor to an Apache project! I'm so proud! Granted, it's one line: https://issues.apache.org/jira/browse/NUTCH-871


Create Wallet
Import Wallet
Your Wallet
Send
History
Chain info
Settings
Block Height:
loading...
Network Hashrate:
loading...
Circulating Supply:
loading...
SUGAR/BTC:
loading...
BTC
SUGAR/USD:
$
loading...


def method
puts "You just made a method."
end
But what about when you want methods to not only run one after the other, but pass information between them so Method B can build upon whatever Method A was tasked to accomplish?
Methods can be grouped together under a class and executed one after another to achieve the finale product. Instance variables are variables with an @ sign in front, allowing them to be accessed in both Method A and Method B. Here is a simple program for teaching basic math to a child.
class Addition
def first_pass
@answer = 2
puts "Hello! Let's talk about 1 + 1"
puts "Do you know what 1+1 equals?"

puts " ... "
puts "Now that you're done shaking can you tell me again, what is 1 + 1?"
puts "Hit enter when you know the answer"
gets
puts "The answer is 1 + 1 = "
sleep 1
puts @answer
end
end
Addition is a class where all of the methods reside. first_pass is the first method, introducing the child to the idea that 1 + 1 = 2. The second_pass prompts them to wiggle a bit, and then revisit the question and see if they can respond with the correct answer.
@answer is the variable used in both first_pass and second_pass. It seems silly to break them apart in this simple example, but once more complicated code is introduced moving the information between methods will become critical. In this basic example having the code run as two methods would allow the second_pass to be cut off, if the teacher wanted the student to skip the wiggles shaking and just focus on letting the child be asked the question, wait four seconds, and then be given the answer.


Overview
Licensing
Installation
Examples
Section One
Section Two
Section Three
Limitations
Place Page Title Here


Toggle navigation
.
Timer
Reports
Summary
Daily
Charts
Actions
Daily break time setting
Delete entries
Export raw data
0 sec
ID
Task
Project
Date
running
Project Summary
From
To
Project
Duration (H)
Tasks
Daily Summary
From
To
Date
Duration (H)
Projects
From
To
Daily Summary
Project Summary
×
Add Task Time Entry
Project
Task
Start
End
×
Delete Entries
Are you sure you want to delete entries for this date range?
From
To
×
Daily break time setting
From
To
When this setting is enabled, task time during the break period will be adjusted, or will be split.
×
Delete Entry
Are you sure you want to delete this entry?
Project
Task
Start
End
×
Edit Task Info
Project
Task
Start
End
×
Export data
Export raw data into csv file for this date range.
From
To


SpoilMe Not
Don't let the internet spoil you. Let us do that.
Sign In:
Email
Password
Or
Create an Account
Email
Password
Verify Password
Make sure to restart your browser for changes to take effect
Ok
Welcome
Refresh
Your Blocked Words:
Block this word:
Block
Delete this word:
Delete
Pick Public Word Lists:
Add Game of Thrones
Remove Game of Thrones
Add Breaking Bad
Remove Breaking Bad
Add Green Bay Packers
Remove Green Bay Packers
Add Mr. Robot
Remove Mr. Robot
Add Narcos
Remove Narcos
Logout


Toolkits > SampleDNSMessageParser 2.0.0 > sample > TestDNSMessageParserParallelAnalysis.spl
composite TestDNSMessageParserParallelAnalysis { param expression<rstring> $pcapFilename: getSubmissionTimeValue("pcapFilename", "../../SampleNetworkToolkitData/data/sample_dns+dhcp.pcap" ); expression<uint32> $ingesterProcessorAffinity: (uint32)getSubmissionTimeValue("ingesterProcessorAffinity", "1"); expression<list<uint32>> $parserProcessorAffinities: (list<uint32>)getSubmissionTimeListValue("parserProcessorAffinities"); expression<int32> $parallelChannels: (int32)getSubmissionTimeValue("parallelChannels", "1" ); type PacketType = timestamp captureTime, // time that packet was captured, in seconds since Unix epoch rstring dstAddress, // string representation of IPv4 destination address uint64 partitionKey, // combination of addresses and ports, for downstream @parallel annotation blob dnsMessage; // the DNS message from a packet, excluding all network headers graph stream<PacketType> PacketStream as Out = PacketFileSource() { param pcapFilename: $pcapFilename; processorAffinity: $ingesterProcessorAffinity; inputFilter: "udp port 53"; metricsInterval: 0.0; output Out: captureTime = createTimestamp( (int64)CAPTURE_SECONDS(), CAPTURE_MICROSECONDS() * 1000u ), dstAddress = convertIPV4AddressNumericToString(IPV4_DST_ADDRESS()), partitionKey = hashCode(IPV4_SRC_ADDRESS()) + hashCode(IPV4_DST_ADDRESS()) + hashCode(IPV6_SRC_ADDRESS()) + hashCode(IPV6_DST_ADDRESS()) + hashCode(IP_SRC_PORT()) + hashCode(IP_DST_PORT()), dnsMessage = PAYLOAD_DATA(); } () as PacketSink = FileSink(PacketStream) { param file: "debug.TestDNSMessageParserParallelAnalysis.PacketStream.out"; format: txt; hasDelayField: true; flush: 1u; } @parallel(width=$parallelChannels, partitionBy=[{port=PacketStream, attributes=[partitionKey]}]) ( stream<TestDNSAnalytics.PredictiveBlacklistingResultType> PredictiveBlacklistingResultStream ; stream<TestDNSAnalytics.DomainProfilingResultType> DomainProfilingResultStream ; stream<TestDNSAnalytics.HostProfilingResultType> HostProfilingResultStream ) = TestDNSAnalytics(PacketStream) { param parserProcessorAffinities: $parserProcessorAffinities; } }
composite TestDNSAnalytics ( input PacketStream ; output PredictiveBlacklistingResultStream, DomainProfilingResultStream, HostProfilingResultStream ) { param expression<list<uint32>> $parserProcessorAffinities; type // input to 'predictive blacklisting' analytic FullDNSResponseMessage_t = timestamp captureTime, rstring dstAddress, rstring questionName, rstring questionType, uint8 responseCode, uint16 answerCount, list<rstring> answerNames, list<rstring> answerData, list<uint16> answerTypes, list<uint32> answerTTLs, uint16 nameserverCount, list<rstring> nameserverNames, list<rstring> nameserverData, list<uint16> nameserverTypes, list<uint32> nameserverTTLs, uint16 additionalCount, list<rstring> additionalNames, list<rstring> additionalData, list<uint16> additionalTypes, list<uint32> additionalTTLs; // input to 'domain profiling' and 'host profiling' analytics ShortDNSResponseMessage_t = timestamp captureTime, rstring dstAddress, rstring questionName, rstring questionType, uint8 responseCode, list<rstring> answerData, list<rstring> additionalData; // output from 'predictive blacklisting' analytic static PredictiveBlacklistingResultType = int32 result; // output from 'domain profiling' analytic static DomainProfilingResultType = int32 result; // output from 'host profiling' analytic static HostProfilingResultType = int32 result; graph ( stream<FullDNSResponseMessage_t> FullDNSResponseMessageStream as OutFull ; stream<ShortDNSResponseMessage_t> ShortDNSResponseMessageStream as OutShort ) = DNSMessageParser(PacketStream) { logic state: { map<uint16,rstring> dnsTypes = { 1: "A", 2: "NS", 3: "MD", 4: "MF", 5: "CNAME", 6: "SOA", 7: "MB", 8: "MG", 9: "MR", 10: "NULL", 11: "WKS", 12: "PTR", 13: "HINFO", 14: "MINFO", 15: "MX", 16: "TXT", 28: "AAAA" }; map<uint16,boolean> dnsAnalysisTypes = { 1: true, 2: true, 5: true, 12: true, 28: true }; // analyze only types A, NS, CNAME, PTR, and AAAA } param processorAffinity: $parserProcessorAffinities[getChannel()]; messageAttribute: dnsMessage; outputFilters: DNS_RESPONSE_FLAG() && DNS_QUESTION_TYPE() in dnsAnalysisTypes && !parseError(), DNS_RESPONSE_FLAG() && DNS_QUESTION_TYPE() in dnsAnalysisTypes && !parseError(); output OutFull: questionName = DNS_QUESTION_NAME(), questionType = DNS_QUESTION_TYPE() in dnsTypes ? dnsTypes[DNS_QUESTION_TYPE()] : (rstring)DNS_QUESTION_TYPE(), responseCode = DNS_RESPONSE_CODE(), answerCount = DNS_ANSWER_COUNT(), answerNames = DNS_ANSWER_NAMES(), answerData = DNS_ANSWER_DATA(), answerTypes = DNS_ANSWER_TYPES(), answerTTLs = DNS_ANSWER_TTLS(), nameserverCount = DNS_NAMESERVER_COUNT(), nameserverNames = DNS_NAMESERVER_NAMES(), nameserverData = DNS_NAMESERVER_DATA(), nameserverTypes = DNS_NAMESERVER_TYPES(), nameserverTTLs = DNS_NAMESERVER_TTLS(), additionalCount = DNS_ADDITIONAL_COUNT(), additionalNames = DNS_ADDITIONAL_NAMES(), additionalData = DNS_ADDITIONAL_DATA(), additionalTypes = DNS_ADDITIONAL_TYPES(), additionalTTLs = DNS_ADDITIONAL_TTLS(); OutShort: questionName = DNS_QUESTION_NAME(), questionType = DNS_QUESTION_TYPE() in dnsTypes ? dnsTypes[DNS_QUESTION_TYPE()] : (rstring)DNS_QUESTION_TYPE(), responseCode = DNS_RESPONSE_CODE(), answerData = DNS_ANSWER_DATA(), additionalData = DNS_ADDITIONAL_DATA(); } () as FullDNSResponseMessageSink = FileSink(FullDNSResponseMessageStream) { param file: "debug.TestDNSMessageParserParallelAnalysis.FullDNSResponseMessageStream" + (rstring)getChannel() + ".out"; format: txt; hasDelayField: true; flush: 1u; } () as ShortDNSResponseMessageSink = FileSink(ShortDNSResponseMessageStream) { param file: "debug.TestDNSMessageParserParallelAnalysis.ShortDNSResponseMessageStream" + (rstring)getChannel() + ".out"; format: txt; hasDelayField: true; flush: 1u; } // placeholder for 'predictive blacklisting' analytic stream<PredictiveBlacklistingResultType> PredictiveBlacklistingResultStream = Custom(FullDNSResponseMessageStream) {} // placeholder for 'domain profiling' analytic stream<DomainProfilingResultType> DomainProfilingResultStream = Custom(ShortDNSResponseMessageStream) {} // placeholder for 'host profiling' analytic stream<HostProfilingResultType> HostProfilingResultStream = Custom(ShortDNSResponseMessageStream) {} }


---
layout: service
name: Ecommerce
icon: flaticon-commerce-and-shopping
image: blog-lg.jpg
summary: "Duis dolor in reprehenderit
in voluptate velit esse cillum dolore fugiat nulla pariatur. Excepteur
sint occaecat cupidatat non proident,"
---
Having been around for over a decade, Basecamp is considered a reliable tool that excels at giving organizations a high-level view of their teams. Like Asana, Basecamp can help monitor tracking, but also offers additional features like direct messaging chats, centralized document storage, and a scheduling tool.Basecamp aims to take on Slack, Asana, Google Drive, and Dropbox by melding all of their competitors into one robust management tool.
Designed with the harried business person in mind, Basecamp helps managers and team members stay on top of their professional lives. The app boasts that users will no longer drown in a sea of emails as that feature is already embedded into the app. Additionally, the scheduling and tracking features help ensure teams never again miss a deadline. Another interesting component of Basecamp is that manager can eliminate the need for “check-in” meetings by sending an automated message daily to employees that ask for a recap of what they accomplished that day. Then employees can “tag” teammates in their recaps to explain what they need help with or what they finished.
A unique feature of Basecamp is that the app doesn’t charge for an increase in the number of users or projects. So unlike some of its peers, Basecamp charges a flat-fixed fee of $99 a month for a team, no matter the size.
Managing a client’s SEO consists of many different timelines and action items. Keeping track of client emails, meetings, and central documents is a full-time job.
By offering one of the best all-encompassing software solutions, Basecamp helps busy SEO pros stay on top of their entire business by more efficiently checking in with their team and deadlines in one easy to use the app.Casie Gillette, senior director of digital marketing at KoMarketing, uses Basecamp mainly for communicating to clients.
“Basecamp is our primary means of communication with clients,” Gillette said. “For any deliverable, it allows an easy way to track the conversation and adjust docs accordingly.”


About the USGS Historical Topographic Map Collection and Explorer
In 2014, the US Geological Survey (USGS) and Esri collaborated to bring the ever-increasing collection of US historical topographic maps to everyone through the USGS Historical Topographic Map Explorer. This app brings to life more than 178,000 maps dating from 1882 to 2006. Previously available only as printed lithographic copies, the legacy quadrangles are now available as web viewable images and free, downloadable digital files. The USGS Historical Topographic Map Explorer allows users to explore the historical maps, save the current view as a web map, and download the maps as high-resolution georeferenced images in GeoTIFF format for use in web mapping applications and GIS. Learn more about the app in the item description on ArcGIS Online.
The historical maps are part of the USGS Historical Topographic Map Collection ― a project that was launched in 2011. The collection includes all scales and all editions of the topographic maps published by the USGS since the inception of the topographic mapping program in 1879. The maps have been prepared at scales ranging from 1:10,000 to 1:250,000. Some scales have broad coverage across the United States, while others may have only one map.
The USGS scanned each map as is to capture the content and condition of each map sheet. All maps were georeferenced, and metadata was captured as part of the process. Using ArcGIS, the scanned maps were made into the USGS Historical Topographic Maps image service that can be viewed on the web and provides links to allow users to download individual scanned images. Learn more about the image service in the item description in ArcGIS Online.
"We are so pleased to see these historic topographic maps being made more accessible to the nation," said Kevin Gallagher, associate director of Core Science Systems for the USGS. "We recognize the fundamental role of government in acquiring mapping information and putting it in the public domain. At the same time, we recognize the tremendous benefits of the private industry adding value through innovative approaches to access and distribution."
- 1. Find or search for your place of interest.
- 2. Click on the map view to see which USGS maps are available for that location.
- 3. Use the timeline to explore thumbnails of the maps, see their extents, and select the ones you want to view.
- 4. Use the slider for each map in the side panel to control its transparency and compare it to other maps.
- 5. Use the links at the top of the app to share the current map view with others via social media or embeddable links.
- 6. Download the map images, if you wish.
- 7. Once logged in to your ArcGIS Online account, you can create a web map that includes the historical maps you have selected.
"We are pleased to partner with the USGS on this app to bring this national treasure to life," said Jack Dangermond, president of Esri. "This application provides an easy way for anyone to explore the historic map collection by both place and time. The ArcGIS platform supports the building and sharing of amazing maps and content such as this collection."
Please contact us at<EMAIL_ADDRESS>with your questions or comments about the map collection or the online app.


Provides misc utils: I/O, statistics and probability, performance measuring, string manipulation etc.


---
layout: post
title: not exactly what i was looking for when i had a
date: '2016-08-26T07:11:39-07:00'
tags:
- frombrett
- programming humor
- sql
tumblr_url: http://beekley.xyz/post/149509425111/not-exactly-what-i-was-looking-for-when-i-had-a
---
Not exactly what I was looking for when I had a SQL question.


[gecode-users] How to wait for a variable
Max Ostrowski
ChaosAngel at gmx.de
Thu Jul 28 16:11:49 CEST 2011
Hi, i want to use the wait function to get notified what a certain variable has been assigned.
And i want to do this for some variables, to finally to something with them.
so i want to have
wait(*this,a,&foo);
wait(*this,b,&foo);
And in my function foo i want to add the variables into a list or something like this.
void foo(Space&, Var a)
{
do something with a
}
but as foo does not get any information about which variable has been assigned i can not use it.
Is there another method to find out/get notified when a variable has been assigned, without going through the list of variables and testing each of it.
If the expected function would like to have a boost function pointer this would be great.
Then you could bind additional information to figure out which variable.
This would also be advantageous if you have several Spaces running in parallel, there is no easy way to figure out which one triggered the callback.
Best,
Max
--
Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de
More information about the users
mailing list


Chest of Wisdom:
[A voice emanates from the chest]
You are the chosen one. I give you the gift of knowledge.


HOME
DAY
Sample Post
by Me
Jan 1, 2019
slick
site
Welcome to your first blog post!
Tweet
Follow @myslickhandle


|
Micro Focus Content Manager SDK 9.4
|
Allows you to retrieve and update the access control list associated with this Trim Main Object More...
Properties | |
| TrimAccessControlList | AccessControlList [get, set] |
| Gets or sets the access control list attached to this object. More... | |
Allows you to retrieve and update the access control list associated with this Trim Main Object
|
getset |
Gets or sets the access control list attached to this object.


(data addr - )
Write the data second on the stack to the address on the top of the stack
( - data)
# accesses basic variables ; it compiles code to push the variable following it in the source on top of the stack. #test is the equivalent of test @ in FORTH.
(n1 n2 - n1*n2)
Multiply the top two values on the stack and push the result on the stack
(n1 n2 - n1+n2)
Add the top two values on the stack and push the result on the stack
(data addr - )
Add the data second on the stack to the address on the top of the stack
(n - m)
Increment the top of the stack
(n1 n2 - sub)
Subtract the top of the stack from the second on the stack and push the result on the stack
(n - m)
Decrement the top of the stack
(n - )
Print the top value of the stack in signed decimal
(n1 n2 - div)
Divide the second on stack by the top of the stack and push the result on the stack
(n - -n)
Negate the top of the stack
(n - t)
Check the top of the stack ; drop the value ; if less than zero push -1 , if non zero push false
(n - t)
Check the top of the stack ; drop the value ; if zero push -1 , if non zero push false
(n1 n2 - t)
Compare the top two stack values and drop both, replacing them with -1 if the second value on the stack is less than the first
(n - m)
Shift the top of the stack left
(n1 n2 - t)
Compare the top two stack values and drop both, replacing them with -1 if the second value on the stack is less than or equal to the first
(n1 n2 - t)
Compare the top two stack values and drop both, replacing them with -1 if the second value on the stack is not equal to the first
(n1 n2 - t)
Compare the top two stack values and drop both, replacing them with -1 if the second value on the stack is equal to the first
(n1 n2 - t)
Compare the top two stack values and drop both, replacing them with -1 if the second value on the stack is greater than the first
(n1 n2 - t)
Compare the top two stack values and drop both, replacing them with -1 if the second value on the stack is greater than or equal to the first
(n - m)
Shift the top of the stack right logically (so bit 15 is always clear)
(addr - data)
Read the word at the given address
(data - )
# accesses basic variables ; it compiles code to store the top of the stack in the variable following it in the source. ^test is the equivalent of test ! in FORTH.
(n1 n2 - n1&n2)
Binary and the top two values on the stack and push the result on the stack
(-)
Compiles a break into the code.
(n - b)
Swap the upper and lower byte of the top of the stack
( - )
Print a carriage return
(m n - m)
Drop the top of the stack
(n - n n)
Duplicate the top value on the stack
( - )
Marks the start of the else code, which is executed if the IF test failed. This is optional
(n - )
Output the top of the stack are a character
(n - )
Starts a loop which executes a fixed number of times, counting down from n-1 to zero. Cannot be nested 10 FOR ...... NEXT executes the code for 9 8 7 ... 0
( - n)
Get the current index value to the top of the stack. This value is held on the return stack so cannot be accessed inside another method.
(test - )
If the top of the stack is true execute the code that is between here and either ELSE or THEN. These cannot be nested
(n1 n2 - n)
Push the higher of the top two values on the stack on the stack
(n1 n2 - n)
Push the lower of the top two values on the stack on the stack
(n1 n2 - mod)
Divide the second on stack by the top of the stack and push the modulus on the stack
( - )
Next marks the end of the loop.
(m n - n)
Drop the second element on the stack
(n - ~n)
Binary not (1's complement) the top of the stack
(n1 n2 - n1|n2)
Binary or the top two values on the stack and push the result on the stack
(m n - m n m)
Copy the second value on the stack to the top of the stack.
( - )
Marks the start of the conditional loop. REPEAT ......
( n1 n2 n3 — n2 n3 n1 )
Rotate the third item on the stack to the top
(m n - n m)
Swap the top two values on the stack
(
Calls routine address, with count parameters which are pushed on the stack backwards (e.g. R3v R2v R1v R0v 4 code.address SYS) ; these are loaded into R0-R4. The value in R0 on return is put on the top of the stack
( - )
Marks the end of the if structure.
(test - )
Marks the end of the conditional loop, using the top of the stack as a test, loops back to the top if the test is zero
(n1 n2 - n1^n2)
Binary xor the top two values on the stack and push the result on the stack


NMR-ML: Nuclear Magnetic Resonance Spectrometry Markup Language
- nmrML Specification Document, Version 1.0 -
Status of This Document
This document presents the first draft of a specification for the nmrML XML data format developed by the COSMOS work package 2 ‘Standards Development’ in approval of the Metabolomics Standards Initiative (MSI). Its structure and wording was taken from an existing specification of equal scope, namely the PSI mzML specification available under http://www.psidev.info/mzml. Distribution is unlimited.
The COSMOS EU project and the Metabolomics Standards Initiative (MSI) defines community standards for data representation in metabolomics to facilitate data comparison, exchange and verification. The COSMOS WP2 develops standards for describing NMR experiment data. This document presents information to the NMR community about the modelling in XML of the experimental results obtained by NMR of metabolite samples and biomolecular compounds. COSMOS WP2 here specifies the missing open standard called NMR Markup Language (nmrML) for capturing and disseminating Nuclear Magnetic Resonance spectroscopy data in metabolomics. This is urgently needed as long-term archival format if metabolomic databases are to capture all the formats of metabolomics data, as well as supporting developments in cheminformatics and structural biology.
This XML format is inspired by the PSI mzML format and hence consists of an XML Schema Definition (XSD) that is accompanied by a controlled vocabulary (CV). The XSD defines the allowed XML elements and attributes and their corresponding XML structure. The CV provides the terminology to describe the data in detail and provide standardized values for the XML tags.
This document assumes familiarity with a few data modelling notations, namely XML and XML Schema (www.w3.org/XML/Schema) for the XSD-based specification of the XML standard and controlled vocabularies in which terms are described in an ‘is-a’ hierarchy called subsumption graph or ‘taxonomy’. You should know what xml elements are, that they can have attributes and that elements can be nested. You should know that a CV term usually has an ID (accession), a label, and potentially more metadata.
This document should be read in conjunction with a kit of auxiliary files, including the XSD and CV documentations as well as ‘How-to’ tutorials for the example instance documents. All files related to this proposal are available for download at http://nmrml.org.
Contents
Abstract.......................................................................................................................................... 1
Introduction................................................................................................................................... 3
Background............................................................................................................................... 3
Relationship to previous formats........................................................................................... 6
Design philosophy................................................................................................................... 6
Overall set-up............................................................................................................................ 7
Data validation by means of semantic validator software................................................. 8
Tool support and software availability.................................................................................. 9
File versioning and release policy...................................................................................... 10
Implementation of the format................................................................................................... 10
The nmrML XSD.................................................................................................................... 10
The CV term referencing mechanism............................................................................ 12
Introduction to nmrML top level elements...................................................................... 13
Example nmrML implementations (valid nmrML.xml instances)................................... 16
Selecting good example NMR data sets for nmrML xml instances........................... 16
Bruker and Varian NMR raw data nmrML examples................................................... 16
Relationship to other efforts and specifications............................................................... 20
The NMR controlled vocabulary: nmrCV........................................................................... 22
Scope and coverage......................................................................................................... 22
Development history......................................................................................................... 23
Metadata provided with each CV term........................................................................... 23
External ontology term reference and import mechanism.......................................... 24
Resolved XSD design Issues.............................................................................................. 24
Count attributes.................................................................................................................. 24
Numerical value and datetimestamp encoding............................................................ 24
The ‘new CV term’ problem.................................................................................................. 25
Other supporting materials................................................................................................... 26
Source files and documentation......................................................................................... 26
Next steps.................................................................................................................................... 27
How to contribute and provide feedback........................................................................... 28
Summary..................................................................................................................................... 28
Authors and contributors.......................................................................................................... 28
Intellectual property statement................................................................................................. 29
Appendix A................................................................................................................................. 29
Nuclear magnetic resonance (NMR) spectroscopy is an important analytical method in metabolomics. As the instrument vendors typically also provide the software to process the vendor specific data, alternative data analysis software needs to put considerable efforts into reading and writing these specific vendor formats. This applies both to commercial software, such as NmrPipe, MestReNova (Mnova) or Chenomx NMR Suite, but even more so to community developed open source efforts such as Metaboquant[1] (Matlab-based), the Batman R package or rNMR. Currently existing standard data formats such as the JCAMP family[2] have several drawbacks, especially in metabolomics applications. One problem is that there is no semantic validation and error checking of JCAMP-DX files.
To continue the standardization efforts by the Metabolomics Standards Initiative (MSI) [3] and to leverage and canonize existing predecessor artifacts[4] and to coordinate further developments, the COSMOS EU project was granted to create an open exchange data standard to allow metabolomics NMR raw data, to be shared and stored in an agreed-upon stable and persistent, yet flexible, vendor agnostic and easy to understand XML format.
The COSMOS project coordinates efforts from multiple international groups who are working in NMR based metabolomics and NMR software-engineering to design and establish an nmrML data format (http://nmrml.org) based on the experience with the PSI (Proteomics Standards Initiative)[5] mzML[6] format for mass spectrometry.
A bird’s eye view on the envisioned nmrML use cases is provided in Fig. 1.
Figure 1: Illustration of NMR data management facilitation by means of the common nmrML standard developed in COSMOS
We have formalized these use cases and requirements which the new standard should meet in the Unified Modeling Language (UML) use case diagram (Fig. 2) to illustrate the distinct usages of nmrML in a more standardized manner.
Figure 2: UML use case diagram illustrating the multiple application scenarios of the nmrML standard
The following target objectives can be defined for the nmrML core format:
T1. The discovery of relevant results, so that, for example, data sets in a database or public repository that use a particular technique or combination of techniques can be identified and studied by experimentalists during experiment design or data analysis.
T2. The sharing of best practice, whereby, for example, approaches that have been successful at analysing low abundance analytes can be captured alongside the results produced.
T3. The evaluation of results, whereby, for example, the number and quality of the spectra recorded from a sample can be assessed in the light of the experimental conditions.
T4. The sharing of data sets in an open vendor agnostic manner, so that, for example, public repositories can import or export data, multi-site projects can share results to support integrated analysis, or meta-analyses can be performed by third parties from previously published data.
T5. The most comprehensive support of the instruments output, so that data can be captured [from] all relevant forms of NMR data representations.
T6. The increase of data persistence and traceability over time, by delivering a robust storage format. The primary focus of the model is to support long-term archiving and sharing, rather than day-to-day laboratory management, although the model is extensible to support context-specific details.
This document defines a specification and is not a tutorial. As such, the presentation of technical details is deliberately direct. The role of the text is to describe the schema model and justify design decisions made. This document does not provide comprehensive examples of the schema in use. Example documents are provided separately (see nmrml.org/examples) and should be examined in conjunction with this document. It is anticipated that tutorial material will be developed to aid implementation. Although the present specification document describes constraints and guidelines related to the content of an nmrML document as well as the availability of tools helping to read and write nmrML, it does not describe any implementation constraints or specifications such as coding language or operating system for software that will generate and/or read nmrML data.
Cosmos WP2 started the nmrML.xsd development by modification of a predecessor XSD[7] and with additional elements and structures from the BML-NMR XSD developed by Christian Ludwig and D. Rubtsov in Birmingham[8]. Both these efforts were integrated by COSMOS, expanding the schema of the TMIC Group, as it was already capturing the basic raw data and had the CV reference mechanism (see Tab 1) already in place. The merged successor artefact described in this document is now called nmrML and invalidates both predecessors as the MSI recommended common standard.
Since the development of nmrML brought together many different philosophies, the designers agreed on the following design principles:
As in our PSI mzML role-model, we agreed on implementing a combined exchange syntax using XML schema and accompanying controlled vocabulary (CV) terms (Fig. 3). The basics of XML and CV based data standardization have been summarized in a Powerpoint presentation[9] and highlight the general reasons for our nmrML setup.
In areas where the terminology is likely to change faster than the nmrML XSD could be updated and aligned, branching out from the XSD to CV usage can compensate for such dynamics in a more flexible way (read more on this issue in Sec 3.1). The CV can be maintained externally and even in a decentralized manner. For example, new NMR probe types can be represented in an nmrML file by requesting and adding a new controlled vocabulary term, without the need for a full XSD revision.
Figure. 3: nmrML consists of an XSD specification, capturing the more data-near and less variant raw data, and a CV in OWL format capturing the more variant contextual terminology on NMR as a simple taxonomy. For example when capturing information about the NMR instrument configuration there are many different possibilities such as probe heads, auto-samplers, brands, models, etc.
The XSD-CV set-up allows for multiple data validation levels to be established (Fig. 4), contributing to data consistency, completeness and overall quality assurance.
To avoid the problem of inconsistent usage of vocabulary terms and the appearance of different dialects encoding the same information, we are implementing a semantic validator that checks if the CV terms are used correctly within a particular XML data file. ‘Correctly’ means that the terms are used in appropriate XML elements and in the correct cardinality. So, the semantic validator enforces rules not only making sure that the terms are actually found in a specified CV, but also that the correct terms are used in the correct location (XML Tag) in the XML document and the required terms are present the correct number of times, i.e. that there are two filler values allowed for the SampleTemperature-Element, and that these must come from the Unit Ontologies’ “temperature unit” subtree.
This allows greater flexibility in the schema, but enforces order in how the CV terms are used. This will require the discipline of using the semantic validator exploiting validation rules, not just an XML validator for checking an annotation prior to storage and submission. The result is that new technologies or information can be accommodated with adjustments to the controlled vocabulary and validator, not to the schema which hence can stay stable.
Fig. 4: XML syntax and structural validity of XML instances can be validated by an XML parser against the XML Schema. Examples include XML element and attribute positions, order and cardinality. Our proprietary validation tool exploits mapping files to enforce also semantic validity[10] of an xml file by specifying which CV terms are allowed in which elements, from which ontology they should come, as well as their order and cardinality. The semantic validator to be developed for the next deliverable checks that the criteria outlined by the mapping file are met in a given XML instance (.nmrML data file). The mapping file combined with the CV can also be used for intelligent support in data acquisition, i.e. when creating an interface that records NMR experiment information, it can populate a drop down menu or an autocomplete box with plausible CV terms that make sense in this particular place in the file.
One of the aspects that will enable swift adoption is the timely availability of open source tools that implement the format (e.g. Batman, nNMR, pynmrML, …). With these tools many users are able to begin using the format immediately, without coding their own software. To insure that nmrML will be adopted quickly, the format is presented with several tools that write, read, and validate nmrML:
We are finalizing the release policy and hence refer to the corresponding wiki page draft at https://github.com/nmrML/nmrML/wiki/nmrML-release-process. We are working on automatizing the release procedure via a release script.
Any valid nmrML XML instance must adhere to a specific structure or grammar, which is specified in an XML Schema Definition (XSD). The nmrML XSD is split up into multiple sections that organize the information that can appear in nmrML in an intuitive way that facilitates understanding of the format as well as tool development. The current top level structure of the nmrML XSD is described in Fig. 5.
Figure 5: The top level XML elements of the nmrML.xsd, illustrating its main elements and datatypes thereof. The CVList element defines the controlled vocabularies from which terms are drawn in an XML data file. The other elements are self-explanatory and refer to the actual NMR data description, a bit like sections in a material & methods paragraph, describing an NMR experiment. These are described below. For detailed documentation, we refer to the HTML documentation of the XSD, or the XSD itself, in which extensive element annotations explain the usage of the elements.
At certain locations in the XSD the user is allowed to describe his data by means of standardized controlled vocabulary terms. The XSD ‘branches out’ into CV-usage, where:
· The terms are unstable, variant & dynamically evolving, or need to be changed and updated often
· The terms refer to fast paced dynamically changing terms such as software names/versions, processing parameters etc.
· The terms describe contextual metadata, rather than concrete NMR raw data, i.e. for cases where the terminology is already extensively defined in existing ontologies or CVs.
· The terms are better maintained by a fast reacting NMR user community rather than by resource-limited Cosmos work packages.
· The terms represent search attributes for data querying and large scale database-integration in an open linked data fashion.
· The terms should be accessible to rule-based or other reasoning techniques and validation
· The terms should be exploited by profiting from robust subsumption, e.g. exploiting the taxonomic CV backbone to generalize over query attributes and hence increase result recall and precision.
We here outline how CV term usage in nmrML is specified in the XSD. The requirement and modality for a CV term occurrence in an XML instance is specified in the XSD by reference elements/types as illustrated in Table 1. Keep in mind that the last element (UserParamType) captures free text and makes no CV reference to populate an xml element.
Table 1: The different ways to reference a CV term from within an nmrML xml file are listed.
|
Reference Type |
Definition |
Attributes |
Comment |
|
CVTermType |
Elements of this type hold additional data or annotation as a simple CV term with no further values (Parameters) associated with it. Only controlled CV terms are allowed here. |
CVRef (the ontology), accession (the ID), name (the label) |
The “CVRef” attribute contains an id for the source CV, unique to the XML instance, that is defined in the cvList element. This allows for multiple CVs to be referenced crisp and unambiguously. The “accession” attribute contains the ID of the CVterm which is unique within the CV. The “name” attribute contains the term itself, the intelligible label which is e.g. displayed it to a user) without requiring the CV file to be downloaded and parsed. |
|
CVParamType |
Elements of this type hold additional data or annotation. In contrast to CVTermType, here a pair of descriptors, i.e. the CV term AND a value (=Parameter) is captured. Only controlled terms are allowed here. |
CVRef, accession, name, value |
The ‘value’ attribute stores the parameter to be captured as value. |
|
CVParamWithUnitType |
Elements of this type hold additional data or annotation, i.e. a controlled term describing a parameter, as well as a value and a description of the unit the value is recorded in. Only controlled values are allowed here. The unit ontology is typically used to provide the terms for the unit. |
CVRef, accession, name, value, unitCVRef, unitAccession, unitName |
The ‘unitCvRef’, ‘unitAccession’ and ‘unitName’ attributes are used in the same way to describe the unit as the ‘cvRef’, ‘accession’ and ‘name’ terms are used to describe other CVTerms. |
|
ValueWithUnitType |
Elements of this type hold additional data or annotation. Only controlled values are allowed here. For cases where only a Value with an ontologically defined Unit should be given. Elements of this type hold a value and a reference to the unit the value is recorded in, but is used in locations where the type of value is already defined by the element, but the unit of the value still needs to be recorded. |
Value, unitAccession, unitName, unitCvRef |
|
|
UserParamType |
Elements of this type hold uncontrolled user parameters (essentially allowing free text). For cases where no suitable CV term exists. Before using these, one should verify whether there is an appropriate CV term available, and if so, use the CV term instead. This list can however later be exploited to generate corresponding term requests in given ontologies or CVs. |
Name, valueType, value, unitAccession, unitName, unitCvRef |
The ‘valueType’ attribute |
References to the specific CVs used in the XML instance are recorded in the ‘cvList’ element at the top of the file, which allows for unambiguous reference to CV terms.
The ‘fileDescription’ element captures a general description about the file and its contents which allows for easy categorization of different types of nmrML instances e.g. 1D vs. 2D. The ‘contactList’ element captures information that allows one to contact the original creators/corresponding authors of a file/paper in the case that further clarification is needed. The ‘sourceFileList’ contains information about the original files used to make the nmrML instance including files that were required during the acquisition of the spectrum, for example a Varian processing parameter file or a source code file for a pulse program. Similarly the ‘softwareList’ element captures references to software that was used during data acquisition and processing, and may include several different pieces of software. The ‘informationConfigurationList’ element contains information about the configuration of an instrument beyond the acquisition parameters, for example the brand and model of the instrument. The ‘acquisition’ element captures the processing parameters used during the acquisition. Since vendors have their own set of names for each of these parameters, we have standardized them with hopefully intuitive clear names. This element also contains the captured FID data. The ‘spectrumList’ element contains one or more spectra in the frequency domain.
Figure 6: Specification of CV term usage via the CVParam element in the XSD (Oxygen Design view screenshot). The accession attribute encodes the CV term ID and the name encodes the CV term (label).
An example of how a CV term reference by means of the CVParam type (specified in Fig 6) is used in an example XML instance data file can be found in Fig. 7.
Figure 7: Example XML instance (Oxygen grid view) for example data from the original J. Cruz XML example[11]. This figure illustrates instantiation of CV terms to describe a concrete file content via CV Parameters. Where the correct entity usage for some values was not given in the original file or doubtful, value entries were marked with the String "???".
The large binary FID data is stored in the xml at the end of the file in order to allow researchers/programs to look at the first part of the file, which contains the human readable data, without the need to load the whole binary blob.
At the core of XML Schema definitions lies a principle called object inheritance. Like in object oriented programming languages a complex but basic element can be defined in an abstract and general way. This allows to derive subelements which inherit the already defined characteristics of the parent-element, but can have additional characteristics.
The nmrML.xsd and data.nmrML XML files can be opened with any text editor and are human readable. Element descriptions were added as annotations to help rendering the schema self-explanatory and intuitive. To foster element retrieval and selection, we added a synonym field per XSD element (as we capture synonyms for the CV). These annotations are useful user entry points when searching for suitable annotations/elements.
Values and attributes for elements that appear in an nmrML file can be
a) autogenerated at run-time form the source vendor file parameters via a simple mapping that the parser[2] accesses.
b) autogenerated at parser run-time by computation from given parameters in the vendor data files. An example is the value for gamma_b1_pulse_field_strength, which is computed[3] from the varian pulse with parameter.
c) autogenerated totally anew at parser run time. These refer to mainly administratory information, e.g. local variables like hashes and temporary IDs.
d) manually/user generated additional annotations that pertain to metadata that is not easily accessible or not available from the vendor files.
We created multiple example xml files to serve as data-driven check on the format and allow end-users to learn and grasp the nmrML format more easily.
We defined the following characteristics of intelligible/intuitive example data set in order to increase didactic compliance:
· The data was gathered in a prototypical, abundant experiment set up, representative for metabolomics data acquisition
· The data should stem from a simple experimental set-up (e.g. 1D 1H NMR data)
· The data has a published paper available (not a method-, but a research-paper)
· The data has a database entry available, e.g. in MetaboLights[12] or HMDB[13]
· The data has accompanying original data files (FIDs)
· The data is using an abundant vendor format like Bruker, Varian or JEOL standard files
· The data is associated with a responsive contact person, in case someone needs to get back to the data producers to be able to gather additional information or resolve questions
· The data has been analyzed further with open source tools like Batman or MetaboQuant, so that we can later reproduce the same results based on the converted nmrML data.
According to these criteria we have collated example NMR raw data sets to be converted into nmrML by an automatic parser that reads in the vendor files and writes valid nmr xml files which comply to the nmrML.XSD. These examples .nmrML xml files can be found in the corresponding github ‘example’ folder[4], together with an accompanying readme file illustrating its generation in more detail. For a quick glance you should look under http://nmrml.org/examples. To learn nmrML we advise our readers to look at these example files in the vendor format they are familiar with. Another place to look at examples are the documentation pages at nmrml.org/schema.
Example 1 (Cruz_Example): At first, we analyzed, if our schema compensated for all data required by the original predecessor. The original J. Cruz nmrML XML example was taken from http://www.metabolomicscentre.ca/nmrML/biosample-concentrations.xml and was translated manually into an nmrML XML instance.
Example 2 (reference_spectra_example): Another example was created from a reference spectrum obtained from HMDB (http://www.hmdb.ca/spectra/nmr_one_d/1024). The file was initially written manually, obtaining values from the Varian procpar file and a python script for encoding the raw FID data into the correct format. This example also proved useful for creating the conversion software since the output could be compared.
Example 3 (IPB_HOP_Example): We added another example which represents a typical metabolomics experimental set-up. Thirteen hop plant ecotypes were profiled for interesting secondary metabolites using MS and NMR in combination[14]. Fig. 7 illustrates how 1D acquisition and raw FID data is stored in an nmrML xml instance for one of the hop variants (AHTM). In order to familiarize with nmrML, this example is the one you should start with when you are working with Varian data.
After the development of the vendor to nmrML parsers was sufficiently complete, more example files were generated, i.e. from MetaboLights[5] entries MTBLS1 and 25 data. All examples can be browsed in the corresponding GitHub folder.
Example 4 (MTBLS1): This is example nmrML file that was generated from Bruker data.
Figure 7: We here provide an nmrML XSD snippet where the FID element is shown (above). The code screenshot (below) illustrates how basic 1D acquisition parameters are stored in the example XML and how Varian raw FID data is stored. The FID is stored as a binary blob (base64 encoded binary data). Byte ordering is always Intel-style little endian. Computers using a different endian style must convert to/from little endian when writing/reading nmrML. The FID should be converted into an array of complex numbers before encoding.
The specification described in this document is not developed in isolation; indeed, it is designed to be complementary to, and thus used in conjunction with several existing and emerging information models. Related specifications include the following:
1. nmrML parsers: We have implemented multiple parsers. The python based vendor2nmrML format parser[6] uses the nmrGlue API to access the most important parameters from the Bruker and Varian Files. Our Parser, developed by Michael Wilson writes these parameters into an nmrML xml file. Another parser, called nmrRIO, parses nmrML and makes its content available to R based statistics tools such as Batman and rNMR.
2. nmrQuant: A future extension of the nmrML schema that allows to capture NMR based quantification data on metabolites
3. nmrIdent: An future extension of the nmrML schema that allows to capture NMR based Identification data on metabolites.
4. nmrML (to nmrCV) mapping file: Although the structure of the CV and the nmrML schema are related, the details of which CV terms are allowed/recommended at a given schema location is reported in an external mapping file. The mapping file is a list of associations between a cvParam element in the schema (described via XPath) and the allowed CV term entry nodes/branches of the CV terms expected in that location. The mapping file is read and interpreted by the semantic validator in order to check that the data annotation is consistent and complete. The mapping file needs to be checked and eventually updated when the CV terms or structure are changed. A mapping file will be provided in the next version of this document
5. BioSharing: http://www.biosharing.org is a consortium that collects and promotes common representations for Minimum Information Standards for Metabolomics. We will build on the BioSharing and the ISA-Tab efforts to harmonize representation of the metadata recommendations with other -omics communities, and use automated tests to ensure the interoperability of the metadata between the involved data producers, -consumers and -repositories.
6. CIMR (Core Information for Metabolomics Reporting) at http://mibbi.sourceforge.net/projects/CIMR.shtml specifies the minimal guidelines reporting metabolomics[15] work in a comprehensive and repeatable manner:
7. Minimum Information on an NMR experiment (MI NMR) as defined in http://link.springer.com/article/10.1007%2Fs11306-006-0040-4. The COSMOS nmrML format has been designed to encode the requirements specified in this MI NMR. However, nmrML does not enforce MI NMR compliance itself; nmrML documents may be valid and useful without being fully MI NMR compliant. The nmrML validator will have settings to validate either the basic nmrML raw data level or at a more comprehensive MI NMR compliant level, depending on the needs of the user.
8. SMRS (Standard Metabolic Reporting Structures): An Open Standard for Reporting Metabolic Data (http://www.smrsgroup.org).
9. Analytical Information Markup Language (AnIML):An emerging ASTM XML standard for analytical chemistry data. http://animl.sourceforge.net AniML captures the instrumental set-up of chemical analytical techniques, so is more general in scope than our NMR restricted effort.
10. mzML: http://www.psidev.info/mzml_1_0_0. The XML based open and PSI approved Mass Spectrometry data standard. This format served as a general role model for the development of nmrML and its success made us to copycat many of their design decisions.
11. ISA-Tab: http://isa-tools.org. As research in biomedical and life sciences is increasingly moving towards multi-omics studies, the ‘Investigation/Study/Assay’ ISA-Tab format was developed to represent experimental metadata independently from the assay technology used. We will use ISA-Tab to standardize metabolomics reporting requirements and terminologies through customized ISA configurations.
This controlled vocabulary (CV) is an MSI-approved ontology developed under COSMOS governance. This CV was derived from two predecessors (The NMR CV from the David Wishard Group, developed by Joseph Cruz) and the MSI NMR CV developed by Daniel Schober at the EBI. This simple taxonomy of terms[7] serves the nuclear magnetic resonance markup language (nmrML) with meaningful descriptors to amend the nmrML XML in an explicit yet standardized way. Metabolomics scientists are encouraged to use this CV to annotate their NMR raw and experimental context data.
The nmrCV is implemented as a simple taxonomy in owl syntax[8]. We choose the OWL Syntax[16] over the OBO format[17] as exchange syntax for the CV, as the OBO tools are less stable. Because the OBO format is only established in the biology domain (lack of off-the-shelf development tools) and there are hence less resources to integrate with.
The nmrCV is accessible at http://nmrml.org/cv, but soon will be available from ontology libraries such as the NCBO Bioportal[18]. More extensive documentation will be available form the website soon.
After agreement on the set up of development tools (Protégé 4), we formulated our CV design principles, namely agreed on file names, format syntax, namespaces, (auto) term ID schemes, a term obsoletion policy, as well as versioning & release procedures. We analyzed existing CVs on suitability and modelling errors[19]. From the given predecessor CVs, we proceeded in a bottom-up and middle-out approach to expand the CV. We first added CV terms as required in the XSD leafs, i.e. where CVTermType, CVParamType, CVParamWithUnitType references occur in XSD elements. After this, we continued with a use-case driven term population, taking multiple data sets as examples. No high throughput term-additions were attempted in the early design phase, as this would clutter the CV with terms of doubtful need, impair orientation in the term tree as too many terms distract us from getting the main structure right. The nmrCV.owl ontology momentarily contains ~ 600 classes under the nmr: namespace. Around 2000 terms are imported from the Unit Ontology and the BFO top level ontology.
Not all of our terms currently have natural language definitions, as these are time-intensive and not needed for our use case, given the terms are usually self-explanatory. None has deeper provenance data explicitly annotated (there is only an implicit indication from which predecessor CV a term came in the ID ranges). We try to avoid getting stuck in the meta-ether, and have been pragmatic about this.
The CV in its current stage is far from being complete. Its coverage is just sufficient to express the example raw data. We rely on our users that code their own NMR data in nmrML to submit request-emails for missing nmr CV terms to the nmrML mailing list[9].
The nmrCV should be dynamically maintained via the COSMOS nmrML mailing list (https://groups.google.com/forum/?hl=en#!forum/nmrml/join ) to allow any user to request new terms in agreement with the community involved. Once a consensus is reached among the community the new terms are added within few days. If there is no obvious consensus, the CV coordinators should vote and make a decision.
If you require us to integrate a whole list of new nmr CV terms, you can do so in an email to the author. In this case a term batch-submission table should have the following fields:
term name (rdfs:label)àskos:prefLabel,ideally adhering to labelling best practice[20].
term definition in natural language (IAO_0000115)àskos:definition
superclass (ideally a term from the current nmrCV.owl, or an own suggestion)
Optional fields (good to have) are:
synonym (oboInOwl:hasExactSynonym)àskos:altLabel
term definition source (dc:source)
dc:creatoràdc:author
We use owl:import statements to import the BFO top level and the unit ontology into the nmrCV. Although this option tends to clutter the core CV with seldomly used terms and occupies a lot of RAM, it retains all metadata for the imported terms. We might at some point use the MIREOT term import mechanism, i.e. to reference Chebi terms for the description of Atoms, chemicals and small molecules.
There were several issues regarding the design of the format that were not clear cut, and a design choice was made that was not completely agreeable to everyone. So that these issues do not keep coming up, we document here the issues and why the decision that is implemented was made.
At the moment all list elements would have a count attribute. The reason is that parsers implemented in languages where memory allocation or array sizing is important, it is a nice performance enhancement to have a count attribute indicating how many elements there are in the list. As this is an easy target for creating inconsistent files (i.e. specifying a count=”5” attribute followed by 6 items in the list), this was deemed to be not very useful. That is where we diverge from our role model the PSI mzML not using count attributes in the next versions.
All numerical values shall appear in the XML schema datatype specification (http://www.w3.org/TR/xmlschema-2/). The number 1/10 must always appear as 0.10 and never as 0,10. A preceeding + before a number (+5.0) is prohibited.
Datetimestamps must also be encoded as in the XML specification such as 2007-06-27T15:23:45.00035.
All id attributes follow the XML schema datatype xs:ID (http://www.w3.org/TR/xmlschema-2/#ID), which means that no two id attributes may be the same within a document, and id attributes must be purely alphanumerical strings with at least one letter. Thus, they may not contain spaces or underscores, and id attributes may not be a plain number.
Whereas we allow the users to specify CV terms and CV term with unit and value combinations along the term reference modalities described in Table 1, all information encoded as element attributes are never controlled vocabulary terms. Thus, as an example to describe spectrum type, the cvParam element must be provided to specify a term below NMR:1002007 “NMR spectrum”, such as:
<cvParam cvLabel="nmrCV" accession=" NMR:1000118" name="J-resolved spectrum" value=""/>
Note that both accession and the term name are provided. Parsers should focus on the accession number as this should never change, even if the term name is adjusted in the controlled vocabulary later. Note that there is no value. The mere presence of the term is the annotation.
The problem comes when there is a new term to be added. Let us assume that it becomes necessary to add a new spectrum type “heteronuclear J-resolved spectrum”. Vendor X would like to start writing nmrML with this spectrum type. What should happen and what could also happen?
In an ideal world, Vendor X would contact the Cosmos standards development Work package 2 nmrML list and request a new child term of “J-resolved spectrum”. A CV coordinator would verify that this is a new concept, not simply a synonym of an existing concept, add the term to the CV and release a new version of the nmrCV.owl file at the same location. Vendor X would obtain the accession number and could begin writing out valid nmrML. The semantic validator would (and already does) automatically download the new .owl file and validates that the new nmrML is semantically valid using the new term. If the file is then distributed to arbitrary site Y, local software will suddenly encounter this new term:
<cvParam cvLabel="MS" accession=" NMR:1000129 " name=" heteronuclear J-resolved spectrum" value=""/>
and there is the possibility of failure. The first problem that may occur is that reader software may try to understand what the spectrum type is, but it will not find a spectrum type that it understands. Therefore it can only conclude that either no spectrum type was provided, or one of the terms it doesn’t recognize is a spectrum type but it won’t know which one. If the software could connect to the Internet, and could automatically download the latest .obo file, and look to see if this term was in the file, and then determine what parent the above term had, and understand that the parent is “NMR spectrum”, then the software could conclude that the above cv term is an NMR spectrum, but a new one that it doesn’t not know how to handle yet. Such a string of logic is not terribly difficult but it is not trivial and is objectionable to some.
Worse yet, Vendor X could have been lazy and not even contacted the nmrML CV coordinators and just started publishing nmrML with (“option A”):
<cvParam cvLabel="nmrCV" accession="NMR:9999999" name=" heteronuclear J-resolved spectrum" value=""/>
There is no way to resolve this. No reader could possibly know how to handle this. It should be avoided at all cost. Although it should be noted that until the proper accession number is furnished, such an approach could at least initially be used. In any case, processing software may still not know how to properly handle heteronuclear J-resolved spectra, but it should already be able to confidently understand what the spectrum type is and admit it cannot handle it.
This document cannot be fully judged on its own. It is important to study the accompanying power point presentations, sample instance documents, controlled vocabulary, schema files, and the software that implements this pre-release version of nmrML.
All these files and programs are available from nmrml.org. Further development versions with accompanying readme files can be found on the nmrML GitHub site (https://github.com/nmrML/nmrML).
The following describes the more important files and documents that we have prepared and their respective download locations:
nmrML.xsd
(nmrml.org/schema/1.0.rc1/nmrML.xsd): An XML schema that defines the structure, content and parts of the semantics of the allowed nmrML XML documents. The XML schema definition (XSD) uses XML Schema version 1.1 format following the W3C recommendation (w3.org/XML/Schema). The schema allows for the capture of raw NMR spectrum data and acquisition parameters for both one-dimensional and two-dimensional spectra, including two-dimensional J-resolved spectra.
nmrCV.owl
(nmrml.org/cv/1.0.rc1/nmrCV.owl): The controlled vocabulary (CV) describing the more variant terminology in an unambiguous and standardized way. This ontology is the MSI-sanctioned successor of artifacts developed previously at EMBL-EBI, Hinxton, UK (D. Schober, Sansone Group) and the Wishart Research Group, Edmonton, Canada (J. Cruz). This CV currently covers the description of NMR spectrum acquisition set up and raw data generated during the acquisition. There is less coverage of data generated by analysis of the spectrum such as metabolite quantification and identification. The CV terms are used within the nmrML xml file, at positions specified in the XSD, e.g. by CVParam references.
XML example files
(https://github.com/nmrML/nmrML/tree/master/examples/working.tmp/nmrML & https://github.com/nmrML/nmrML/tree/master/examples): Multiple XML instances complying with the XSD were generated to illustrate the usage of nmrML in a practical experiment data annotation. These instances also served to test the XSD and CV on coverage, structural soundness and to test parser software.
XSDToCV mapping file
(nmrml.org/schema/1.0.rc1/nmrml-mapping.xml): This xml file specifies rules to constrain CV term usage during data entry, i.e. it allows to verify validness of CV term usage in the nmrML XML files. This mapping file will also be used to enforce minimal metadata standards[21]. Only a very first draft has been created for testing purposes.
HTML documentation files
(nmrml.org/schema/1.0.rc1/doc & nmrml.org/cv/1.0.rc1/doc): Documentation was generated with automated tools that describes the nmrML XSD and the CV OWL. The documentation allows non-XML and non-ontology savvy end-users to open, browse and comment on the standards as well as facilitating the use of the data format by developers and the implementation of tools that use, read or write nmrML.
All source files are available on the project Github pages, together with an accompanying readme file.
GitHub: https://github.com/nmrML/nmrML
Cosmos website: http://www.cosmos-fp7.eu
nmrML website: http://nmrml.org
nmrML wiki: http://cosmos-fp7.eu/nmrML/
nmrML google forum: https://groups.google.com/forum/#!forum/nmrml
Further testing of the XSD is required with diverse experimental configurations, to ensure that our goal of flexibility has been achieved. Continuing to improve the documentation and building a community of users will hopefully provide further feedback for improvements to the Schema and CV. At the same time we will continue the data-driven CV expansions and add new terms according to the additional examples selected by our different partners. We must also ensure that the schema is compatible with the steps we are taking toward NMR QuantML and IdentML, which pose the next layer in our onion approach to expand the nmrML (from raw data to preprocessed data to post processed data to full spectra, and their ident and Quant annotations).
Also we need to work out an evaluation pipeline. As part of the next deliverable (D2.5 - Real data, Converters, Validators and Parsers for NMR-ML, m24), we will implement the CV-aware validator software and extensive mapping files containing the verification rules to check XML instances on semantic errors and completeness.
In parallel we will implement the parsers for format conversions and I/O to open source tools. The creation of ISA Tab specifications for easy tabular data entry and minimal reporting requirement enforcement is considered a further next step (D2.6).
We here explicitly solicit feedback on our Project, i.e. on potential XSD and CV errors like missing elements, unintuitive element labels or unintuitive element nesting. We also solicit feedback on the didactics of our specification documentation. Ideally you could start to test the overall format by making your Bruker or Varian NMR raw data accessible to our format converter and check the resulting nmrML format. Experienced xml users can also write valid nmrML files from scratch, validating it through the XSD, and annotate the nmrML further (manually).
Questions of interest to the whole community and more general requests should be send to the COSMOS nmrML mailing list at https://groups.google.com/forum/?hl=en#!forum/nmrml/join
Remarks, change- and expansion requests on the nmrML.xsd, nmrCV and the documentation should be send to the email list at<EMAIL_ADDRESS>If you have a specific request and are a Git user you can use the nmrML Git issue tracker at
https://github.com/nmrML/nmrML/issues?direction=desc&sort=created&state=open
Here use a „CV:“-prefix in the issues subject-line to ease issue archaeology. For XSD requests it should be „XSD:“ (the default), „EX:“ for data examples, “PC:” for Parsers & Conversters and “VAL:” for validation Issues.
This document contains the specification for using the nmrML format to represent NMR spectrometry raw data and associated contextual metadata. This specification, in conjunction with the nmrML XML Schema and nmrCV, constitutes the proposed Metabolomics Standards Initiative sanctioned NMR exchange data coordinated by the COSMOS EU project. For didactic compliance, we provide nmrML example data files and illustrate how these were generated from the vendor files and how they can be validated.
Daniel Schober, Mike Wilson, Steffen Neumann for Cosmos WP 2
We acknowledge the following people, who contributed to the model or controlled vocabulary development and gave feedback or tested nmrML:
Reza Salek, Mike Wilson, Steffen Neumann, Christian Ludwig, Ulrich Günter, Catherine Deborde, Daniel Joseph, Antonio Rosato, John Easton, Tim Ebbels, Kenneth Haug, Annick Moing, Luis de Figueiredo, Philippe Rocca Serra, Jie Hao, Andrea Porzel
COSMOS and MSI take no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the MSI/PSI Chair.
COSMOS and MSI invite any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights, which may cover technology that may be required to practice this recommendation. Please address the information to the main author.
Copyright (C) Cosmos and the Metabolomics Standards Initiative (2013). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation, may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works.

References
[3] In the varian reader at nmrML\tools\Parser_and_Converters\python\pynmrml\io\readers we find the formula “def gamma_b1_pulse_field_strength(self): return 1/( 4 * float(self.pulse_width()) / 1000000.0 )
[4] https://github.com/nmrML/nmrML/tree/master/examples , look at the files in the latest nmrMLs folders.
[7] No DL semantics used, for a short overview on the differences of CV, taxonomy and ontology look at http://infogrid.org/trac/wiki/Reference/PidcockArticle
[8] without leveraging on complicated description logics semantics
[1] Wolfram Gronwald, Matthias Klein and Peter Oefner (submitted ?), MetaboQuant: A Tool Combining Individual Peak Calibration and Outlier Detection for Accurate Quantification from NMR Spectra
[2] P Lampen, J Lambert, RJ Lancashire et al., AN EXTENSION TO THE JCAMP-DX STANDARD FILE FORMAT, JCAMP-DX V.5.01, Pure Appl. Chem., Vol. 71, No. 8, pp. 1549-1556, 1999
[3] Sansone SA, Schober D, Atherton HJ, Fiehn O, Jenkins H, Rocca-Serra P, Rubtsov DV, Spasic I, Soldatova L, Taylor C, Tseng A, Viant MR (2007) Metabolomics standards initiative: ontology working group work in progress. Metabolomics 3, 249-256. ISSN 1573-3882
[4] Sansone,S.A., Fan,T., Goodacre,R. et al. (2007) The metabolomics standards initiative. Nat. Biotechnol., 25, 846–848.
[6] Martens,L., Chambers,M., Sturm,M. et al. (2011) mzML—a community standard for mass spectrometry data. Mol. Cell Proteomics, 10, R110000133. http://www.ncbi.nlm.nih.gov/pubmed/20716697
[8] Taylor CF, Field D, Sansone SA, et al., Promoting coherent minimum reporting guidelines for biological and biomedical investigations: the MIBBI project, Nat Biotechnol. 2008 Aug;26(8):889-96. doi: 10.1038/nbt.1411. , PMID:18688244
[10] Montecchi-Palazzi L., Kerrien S., Reisinger F. et al. (2009) The PSI semantic validator: a framework to check MIAPE compliance of proteomics data. Proteomics, 9, 5112–5119.
[12] Haug, K., Salek, R. M., Conesa, P., Hastings, J., de Matos, P., Rijnbeek, M., et al. (2013). MetaboLights--an open-access general-purpose repository for metabolomics studies and associated meta-data. [Research Support, Non-U.S. Gov't]. Nucleic acids research, 41(Database issue), D781-786, doi:10.1093/nar/gks1004.
[13] Wishart, D. S., Jewison, T., Guo, A. C., Wilson, M., Knox, C., Liu, Y., et al. (2013). HMDB 3.0--The Human Metabolome Database in 2013. [Research Support, Non-U.S. Gov't]. Nucleic acids research, 41(Database issue), D801-807, doi:10.1093/nar/gks1065.
Rubtsov DV, Jenkins H, Ludwig C, Easton J, Viant MR, Günther U, Griffin JL, Hardy N (2007) Proposed reporting requirements for the description of NMR-based metabolomics experiments. Metabolomics 3, 223–229.
[14] Farag, M., Porzel, A., Schmidt, J. & Wessjohann, L. Metabolite profiling and fingerprinting of commercial cultivars of Humulus lupulus L. (hop) - a comparision of MS and NMR methods in metabolomics Metabolomics 8, 492-507, (2012)
[15] Sumner LW, Amberg A, Barrett D, Beale MH, Beger R, et al. 2007. Proposed minimum reporting standards for chemical analysis. Metabolomics 3:211–21
[19] Schober D., Mayer G., Moing A., Eisenacher M., Neumann S., Ontological analysis of controlled vocabularies used in PSI/MSI supported XML standards, Workshop: ODLS 2013, GI-Edition Lecture Notes in Informatics, Proceedings of the Jahrestagung der Gesellschaft für Informatik 2013, Matthias Horbach (Hrsg.), Koblenz, Germany, 16.–20. September 2013, p. 1875-1888, https://wiki.imise.uni-leipzig.de/Gruppen/OBML/Workshops/2013-ODLS-en
[21] Montecchi-Palazzi L., Kerrien S., Reisinger F. et al. (2009) The PSI semantic validator: a framework to check MIAPE compliance of proteomics data. Proteomics, 9, 5112–5119.


Nov 30, 2015 at 6:00AM
Currently raining in Chennai. Rain to continue for some time in
coastal TN and South Andhra. Further updates after noon.
Update 5:15 PM
As you can see from the 5:15 image, Chennai and sorrounding cities
are engulfed by huge storm clouds now. Almost entire Tamil Nadu
Coastal areas will receive heavy rains, especially, again Cudallore,
Pondicherry, Karaikal, Nagapattinam. Chennai is also in focus for
moderate to heavy rain.
|
|
Nov 29, 2015 at 5:30 PM
Highlights - Development of a huge storm system just to the west of
Andaman Islands. At present there is no threat from this - has to be
watched. Current system near Srilanka has moved inland. Most of the
areas inside Tamil Nadu, Madurai, Tiruchirapalli and Tanjore
District and coastal areas to receive heavy rain. Also, heavy rains
at Kanchipuram, Thiruvallur area. North Chennai may receive heavy
rain. Other parts will receive drizzles for now and there are
chances of heavy shower tonight. |
|
Nov 28, 2015 at 9:15 AM
Big one coming
The low pressure we saw for few days now has grown in size and has
not moved much west...instead, it appears to move north west and
heading straight to Tamil Nadu. So, we should expect moderate -
heavy rain throughout Tamil Nadu in the next 6-7 hours, starting
from South TN, Chennai no exception. Image was received from Russian Meteor M-N2
Satellite at my home.
Update 2:10PM
The storm is closing in. As expected, it has started moving inland,
starting at Rameswaram in Tamil Nadu. Expect rain in coastal Tamil
Nadu in 4-5 hours from now.
Update 5:30 PM
Movement into the land is not as fast as expected. The rain is just
delayed but it is there for sure.
|
|
Nov 27, 2015 at 9:30 AM
The Storm near Andaman is currently not showing much interest.
Except in Rameswaram area in Tamil nadu, rest of the places should
remain dry. |
|
Nov 26, 2015 at 10:00 AM
More heavy rains expected in Chennai, Pondicherry, Cudallore,
Vedaranyam, Nagappattinam again.
Other parts of Tamil Nadu to remain dry. System at Arabian sea is
moving away from the continent. Bombay escapes. Hope it doesn't come
around Lanka.
Click the picture to see high resolution - received from Russian
Meteor MN-2 satellite at my radio station.
Update 2:45 PM
Rain to pick up any time in Chennai now. Rainfall - low - moderate
expected. |
|
Nov 25, 2015 at 2:30 PM
Here comes the rain again
We see massive formations on either side of the peninsula. As of now
things are clear over TN. Over to the east of Srilanka, is the LP we
need to worry about. It is already showing tendency to move North
West towards Tamil Nadu. We could see low cloud formation East of
Chennai. It is not water bearing at present but things could change
rapidly here as we have seen. So I would say, there is chance of
another spell of Rain in Chennai today evening.
|
|
Nov 24, 2015 at 3:00PM
All Clear
At present it appears to be calm over entire Tamil Nadu, sunny in
most places. There is still possiblity of rain as observed in this
years season. The convection appears to happen very fast. Convection
is the process in which heated air moves up over a region to create
low pressure and wet air rushing from sea to fill up the gap and
then pour. This is very active in Chennai region.
|
|
Nov 23, 2015 at 5:45 AM
Updates at 9:30 AM
Highlight is the formation of a huge cyclone as you can see, in
Arabian Sea. It will be interesting to see how it develops. In
Tamil Nadu, cities west to Chennai, Tanjore East coast are receiving
rain. Sun is fully out in Chennai and they have declared holiday for
kids for 8th day in a row without any heavy rain!
Current rain in Cudallore, Chennai and other places is just a
fraction of what came on 15th and 16th. Since ground is already
saturated with water, it cannot take in any more and hence there is
flooding.
Note the patch of cold wind on east coast of Orissa, Andhra (Purple
Blue).
|
|
Nov 22, 2015 at 9:30Am
As you can see, most of the clouds have left Srilanka and crossed
over to South Tip of TN. Rain to continue in Madurai, Tiruchi,
Kanyakumari, Rameswaram and up to Vedaranyam in North. Chennai will
remain clear, Sunny with intermittent cloud cover and possibly
drizzles. |
|
Nov 21, 2015 at 9:45Am
Srilanka taking it all
The system I mentioned yesterday 950 kms south east of Chennai has
gained in size and moved westwards and situated over Srilanka. This
will vent most of its fury over Srilanka and part of it may move to
Southern Tamil Nadu in 8-12 hours.
As of now, it will be quite calm over TN. Formation of low clouds
(Yellow), typical of Karthigai Month. In Chennai, it will be Sunny
at times with drizzles.
Update at 5:15PM
Since morning, the cyclone, after drenching Srilanka, is continuing
to move Westwards. Coastal Tamil Nadu will receive rain any time
starting now, Southern most regions receving most of it. There is
more rain for Chennai tonight and morning. Low - Moderate rain
expected. On the West, Bombay is waiting for rain. |
|
Nov 20, 2015 at 5:30 PM
Formation of a new low pressure about 950 Kms South East of Chennai.
Other than that, short spells will continue in Chennai and its North
suburbs. Larger area covering Tiruchi, Tanjore, Dindigul, Madurai
area and parts of Kerala to receive rain. Kerala rains will be
heavy.
|
|
Nov 19, 2015 at 2:30 PM
More Rains for Chennai
Chennai and suburbs, Pondicherry will receive moderate - heavy rain
for the next 5-6 hours. Down south, Kanyakumari is already receiving
rainfall and this will continue for few more hours. Madurai,
Theni, Cumbum, Kodaikanal also will receive rain. Nellore,
Machilipatnam and Vishakapatnam will receive heavy rain. |
|
Nov 18, 2015 at 2:30 PM
We are seeing a new storm brewing North East of Srilanka. We have to
wait and see how it progresses. Immediate prediciton is .... some
rain is expected in Chennai - not heavy - in the next few hours.
We could observe a change in Chennai/Bangalore climates (cold dry
wind that causes skin dryness and discomfort). This usually
indicates that the season is coming to an end.... but nature is
unpredictable! |
|
Nov 17, 2015 at 9:30 AM
It is now turn for Andhra Pradesh coast line to get some share of
water. This storm currently is showing a tendency to move North
West. It is however early to confirm it. As of now, we should see
more and more of Sun in Chennai. Rest of Tamil Nadu should remain
dry mostly except for localized light rain here and there.
Update 2:30 PM
NASA/NOAA 19 Satellite
The storm system has moved northward due to drop in temperature in
Tamil Nadu. It is now centered between Vishakapatnam and Kakinada.
Coastal Andra, especially Machilipatnam up to Vizag in the north and
some parts of Orissa coast will receive rain. At Chennai, there is a
possiblity of drizzles and cloud cover. |
|
Nov 16, 2015 at 2:15 PM
There will be some respite for Chennai from the rain. That is, for a
brief period of 8-10 hours. Other parts of Tamil Nadu will remain
dry mostly. |
|
Nov 15, 2015 at 6:00AM
This was the image received from NOAA-15 just now. Shows that the
storm has grown and consolidated. Eye or center of the storm is
right over Chennai/Pondicherry as of now. Rain is set to start in
Coastal Tamil Nadu any time now. Almost entire Tamil Nadu,
especially east coast is expected to receive lot of rain starting
any time. |
|
Nov 14, 2015 at 5:00PM
The storm system that developed near Andaman is not as big and
strong as we thought it would become. It is right now a weak storm
system currently crossing over near Nagapattinam Coast. Result of
this will be felt in Nagapattinam - Rameswaram coast and Tanjore
district mostly. These regions will receive heavy to very heay
downpour. Knowing how nature acted in recent days, in Chennai
area, we can say there will be one or two spells of heavy rain /
cloud break tonight or tomorrow. |
|
Nov 13, 2015 at 5:37PM
Much of the threat is now gone as you can see in the image. In fact
the weather will remain mostly clear (slight rains possible) in
Chennai and North Eastern coastal region. In fact there is a
possiblity of sun shine for brief periods tomorrow in Chennai, if
any rapid system doesn't form. South India will continue to receive
rainfall. |
|
Nov 13, 2015 at 9:15AM
Chennai has just experienced a cloudburst from this huge system.
This is a big one! Heavy rains expected to lash Chennai, Cudallore,
Pondicherry, Kanchipuram, Dharmapuri and all the way to Bangalore in
the West. Also Southern tip of Tamil Nadu up to Madurai in the North
is expected to receive very high rain fall.
Weather image on the right was received from Russian Weather
Satellite Meteor M-2 at my weather station at home. |
|
Nov 11, 2015 at 9:45AM
Today's image is from the Russian Meteor M-2 satellite. High
resolution image - click on the image to see full size. Today, they
have switched off Infra red channel in the satellite. Clouds cover
most of TN and scattered rain fall (not heavy) is expected.
Interesting part is that the next one is moving in from North East.
Good News. |
|
Nov 10, 2015 at 2:15 PM
Sun did pop out for a few hours in the morning today at Chennai but
it looks like there would be few more spells of light - medium heavy
rain at Chennai, Pondicherry, Cudallore area. Remaining part of TN
may get scattered light rain. |
|
Nov 09, 2015 at 2:30 PM
After doing busy work on the east cost of Tamil Nadu, the storm
system has crossed over into the land and is situated, covering
almost entire Tamil Nadu. More rain is expected in all of Tamil
Nadu. Chennai is now begining to show signs of clearing up but there
could be few more spells of rain from now until tomorrow. Tomorrow I
expect it will be partially sunny in Chennai.
5:30 PM Update
Further rains expected in Chennai tonight and possibly tomorrow
also. |
|
Nov 07, 2015 at 9:30 AM
As I said yesterday, the system is just
beginning to form into a spiral storm system. At present it is
difficult to predict its movement but it appears to move South East
towards Indonesia. So there wont be any major effect in Tamil Nadu.
However, South tip of TN and Pondy - Rameswaram can expect rain. In
Chennai, we can expect sun to pop in and out with drizzles in
between. |
|
Nov 06, 2015 at 5:30 PM
This is a system which is coming from Arabian Sea, which is unusual
at this time. North East Monsoon is supposed to be active from Bay
of Bengal but now it is from Arabian Sea. This system is showing
signs to become a tropical storm. In a few days, we might see a full
fledged cyclone in Bay of Bengal. As of now, North TN will remain
dry while south may receive some rain. |
|
Nov 02, 2015 at 3:30 PM
Since Morning today, rain clouds have reduced considerably over Bay
of Bengal and Arabian Sea. Clouds over Chennai has depleted an
chances of heavy rains is less. Further update at 6:00PM today
6:00 PM Update : Further depletion of Bay of Bengal system. Still
there is chances for rain in Chennai from westerly direction.
Tomorrow we can expect a bright and sunny Chennai. |
|
Nov 01, 2015 at 9:45AM
and 6:00PM
Stay warm. Tamil Nadu, southern region experiencing heavy rain.
Chennai and suburbs, South Arcot, East Coast all expected to receive
heavy rain. |
|
Oct 30, 2015 at
02:30 PM
Look at the animation on the right. Click for a bigger picture. NE
monsoon has arrived! brace yourselves. Moderate to heavy
rain is expected to start any time now in Chennai, and coastal areas
like Pondicherry. We have to wait and see how it progresses. Put off
travel if possible. |
|
| |
|
Oct 28, 2015 at
09:30 AM
This is the
image received from Russian Meteor M-2 LRPT at high resolution.
Heavy cloud cover above Chennai. Mostly cloudy conditions expected
with drizzle. Possibility of heavy rain in the evening/Night. South
TN can expect rain tomorrow. |
|
Oct 05, 2015 at 02:15
PM
Expected to be cloudy and rainy in parts of Tamil Nadu with chances
of more rain in the next few days. South experiences severe rainy
weather at the moment.
|
|
Oct 05, 2015 at 02:15
PM
Expected to be cloudy and rainy in parts of Tamil Nadu with chances
of more rain in the next few days. South experiences severe rainy
weather at the moment.
|
|
Oct 03, 2015 at
09:30 AM
This is the
image received from Russian Meteor M-2 LRPT at high resolution.
Click on the picture to see full resolution. Rain is due to
formation of nice cloud system over Chennai/Tamil Nadu and Andhra
coastal region on the eastern side. Rain is here to stay for at
least 2-3 days. Chennai, Pondicherry, and up to Rameswaram Coast
will remain cloudy with intermittent rain. Further udpate this
evening.
|
|
September 29, 2015 at
05:30 PM
Heavy rains expected in South Kerala and
Tamil Nadu. Rains fail Chennai again. Click on the pictures to see
higher resolution.
First one from left uses Infra Red channel of the satellite. Shows
thick cloud cover, mostly water bearing over TN, Kerala and
Srilanka. Heavy rains expected.
Middle image is Visual, as seen by the Satellite's camera. Sun
setting on the west, most of Arabian sea shows reflected light from
the Sun. You can see shadows of clouds on the land - bigger and
longer the shadow, higher the cloud is.
Thermal image on the right shows Rajasthan and Gujarat cooling down
further. Himalayan region has cooled down completely now...In few
weeks or a month, we can expect air to flow from the North East.
Remember the Geography lesson we read as kids? Himalayas protects
India from cold artic winds... you can see that in the thermal
image! |
|
September 27, 2015 at
02:15 PM
Thunder storoms expected by
evening/tonight in Chennai and suburbs. Some parts of Tamil Nadu,
Selam, Erode, Krishnagiri are receiving lot of rain fall. Cauvery
Catchment areas receiving heavy rainfall. Inflow into Mettur dam
expected for next few days. Kerala will continue to receive rain.
Expecting some firecrackers in the sky tonight. Make sure your
overhead water tank is full.
Click the image for larger picture. |
|
September 25, 2015 at
02:45 PM
Nothing much today as far as prediction
is concerned. No rain for most of India.
Thermal Image shows Rajasthan and Gujarat cooling down slowly which
is good news - Once this region cools down completely, NE monsoon
will start. Looks like it will be on time this year.
|
|
September22, 2015 at 09:25 AM
These are couple of High Resolution
Images from Russian Meteor M-2 Satellite transmitting at 137.1 Mhz.
LRPT (Low Rate Picture Transmission) is about 12 times more in
resolution than the APT (Automatic Picture Transmission) transmitted
by USA's NOAA satellites. So we get to see a larger image. There is
nothing much to talk about as far as rain is concerned from todays
two images. Chennai and Tamil Nadu will be Sunny and hot throughout
the day.
Image on the left is called vegetation enhancement - Shows clearly
forest (vegetation) distribution in India. You can clearly see how
green Kerala is, with its western ghats mountains clearly seen.
You can also spot few rivers - Cauvery, Mettur Dam etc. The haze
just to the right of east coast is due to the reflection from the
Sun on Sea water as seen by the satellite! Click on the pictures to
see the high resolution images. Enjoy. Next forecast tomorrow.
|
|
September 18, 2015 at 05:30PM
Bombay and Calcutta are getting it! Next 2 days it will be raining
in Bombay. Calcuta will be receiving substantial rain tonight.
Possiblity of heavy rains in Chennai and Tamil Nadu tomorrow - day
after. Till that time, humidity will reach high levels and lot of
discomfort due to heat. |
|
September 17, 2015 at 09:25 AM
On the Right, is today's image from the
Russian Meteor M-N2 Satellite received right here at my station.
Click the picture to see a high resolution image. Clearly shows the
spiraling monsoon cloud, perhaps the first one in this NE monsoon
season. Seems to have crossed Andhra Coast as I mentioned in my
previous post. Chennai and Tamil Nadu will remain sunny mostly today
while Kerala and mid part of India will receive thunder showers.
|
|


Researcher Lorain:
Sometimes I question my decision to start collecting coins. Many people have made their families destitute with this collecting business.
But once you get started it's hard to stop. I have heard that my personality changes when I trade coins. What do you wish to trade with? These are the coins I have. I mainly trade mine for coins of the lowest grade.
Gold Knight
Silver Golem
Blood Drevanul
Nia's Gold Wyvern


Sindh govt decides to launch ‘war against stray dogs’
by Staff ReportKARACHI: The Sindh government on Thursday finally decided to launch a war against stray dogs, after an uproar over increasing deaths from dog-bite incidents in the province.
The decision was taken from the provincial local government department. The project named ‘War against stray dogs’ will emphasize on training staffers of the local councils to capture and sterilize the stray dogs.
Several non-governmental organizations will also be part of the project and would provide funding and technical assistance required for the campaign.
Divulging details of the project, Secretary Local Government Roshan Ali Shaikh said that the province is going to launch a comprehensive plan against stray dogs.
“We will be adopting procedures followed in the modern world to counter stray dogs,” he said.
According to Sindh Health Minister Azra Pechuho, over 92,000 dog bite cases have been reported across Sindh thus far this year.
Around seven dogs attacked a child in the north-west city of the Sindh province, Larkana, inflicting severe injuries at the face.
The incident was reported at Otha roundabout in Larkana. The boy was initially taken to the Chandka Medical Hospital in Larkana, a city that also happens to be a stronghold of the ruling party in Sindh, Pakistan People’s Party.
However, the doctors at the hospital refused to treat the child due to severe injuries and asked the relatives to take him away to any hospital in Karachi, capital of the province and around 450 kilometres away from Larkana.
The boy is undergoing treatment at National Institute of Child Health (NICH) in Karachi and his condition is said to be improving after a 10-member doctors’ body is taking care of him on the directives of provincial authorities.


{{- partial "summary_tags.html" . -}}
{{ .Content | safeHTML }}
{{- partial "syndication.html" . -}}
If you liked this article,
please share it on
{{- partial "syndication.html" . -}}{{ define "more_head"}} {{ $image := .Resources.GetMatch "{cover.jpg,cover.png,cover.jpeg}"}} {{ end }} {{ define "main"}}
If you liked this article,
please share it on
{{- partial "syndication.html" . -}}


Emails
Please verify an email address to collaborate on GitHub, receive notifications, and help us protect your account.
-
<EMAIL_ADDRESS>– Primary- Unverified
- Not visible in emails
- Receives notifications
Email preferences
Looking for activity notification controls? Check the Notification center.


<lq>
The <lq>
is used to provide extended content quoted from another
source. Use the quote element <q>
for short, inline quotations, and long
quote <lq>
for quotations that are too long for inline use, following
normal guidelines for quoting other sources. The @href
and
@keyref
attributes are available to specify the source of the quotation.
The <longquoteref>
element is available for more complex references to
the source of a quote.
Category: Body elements


This package contains helper classes for implementing Radius clients and servers.
The class RadiusClient can be used to send Radius packets to a Radius server.
The class RadiusServer must be subclassed in order to implement a Radius server.


Account Verification
Thanks {{ body.fullname }}, for choosing ..., please click on the link below to verify your account
Verify your email
If you did not register for ..., please kindly ignore this email and nothing will happen. Thanks