The ThreeTen library is available as backport for Java 6 and Java 7: http://www.threeten.org/threetenbp/

We should use this one instead of the current local JSR-310 library. This will also prevent a namespace issue when running the narwhal under Java 8 where the 'javax.time' classes were included in the JDK.

Looking at this dictionary file it seems the processor is case-insensitive, but not accent (¨^´ etc) and hyphen (- –) agnostic.

I think it should be, otherwise a lot of time will be invested in creating dictionaries that can handle all cases, while the processor can do this easily.

This is sensible:

REGION DE BRUXELLES CAPITALE    BRU
REGION DE BRUXELLES CAPITAL BRU
REGION BRUXELLES CAPITALE   BRU
REGION BRUXELLES CAPITAL        BRU
BRUXELLES   BRU
BRUXELLE    BRU

This is not:

RÉGION DE BRUXELLES-CAPITALE   BRU
REGION DE BRUXELLES-CAPITALE    BRU
RÉGION DE BRUXELLES CAPITALE   BRU
REGION DE BRUXELLES CAPITALE    BRU
RÉGION BRUXELLES-CAPITALE  BRU
REGION BRUXELLES-CAPITALE   BRU
RÉGION BRUXELLES CAPITALE  BRU
REGION BRUXELLES CAPITALE   BRU
etc.

If the narwhal can already deal with this: great! But then we should update the documentation and only use uppercase, no accents, and no hyphens in our dictionaries.

Check if a scientific name is validly formed according to the specified rules of nomenclature (eg ICZN, ICNafP).

Use GeoTools library to support more coordinate system conversions.

Feeback for https://github.com/Canadensys/narwhal-processor/wiki/Building-a-semantic-web-based-country-list

The processor should be able to reconize months at least in English, French and Spanish.

A method to add addional Locale should be available.

In which maven repository are you publishing the narwhal artifact please?
Or perhaps people just check it out and install locally?

If you are in need of a repository, Canadensys are welcome to use http://repository.gbif.org/ for their artifacts.

Hi i'm using your API for coordinate conversion, and i couldn´t find more info about the geodetic Datum of this tool, it would be nice if you can add a field with this info... i guess is WGS84 or EPSG:4326.

Thank you for your answer

This would be used to allow translation of error messages returned by the narwhal.

This would be done using PostGIS and one or more shape file.
Possible shape files:

• http://www.naturalearthdata.com/
• http://www.diva-gis.org/gdata

We should get at least stateProvince, country and continent as result.
Still TBD for a waterbody.

We do not plan to use an external service due to the limit of request we can do.

Would be interesting to expand the narwhal to be able to build an up-to-date and well-maintained knowledge base of country names, their alternative representations (possibly multilingual) and mappings to known misspellings using linked open data (semantic Web).

This could be done using a semantic Web URI.
Something like : http://dbpedia.org/page/Category:Member_states_of_the_United_Nations

A country could than be identified with a URI such as http://dbpedia.org/resource/Canada
The name of a country in different languages could populated using "owl:sameAs".
The known misspellings could be handle using SKOS.

For performance reasons, we'd like this thesaurus to be embedded in the library, but with the capacity to be periodically refreshed with data pulled from external resources (like it's currently the case through the gbif-parser).

Benefits:

• Different labeling used for this concept (see rdfs:label
  http://dbpedia.org/page/Canada) in different languages.
• Recognize a country name in a different language vs a typo to not report
  country name in different languages as error
• Information about where it is, without any geopetial query, (ex.
  continent, hemispere)
• Opens the door for validation using the date. (think Russia, USSR)
• Use semantic web standards allowing biodiversity application to benefits from it in a near future.
• Same concept can be expanded to states, provinces and municipalities

After testing some usage scenarios for this library, I came to the conclusion that processBean() functions should be delegated to the user of the library and should not included in the core library. It makes intermediate steps less efficient (e.g. clean string before processing).

11-12-2012 could be a little-endian date (11 december) or a middle-endian date (12 november) and is thus dubious.

Currently, the parser returns nothing for these dates, but the year can be unambiguously determined: 2012.

Improve regex to include more characters that could be used to flag 'minute' and 'second' in DDMMSS coordinates notation.

minutes[‘'’‛]
seconds ("|“|''|‛‛|‟|”|‘‘|’’)

Provided by David Fichtmüller

e.g. N45 30.361, W73 36.947

SLF4J or log4j directly

Currently, the narwhal-processor returns results for coordinates like
45° 332' 255" N, 129° 410' 311" W.

This is incorrect, mm and ss should be >=0 and ­< 60.

ISO 8601 Date Interval : 2007-03-01/2008-05-11

This new processor should extends the NumericPairDataProcessor and add boundaries validation.