European Climate Forum - Harrys Club

 
You are not logged in.
LoginLogin Join for freeJoin for free
MessagesMessages MembersMembers SearchSearch HelpHelp
VotesVotes FilesFiles CalendarCalendar BookmarksBookmarks
Harrys Club - Venice Meeting (copy of email from 2004-01-19)

First   Previous   Next   Last
Author Message
Marcel Endejan
Guest
New PostCreated: 2004-02-20, 05:52 PM CET  Subject: Harrys Club - Venice Meeting (copy of email from 2004-01-19)  print  print thread  recommend Reply with Quotation  

(this is a copy of my email to the venice-meeting participants)
(just to enliven the discussion a bit...)

Dear 'Club Members',

during and after the very interesting meeting in Venice I got some ideas I'd like to share with you.
Since the focus of my work in Kassel is on integrated dynamic models and I'm not very familiar with modelling of the economy, I'd like to give some remarks about some technical things.

[using standards]
There are so many problems occuring not only in one but in almost every institution. The coupling of simulation models is only one example, documentation and the need of software to convert between data formats are just two additional ones. In these fields it would be helpful to use already established or upcoming standards.

[coupling simulation models]
For coupling dynamic simulation models the so-called 'high level architecture' (HLA) becomes more and more important in many application areas. Unfortunately, this architecture is not yet established in integrated models or in other models dealing with the natural/social/economic environment. From my point of view there are big potentials for increasing the re-usability of simulation models in using the HLA. These potentials would be worse to investigate and discuss.

[different resources]
Simulation models should not be the only 'resource' to share with other club members. The main resources may be software, documents and data. Software includes simulation models, tools, programming libraries. Documents include program documentations, reports, papers. And data resources include base data for models such as GDP, climate, population and land use data etc. and model outputs.

[metadata]
To enhance the re-usability of such resources it is not sufficient to provide the resources but they have to came along with appropriate metadata. I think the metadata topic is very important in the current stage of the club since it allows us to get an overview what models and data are available in the club's 'resource pool'.

[metadata standards]
The metadata topic in general and the question which attributes (elements) should be used to describe a resource are still under discussion within the metadata community. But there are some standards becoming more and more common. One of these standards is the ISO 19115 -- Geographic Information Metadata (also available as OpenGIS specification -- topic 11). This standard could serve as a guiding principle for describing data.
Another promising standard is the 'Content Standard for Computational Models', which is a result of the 'Alexandria Digital Earth Prototype (ADEPT)' project at the University of California. This standard could serve as a basis for describing the club's simulation models.

[basic metadata]
As a minimum set of metadata at the Center for Environmental Systems Research in Kassel I have introduced the so-called Dublin-Core Metadata Element Set (DCMES). DCMES describes a resource by the following 15 elements:
Title, Creator, Subject, Description, Publisher, Contributor, Date, Type, Format, Identifier, Source, Language, Relation, Coverage, Rights.
A short description of the element's meaning can be found at the end of this mail.
From my experience this set is good enough to give the basic information about a resource (answers to the questions: Is there a certain resource? Where is the resource? Where can I get the resource? Where can I get more information about the resource?). It doesn't cost much effort to fill in the 15 elements for each resource -- this is very important because it doesn't make sense to provide a very detailed standard (like the mentioned ISO 19115 with about 400! elements) when nobody will find the time to fill in all the elements.
As a first step to vivify the exchange of resources I'd suggest that Harrys Club web page should:
- provide a minimum set of metadata for each resource in our pool
- provide a database with all the metadata and a tool to create and search entries

Programming a first web-based metadata-database using DCMES was a part my PhD thesis and if the Club is interested I'd provide some details on the implementation or the program code itself.

Also a result of my thesis was that an integrated model consists of more then just coupled simulation models. The main parts of an integrated model include moduls for data integration, documentation, simulation & scenario management, and a sound data base system. Unfortunately, the thesis is available only in German, but I'm currently preparing a paper in English about some main results. If anybody is interested in the German version or has some questions about that work, please don't hesitate to contact me!

[enhance share of information]
To all appearances, the club's web page and the discussion group is not (yet) used so much. To improve the information share the home page of the club could be enhanced by the following sources:
- Slides and other documents presented at the workshops
- Software (simulation models, tools, programming libraries etc.)
- Documentation of software
- Metadata on software and data

With this email I hope I can refresh our discussion started in Venice.

With this in mind, I'm looking forward to any response
Marcel

--------------------

Further information about the High Level Architecture:
- US Department of Defense: https://www.dmso.mil/public/transition/hla/

Further information about metadata:
- on ISO 19115: http://www.opengis.org/specs/?page=abstract (topic 11)
- on CSCM: http://www.dlib.org/dlib/june01/hill/06hill.html
- on DCMES:

----------------------
Dublin Core Metadata Element Set:
(source: http://dublincore.org/documents/dces/)

Title
Definition: A name given to the resource.
Comment: Typically, Title will be a name by which the resource is formally known.

Creator
Definition: An entity primarily responsible for making the content of the resource.
Comment: Examples of Creator include a person, an organization, or a service. Typically, the name of a Creator should be used to indicate the entity.

Subject
Definition: A topic of the content of the resource.
Comment: Typically, Subject will be expressed as keywords, key phrases or classification codes that describe a topic of the resource. Recommended best practice is to select a value from a controlled vocabulary or formal classification scheme.

Description
Definition: An account of the content of the resource.
Comment: Examples of Description include, but is not limited to: an abstract, table of contents, reference to a graphical representation of content or a free-text account of the content.

Publisher
Definition: An entity responsible for making the resource available
Comment: Examples of Publisher include a person, an organization, or a service. Typically, the name of a Publisher should be used to indicate the entity.
Element Name: Contributor

Contributor
Definition: An entity responsible for making contributions to the content of the resource.
Comment: Examples of Contributor include a person, an organization, or a service. Typically, the name of a Contributor should be used to indicate the entity.
Element Name: Date

Date
Definition: A date of an event in the lifecycle of the resource.
Comment: Typically, Date will be associated with the creation or availability of the resource. Recommended best practice for encoding the date value is defined in a profile of ISO 8601 [W3CDTF] and includes (among others) dates of the form YYYY- MM-DD.

Type
Definition: The nature or genre of the content of the resource.
Comment: Type includes terms describing general categories, functions, genres, or aggregation levels for content. Recommended best practice is to select a value from a controlled vocabulary (for example, the DCMI Type Vocabulary [DCT1]). To describe the physical or digital manifestation of the resource, use the FORMAT element.

Format
Definition: The physical or digital manifestation of the resource.
Comment: Typically, Format may include the media-type or dimensions of the resource. Format may be used to identify the software, hardware, or other equipment needed to display or operate the resource. Examples of dimensions include size and duration. Recommended best practice is to select a value from a controlled vocabulary (for example, the list of Internet Media Types [MIME] defining computer media formats).

Identifier
Definition: An unambiguous reference to the resource within a given context.
Comment: Recommended best practice is to identify the resource by means of a string or number conforming to a formal identification system. Formal identification systems include but are not limited to the Uniform Resource Identifier (URI) (including the Uniform Resource Locator (URL)), the Digital Object Identifier (DOI) and the International Standard Book Number (ISBN).

Source
Definition: A Reference to a resource from which the present resource is derived.
Comment: The present resource may be derived from the Source resource in whole or in part. Recommended best practice is to identify the referenced resource by means of a string or number conforming to a formal identification system.

Language
Definition: A language of the intellectual content of the resource.
Comment: Recommended best practice is to use RFC 3066 [RFC3066] which, in conjunction with ISO639 [ISO639]), defines two- and three-letter primary language tags with optional subtags. Examples include "en" or "eng" for English, "akk" for Akkadian", and "en-GB" for English used in the United Kingdom.

Relation
Definition: A reference to a related resource.
Comment: Recommended best practice is to identify the referenced resource by means of a string or number conforming to a formal identification system.

Coverage
Definition: The extent or scope of the content of the resource.
Comment: Typically, Coverage will include spatial location (a place name or geographic coordinates), temporal period (a period label, date, or date range) or jurisdiction (such as a named administrative entity). Recommended best practice is to select a value from a controlled vocabulary (for example, the Thesaurus of Geographic Names [TGN]) and to use, where appropriate, named places or time periods in preference to numeric identifiers such as sets of coordinates or date ranges.

Rights
Definition: Information about rights held in and over the resource.
Comment: Typically, Rights will contain a rights management statement for the resource, or reference a service providing such information. Rights information often encompasses Intellectual Property Rights (IPR), Copyright, and various Property Rights. If the Rights element is absent, no assumptions may be made about any rights held in or over the resource.
back to top
Sortierung ändern:  
First   Previous   Next   Last
Page 1 of 1
Search

powered by carookee.com - group communication for you