Core Public Service Conceptual Model v0.5

This version of the conceptual model and the accompanying specification draft have been produced to reflect the discussion held on 9th January. In particular they:

1. Make clear that the creator of the rules, policies or legislation is the responsible organisation, not the individual(s) who actually wrote whatever it is.
2. Replaces the relatesTo property that linked an Input to a Public Service with a property of 'input' that points the other way. (Note the capitalisation. Following best practice, properties begin with a lower case letter, classes with upper case and, often, that is the only difference between a property and the class it points to).
3. Rule and LegislationOrPolicy classes defined as sub classes of frbr:Expression (could make them equivalent classes but sub class seems neater).
4. Replaces the use of dcterms:coverage with the more specific sub properties with attendant changes to the classes they point to. Jurisdiction remains absent.
5. available from property renamed to physicallyAvailalableAt to clarify difference between physical location and online service.
6. 'Triggers' are discussed (briefly) in the definition of the requires property. This states: "One Public Service may require or in some way make use of another. It is common that the Output of one Public Service is the Input to another and that a Rule will stipulate that the completion of the first service triggers the second." i.e. we make it explicit that triggers are effectively rules. 
7. Removes the ORG ontology's Memebrship and Role classes although they remain available as discussed in the text. ORG has two methods of describing a role. One is simple and similar to the Agent --> hasRole --> Public Service shown here. The more sophisticated version that allows n-ary relationships between agents roles is referred to in the spec but the detail is not provided since to do so would confuse rather than clarify.

The diagram and initial commentary is pasted below. The draft spec is available now but it is anticipated that a further update will be available before the next meeting.

The conceptual model presented is independent of any technology that may be used to represent it. It describes the minimal set of classes, relationships and properties necessary to describe a public service. Properties and classes from the existing Dublin Core and FOAF vocabularies are prefixed with dcterms and foaf respectively. All others are newly minted as part of the Core Public Service Vocabulary.

At the heart of the model is the public service itself. This will very likely have a name, a description and, in many cases, will be of a specific type. For greatest interoperability, service types should be given as values from a list such as the service list used in many EU countries [SL4]. The service may be available online at the URL given as the value for the homepage property, and/or at one or more physical locations, given as the value for the physically available at property. Details of the location can be given using the Location Core Vocabulary [LOCN] or similar.

A service will almost always require some sort of input. In the case of issuing a driving licence, for example, this will be evidence that driving test has been passed; many services will require some sort of proof of ID and so on. Likewise, the output will vary depending on the specific service but there will usually be a document or other artefact that is the output, as well as a record in a database. This is not the same as the outcome. Drawing on the definitions used in StratML [StratML], if the service controls all of the necessary inputs and processes, the desired result is an output.  If not, it is an outcome. For example, a driving licence is an output - a physical change that is entirely within the control of the service that issues it. The outcome is that the new licence holder can drive a vehicle on the public highway. How they do that, which vehicle they drive etc. is beyond the service's remit.

Public services are regulated by a set of rules. These will typically be set by a single organisation and will implement combination of legislation and policy that may be decided at any level from local to supranational by any number of bodies. The creator of the rules, policy or legislation is the body responsible for their creation, not the individual(s) who wrote them. It is notable that the Rule and Legislation or policy classes are both defined as sub classes of the FRBR class Expression [FRBR]. This allows linkage to other expressions of the same conceptual set of rules, policies or legislation.

An individual service may be part of a 'service bundle', that is, a collection of services that logically work together. One service may require the use of another.

The Agent class represents any individual, group or organisation that plays any role in the service. These include but are not limited to:

• the public administration responsible for providing the service;
• the public administration that defines the rules that regulate the service;
• the person, organisation or group that uses the service;
• the organisation(s) that deliver the service on behalf of the responsible public body;
• the public body responsible for passing the legislation or setting the policy or policies from which the rules are derived.

The basic roles however are 'provides' and 'uses' and specific object properties are provided for these. To support the description of any role played within the provision or usage of a service a 'has role' super property is provided from which sub properties with specific semantics may be defined as part of a CPSV Profile (see section 3). More sophisticated descriptions of roles played may be described using relevant mechanisms defined in the Organisation Ontology [ORG].

Finally the service is likely to be available within a defined geographical area and/or time frame. These limits are recorded using the relevant classes and properties from the Dublin Core Metadata set [DC].

Nature of documentation: Manual (technical documentation)