This System is a new addition and is subject to change and general bugginess. If you have any questions or bug reports, contact Colin Williams or Nick Gibbins.
These pages supply up to date information about various ECS entities in RDF format. Each entity has been assigned a URI, which can be resolved to retrieve the location of documents related to that Entity.
Wikipedia describes RDF as follows:
Resource Description Framework (RDF) is a family of World Wide Web Consortium (W3C) specifications originally designed as a metadata model using XML but which has come to be used as a general method of modeling knowledge, through a variety of syntax formats (XML and non-XML).
The RDF metadata model is based upon the idea of making statements about resources in the form of a subject-predicate-object expression, called a triple in RDF terminology. One way to represent the fact "The sky has the colour blue" in RDF would be as a triple whose subject is "the sky," whose predicate is "has the color", and whose object is "blue." Predicates are traits or aspects about a resource and express a relationship between the subject and the object.
This mechanism for describing resources is a major component in what is proposed by the W3C's Semantic Web activity: an evolutionary stage of the World Wide Web in which automated software can store, exchange, and use machine-readable information distributed throughout the web, in turn enabling users to deal with the information with greater efficiency and certainty. RDF's simple data model and ability to model disparate, abstract concepts has also led to its increasing use in knowledge management applications unrelated to Semantic Web activity.
A Uniform Resource Identifier (URI), is a compact string of characters used to identify or name a resource. The main purpose of this identification is to enable interaction with representations of the resource over a network, typically the World Wide Web, using specific protocols. URIs are defined in schemes defining a specific syntax and associated protocols.
For further information on RDF, read the W3C RDF Primer.
The URI scheme contains the following sections to represent entities. The table below also details which sections are implemented for which domains. The 'www redirect' column indicates which sections have an appropriate html version to redirect to when html is the preferred mime type.
The scheme for the resolution of entity URIs described in this section is based on the recipes for publishing RDF vocabularies published by the W3C Best Practices and Deployment Working Group, which in turn are based on the resolution of TAG Issue httpRange-14. This work has also been heavily influenced by the Tabulator SW browser, and our experiences when gathering data for the CS AKTive Space.
Retrieving a valid URI under the domain 'id.ecs.soton.ac.uk' will generate an appropriate HTTP 303 See Other response, redirecting the client to an appropriate resource related to the URI. The result of this redirection depends on the section in question, and the mime type preference headers sent by the client (see Figures 1 and 2).
(Serves a human-readable description of the entity, encoded as HTML.)
(Serves a description of the entity suitable for general dissemination, encoded as RDF/XML.)
A key motivation for this work has been the development of a scheme for publishing an organisation's knowledge in RDF that is compatible with the provisions of the Data Protection Act. ECS members are explicitly asked for permission to make their personal information available online, defaulting to internal-only if no response is received. Consequently, access to the RDF from within ECS is given privileged status, with the full record made available, as shown in Figure 3.
(Serves a complete description of the entity, encoded as RDF/XML.)
Each section has its own redirection configuration, derived from a list of supported mime types, in order of preference, and a mapping from those to an appropriate function, which should return the URI to redirect the client to. This function either returns a valid URI, or NULL in the event an HTTP 404 Not Found response should be generated. 404 responses are generated if the entity URI is unknown (no such entity exists) or if the client has insufficient authority to view information on that entity. We have taken the explicit decision to return 404 Not Found in this latter case instead of 403 Forbidden, because we feel that a 403 response still provides personal data by virtue of revealing the existence of a person, even if no further information is supplied.
(Fails if the entity is unknown, or if the client is not permitted to see information about that entity.)
In the event that none of the client's mime types match the configured list, the most preferred mime type for the section is returned instead.
Example HTTP 1.1 request for 'http://id.ecs.soton.ac.uk/group/iam' and the HTTP 303 response
$ telnet id.ecs.soton.ac.uk 80 Trying 2001:630:d0:f102:204:23ff:feb9:897f... Connected to id.ecs.soton.ac.uk (2001:630:d0:f102:204:23ff:feb9:897f). Escape character is '^]'. GET /group/iam HTTP/1.1 Accept: application/rdf+xml Host: id.ecs.soton.ac.uk HTTP/1.1 303 See Other Date: Thu, 07 Sep 2006 09:56:00 GMT Server: Apache/2.0.46 (Red Hat) Accept-Ranges: bytes X-Powered-By: PHP/4.3.2 Location: http://rdf.ecs.soton.ac.uk/group/iam Content-Length: 0 Connection: close Content-Type: text/html; charset=utf-8 Connection closed by foreign host.
A lot of effort has gone into making sure that all data supplied by this project complies with the Data Protection Act. All people can choose a visibility for themselves (as can be seen on the ECS people pages) and this will limit what can be seen from inside and outside the University. It can be set to visible everywhere, visible inside UoS and visible nowhere. Within the this URI scheme this is most obvious with people and roles. If a role has it's DPA set to visible eveyrwhere, it's rdf.ecs page is visible anywhere (intra.rdf.ecs is still only internal to UoS). If it is visible internally, rdf.ecs and intra.rdf.ecs are visible from within UoS. If it is visible nowhere you cannot see them anywhere.
It is important to note what invisible means in this context. Attempts to access invisible people or roles will cause a 404 Not Found. It will not cause a 403 Forbidden response, as this acknowledges the existence of this person. Likewise accessing an intra.rdf.ecs page externally will also cause a 404 Not Found response.
For those extracting RDF from these pages and storing it somewhere, you must respect DPA requirements.
Obviously it is up to you to comply with these points.
Should you need to resolve a URI from within the University of Southampton as if you were resolving it externally, you should append the following text to the URI.
|rdf||application/rdf+xml||Will redirect to an appropriate URI under either 'rdf.ecs.soton.ac.uk' or 'intra.rdf.ecs.soton.ac.uk'.|
|(x)html||application/xhtml+xml, text/html||Will redirect to an appropriate html based page, if there is one avaliable for the section|
|vCard||application/vnd.groove-vcard||Will redirect to an appropriate URI under the 'vcard.ecs.soton.ac.uk' domain.|
The URIs given by this system should be treated opaquely, that is to say you should not infer anything from their structure.
From this URI you should not infer that the room this URI represents is in building 59. Rather you should look to the content of the document referencing the URI for Building 59.
There are 4 domains allocated to this uri scheme:
The following ontologies are of importance to the RDF generation.
URIs related to research groups will take the following form:
Where 'GroupID' is a valid research group unix name.
Project URIs are of the form:
Where 'ProjectID' is the unix filename of the specific project. This is the same identifier as used in the ECS project pages.
Theme URIs are of the form:
Where 'Theme Name' is the name of the theme in question. Spaces should be replaced by '+' characters, as used in the ECS themes page.
Seminar URIs are of the form:
Where 'SeminarID' is the numerical identifier of the particular seminar.
Presentation URIs are of the form:
Where 'PresentationID' is the numerical identifier of the particular presentation. The ECS web page equivalent of the presentation identifier can be found at
Person URIs are of the form:
Where 'PersonID' is the person's numerical ecs id. Not their role id or username.
The ECS web page equivalent of the person identifer makes use of the user's username, and can be found at:
Role URIs are of the form:
Where 'RoleID' is the role's numerical role id. Not their person id or username. For most roles this is the same as the person who performs this roles person id.
The ECS web page equivalent contains all roles of that person who has this role, it can be found at:
Publication URIs are of the form:
Where 'EPrintsID' is the publication's numerical id used by EPrints.The ECS web page equivalent of the publication is the eprints page for it at
Interest URIs are of the form:
Where 'Interest Name' is the name of the Interest. Spaces should be replaced by '_' characters. This scheme is as used on ECS interests pages.
Location URIs should be of the following form:
For identifying a building.
For identifying a room within a building.
For identifying the highfield campus.
For identifying the city of Southampton.
These RDF URLs supply information about all cities, sites and buildings, respectively.
The following URIs should not be used, as they have no logical meaning in identifying a location. The Univeristy and Department of Electronics and Computer Science are spread over a number of locations, and thus cannot be described as a location in their own right.
Where 'DegreeID' is the cohort code without a number i.e. csBSc.
Where 'CohortID' is the standard cohort id, 'YearOfStudy' represents the year of the cohort as part of the degree programme, and optionally, 'Session' is the particular session of that cohort in yyyy-yyyy form (i.e. 2005-2006). Specifying the Session will restrict the scope of the data to matching cohorts in that particular session.
Where 'ModuleID' is the module code (ie. COMP1004) and, optionally, 'Session' is the particular session of that module in yyyy-yyyy form (ie. 2005-2006).
Where 'SemesterID' is either 1 or 2 and 'Session' is the particular session of that cohort in yyyy-yyyy form (i.e. 2005-2006).
Where 'SessionID' is in yyyy-yyyy form (i.e. 2005-2006).
Where 'YearOfStudy is a number between 1 and 6. 1 to 5 indicate normal undergraduate years, whilst 6 indicates a taught postgraduate course.
The URI describing the University of Southampton as an Organisation
The URI describing ECS as an Organisation Unit
The URI describing a notice or news item. Redirects to either a public or internal webpage with the news item on, if available.
By visiting this page you can request a list of URIs that have been updated or not checked since a specified date. Further explanation of using this feature is given there.
By visiting this page you can apply a number of different mappings to convert data using a number of different converters. Further explanation of using this feature is given there.
Generation of the RDF is done with a PHP implementation of an RDF serialiser, extended from Nick Gibbins' RDF serializer. It takes an array of statement objects, and converts them to rdf, and groups those with like subjects. Each statement object has a subject, predicate and object as would be expected in an RDF triple. The first two must be of type Resource and the last must be a Resource or a Literal. The serializer should be passed complete URIs in the statement objects, it will generate appropriate xml namespaces wherever possible (unknown namespaces are nsX:, if there is a preference for a name, edit the NamespaceDictionary to define it). It has been modified to allow typed literals to be used.
A more detailed description of the workings of the RDF serializer with the RDF generators is available here.
Work on this system was carried out by Marcus Cobden, Alastair Cummings, Nicholas Gibbins and Colin Williams.