Software Architecture of the Bernstein Atlas service

This document details the software architecture of the Bernstein Atlas service and the elements required to make it function. The homepage of the Bernstien GIS services is here and the prototype Atlas here in ArcGIS 9.3 JavaScript API version and here in ArcGIS WebServer 9.2 version.

Some information on this page might be outdated. Please refere to this page for the latest version.

Architecture

The following figure provides a graphical summary of the architecture of Bernstein geographical service.

Extended view:

Compact view:

Elements

Databases - The databases contain georeference information to the papers and watermarks records. They are configured to interact with the Workspace.

Workspace - In the Workspace users construct requests on the data available in the databases. The Workspace software forwards the requests to the databases and displays the output. It also access georeference information, prepares and manage it for use by the Atlas.

Atlas data - There are three types of data that the Atlas consumes: dynamic data originating in databases as provided by the Workspace search engine, static data generated by project Bernstein but not part of the integrated databases, data from the Web.

Atlas interface - The Atlas interface displays maps of the Atlas data and gives users tools to interact with it. It is driven by webbrowsers and consists in html layouts, css stylesheets and JavaScript scripts.

GIS server - The GIS server generates maps to display in the webbrowsers based on the Atals data and users settings.

Third parties - The Bernstein Atlas has the ability to use geographical information generated by entities outside the project itself. Also, third parties can in turn use in their own mapping services datasets originating in the project.

Workflow

The Atlas service can be accessed - from the search interface of the Workspace - from the Atlas page itself - from outside the Bernstein project

User perspective

In the first scenario - search interface to Atlas - the user is initially on the Bernstein search interface of the Workspace, constructs a search request, the Workspace software generates the reply and provides a link to the Atlas. The user clicks on the link and a new webpage is generated where he can see a geographical mapping of the results. There he also finds tools to modify the map or add new maps.

In the second scenario - Atlas to search interface - the user can select datasets for mapping among those provided by the integrated databases, those outside them or those of third parties on the Web. If he chooses the integrated databases datasets, a link will bring him on the search interface, where he constructs a query after which a link will bring him back to the Atlas page where the results are mapped.

In the third scenario - third party to Bernstein - the user can either map Bernstein static datasets by simply selecting them in the list provided by the service he uses, or be linked to the Bernstein Workspace search interface to construct a query, then prompted to go back to the initial service to map the results.

Software perspective

Search interface side

For each request the search interface software generates a unique set of files containing the results. A subset of these provides the data processed for consumption by the Atlas. The location of the geographical file is made aware to the Atlas software by embedding it in the link on which the user will click to access the Atlas.

Dynamic link encoding

Lets take a look at the link to be encoded in the search interface webpage once the response to the user's request is ready.

<a name="BernsteinAtlasLink" href="http://www.viskom.oeaw.ac.at/~vlad/atlas/online/
atlas/atlas.html?url=http://www.viskom.oeaw.ac.at/~vlad/atlas/online/atlas/data/static/
geo_default.jsonp" target="_blank">Show Map</a>

You see that the link contains the URL http://www.viskom.oeaw.ac.at/~vlad/atlas/online/atlas/atlas.html - this is the Bernstein Atlas webpage (the URL given here is not the final one, just that of the development phase of the project). After a question mark follows the URL of the geographical file produced by the Workspace search interface. Several files can be referenced separated with 'and' symbols &. These locations have to be accessible on the Web. More about the file itself in the Datasets section further down.

Note that target="_blank" will make the Atlas appear in a new page. It enhances the 'real estate' where the map will be deployed and separates the Atlas software from that of the Workspace for easiness of development and portability.

Because the link is referenced by a name - name="BernsteinAtlasLink" - it makes it possible to third parties to consume in their own environments the geographical results of a search done with the Bernstein interface.

A similar link can be embeded in a button.

<form name="BernsteinAtlasLink" action="http://www.viskom.oeaw.ac.at/~vlad/atlas/online/
atlas/atlas.html?url=http://www.viskom.oeaw.ac.at/~vlad/atlas/online/atlas/data/static/
geo_default.jsonp" method="post">
<input type="submit" value=" Show results ">
</form>

File naming

There is no requirement set on the naming of geographical files. The following format is however suggested.

Format: geo_<unique file id>.json
Example: geo_wxcvqsdf.jsonp

The prefix geo indicates a geographical content; the id keeps the file distinct from others at the same location; the extension jsonp specifies the content as JSONP formatted, which is the standard used by the Atlas software for information interchange.

Storing location

No requirement other than the location should be readable form the Web. A convenient location to store all datasets intended for consumption by the Atlas is the directory <atlas software location>/data/dynamic/, where <atlas software location> is the URL of wherever the Bernstein Atlas will be stored. Presently this is http://www.viskom.oeaw.ac.at/~vlad/atlas/online/atlas/.

Cache cleaning

With every request made to the search interface resulting in maps, the geographical files produced by the Workspace accumulate. A mechanism has to be put in place to clean the files that are deemed not to be used by users anymore. Time lapses seem appropriate to the kind of website that is Bernstein. Files could deleted 24 hours after their creation.

Atlas interface side

When the Atlas webpage is uploaded in a webbrowser the URL content of the link on which the user has clicked to arrive at the Atlas is forwarded to the webbrowser. The Atlas software reads it and extracts from it the location of the file containing the georeferences data to map. This information exchange is sufficient to the Atlas software to start provide Bernstein users with GIS services. URLs to datasets of third parties are hard coded in the JavaScripts of the Atlas software. The files themselves are read as JavaScript files, who's URL is dynamically written in the HTML after reading it from the URL of the HTML. (Note: Local files - but not cross-server files - could be read via XMLHttpRequest.)

GIS server side

Mapping service by Bernstein is based on ArcGIS products ArcGIS Desktop, Server and JavaScript API. While waiting to upgrade from version 9.2 to 9.3, released during summer 2008, the ESRI company's free server services are used.

Prior to the release of the JavaScript API we experimented with the WebSever 9.2. The results presented here show that:

• interaction on the website is slow
• the conceptual architecture of the website is rigid
• extensive coding is needed for managing the website
• communication procedures with the Workspace is not yet solved
• the tool for producing density maps is readily implementable

Third party side

If a dynamically file generated by the Bernstein search interface wants to be used by third parties its location can be automatically found with a JavaScript code that scans the search webpage for the name of the link - BernsteinAtlasLink - and extracts the URL from the content of the link. A demonstration page shows the code in action.

The URLs and description of the static datasets served by Bernstein are given on the Atlas page.

Summary

In short communication between elements of the geographical service is happening by having the Workspace passing to the Atlas the locations of geographical files through links embedded in the search webpage and the URLs they contain. Third parties get the same information by parsing the search webpage for these links tagged with know names.

Datasets

Follow the requirements set on the dataset files.

Files

• Naming - See the the 'File naming' section further up.
• Encoding - Plain text files, encoded according to Unicode UTF-8.
• Formatting - Content formatted following the JSON standard. The standard is described in JSON RFC-4627 and a short description of how JavaScript is used to read JSON files in webbrowsers given here. JSON is a relatively new data interchange format expected to concurrence XML. It is simple, light and human readable. In the context of the ArcGIS GIS software used by Bernstein, JSON is the standard adopted by the ArcGIS 9.3 JavaScript API.
• Padding - In order to make the JSON data readable from any server, its content is padded with a JavaScript function name. The file content will look like this: "jsondata( [... JSON data ...] )".
• Fields - Containg the fields shown below. The fields of records are discussed in greater detail in DALEK. Georeferences for the Bernstein Paper Atlas.
• Content - Georeferences to records in the Bernstein databases are provided by project partner LAMOP to partners KB, LABW, NIKI and OEAW for inclusion in their databases. These georeferences provide a unified medium for GIS services by the Bernstein project. Georeferencing in Bernstein is also described in the Dalek documentation.

Content

padding - Needed to make the content readable to the JavaScript program. The padding enclosing the JSON content must be "jsondata( [... JSON data ...] )".

header - Gives information about the file content and media. The terminology follows the recommendation of the Dublin Core Metadata Initiative (v2008.01.14). This header is reusable for of the search results file that can be downloaded by Workspace users.

• content - Class of fields describing the file content.
  • title - Description that can be placed on a map as its title.
    • For files generated by the search page of the Workspace ("dynamic files") the title has a set value. For other files ("statics files"), such as the contextual dataset on plague, the value of this field might be different from dataset to dataset.
    • dynamic value: Places of paper use from a selection in the Memory of Paper databases
    • static example: Places of plague occurencies in Europe, 1347-1600
  • abstract - A more detailed description than given in the title.
    • dynamic value: These locations represent places where papers where used, like handwritten or printed, as it results from historical analysis, mostly from inscriptions on the papers. The source are the databases connected to the Memory of Paper website, according to search criteria provided by the user.
    • static example: Locations showing the extent of plague epidemics in Europe during the Late Middle Ages and the Renaissance.
  • subject - Keywords to the content.
    • dynamic value: history, paper studies, watermarks, georeferences
    • static example: history, plague, epidemics
  • source - The source(s) from which the georeferences are extracted.
    • dynamic value: Project Bernstein: The Memory of Paper, http://www.memoryofpaper.eu
    • static example: Jean-Noël Biraben, Les Hommes et la peste en France et dans les pays européens et méditerranéens, Paris/La Haye, Mouton/École des hautes études en sciences sociales, 1975-6.
  • creator - The creator(s) of the file content.
    • dynamic value: Project Bernstein: The Memory of Paper, http://www.memoryofpaper.eu
    • static example: Vlad Atanasiu, Claire Priol, Anne Tournieroux, Ezio Ornato
  • publisher - The publisher(s) of the file content.
    • dynamic value: Project Bernstein: The Memory of Paper, http://www.memoryofpaper.eu
    • static example: Project Bernstein: The Memory of Paper, http://www.memoryofpaper.eu
  • created - Date the file content was created.
    • dynamic value: [generated at the creation of the file]
    • static example: 2008.08.14
  • rights - Legal right terms and rights holder.
    • dynamic value: Project Bernstein: The Memory of Paper, http://www.memoryofpaper.eu
    • static example: Project Bernstein: The Memory of Paper, http://www.memoryofpaper.eu
• criteria - These fields are used in the case that the dataset represents a selection in a bigger one, such as an answer to a request in a database. The criteria used to define the selection are documented here. As an example are provided the criteria used by the Bernstein website, but the user can add any content to the field "criteria". Multiple entries are separated by comma ( , ).
  • databases - Names of the databases in which the search was conducted (checkboxes checked in the search interface). Ex.: NIKI, POL, WILC, WZMA
  • hits - Number of hits for the search. Ex.: 2496
  • term - Search term. Ex.: Ochsenkopf, Meerjungfrau
  • motif - Name of th watermark motif. Ex.: Adler
  • dateStart - Start of a date range. Ex.: 1450
  • dateEnd - End of a date range. Identical to dateStart or empty to denote a single year. Ex.: 1500
  • depository - Name of the depository holding the records. Ex.: Gdansk AA
  • height - Watermark height. Ex.: 5
  • heightTolerance - Tolerance around given value. Ex.: 1
  • measurementUnit - Unit of measure. Ex.: cm
  • chainLines - Distance between chain lines. Ex.: 3
  • chainLinesTolerance - Tolerance around given value. Ex.: 0
  • laidLines - Density of laid lines. Ex.: 20
  • laidLinesTolerance - Tolerance around given value. Ex.: 0.3
  • laidLinesUnit - Unit of laid lines density measurement. Ex.: mm / 20 laid lines
  • useplace - Place of paper use. Ex.: Rome
  • useplaceStatus - Status of the useplace. Ex.: localities, localities and regions
• spatial - Fields expliciting the spatial information contained in the file.
  • coordinates - Coordinates format. Ex.: decimal [default value in Bernstein]
  • nomenclature - Naming system used for the names of regions. Ex.: NUTS 2003 [default value in Bernstein]
• media - Information on the medium containg the content.
  • encoding - File encoding. Ex.: UTF-8 [default value in Bernstein]
  • format - Data structure format. Ex.: JSON [default value in Bernstein]
• extra - Additional data deemed of interest to be displayed in the Atlas.

items - Contains information about each location. With the exception of the 'records' field these are extracted from the data providers. 'Records' is computed by the Workspace.

• status - Geometry of the place: point or surface. Ex.: locality, region
• placename - Normalized name of the place as given in Dalek. Ex.: Roma (normalization of "Rome, Rom, ..."), Liguria (normalization of "Ligurien, ...")
• latitude - Latitude expressed in decimal degrees. Ex.: 41.90
• longitude - Longitude expressed in decimal degrees. Ex.: 12.48
• regionId - Region code according to NUTS 2003 standard (see references below). Ex.: ITE43, ITC33
• country - Country in original spelling. Ex.: Italia, Italia
• region1 - NUTS level 1 region name. Ex.: Centro (I), Nord-Ovest
• region2 - NUTS level 2 region name. Ex.: Lazio, Liguria
• region3 - NUTS level 1 region name. Ex.: Roma
• region4 - NUTS level 1 region name.
• records - Quantity of records in the current location. Ex.: 1248, 256
• extra - Additional data deemed of interest to be displayed in the Atlas.

Example - source: http://www.viskom.oeaw.ac.at/~vlad/atlas/online/atlas/data/static/geo_default.jsonp

jsondata(
{"header":   {
   "content":   {
      "title":   "The members of Project Bernstein: The Memory of Paper",
      "abstract":   "The list of Project Bernstein members with their respective contributions.",
      "subject":   "history, paper studies, watermarks, georeferences",
      "source":   "Project Bernstein: The Memory of Paper",
      "creator":   "Project Bernstein: The Memory of Paper",
      "publisher":   "Project Bernstein: The Memory of Paper, http://www.memoryofpaper.eu",
      "created":   "2008.11.11 12:59:59",
      "rights":   "Project Bernstein: The Memory of Paper, http://www.memoryofpaper.eu"
   },
   "criteria":   {
      "databases":   "",
      "hits":   "",
      "term":   "",
      "motif":   "",
      "dateStart":   "",
      "dateEnd":   "",
      "depository":   "",
      "height":   "",
      "heightTolerance":   "",
      "measurementUnit":   "",
      "chainLines":   "",
      "chainLinesTolerance":   "",
      "laidLines":   "",
      "laidLinesTolerance":   "",
      "laidLinesUnit":   "",
      "useplace":   "",
      "useplaceStatus":   ""
   },
   "spatial":   {
      "coordinates":   "decimal",
      "nomenclature":   "NUTS 2003"
   },
   "media":   {
      "encoding":   "UTF-8",
      "format":   "JSON"
   },
   "extra":   ""
},
"items":   [
{
   "status":   "locality",
   "placename":   "Stuttgart",
   "latitude":   "48.77",
   "longitude":   "9.18",
   "regionId":   "DE111",
   "country":   "Deutschland",
   "region1":   "Baden-Württemberg",
   "region2":   "Stuttgart",
   "region3":   "Stuttgart, Stadtkreis",
   "region4":   "",
   "records":   "90000",
   "extra":   "<a href='http://www.piccard-online.de/'>Archives of the State of Baden-Wuerttemberg</a>: data provider"
},
{
   "status":   "locality",
   "placename":   "Den Haag",
   "latitude":   "52.08",
   "longitude":   "4.30",
   "regionId":   "NL332",
   "country":   "Nederland",
   "region1":   "West-Nederland",
   "region2":   "Zuid-Holland",
   "region3":   "Agglomeratie &#8217;s-Gravenhage",
   "region4":   "",
   "records":   "16000",
   "extra":   "<a href='http://www.kb.nl/'>Koninklijke Bibliotheek</a>: data provider"
},
{
   "status":   "locality",
   "placename":   "Wien",
   "latitude":   "48.21",
   "longitude":   "16.37",
   "regionId":   "AT130",
   "country":   "Österreich",
   "region1":   "Ostösterreich",
   "region2":   "Wien",
   "region3":   "Wien",
   "region4":   "",
   "records":   "8000",
   "extra":   "<a href='http://www.oeaw.ac.at/'>Austrian Academy of Sciences</a> (<a href='http://www.viskom.oeaw.ac.at/'>VISKOM</a>, <a href='http://www.ksbm.oeaw.ac.at/'>KSBM</a>): coordinator, data provider, GIS, image processing"
},
{
   "status":   "locality",
   "placename":   "Firenze",
   "latitude":   "43.77",
   "longitude":   "11.25",
   "regionId":   "ITE14",
   "country":   "Italia",
   "region1":   "Centro (I)",
   "region2":   "Toscana",
   "region3":   "Firenze",
   "region4":   "",
   "records":   "4000",
   "extra":   "<a href='http://www.iuoart.org/'>Dutch University Institute for Art History Florence</a>: data provider"
},
{
   "status":   "locality",
   "placename":   "Leipzig",
   "latitude":   "51.30",
   "longitude":   "12.33",
   "regionId":   "DED31",
   "country":   "Deutschland",
   "region1":   "Sachsen",
   "region2":   "Leipzig",
   "region3":   "Leipzig, Kreisfreie Stadt",
   "region4":   "",
   "records":   "",
   "extra":   "<a href='http://www.ddb.de/'>German National Library</a>: bibliographical data provider"
},
{
   "status":   "locality",
   "placename":   "Paris",
   "latitude":   "48.87",
   "longitude":   "2.33",
   "regionId":   "FR101",
   "country":   "France",
   "region1":   "Île-de-France",
   "region2":   "Île-de-France",
   "region3":   "Paris",
   "region4":   "",
   "records":   "",
   "extra":   "<a href='http://lamop.univ-paris1.fr/W3/'>National Center for Scientific Research / University Paris 1</a>: GIS, contextual data provider"
},
{
   "status":   "locality",
   "placename":   "Graz",
   "latitude":   "47.07",
   "longitude":   "15.45",
   "regionId":   "AT221",
   "country":   "Österreich",
   "region1":   "Südösterreich",
   "region2":   "Steiermark",
   "region3":   "Graz",
   "region4":   "",
   "records":   "",
   "extra":   "<a href='http://www.tugraz.at/'>Graz University of Technology</a>: integration"
},
{
   "status":   "locality",
   "placename":   "Liverpool",
   "latitude":   "53.42",
   "longitude":   "-3.00",
   "regionId":   "UKD52",
   "country":   "United Kingdom",
   "region1":   "North West",
   "region2":   "Merseyside",
   "region3":   "Liverpool",
   "region4":   "",
   "records":   "",
   "extra":   "<a href='http://www.liv.ac.uk/'>University of Liverpool</a>: integration"
},
{
   "status":   "locality",
   "placename":   "Delft",
   "latitude":   "52.00",
   "longitude":   "4.37",
   "regionId":   "NL333",
   "country":   "Nederland",
   "region1":   "West-Nederland",
   "region2":   "Zuid-Holland",
   "region3":   "Delft en Westland",
   "region4":   "",
   "records":   "",
   "extra":   "<a href='http://ict.ewi.tudelft.nl/'>Delft University of Technology</a>: image processing"
}
]})

Implementation requirements

The following lists the requirements set by the Bernstein geographical service on the databases, Workspace, Atlas and third parties.

Databases

The databases owners need to:

1. obtain the georeferences file Dalek from here and the accompanying documentation
2. add to their databases the content of the following fields. The entries relevant to each database are marked with a 'x' in the columns named with the acronyms of the databases as described in the Dalek description document. The utility of each field is given in parenthesis.
   1. status (necessary to filter out unidentified locations and regions by the coordinates of a single locality within the region)
   2. original placename - doesn't need to be added, exists by default in each database, only access to this field for the Bernstein Workspace has to be provided
   3. normalized placename (provides consistency within the databases connected to the Workspace)
   4. latitude (imperative to produce maps)
   5. longitude (idem)
   6. region id (provides faster region identification)
   7. NUTS1 region name (provides a mean to search paper and watermarks records by regions of occurrence)
   8. NUTS2 region name (idem)
   9. NUTS3 region name (idem)
   10. NUTS4 region name (idem)
3. make these fields available for query over the Internet to the Workspace software
4. consider if the use of region codes instead of region names for data search and transfer is a welcome solution given the drawbacks detailed in the section 'Region codes usability' below

Workspace

The Workspace developers need to:

1. ensure the georeferences fields required for addition to the databases (see paragraph before) are accessible to the Workspace
2. within the Workspace search pages provide users with the ability to select data by
   1. original placenames
   2. normalized placenames
   3. region names: country and NUTS1-4 names
3. remove from the results of searches entries with status "not identified" and "ambiguous" (these can't be evaluated for statistics or mapping since no coordinates or region names have been attributed to them, they just make the file sizes bigger)
4. sort the records in descending order according to the number of records per location (this is needed because bigger location symbols on the map have to be drawn first, with smaller ones on top of them, so as to keep all locations visible)
5. add for each location the number of records in field items.records
6. add header information:
   1. read the header template from the URL ≶path>/data/header.json (during the development period ≶path> is http://www.viskom.oeaw.ac.at/~vlad/atlas/online/atlas/).
   2. add the date of the file creation in field header.content.created
   3. fill in the fields of fields class criteria with the information derived from the search criteria of the Workspace search page, following the scheme described above in "Datasets > Content"
7. save the data as files with unique names ...
8. ... in a location accessible over the Internet
9. append links to the files on the Workspace search page as detailed above in "Workflow > Search interface side"
10. implement a clearing mechanism for expired files
11. consider if the use of region codes instead of region names for data search and transfer is a welcome solution given the drawbacks detailed in the section 'Region codes usability' below

Atlas

The next steps in developing the Atlas service and the known bugs are detailed here.

Third parties

To consume static datasets thrid parties have to:

1. copy the URLs of datasets as given in the list of available Bernstein datasets at either the Atlas or the Bernstein's GIS services homepage
2. use these URLs in whatever software the third party is using

To consume dynamic data generated by the Workspace as a result of a search on the integrated databases:

1. modify the button that generates the map so that it reads the URL of the Bernstein dynamic datasets when the user has choosen to map Bernstein data. An example of how this can be implemented in HTML and JavaScript is provided here (open the file to see the code).
2. instruct the users to perform the search in the Bernstein Workspace...
3. ... and once the search is performed, come back on the third party's website
4. and click the appropriate button for generating the map

Region codes usability

Relying on the region codes instead of region names for making request to the databases, searching teh databases and ultimately transferring the results back to the workspace is a good idea with the potential to get the results quicker to the user. However it has a fundamental impediment. Lets see first the details of the scenario, the analyze the flaw.

Idea - The idea is to look up the codes of the region names selected by the user and query records from the databases with the region codes instead of the region names. In turn the databases will send back only the region codes and the Workspace will reconstruct the region names from the codes using the lookup table. The NUTS nomenclature table is found here.

Drawback - The use of region codes relies on the assumption that the length of the code is proportional to the degree of detail specified by the NUTS (see next paragraph). However it was not possible to find the codes for all location, if they exist at all. While Europe is fairly well described by NUTS, most non-European states are referenced in the georeferences of Bernstein by only the code of the country, even if the names for lower region level is provided. This leads to such a case as a code 'US' from which it is impossible to know if the location 'Washington' is in the Washington state or the District of Columbia. Coverage of non-European states is essential to Bernstein: many records on paper use reference locations in Eastern Europe, an important amount of repositories are outside Europe (especially in WILC and the additional datasets of ISTC and GW), and a substantial proportion of the bibliography locations are scattered worldwide.

Solution - A solution would be that if the code is only two-digits long, referencing only the country, then information is passed from the Workspace to the databases with the full name of the region instead of just the code. The databases have to implement a software procedure to deal with this modality. Is this software complication worth the trouble and does it speed data processing?

Code structure - Note the formation of the codes: two-digits country code + one digit nuts1 name + one digit nuts2 name + one digit nuts3 name + one digit nuts4 name. For example DEA21 stands for 'Deutschland > Nordrhein-Westfalen > Köln > Aachen, Kreisfreie Stadt'. Since the region is defined only down to the NUTS3 level, the code is also only five digits long. An alternative variant to note the level of detail is to use zeros for not defined NUTS levels. 'Deutschland' can be thus rendered as 'DE' or 'DE000'. Software developers should be aware of this variation.

NUTS evolution - The NUTS is an evolving entity, changing every couple of years according to changes in the territorial organization of countries or demographic modification (since NUTS are essentially means for uniform demographic statistics). For Bernstein we choose the NUTS nomenclature of year 2003, the lasts for which polygon coordinates defining the regions contours can be provided (they are included in ArcGIS). Polygons allow to select data without the need to know the names of the regions that are to be selected. Data selection geoprocessing are easier, more flexible and more powerful.

References

Bernstein Atlas

• Bernstein Geographical services homepage
• Prototype Atlas with JavaScript API technology
• Access to the prototype from a dummy replica of the Workspace
• Prototype Atlas with ArcGIS Server 9.2

Bernstein georeferences

• Bernstein georeferences - the Dalek file
• Dalek documentation
• Bernstein GIS georeferencing and visualization tools

NUTS

• Concise description of what NUTS are: deutsch, english, français
• Official NUTS webpage
• NUTS regions maps
• NUTS 2003 nomenclature

JSON, JSONP, XMLHttpRequest, Dublin Core

• JSON RFC-4627
• Reading JSON files with JavaScript
• JSONP: Reading JSON data cross-domain
• The future of cross-domain JSON reading: JSONRequest
• About XMLHttpRequest
• Dublin Core Metadata Initiative Terms

ArcGIS

• ESRI products: ArcGIS overview, ArcGIS JavaScript API

-- VladAtanasiu - 15 Nov 2008