What is our URI?

Canonical URI is already a bit of a loaded term, but what I really mean is what URI should I use to refer to Southampton University when writing linked data about it. Or, for that matter, how about The WebScience Trust?

Here’s the rule I think we should follow:

1. If the organisation who grants your charter assigns you a URI then use that.
2. Failing that, mint one for yourself in your own domain.

I don’t think it makes much sense to use your dbpedia URI — they are too volatile.

In both cases you should mint your own URIs for any entities which are within your scope, such as sub-organisations.

The problem is that (1) won’t resolve to your open data about your organisation, but rather to your parent organisation’s data about your organisation. In this case I suggest the following pattern is added to your ‘boilerplate’ which you add to most or all RDF documents:

<http://data.example.ac.uk/docs/exampleacuk.rdf> 
  foaf:primaryTopic 
  <http://education.data.gov.uk/id/school/666666> .

<http://data.example.ac.uk/docs/exampleacuk.rdf> 
  rdf:type 
  oocore:OpenOrgDocument .

What’s oocore?

oocore is the (still in development) core namespace for a bunch of namespaces for tools to help “Open Organisations” provide useful information about themselves and make it discoverable. The focus is not on perfect models (beware the Modeller) but rather on making the data easy to use and reuse.

The idea of an OpenOrgDocument is that it would obey certain conventions, and would be a little like a foaf:personalProfileDocument for an organisation. It will have some strong guidelines on what is useful to include, and link to additional OpenOrg documents for common facets of organisational data, such as buildings and amenities, organisational structure, news, publications, membership, financial information etc.

What if our parent organisation creates a URI for us in the future?

Well, that’s an issue. You’ll have the choice of using that in future, or just adding a sameAs link. It’s a pain, but I suspect most places will just continue to use the URI they picked early. The key thing is not to mint a URI if there’s already one out there.

Discovering the OpenOrg Document

If you request “/” from the organisation’s main domain, eg. www.example.ac.uk, with an HTTP heading that prefers to accept ‘application/rdf+xml’ then you should be redirected to the open org document. In addition, the homepage should have a

<link rel="alternate" type="application/rdf+xml" href='..path to openorg document..' />

This will mean that people can discover standard data about your organisation without jumping through any complicated hoops, or having to try 10 different fiddly approaches.

What should go in an OpenOrg Document?

Well, we’ll work that out as we go, but I’d go with some of:

• Basic name of the organisation
• contact details; main email, main homepage, main phone number
• based_near to the nearest population centre
• based_near also to a geo:point for simple navigation purposes.
• links to additional openorg documents which (and this is a neat bit) can be the current document. If it’s a small organisation, you might as well put all the data in one big document which is rdf:type several types of openorg document.
• links to additional datasets, with enough data to let a system know if it’s helpful to resolve the URI or not.

That last bit is important. By saying that a URL is of type “OpenOrgBuildingsDocument” that tells a consumer that the resulting data will not only be in RDF but will follow a known pattern, which should help it provide a user interface to it, especially for mobile applications.