An early draft of the sp ec for the vocabulary is available at but I've copied the revised conceptual model and its brief description below. It is based on the discussions held during the first two telecons and, I hope, reflects what the WG has so far considered.
The conceptual model presented in Figure 1 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.
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. Details of the location can be given using the Location Core Vocabulary [LOCN] or similar.
A service will usually require some sort of input. In the case of issuing a driving licence 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. 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. 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 derived from some combination of legislation and policy that may be decided at any level from local to supranational by any number of bodies.
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 basic roles are 'provides' and 'uses' and specific object properties are provided for these as shortcuts. However there are any number of roles that may be played in the provision or use of a service. Therefore a 'has role' super property is provided.
Details of the specific role played by an Agent can be provided using the Role and Membership classes. These are defined in the Organization Ontology [ORG] which in turn derived them from FOAF [FOAF]. It allows for the roles to be defined separately from the agents that fulfil those roles and for any number of agents to be associated with any number of roles.
@@@ Need an example here @@@
Finally the service is likely to be available within a defined jurisdiction and/or time frame. These limits are recorded in the Coverage/Extent class (from Dublin Core).