Event Programme Ontology

For...

This is a simple ontology being developed by Christopher Gutteridge, with advice from the community. It is intended to allow programmed events to easily publish their programmes online in an interoperable manner.

It should be easy enough to create and publish a valid programme without any understanding RDF, Linked Data etc.

Example

This example implements a multi-day conference, with a programme streamed by location. [Download]

Renderer

We've created a basic HTML renderer, ask if you'd like a copy of the source code:

Relationship to Semantic Web Conference Programme Ontology

The ISWC ontology is very specific and designed for describing academic conferences. You may wish to add additional semantics to your programme by using rdf:type to indicate that your events and locations have specific semantic meanings. Also check out their conference chair specification and listing a paper being given in an event. These are compatible with this Programme Ontology, but make sure you don't lose our class types,even if you also add theirs, as otherwise consuming apps may not understand it.

Relationship to ical/ics and the cal: namespace

The event properties should be very easy to map into ical or the cal: namespace. We don't use the properties from that namespace as an abstract event can have a summary and description, which if we used cal:summary would semantically indicate that it's an event, which it's not. Also the timezone information in the cal: namespace is a tad icky.

ical prog
summary  -  rdfs:label
description  -  dcterms:description
dtstart  -  event:time → tl:start
dtend  -  event:time → tl:end
location  -  event:place → rdfs:label
uid  -  The URI of the event

The Obligitary Relationship Diagram

Best Practice

Good practice is to publish all of the data required for a programme in a single RDF+XML document, with boilerplate triples identifying the programme which is the foaf:primaryTopic, and clearly stating a license.

Reference

Classes and properties with no prefix are in the prog: namespace.

event:   http://purl.org/NET/c4dm/event.owl#
prog:   http://purl.org/prog/
tl:   http://purl.org/NET/c4dm/timeline.owl#
dcterms:   http://purl.org/dc/terms/
rdf:   http://www.w3.org/1999/02/22-rdf-syntax-ns#
foaf:   http://xmlns.com/foaf/0.1/
geo:   http://www.w3.org/2003/01/geo/wgs84_pos#
oo:   http://purl.org/openorg/
spacerel:   http://data.ordnancesurvey.co.uk/ontology/spatialrelations/
skos:   http://www.w3.org/2004/02/skos/core#
xsd:   http://www.w3.org/2001/XMLSchema#
bibo:   http://purl.org/ontology/bibo/
bio:   http://purl.org/vocab/bio/0.1/
xtypes:   http://purl.org/xtypes/

Classes List

Properties List

Classes

event:Event (Class)

A single event in time. Used in this system to represent both the major event which has a prog:Programme, and the individual events in a programme. Some events may appear in more than one programme. Some programmed events may have sub-events or programmes of their own. Most events will have event:time and event:place.

Notes for programme producers

If this event is in a prog:Programme then it should have an event:time describing a tl:Interval with both tl:start and tl:end defined. It should have a rdfs:label which is the text which should be shown in the programme. A full title may be specified with dcterms:title (but rdfs:label should still be set too). A description may be provided as either a dcterms:description, or for more academic sessions a bibo:abstract. If it is the realisation of an Activity then and is missing any of rdfs:label, dcterms:title, bibo:abstract, dcterms:description then these values may be inherrited from the prog:Activity. Some programmes may need to define instants (eg. Bar closes) in addition to intervals. Do this with tl:Instant and tl:at, but some consumers may ignore it.

Notes for programme consumers

An application must understand rdfs:label, event:time → tl:start and event:time → tl:end and ideally prog:realises. Points in time may be represented with tl:Instant and tl:at. An example is "Registration Desk Opens" or "No children permitted after this time". Points in time may be irrelevant to certain applications. We may improve this later.

In domain of
In range of

foaf:Agent (Class)

Generally use the subclasses of this class; foaf:Group, foaf:Organization and foaf:Person.

Notes for programme producers

An foaf:Agent (or a subclass thereof) is expected to have a foaf:name. Use other foaf: predicates as appropriate. To give the biography of a speaker, use the bio:biography predicate. If you want an HTML biography use the xtypes:Fragment-HTML datatype.

Notes for programme consumers

You may choose to entirely ignore the agents involved in an event.

In domain of
In range of

foaf:Person (Class)

Subclass of foaf:Agent meaning an actual person.

Notes for programme consumers

You may choose to entirely ignore the agents involved in an event.

In domain of
In range of

geo:SpatialThing (Class)

Use this class to for a location, either permenant or defined as part of an event. For example room 412 may be named 'Group Discussion Area' in the context of an event. In the case of a temporarily defined location, do not use owl:sameAs to link the temporary location with the permenant location. Locations in programmes come in three main types, 1. The city which a programmed event is foaf:based_near, 2. The venue in which a programmed event is held (generally a building or campus), 3. A location in which one or more specific programmed events occur.

Notes for programme producers

Locations should have a rdfs:label. They may have a geo:lat and geo:long, but they must have both of these or neither. It is good practice to give details of venue and city, but this is not required. We recommend using the geonames (or at a push, dbpedia) URI for the city.

Notes for programme consumers

The application may ignore the venue and city information if it chooses. It must understand locations rdfs:label at a minimum unless it ignores locations completely.

In domain of
In range of

prog:Activity (Class)

This class represents the abstract content of an event, which may be repeated many times, once or never. For example a training course, or a play. The primary purpose is to indicate that several events will have very similar content, to aid planning what to attend. It does not indicate that there is any reason people could not attend more than one realisation. It should not be used to abstract a repeating event, such as morning coffee or a monthly meeting.

Notes for programme producers

Multiple Events may reference that they are realises of the same Activity. Activities are not Events and may not have a time or place.

In domain of
In range of

prog:Programme (Class)

A programme is a description of the parts of a complex event to aid understanding it. A single event may be described by several programmes, for example one may give a break down by day, another by rooms, another by topic.

Notes for programme producers

A programme should not have Timeslots or Events if it subprogrammes. In effect this means there are two subclasses of Programme, but there's no need to express that in the data.

Notes for programme consumers

A simple application only needs to operate on a single Programme at once.

In domain of
In range of

prog:TimeSlot (Class)

This is a property of a Programme to facilitate understanding by humans. There is no semantic relationship between events in the programme and TimeSlots as complex programmes often have events which ignore the published timeslots. A timeslot is effectively an event with nothing but a time interval and label.

Notes for programme producers

A Timeslot must have an rdfs:label and a event:time linking it to a tl:Interval.

Notes for programme consumers

Timeslots are purely cosmetic and it is not recommended that events should not be artificially fitted into them.

In domain of
In range of

skos:Concept (Class)

A concept is the subject of one or more events. It may be used to lay out a visualisation of a programme.

Notes for programme producers

A concept should have a skos:prefLabel. When rendering a programme, only concepts linked from the programme by prog:streamed_by_subject will be looked for on events

Notes for programme consumers

An application needs to understand this if working with programmes, but not if only looking at basic events. A programme viewer should cope with the fact that an event can be in two concepts in the same programme, and two events with the same concepts as dcterms:subject may overlap in time. Do not worry about it being type skos:Concept but rather just look at the prog:streamed_by_subject and dcterms:subject relations to it.

In domain of
In range of

tl:Instant (Class)

Used for the event:time of events with no duration.

In domain of
In range of

tl:Interval (Class)

Used for the event:time of events with a duration.

In domain of
In range of

Properties

bibo:abstract (Property)

A summary of the content of the event. Assumed to be plain text, but may use xtypes:Fragment-HTML as the datatype to indicate it contains a fragment of HTML.

→ bibo:abstract →
Text Literal

bio:biography (Property)

The biography of a person, if that's part of the programme. If you want to put the bio in HTML then make the datatype xtypes:Fragment-HTML. If you known that the biography in plain text only (no HTML markup, wiki markup etc), use datatype xtypes:Fragment-PlainText.

→ bio:biography →
Literal

dcterms:description (Property)

A fuller description than the label. While it can be added to anything, in the programme ontology it is not expected that an application will do anything with it if found on TimeSlot or Stream. Assumed to be plain text, but may use xtypes:Fragment-HTML as the datatype to indicate it contains a fragment of HTML.

→ dcterms:description →
Text Literal

dcterms:subject (Property)

Indicates that an event is associated with a given subject. This is used to create visualisations when the event is part of a prog:Programme.

→ dcterms:subject →

event:agent (Property)

Use this to relate an event to a Person or Group involed in the event. For academic events this will be the speaker of a talk, or the chair of a session. For performances it is the group, artist or troupe giving the performance. Don't try and list every individual involved. There may be extensions for expressing specific relationshipts. If so use event:agent too, if you want the relationship to be understood by simple programme consumers.

→ event:agent →

event:place (Property)

Relates an event to its specific Location. In the case of conferences, this is the conference venue. For other events, it's usually the room the event is in, or the location defined as within the room if the conference or programme assigns special room names.

→ event:place →

event:sub_event (Property)

Indicates that an event is part of a greater event.

→ event:sub_event →

event:time (Property)

Link an event to either an interval of time or an instant of time. The timeline schema can define other gaps but they are beyond the scope of programmes. You can use them but don't expect anyone to understand it.

→ event:time →

foaf:based_near (Property)

Used to locate a major event by identifying the nearest city, or similar notable spatial thing. Use this to identify the nearest well known location, and use event:place to identify the exact venue.

→ foaf:based_near →

foaf:homepage (Property)

Relates an event:Event or geo:SpatialThing to its homepage.

→ foaf:homepage →
URL

foaf:name (Property)

The name of an foaf:Agent, foaf:Group, foaf:Organization or foaf:Person.

→ foaf:name →
String Literal

foaf:page (Property)

Relates an event:Event or geo:SpatialThing to a web page about it.

→ foaf:page →
URL

geo:lat (Property)

The latitude of a location. Must always be used with geo:long.

→ geo:lat →
Float

geo:long (Property)

The longitude of a location. Must always be used with geo:lat.

→ geo:long →
Float

oo:twitterHashtag (Property)

Relate an event, location or concept to the twitter hashtag(s) being used to refer to it.

→ oo:twitterHashtag →
Literal

prog:has_event (Property)

Indicates that an Event is part of the specified programme, but not streamed in any particular way. This should not relate a programme to the event it is a programme of. This is used for events in programmes without streams, or for events which are listed in all streams, such as 'Lunch','Check into Accomodation' or 'Plenary'.

→ prog:has_event →

prog:has_programme (Property)

Connects an ev:Event with a prog:Programme which describes it.

→ prog:has_programme →

prog:has_sidebar_event (Property)

Indicates that an Event is part of the specified programme, but is not part of the normal grid and should be listed separately. Evening events, for example, may be included in this way. Other users include all-day events such as 'exhibition in main hall', for which you do not want to use up 'real-estate' in a grid-display of this programme.

→ prog:has_sidebar_event →

prog:has_streamed_event (Property)

Indicates that an Event is part of the specified programme, and should appear in any relevant 'streams' based on its subject or location. If it matches no things for which the programme is prog:streamed_by_location, prog:streamed_by_parent_event or prog:streamed_by_subject then a tool may choose to report this as broken data.

→ prog:has_streamed_event →

prog:has_timeslot (Property)

Indicates that a TimeSlot is part of the specified programme.

→ prog:has_timeslot →

prog:realises (Property)

Relates a concrete event:Event to the prog:Activity that it is a realisation of. For example this would relate the training course on Thursday to the prog:Activity of the laser safety lecure. All realisations of the laser safety lecture have generally the same content, although details may vary. It is not expected that a normal attendee will attend more than one realisation of an Activity, although certainly not precluded at the level of detail we're working with here.

→ prog:realises →

prog:streamed_by_location (Property)

Indicates that one of the streams in this visualisation is events with a event:place relating them to the geo:SpatialThing indicated. This is the most common way an programme is designed.

→ prog:streamed_by_location →

prog:streamed_by_parent_event (Property)

Indicates that one of the streams in this visualisation is events that are event:sub_event of the event:Event indicated. This can be used to show several workshops in an event. This should only apply to things which are immediately stated explicitly as event:sub_event, it is assumed that the consumer will not treat this property as transitive, unless they are doing something weird or clever.

→ prog:streamed_by_parent_event →

prog:streamed_by_subject (Property)

Indicates that one of the streams in this visualisation is events with a dcterms:subject relating them to the skos:Concept indicated.

→ prog:streamed_by_subject →

rdfs:label (Property)

The human readable description of a thing, generally short enough to be displayed in all views of the programme.

→ rdfs:label →
Text Literal

skos:prefLabel (Property)

The label to show for a concept. It may have other rdfs:label added too if needed.

→ skos:prefLabel →
Text Literal

spacerel:within (Property)

Link a place to a place it is within. Use this to relate rooms to buildings. If a place doesn't have a geo:lat and geo:long but it is within a place which does then this lat and long can be used as an appoximate reference point for the place.

→ spacerel:within →

tl:at (Property)

The time of an event:Instant which is the event:time of a event:Event or prog:TimeSlot. In the format 2010-04-07T18:07Z. Seconds mat be added in .00 format, and the Z may be replaced by the time offset, eg. -0100. See http://en.wikipedia.org/wiki/ISO_8601

→ tl:at →
Date-Time

tl:end (Property)

The end time of an event:Interval which is the event:time of a event:Event or prog:TimeSlot. In the format 2010-04-07T18:07Z. Seconds mat be added in .00 format, and the Z may be replaced by the time offset, eg. -0100. See http://en.wikipedia.org/wiki/ISO_8601

→ tl:end →
Date-Time

tl:start (Property)

The start time of an event:Interval which is the event:time of a event:Event or prog:TimeSlot. In the format 2010-04-07T18:07Z. Seconds mat be added in .00 format, and the Z may be replaced by the time offset, eg. -0100. See http://en.wikipedia.org/wiki/ISO_8601

→ tl:start →
Date-Time

Extension: Ticket Prices

We recommend using GoodRelations, as described in this article.

Extension: People

This extension allows you to associate people (or other foaf:Agent) to your sessions and programme.

Relating People to Events

You may associate foaf:People with an event using the following properties. The can be applied to either the top-level event or the individual sessions. These are specifically aimed at more academic events, for music events use the Music Ontology Performance Relationships.

We use foaf:Person in the examples, but it can be any foaf:Agent. All the following are sub-properties of event:agent.

<event> prog:speaker <person>
A person or group who provides some of the live content of the event. This can also be a group (eg. theatre group). It includes presenters and performers. (but we can't think of a better term for it). A group listed as prog:speaker does not imply that all members are prog:speaker of the event.
<event> prog:chair <person>
A person who does any of introducing a session, chairs a panel, makes sure that the session runs to time. This is not a conference chair, which is an organisation role.
<event> prog:attendee <person>
A person or group which is attending, or did a attend an event. Use this to track people planning to go to an event, or a list of who did go. It may make sense to store the prog:attended-by relationships in a separate document to the main programme.
<event> prog:panel_member <person>
A person who is part of a panel in this event.

The following relations may relate a location, theme or event to a person or organisation, so are not simple sub-properies of event:agent.

<event/subject/location> prog:sponsor <organization>
Unlike the above, this will usually be relating an organisation, but it can still be a person. It indicates that the organization has supported the event in some fashion and is identified by the event as a sponsor. This may also be used to relate a location or theme to a specific sponsor. For example, the childrens fun-zone could have a sponsor. It is recommended that a sponsoring organization has both a foaf:name and foaf:logo.
<event/subject/location> prog:support <person>
A person provides some kind of support for a session, such as lighting, helping people to their seats. This is included to help make sure you don't schedule two events at the same time requiring the same person.
<event/subject/location> prog:organiser <person>
A person who is organising all or part of this event. Organising an event does not imply attendance. The organisers can be both people and groups or organizations.

Relating People to the Programme

You may describe the person or people who maintain the programme by using dcterms:creator.

<programme> dcterms:creator <person>

Describing People

Basically use 'foaf', but use bio:biography and prog:has_affiliation for bigraphies and affiliation information. Both these should be constrianed to facts relevant to the person's relationship to the programme. If you use an HTML bio, that's fine but note it in the datatype.

foaf:name should always be included, everything else is optional.

Rather than describe this in detail; here's an example.


  <foaf:Person rdf:about="http://data.dev8d.org/2011/programme/dev8d_programme.rdf#person-cgutteridge">

    <foaf:name>Christopher Gutteridge</foaf:name>
    <foaf:givenName>Christopher</foaf:givenName>
    <foaf:familyName>Gutteridge</foaf:familyName>
    <foaf:mbox rdf:resource="mailto:cjg@ecs.soton.ac.uk"/>
    <foaf:account>
      <foaf:OnlineAccount>
        <foaf:accountServiceHomepage rdf:resource="http://www.twitter.com/"/>
        <foaf:accountName>cgutteridge</foaf:accountName>
        <foaf:accountProfilePage rdf:resource="http://www.twitter.com/cgutteridge"/>
      </foaf:OnlineAccount>
    </foaf:account>
    <foaf:weblog rdf:resource="http://blogs.ecs.soton.ac.uk/webteam/"/>
    <foaf:homepage rdf:resource="http://users.ecs.soton.ac.uk/cjg/"/>
    <foaf:depiction rdf:resource="http://lemur.ecs.soton.ac.uk/~cjg/cjg.jpg"/>
    <foaf:workplaceHomepage rdf:resource="http://www.soton.ac.uk/"/>

    <bio:biography rdf:datatype="http://purl.org/xtypes/Fragment-PlainText">Chris likes cheese and ham.</bio:biography>
    <bio:biography rdf:datatype="http://purl.org/xtypes/Fragment-HTML">&lt;p&gt;&lt;a href="http://www.ecs.soton.ac.uk/people/cjg"&gt;Chris&lt;/a&gt; likes:&lt;/p&gt; &lt;ul&gt;&lt;li&gt;cheese:&lt;/li&gt;&lt;li&gt;ham&lt;/li&gt;&lt;/ul&gt;</bio:biography>

    <prog:has_affiliation>
      <prog:Affiliation>
        <rdfs:label>Open Linked Data Architect</rdfs:label>
        <prog:affiliation_to>
          <foaf:Organization>
            <foaf:name>University of Southampton</foaf:name>
            <foaf:homepage rdf:resource="http://www.soton.ac.uk/"/>
          </foaf:Organization>
        </prog:affiliation_to>
      </prog:Affiliation>
    </prog:has_affiliation>

  </foaf:Person>
© 2010 Christopher Gutteridge, Creative Commons License
This work is licensed under a Creative Commons Attribution 3.0 Unported License.