URI Guidelines

Deprecated. Please go to the Ontology Providers Guide for a more updated information

Definition

A URI or Unique Resource Identifier, is a Web naming/addressing technology that uses short strings to refer to resources in the Web. These resources could be Web Documents, services, electronic mailboxes, images, downloadable files etc. URI encompasses both URL (Universe Resource Locators) and URN (Uniform Resource Name). For more details, you may wish to visit W3G guidance about URIs, or the 2001 W3G recommendations on URIs, URLs, and URNs.

Advantages of URIs

Expressing vocabularies with URIs has the following implications:

• The vocabularies have an explicit reference for context. In the above example, temperature is not any kind of temperature, it is specified as the one published or described by the marinemetadata.org site in March of 2005. And type is the one published or described by the World Wide Web Consortium site on February 22, 1999.
• Software programs can use this reference to get the term and the relations. Because the reference is based on the well defined and heavily used URI technology, programs know what protocols to use and how to get the resources pointed to by the URI.
• The concept of namespaces is also included in the URI specification. Namespaces allow terms to be further organized, in fact relative to a very particular context. The namespaces concept is well documented, and is a core part of XML Schemas. Most web-enabled programs know how to interact with namespaces and URIs, so there is no need to reinvent a technology to provide this level of grouping.
• Since almost all organizations have an internet domain, the domain can be an easy way to specify a context, by using it (as a namespace) to provide part of the identifier for the vocabularies. Although it is not required to use an internet domain as a namespace, protocols exist to make namespaces self-describing when they are referenceable internet domains. This also allows items within the namespace to have specific information associated with them and accessible via a URI.

Guidelines

Namespace creation guidelines

• Namespace: Our namespaces should start with a referenceable protocol and domain: for example: http://marinemetadata.org. The http protocol is preferred.
• Use of dates: All of our stored ontologies will incorporate a date in their URL, but we will also have a URL for the "latest" version, which will not incorporate the date. For example, for a BODC ontology on our site, the namespace should be:
  With date: _http://marinemetadata.org/2005/03/23/bodc
  Without date: _http://marinemetadata.org/bodc
• Case: Use lower case letters.
• Quantity/quality of words chosen: Use the minimum number of letters that can give some understanding
• Complex words: If two words need to be part of the namespace use an underscore to separate them. For example: bodc_voc
• URI as a URL: The document should be retrievable in the URI created. If I type: http://marinemetadata.org/2005/03/voc#temperature, I should get the http://marinemetadata.org/2005/03/voc ontology.
• MIME type in namespace: The document should be saved without the ".owl".

Naming (fragment or local name) guidelines

A fragment is the word that appears after the symbol "#". So in http://marinemetadata.org/2005/03/voc#temperature, temperature is said to be the fragment. It is also called local name.

• First character: The first character should always start with a letter (a-z) or (A-Z) or with an underscore. Never start a fragment with a number! If the original term started with a number, put an underscore before the number when creating a local name.
• Complex terms: If there are two terms, separate them by an underscore.

• Characters other than letters and numbers:

  Original Character	Replacement Character	Example
  " "	"_"	wind speed -> wind_speed
  "/"	"_or_" or "_per_"	elevation/height -> elevation_or_height; waves/second -> waves_per_second
  ","	"_"	wind,speed -> wind_speed
  "(" and ")"	"-"	wind(speed) -> wind-speed-

  
  

  At the end of the substitutions perform a check and replace repeated characters "--" or "__" for single ones and if "_" or "-" are the last character in the fragment delete them from the fragment. For example: wind____speed_ -> wind_speed