Places

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.

Namespaces

rdfs geo spacerel room org foaf dct oo

Boilerplate

If you are creating a dataset or document conforming to the guidance on this page; you can indicate this using dct:conformsTo relating it to this page!

<rdf:Description rdf:about="http://example.org/places.rdf"> 
  <dct:conformsTo rdf:resource="http://openorg.ecs.soton.ac.uk/wiki/Places" />
<rdf:Description>

</syntaxhighlight>

If the places are all places relating to an organisation, use oo:places to relate the organisation to the document or dataset:

<rdf:Description rdf:about="http://example.org/id/our-org">
  <oo:places rdf:resource="http://example.org/places.rdf"> 
<rdf:Description>

</syntaxhighlight>

URIS

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

http://id.example.com/place/building-23
http://id.example.com/place/room-23-2034
http://id.example.com/place/site-brentford-campus

or

http://id.example.com/building/23
http://id.example.com/room/23-2034
http://id.example.com/site/brentford-campus

or (for those just working with Flat RDF Documents)

http://www.example.com/places.rdf#building-23
http://www.example.com/places.rdf#room-23-2034
http://www.example.com/places.rdf#site-brentford-campus

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

~~http://id.example.com/site/brentford/building/23/room/2034~~

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!

If you use the /id/ or id.foo style URIs but still have everything in one big RDF document, then you can just redirect the URIs to the single RDF document.

It is better to use aspects of something which are least likely to change when building URIs. "/building/23" is likely to stay as building 23, but /building/maths may be taken over by the Law department, then you've got a problem! Do you have a law building with URI /building/maths? As a rule of thumb, the less changable the charactaristic, the better it is for making unchanging URIS.

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.

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

</syntaxhighlight>

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">

  <geo:lat datatype="http://www.w3.org/2001/XMLSchema#float">50.935074</geo:lat>
  <geo:long datatype="http://www.w3.org/2001/XMLSchema#float">-1.395822</geo:long>

</syntaxhighlight>

Make sure you put the datatypes in. If you don't then it makes it tricky to search these fields numerically later on, which you or someone else will want to do!

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,

Addresses

See Address and Phone.

Place Codes

Many organisations choose to assign codes or IDs to certain classes of place. For example, room 101 or building C.

Each coding scheme used by your organisation should have its own URI.

   <skos:notation rdf:datatype="http://id.example.ac.uk/identifiers/room-number">101</skos:notation>

</syntaxhighlight>

See identifiers for more information.

General Place Metadata

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

<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>
</rdf:Description>

</syntaxhighlight>

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.

oo:access

Use this to describe how the place is to be accessed, in text. For example

 <oo:access>Use North entrance, go downstairs. Note: The light may have gone.</oo:access>

</syntaxhighlight>

Types of Place

Building

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

</syntaxhighlight>

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

Relating a Building to an occupant

Quite often you will list occupants at a building level, but not go into detail of exactly what room or floor they occupy. Occupants can be organisations, sub-organistations, groups or people.

    <rooms:occupant rdf:resource="...occupant URI..." />

</syntaxhighlight>

Room

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

</syntaxhighlight>

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.

Relating a room to an occupant

The occupant can be a group or a person or any other "agent".

    <rooms:occupant rdf:resource="...occupant URI..." />

</syntaxhighlight>

Site/Campus

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.

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

</syntaxhighlight>

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.

eg.

<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:Description rdf:about="http://sws.geonames.org/2637487/">
  <rdfs:label>Southampton</rdfs:label>
</rdf:Description>

</syntaxhighlight>

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.

Floor

  <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.

<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" />
<rdf:Description>

</syntaxhighlight>

Tools

Producers

OpenOrg Grinder has a template for producing room, building and site data as described in this recipe, from spreadsheets or CSV files.

Consumers

http://graphite.ecs.soton.ac.uk/geo2kml/ will turn any RDF document containing lat/long data into a Google Map.

Places

Contents

Namespaces

Boilerplate

URIS

Basic Place Data

Lat & Long

Place Hierarchy

Addresses

Place Codes

General Place Metadata

oo:access

Types of Place

Building

Relating a Building to an occupant

Room

Relating a room to an occupant

Site/Campus

Relating a site to an organisation

Sites use foaf:based_near rather than spacerel:within

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

Floor

Tools

Producers

Consumers

Navigation menu

Views

Personal tools

Navigation

Search

Tools