Location

Do not use Location to record the data coverage (temporal/spatial) of a registry object. Use the Coverage element instead.
Location should also not be used to record the repository in which a collective work is held. Instead use an instance of RelatedObject with a Relation Type of "isLocatedAt".

Meaning and purpose

Location is a wrapper for Address and Spatial elements, describing the physical and/or electronic location(s) of a registry object, with the purpose of enabling access to the object. Each Location element should contain information about a single entity; however, the Location element can be repeated. The location information recorded will vary according to the class of entity being described (collection, party, activity or service). 

Location contains the following child elements:

• Address, which itself has the child elements:
  • Electronic - an email address or URI pointing to the object being described
  • Physical - both street and postal addresses, and telephone and fax numbers
• Spatial - geographical references to locations using geospatial coordinates such as latitude and longitude.

Spatial location is less commonly used, since electronic and physical addresses fulfill the purpose of enabling access more directly.

Where the address has changed and older addresses have been recorded in the metadata being provided, the time period for which the location information was current can be specified using DateFrom and DateTo attributes.

Location attributes

Location Type

The Location Type attribute is not currently used in the RDA Registry.

Date From and Date To attributes

Optionally, record the time period for which the location information was current using the DateFrom and DateTo attributes. This is only applicable where the location has changed over time and older versions of the location have been recorded in the metadata being provided. A single date or a range of dates can be provided and may include both start and end dates or an open ended date. Dates should be UTC and of one of the forms described in section 3.2.7 of the W3C Schema Data Types document. 

Use in Research Data Australia

Location information is displayed in Research Data Australia for use in accessing collections or services, contacting parties, or obtaining more information about research domain activities or entities. 

URLs are displayed as active hyperlinks and on collection view pages, these are accessed via the "Access the data" button.

Email and physical addresses display under "Contact Information" in records in Research Data Australia, or on a map in the body of the page if information is provided in the Spatial element.

Dates provided within Location are not displayed or searchable.

Best practice

Only location information that provides access to the object, or aids in the discoverability of the object or in assessing its value, should be recorded. If other location information is readily available and more easily maintained elsewhere, do not record it in the RDA Registry.

Electronic addresses are preferred over physical addresses or spatial locations.

Recording multiple locations

The Location element is a wrapper element that contains repeatable child elements: Address and Spatial. The child element Address is also a wrapper element that contains the Electronic and Physical address address elements. The separation between the elements exists to allow different formatting to be used for the different kinds of locations—URIs for electronic addresses, text for physical addresses, and spatial coordinates for geospatial locations.

To describe multiple locations:

• provide the location of different entities in separate Location wrappers, i.e. if emails and phone numbers for two separate contacts are included, use a separate Location wrapper for each contact.
• otherwise, if multiple locations relate to the same entity, for example, multiple electronic addresses, these can be nested within a single Address wrapper or the Address wrapper can be repeated (see XML examples below). There is no semantic difference between these options, and there are no implications for display in Research Data Australia. The simplest approach that meets your needs is recommended.

Locations for collections

• Collection location information enables users to access the collection. This may mean direct access to the collection or mediated access via a contact person or organisation.
• The location for collections published online will usually be a URL (electronic address). An appropriate electronic address for a collection is a URI to a landing page in a repository and/or an email address of a person or organisation which can respond to enquiries about access. The electronic address may also lead directly to download of the collection. 
• A physical address for the researcher's office/research centre might also be appropriate if access is mediated.
• For collections such as a herbarium or museum, a street address, postal address or spatial location with coordinates for map display of the location may be appropriate.

Locations for services

• For web services, software and workflows, location should contain an electronic address (URL) that provides access to the service. For web services in particular, it is a URL that can be processed by a client following the service protocol (service endpoint).
• For offline services, a URL is not acceptable as a location. Web pages about the service should be recorded in the RelatedInfo element.  
• An electronic address (email), or a physical address can be provided as a contact for arranging access to the service, and should be provided for users to gain access to an offline service.

Locations for activities 

• Electronic addresses are preferred, e.g. a project web page URL. 
• A physical address may also be appropriate, e.g. the phone number or address of an office for the research program. 
• Only use spatial location if no other form of address is available.

Locations for parties

• Electronic addresses are preferred, e.g. the URL of a personal profile, and/or an email address. 
• A physical address may also be provided, e.g. the phone number or address of the research centre. 
• Only use spatial location if no other form of address is available as geographic coordinates are not useful for contacting people.

<location type="coverage">
 <spatial type="iso19139dcmiBox">northlimit=-20.4; southlimit=-21; westlimit=115.2; eastLimit=115.6; projection=WGS84</spatial> 
</location>

XML encoding examples

<location>
	<address>
		<electronic type="url" target="landingPage">
			<value>http://uni.edu.au/repo/one</value>
		</electronic>
		<electronic type="email">
			<value>sarah.smith@uni.edu.au</value>
		</electronic>
		<physical type="streetAddress">      
			<addressPart type="addressLine">798 Palmer Street</addressPart>
    		<addressPart type="addressLine">Townsville QLD 4810</addressPart>
		</physical>
	</address>
</location>

<location dateFrom="1997-01-01T00:00:00Z" dateTo="1997-12-31T23:59:59Z">
	<address>
	<physical type="streetAddress">      
		<addressPart type="addressLine">798 Palmer Street</addressPart>
    	<addressPart type="addressLine">Townsville QLD 4810</addressPart>
    	<addressPart type="addressLine">Australia</addressPart>
	</physical>
	</address>
</location>
 

Syntactically and semantically equivalent examples:

<location>
  <address>
   <electronic type="url"><value>http://uni.edu.au/one</value></electronic>
   <electronic type="url"><value>http://uni.edu.au/two</value></electronic>
  </address>
</location>

<location>
  <address>
   <electronic type="url"><value>http://uni.edu.au/one</value></electronic>
  </address>
  <address>
   <electronic type="url"><value>http://uni.edu.au/two</value></electronic>
  </address>
</location>

Change history