Difference between revisions of "Places"

From OpenOrg
Jump to: navigation, search
(Basic Place Data: Added link for addresses.)
Line 66: Line 66:
=== Addresses ===
=== Addresses ===
See [[AddressAndPhone]].
See [[Address and Phone]].
=== General Place Metadata ===
=== General Place Metadata ===

Revision as of 13:22, 11 January 2011

This is a pattern to describe physical places of note to an organisation. Generally this will include, but is not limited to Rooms, Buildings and Sites (eg. a university campus). We have learned in planning this that one size will not fit all, so will describe a very simple basic pattern, then extensions for various purposes.


rdfs geo spacerel room org foaf


As ever, try and avoid any information in the URI that isn't vital. We suggest something like:




or (for those just working with Flat RDF Documents)


It is recommend that you DON'T express spatial hierarchy in the URIs. eg.


To some degree how you select these URIs will depend on existing schemes at your organisation. Make sure that you check if it's common to re-use building codes!

Basic Place Data

A place is any physical location so there's very little you can say about it, it may have no rdf classes, or several. By definition all places are of class geo:SpatialThing, but it is not required to be stated.

The most simple definition of a place is just a URI and a label.

<syntaxhighlight lang="xml">

<rdf:Description rdf:about='...PLACE-URI...'>
  <rdfs:label>Behind the Bikesheds</rdfs:label>


Lat & Long

If known then its very useful to give the latitude and longitude of a reference point for this place. You may wish to include more fancy descriptions of its shape but this is very useful to anybody trying to use your data so include it even if its not perfect. It should represent a useful point to refer to the place-- usually either the center or the main entrance or reception. <syntaxhighlight lang="xml">



Place Hierarchy

It may be useful to organise your places as a hierarchy. Any place may be declared as 'within' other places. For example;

  • Carparks and Buildings are within a site (campus)
  • Rooms are within buildings
  • Points of service (eg. a shop or bar) are within Rooms or Buildings

It may be useful to infer a lat,long of something using the within relationship, eg. If a shop (point of service) is in a room, and that room is in a building then you could use the lat/long of the building to render an approximate location for the shop. It is not recommended that this chain is followed past "Building" or at most "Site" as it becomes rather useless to work out that a shop is in "Scotland" and use a reference point for Scotland to locate the shop!

IDEA FOR LATER: It might be useful later to add a 'Reference Point Accuracy' value so you can tell how useful a reference point is. ie. A shop would be accurate +/- 10m but the reference point for a building is more like +/-50 and for a city +/-3000.

See the note on Site for why not to describe a Site as being within a city, state or country,


See Address and Phone.

General Place Metadata

The following predicates may be used to enhance the description of a place;

<syntaxhighlight lang="xml">

<rdf:Description rdf:about="...PLACE_URI...">
  <foaf:homepage rdf:resource="...HOMEPAGE-OF-PLACE..."/>
  <foaf:page rdf:resource="...PAGE-ABOUT-A-PLACE..."/>
  <foaf:depiction rdf:resource="...URL-OF-IMAGE-OF-PLACE..."/> 
  <dct:description>A description of the place</dct:description>


Note: pages & homepages of a place should refer to the actual place (room, building, site etc.) not the organisation that currently inhabits/runs the place. For example http://en.wikipedia.org/wiki/Carlton_House_Terrace is fine as a foaf:page about a place, but http://en.wikipedia.org/wiki/Royal_Society is (primarily) about the organisation, not the place, so not a very good choice.

Types of Place


<syntaxhighlight lang="xml">

    <rdf:type rdf:resource="http://vocab.deri.ie/rooms#Building" />


If just publishing a list of buildings (or sites and buildings) and data about them, then it is recommended that this is a single document unless impractical to do so (you have 1000's of buildings!)

If you want to publish data on every room in every building then that (probably) needs to be one document per building, but you should still maintain a top-level list of buildings, and make sure people can follow their nose to get to the full description of the building and rooms.

Don't get too het up about what is or isn't a building, and the following are perfectly reasonabl

  • A building within a building
  • A room within 2 different buildings


<syntaxhighlight lang="xml">

    <rdf:type rdf:resource="http://vocab.deri.ie/rooms#Room" />


Rooms are generally inside one and only one building, but don't assume that. Usually the geo reference point for a room is taken from the building its in.

Some rooms may have confidential uses. eg. Room 5002 might be the Confidential Records room, or 5003 is the place you store the easily stolen precious stuff, or 101 is where something happens. In such cases either (a) omit the room entirely (b) just give it a trivial label without describing the purpose of the room ie. "Room" or (c) omit the label entirely.


This is a place where all or part of an organisation is located. A cluster of places with something in common, such as a university campus or the Glastonbury Festival site.

<syntaxhighlight lang="xml">

  <rdf:type rdf:resource="http://www.w3.org/ns/org#Site" />


Relating a site to an organisation

You can relate an organisation to a site using any of the following relations: org:hasSite, org:hasPrimarySite, org:hasRegisteredSite. It may well be that you choose to list the site or sites of your organisation as part of the Top Level data about your organisation.

See Org Ontology for more details.

Sites use foaf:based_near rather than spacerel:within

Rather than listing a site as being spacerel:within a city, country or state, it should be described by what is the nearest population center or similar landmark.


<syntaxhighlight lang="xml">

<rdf:Description rdf:about="http://id.southampton.ac.uk/place/highfield-campus">
  <rdfs:label>Highfield Campus</rdfs:label>
  <rdf:type rdf:resource="http://www.w3.org/ns/org#Site" />
  <foaf:based_near rdf:resource="http://sws.geonames.org/2637487/" />
<rdf:Description rdf:about="http://sws.geonames.org/2637487/">


Ideally, use geonames to identify cities, but a less-good alternative is to use dbpedia. eg. http://dbpedia.org/resource/Southampton is the ID for whatever http://en.wikipedia.org/page/Southampton is about, but it's always possible wikipedia pages will change their meaning which is why that's not so good.

Points of Service or Sale (eg. shops, helpdesk etc.)

See Points of Service.

A point of service (or sale) is also a place. Ideally don't give it the same URI as a room as it's a different kind of thing. One day the point of sale might move to another room and that would confuse everything.


<syntaxhighlight lang="xml">

  <rdf:type rdf:resource="http://vocab.deri.ie/rooms#Floor" />

</syntaxhighlight> This isn't actually that useful, but included as people really want to model floors if they happen to have the data available. While you can state that rooms are within a floor and floors within building, it is recommended that you also directly list rooms as spacerel:within a building to keep your data compatible with more simple datasets and make it easy for simple tools to work with.

<syntaxhighlight lang="xml">

<rdf:Description rdf:resource="http//example.com/id/place/room-101"> 
  <rdfs:label>Room 101</rdfs:label>
  <rdf:type rdf:resource="http://vocab.deri.ie/rooms#Room" />
  <spacerel:within rdf:resource="http//example.com/id/place/floor=1" />
  <spacerel:within rdf:resource="http//example.com/id/place/building-MOL" />