D02.02 Core Public Service Vocabulary Application Profile 2.1

Transcription

1 SC414DI07171 D02.02 Core Public Service Vocabulary Application Profile 2.1 CPSV-AP 2.1

2 D02.02 CVSP-AP Document Metadata Property Value Release date Status For acceptance Version 1.00 Authors Reviewed by Michiel De Keyzer PwC EU Services Ana Fernández de Soria Risco PwC EU Services Nikolaos Loutas PwC EU Services Approved by This report was prepared for the ISA Programme by: PwC EU Services Disclaimer: The views expressed in this report are purely those of the authors and may not, in any circumstances, be interpreted as stating an official position of the European Commission. The European Commission does not guarantee the accuracy of the information included in this study, nor does it accept any responsibility for any use thereof. Reference herein to any specific products, specifications, process, or service by trade name, trademark, manufacturer, or otherwise, does not necessarily constitute or imply its endorsement, recommendation, or favouring by the European Commission. All care has been taken by the author to ensure that s/he has obtained, where necessary, permission to use any parts of manuscripts including illustrations, maps, and graphs, on which intellectual property rights already exist from the titular holder(s) of such rights or from her Page 2

3 D02.02 CVSP-AP Table of Contents 1. INTRODUCTION SCOPE AND OBJECTIVES PROCESS AND METHODOLOGY STRUCTURE OF THIS DOCUMENT USE CASES USE CASE 1 FINDING INFORMATION ABOUT PUBLIC SERVICES MORE EASILY USE CASE 2 BUILDING USER-CENTRIC CATALOGUES OF PUBLIC SERVICES AT ALL LEVELS FROM REGIONAL TO A EUROPEAN FEDERATED CATALOGUE USE CASE 3 MANAGING PORTFOLIOS OF PUBLIC SERVICES USE CASE 4 FINDING INFORMATION OF GENERIC AND SPECIALISED PUBLIC SERVICES CORE PUBLIC SERVICE VOCABULARY APPLICATION PROFILE (CPSV-AP) MANDATORY AND OPTIONAL CLASSES AND PROPERTIES OF CPSV-AP THE PUBLIC SERVICE CLASS Identifier Name Description Keyword Sector Type Language Status Is Grouped By Requires Related Has Criterion Has Competent Authority Has Participation Has Input Has Formal Framework Produces Follows Spatial Has Contact Point Has Channel Processing time Has Cost Is Described At THE EVENT CLASS Identifier Name Description Type Page 3

4 D02.02 CVSP-AP Related Service THE BUSINESS EVENT CLASS THE LIFE EVENT CLASS THE PUBLIC SERVICE DATASET CLASS Identifier Publisher Name Landing Page THE PARTICIPATION CLASS Identifier Description Role THE CRITERION REQUIREMENT CLASS Identifier Name Type THE EVIDENCE CLASS Identifier Name Description Type Related Documentation Language THE OUTPUT CLASS Identifier Name Description Type THE COST CLASS Identifier Value Currency Description Is Defined By If Accessed Through THE CHANNEL CLASS Identifier Owned By Type Has Input Opening Hours Availability restriction THE OPENING HOURS SPECIFICATION CLASS Page 4

5 D02.02 CVSP-AP THE RULE CLASS Identifier Description Language Name Implements THE FORMAL FRAMEWORK CLASS Name Identifier Description Language Status Subject Territorial Application Type Related THE AGENT CLASS Name Identifier Plays Role Has Address THE PUBLIC ORGANISATION CLASS THE CONTACT POINT CLASS RECOMMENDED CONTROLLED VOCABULARIES EXAMPLE DESCRIPTION OF A PUBLIC SERVICE WITH CPSV-AP PUBLIC SERVICE CLASS BUSINESS EVENT CLASS EVIDENCE OUTPUT CHANNEL PUBLIC ORGANISATION CONFORMANCE STATEMENT PROVIDER REQUIREMENTS RECEIVER REQUIREMENTS ACCESSIBILITY AND MULTILINGUAL ASPECTS NAMESPACES AND PREFIXES ACKNOWLEDGEMENTS CHANGE LOG ANNEX I. DETAILED LIST OF MANDATORY AND OPTIONAL CLASSES AND PROPERTIES ANNEX II. THE CORE PUBLIC SERVICE VOCABULARY ANNEX III. KEY CONCEPTS USED THROUGHOUT THIS DOCUMENT ANNEX IV. DESCRIPTION OF 1ST LEVEL LIFE EVENTS ANNEX V. DESCRIPTION OF 2 ND LEVEL BUSINESS EVENTS ANNEX VI. DESCRIPTION OF OUTPUT TYPES Page 5

6 Page 6 D02.02 CVSP-AP

7 D02.02 CVSP-AP List of Figures Figure 1 - Request handling... 9 Figure 2 - Graphical representation of the relationships between the classes and properties of the full Core Public Service Vocabulary Application Profile Figure 3 - The classes and properties in the CPSV-AP that define the service itself Figure 4 - The classes of the CPSV-AP related to the formal (usually legal) basis for the provision of the service Figure 5 - The classes of the CPSV-AP related to communication with a Public Service Figure 6 - CPSV diagram representation of current data model List of Tables Table 1: CPSV-AP controlled vocabularies Table 2: Example of Public Service class Human readable Table 3: Example of Public Service class Machine readable Table 4: Example of Business Event class Human readable Table 5: Example of Public Service class Machine readable Table 6: Example of Evidence class Human readable Table 7: Example of Evidence class Machine readable Table 8: Example of Formal Framework class Human readable Table 9: Example of Output class Machine readable Table 10: Example of Channel class 1 Human readable Table 11: Example of Channel class 2 Human readable Table 12: Example of Channel class Machine readable Table 13: Example of Public Organisation class Human readable Table 14: Example of Public Organisation class Machine readable Table 15: Namespaces and Prefixes Table 16: CPSV-AP Working Group Members Table 17: Mandatory and optional classes and properties Table 18: Definition of key concepts Table 19: Description of 1st level life events Table 20: Description of 2nd level business events Table 21: Description of output types Page 7

8 D02.02 CVSP-AP 1. INTRODUCTION The original CPSV-AP was prepared in the context of Action Accessing Member State information resources at European level Catalogue of Services 1 of the European Commission s Interoperability for European Public Administrations (ISA) programme 2. The CPSV-AP has been seen as a first step for creating a model for describing public services related to business and life events, to facilitate the setup of catalogues of services oriented to businesses and citizens. This document defines an update to the Core Public Service Vocabulary Application Profile version 2.0 (CPSV-AP v2.0 3 ). The update finds its motivation in the experience of implementing version 2.0 of the CPSV-AP by different MSs and stakeholders and consequent requests received from them, as detailed in D02.01-Analysis on several possibilities to enhance the data model of the SC Scope and objectives Since the publication of the CPSV-AP, several Member States and European projects started to reuse and extend the data model for their own needs. The usage of this data model in national or regional contexts, has led to the identification of potential areas of improvement and extension. In undertaking to respond to the feedback received, version 2.1 has been developed with three primary aims: To add the concept of catalogue in order to cover the metadata of the origin of the sources of those public service descriptions that are collected into a common database; To extend the specifications to allow the relationship between generic, defined for instance on the national level, and specific public service descriptions with different costs, channels but also the titles and descriptions of the public service itself, for instance defined on the regional or local level; To cover additional change requests collected from different MSs and stakeholders that implemented or evaluated the CPSV-AP. This work also keeps into account the current implementations of the CPSV-AP by different entities, trying to keep the specifications as stable as possible. Once finalised reading this document, a user should be able to describe public service descriptions taking into account the caveats provided in Section 6 to be in conformance with the CPSV-AP. 1 European Commission. Interoperability for European Public Administrations (ISA). Accessing Member State information resources at European level. 2 European Commission. Interoperability for European Public Administrations (ISA) Page 8

9 D02.02 CVSP-AP 1.2. Process and methodology This common data model has been defined as an Application Profile of the ISA Core Public Service Vocabulary 4 (henceforth referred to as the CPSV-AP). An Application Profile 5 is a specification that re-uses terms from one or more base standards, adding more specificity by identifying mandatory, recommended and optional elements to be used for a particular application, as well as recommendations for controlled vocabularies to be used. The identification and handling of change requests follows the Change management release and publication process for structural metadata specifications developed by the ISA Programme. In particular this deliverable covers the request handling of the change management process. Receive Request Governance Committee Initial evaluation Operational Team Accept/reject request Governance Committee Decide on further process Governance Committee Inform Steering Committee Governance Committee Figure 1 - Request handling CPSV-AP 2.1 is developed under the responsibility of the European Commission's ISA 2 Programme 6 and the chairs of the Working Group. The Working Group is responsible for defining the specifications and is established from: Members of the EUGO Network; MS representatives from other egovernment portals; Members of the CPSV Working Group; ISA² Committee representatives; Experts on government and modelling of life events and public services; and European Institutions and initiatives (e.g. DG GROW, YourEurope, esens ). The methodology explains the specification process and its approach. It describes the elements that should be included in the specification, including use cases and Page 9

10 D02.02 CVSP-AP definition of terms (i.e. classes and properties) and recommended controlled vocabularies, based on the research and review of existing solutions. Naturally, the specification of the CPSV-AP 2.01 began with the original CPSV-AP version 2.0 and input from Member States and organisations who had first-hand experience of using it. That input is collected and analysed in D02.01-Analysis on several possibilities to enhance the data model. Work done for that analysis, and subsequent interviews with users of the CPSV-AP has led to the recording of a number of specific change requests. In the context of deliverable D02.01 of SC414, we have analysed cases that have already reused the CPSV or the CPSV-AP. Looking at these cases was interesting in order to see whether the data model that has been defined for describing public services can be implemented in practice. In general, the feedback received was positive. Of course, implementing it in the national context implied the need for adapting the model to the corresponding context. In most cases the CPSV(-AP) was extended with additional classes, properties, controlled vocabularies 1.3. Structure of this document This document consists of the following sections. Section 2 defines the main use cases that drive the specification of the Application Profile; The classes and properties defined for the Application Profile are identified in section 3; In section 4, controlled vocabularies are proposed for use as value sets for a number of properties; An example, helping to show how the CPSV-AP can be used in practice for describing a public service, is being described in section 5; Section 6 contains the Conformance Statement for this Application Profile; Accessibility and multilingual issues are addressed in section 7; Namespaces and prefixes used throughout the specifications are listed in section 8; Acknowledgements related to the development of this Application Profile are contained in section 9; Finally, in section 10, an overview of changes to the specification is provided in the change log. Page 10

11 D02.02 CVSP-AP 2. USE CASES The CPSV-AP is designed to meet the use cases described below. These are modified versions of the use cases that motivated the development of the original CPSV-AP, taking into account citizens' life events as well as business events. Although the core motivation remains the same, the scope is wider than the original set Use Case 1 Finding information about public services more easily In several countries (e.g. Austria, Spain, Germany, Belgium ) different local and regional electronic Points of Single Contact (PSCs) and egovernment portals may exist. These national, regional or local one stop-shops for public services may have different ways for making information about public services and the business or life event they correspond to, available. Information on public services is often structured according to the organisational structure of public administration within a Member State or organised by service providers. Businesses, however, expect to find information organised according to their needs or based on the business lifecycle, and thus structured according to business events. This gap makes the discovery of relevant information on the PSCs harder for businesses. The same is true for individuals seeking services relevant to life events. A citizen is unlikely to begin his or her search by examining the organisational structure of the local public administrations. Much more likely it is a search based on a change in their immediate situation, such as a birth, a child approaching school age, planning a home extension, etc. A common data model for describing public services and making it possible to group them logically into business and life events, such as the CPSV-AP, would assist public authorities in providing high-quality descriptions of public services from a user-centric perspective. In this way, businesses and citizens can find the relevant information on public services to be executed in the context of a particular event or context, without having to know how the public administration is organised. In the light of these, it is useful to have a single digital gateway for information on events and related public services, especially in the context of cross-border service delivery. A common data model for business events, life events and public services, such as the CPSV-AP, enables the flexible exchange and integration of the different public service descriptions and facilitates the publication of this information on the single digital gateway Use Case 2 Building user-centric catalogues of public services at all levels from regional to a European federated catalogue A prerequisite of the EU Single Market is the free movement of goods, services and capital across the EU. In this context, the Services Directive foresees simplification measures, such as the PSCs and egovernment portals, to increase transparency for businesses and citizens when they want to provide or use services in the single market. Page 11

12 D02.02 CVSP-AP In this light, PSCs and egovernment portals have been established at the national and regional level in the Member States. The CPSV-AP is designed to make this easier at all levels from regional to pan-european. Currently, the Your Europe Portal 7 provides the EU rules for running a business in Europe, for example. Additionally, MSs are obliged to provide information on the transposition of these rules in their country. This information is also being provided by Your Europe. A pan-european Single Digital Gateway, federating harmonised descriptions of business and life events and related public services from the MSs, could further enhance the cross-border access to these public services. Such a platform, which could extend the work of Your Europe, would then provide a unified view of public services related to business and life events across the EU Member States. It would facilitate the discovery and comparison of services, and allow businesses to make informed decisions about their investments. This would not only improve the discoverability of information within the EU, it would also lower the information access barriers for third country nationals to find their way and invest in an EU Member State. Using a common data model such as the CPSV-AP for describing public services, enables the flexible exchange and integration of service descriptions between the national/regional authorities and pan-european one-stop-shops. This way, the common data model acts as a bridge, a common language that enables mapping all different ways of describing public services, and the business and life events for grouping them, to one common basis Use Case 3 Managing portfolios of public services In most countries, the ownership and management of public services is split amongst different public administrations leading to different ways of managing their lifecycle. This makes it difficult to have a complete view of the public services offered within the context of a Member State, and to have a holistic approach for their management and the way the public services are grouped into business and life events. Public service portfolio management allows a public administration to apply a holistic and systematic management to their investments in public service provision in order to optimise their coverage of citizens and businesses needs against the overall value of their investments. Public service portfolio management improves the management of the lifecycle of public services e.g. by: Identifying for which domain, sector, business or life event public services are missing; Identifying public services that are not used or outdated; Identifying redundant public services; 7 Page 12

13 D02.02 CVSP-AP Providing information on public services of higher quality, i.e. more detailed, complete, valid and timely description of public services and the events they are grouped by. One of the key elements of any service portfolio management methodology is the use of a common data model for describing events and public services. In this vein, using a common data model, such as the CPSV-AP, provides a standardised way of documenting public services and business or life events for grouping these public services. Complete, reusable, machine-readable descriptions of public services and the events by which they are grouped will facilitate the measurement and quantification of their costs and benefits, and will enable their comparison, evaluation, monitoring, management and continuous improvement Use case 4 Finding information of generic and specialised public services Several European countries (Germany, Austria, Belgium, Spain ) are divided into regions, municipalities, etc. In these countries, a subset of public services and their descriptions varies depending on the level of appliance (national, regional or local). Catalogues of public services can publish generic descriptions at national level and point to the regional or local specialisation of the public service description on the local or regional level to get further detailed information. For instance, the cost of the public service, the service provider at local level, but also the descriptive elements of the public service itself (title, description...) etc. Using a common data model that allows describing and relating generic and specific public service descriptions helps public administrations linking the information and offering it to citizens and businesses according to the user needs. The CPSV-AP covers the relationship of different instances of public service descriptions at national, regional or local level. This way, the information can be linked throughout portals at different levels, guiding the user to the most detailed information about a public service depending on the level or location of appliance. Page 13

14 D02.02 CVSP-AP 3. CORE PUBLIC SERVICE VOCABULARY APPLICATION PROFILE (CPSV-AP) The specification of the Core Public Service Vocabulary Application Profile is represented in a series of UML class diagrams. Figure 2 shows the full profile and this is broken down into related sections in the following diagrams to ease understanding: Figure 3 shows the classes and properties that define the service itself: the necessary inputs, possible outputs, the responsible public authority and the events that trigger service use; Figure 4 shows the classes and properties that describe the context in which the service is offered. This includes relevant legislation and rules of operation for the service; and Figure 5 is about the interface between the service and its users: how and when it can be accessed. Page 14

15 Figure 2 - Graphical representation of the relationships between the classes and properties of the full Core Public Service Vocabulary Application Profile Page 15

16 Figure 3 - The classes and properties in the CPSV-AP that define the service itself. Page 16

17 Figure 4 - The classes of the CPSV-AP related to the formal (usually legal) basis for the provision of the service. Page 17

18 Figure 5 - The classes of the CPSV-AP related to communication with a Public Service Page 18

19 3.1. Mandatory and optional classes and properties of CPSV-AP To indicate the minimum requirements to comply with the CPSV-AP, the classes and properties are being classified as being mandatory or optional. A minimal implementation of the CPSV-AP at least provides information on the mandatory properties of the mandatory classes. Optional classes can still have mandatory properties for which information should be provided when the particular class is used in the description of the public services and the business events. The terms mandatory class, optional class, mandatory property and optional property have the following meaning: Mandatory class: a receiver of data MUST be able to process information about instances of the class; a sender of data MUST provide information about instances of the class. Optional class: a receiver MUST be able to process information about instances of the class; a sender MAY provide the information but is not obliged to do so. Mandatory property: a receiver MUST be able to process the information for that property; a sender MUST provide the information for that property. In case the corresponding class is classified as being optional, a receiver MUST be able to process the information for that property; a sender MUST provide the information for that property if it uses the corresponding class. Optional property: a receiver MUST be able to process the information for that property; a sender MAY provide the information for that property if it is available. All classes include the mandatory property of identifier that in Linked Data/RDF encodings will be IRIs. Where the entities do not exist independently of the Public Service, it is permissible for these to be local to the implementation, i.e. blank nodes are explicitly allowed. Global IRIs SHOULD be assigned to the Public Service itself, public organisations, events, outputs, agents, evidence and formal frameworks. The meaning of the terms MUST, MUST NOT, SHOULD and MAY in this section and in the following sections are as defined in RFC In the given context, the term "processing" means that receivers must accept incoming data and transparently provide these data to applications and services. It does neither imply nor prescribe what applications and services finally do with the data (parse, convert, store, make searchable, display to users, etc.). Detailed list of mandatory and optional classes and properties gives an overview of which classes are classified as mandatory or optional. For each class an overview is given of which properties are classified as being mandatory and for which ones the usage is optional. Additionally the proposal in Detailed list of mandatory and optional classes and properties has been discussed with the Working Group. 8 Page 19

20 3.2. The Public Service Class This class represents the Public Service itself, as it is described in a public service catalogue. A Public Service is a mandatory or discretionary set of activities performed, or able to be performed, by or on behalf of a public organisation, publicly funded and arise from public policy. Services may be for the benefit of an individual, a business, or other public authority, or groups of any of these. A service exists whether it is used or not, and the term 'benefit' may apply in the sense of enabling the fulfilment of an obligation. As defined in the revised version of the European Interoperability Framework 9, a European public service comprises any service provided by public administrations in Europe, or by other organisations on their behalf, to businesses, citizens or others public administrations. Class name Mandatory/Optional URI Public Service Mandatory cpsv:publicservice The following subsections define the properties of the Public Service class Identifier This property represents a formally-issued Identifier for the Public Service. Identifier dct:identifier Text Name This property represents the official Name of the Public Service. Name dct:title Text Description This property represents a free text Description of the Public Service. The description is likely to be the text that potential users of the Public Service see in any public service catalogue. Public administrations are encouraged to include a reasonable level of detail in the description, for instance including basic eligibility requirements for the particular Public Service and contact information. Description dct:description Text Keyword This property represents a keyword, term or phrase to describe the Public Service This property should be a URI if it is modelled in RDF. Page 20

21 Keyword dcat:keyword Text 0..n Sector This property represents the industry or sector a Public Service relates to, or is intended for. For example: environment, safety, housing. Note that a single Public Service may relate to multiple sectors. The possible values for this property are provided as a controlled vocabulary. The recommended controlled vocabularies are listed in section 4. Sector cv:sector Concept 0..n Type This property represents the type of a Public Service as described in a controlled vocabulary, for instance social protection, health, recreation, culture and religion, economic affairs... The recommended controlled vocabularies are listed in section 4. Type dct:type Concept 0..n Language This property represents the language(s) in which the Public Service is available. This could be one language or multiple languages, for instance in countries with more than one official language. The possible values for this property are described in a controlled vocabulary. The recommended controlled vocabularies are listed in section 4. Language dct:language dct:linguisticsystem 0..n Status Indicates whether a Public Service is active, inactive, under development etc. according to a controlled vocabulary. Status adms:status Concept Is Grouped By This property links the Public Service to the Event class (section ). Several Public Services may be associated with a particular Event and, likewise, the same Public Service may be associated with several different Events. Page 21

22 Is Grouped By cv:isgroupedby Event 0..n Requires One Public Service may require, or in some way make use of, the output of one or several other Public Services. In this case, for a Public Service to be executed, another Public Service must be executed beforehand. The nature of the requirement will be described in the associated Rule or Input. Requires dct:requires Public Service 0..n Related This property represents a Public Service related to the particular instance of the Public Service class. Related dct:relation Public Service 0..n Has Criterion Links a Public Service to a class that describes the criteria for needing or using the service, such as residency in a given location, being over a certain age etc. The Criterion class is defined in the Core Criterion and Core Evidence Vocabulary 11. Has Criterion cv:hascriterion Criterion 0..n Requirement Has Competent Authority This property links a Public Service to a Public Organisation, which is the responsible Agent for the delivery of the Public Service. Whether the particular Public Organisation provides the public service directly or outsources it is not relevant. The Public Organisation that is the Competent Authority of the service is the one that is ultimately responsible for managing and providing the public service. The term Competent Authority is defined in the Services Directive (2006/123/EC) in the following way: Any body or authority which has a supervisory or regulatory role in a Member State in relation to service activities, including, in particular, administrative authorities, including courts acting as such, professional bodies, and those professional associations or other professional organisations which, in the exercise of their legal 11 Page 22

23 autonomy, regulate in a collective manner access to service activities or the exercise thereof. Has Competent cv:hascompetentauthority Public 1..1 Authority Organisation Has Participation The CPSV-AP defines the two basic roles of Competent Authority and Service Provider, but this simple model can be extended if required using the Has Participation property that links to the Participation class (see section 3.6). Has Participation cv:hasparticipation Participation 0..n Has Input The Has Input property links a Public Service to one or more instances of the Evidence class (see section 3.9). A specific Public Service may require the presence of certain pieces of Evidence in order to be delivered. If the evidence required to make use of a service varies according to the channel through which it is accessed, then Has Input should be at the level of the Channel (section ). Has Input cpsv:hasinput Evidence 0..n Has Formal Framework The Has Formal Framework property links a Public Service to a Formal Framework. It indicates the Formal Framework (e.g. legislation) to which the Public Service relates, operates or has its legal basis. Has Formal cv:hasformalframework Formal Framework 0..n Framework Produces The Produces property links a Public Service to one or more instances of the Output class (see section 3.10), describing the actual result of executing a given Public Service. Outputs can be any resource, for instance a document, artefact or anything else being produced as a result of executing the Public Service. Produces cpsv:produces Output 0..n Page 23

24 Follows The follows property links a Public Service to the Rule(s) under which it operates. The definition of the Rule class is very broad. In a typical case, the competent authority that provides the public service will also define the rules that will implement its own policies. The CPSV-AP is flexible to allow for significant variation in such a scenario. Follows cpsv:follows Rule 0..n Spatial A Public Service is likely to be available only within a given area, typically the area covered by a particular public authority. A common usage of the spatial property will be to define the Administrative Territorial Unit(s) typically a country or region in which a Public Service is available. The Publications Office of the European Union offers a URI set 12 that is suitable for this purpose, e.g. Malta is identified by West Flanders by and so on. N.B. The spatial restriction is not meant to be used to describe eligibility or the speed of operation of the service. These aspects will be covered by the Criterion class. Spatial dct:spatial Concept 0..n Has Contact Point A contact point for the service is almost always helpful. The value of this property, the contact information itself, should be provided using schema:contactpoint. Note that the contact information should be relevant to the Public Service which may not be the same as contact information for the Competent Authority or any Participant. Has Contact Point cv:hascontactpoint Contact Point 0..n Has Channel This property links the Public Service to any Channel through which an Agent provides, uses or otherwise interacts with the Public Service, such as an online service, phone number or office. See section Page 24

25 Has Channel cv:haschannel Channel 0..n Processing time The value of this property is the (estimated) time needed for executing a Public Service. The actual information is provided using the ISO8601 syntax for durations. Some examples are provided below: Duration Syntax 5 years P5Y 1 month P1M 3 days P3D 2 days 4 hours P2DT4H Durations begin with an uppercase P followed by the number and the relevant designator, formally: P[n]Y[n]M[n]DT[n]H[n]M[n]S, where Y is for years, M for months etc. Note that days and times are separated by an uppercase T which also disambiguates M as meaning month (P2M means 2 months) or minute (PT2M means 2 minutes). Durations may also be defined as a number of weeks so P4W means 4 weeks. A full explanation is provided in the Wikipedia page 13 that references the official ISO standard 14. This approach is consistent with both schema.org and the W3C OWL Time Ontology. Processing Time cv:processingtime Text Has Cost The Has Cost property links a Public Service to one or more instances of the Cost class (see section 3.11). It indicates the costs related to the execution of a Public Service for the citizen or business related to the execution of the particular Public Service. Where the cost varies depending on the channel through which the service is accessed, it can be linked to the channel using the If Accessed Through relationship (section ). Has Cost cv:hascost Cost 0..n Is Described At The Is Described At property links a Public Service to the Public Service Dataset(s) (see 3.6) in which it is being described (see section 3.6) Page 25

26 Is Described At cv:isdescribedat Public Service Dataset 0..n 3.3. The Event Class This class represents an event that can be of any type that triggers, makes use of, or in some way is related to, a Public Service. It is not expected to be used directly, rather, one or other of its subclasses should be used. The properties of the class are, of course, inherited by those subclasses. The Event class is used as a hook either to a single related Public Service, such as diagnosis of illness being related to application for sickness benefit (section 3.3.5); or to a group of Public Services, such as all those related to the establishment of a new business (see section 3.2.9). Class name Mandatory/Optional URI Event Optional cv:event Identifier This property represents an Identifier for the Event. Identifier dct:identifier Text Name This property represents the Name (or title) of the Event. Name dct:title Text Description This property represents a free text description of the Event. The description is likely to be the text that a business or citizen sees for that specific Event when looking for relevant Public Services. Public administrations are therefore encouraged to include a reasonable level of detail in the description. Description dct:description Text Type The type property links an Event to a controlled vocabulary of event types and it is the nature of those controlled vocabularies that is the major difference between a business event, such as creating the business in the first place and a life event, such as the birth of a child. Type dct:type Concept 0..n 15 This property should be a URI if it is modelled in RDF. Page 26

27 Related Service This property links an event directly to a public service that is related to it. Related Service dct:relation Public Service 0..n 3.4. The Business Event Class This class represents a Business Event, which specialises Event. A Business Event is a specific situation or event in the lifecycle of a business that fulfils one or more needs or (legal) obligations of that business at this specific point in time. A Business Event requires a set of public services to be delivered and consumed in order for the associated business need(s) or obligation(s) to be fulfilled. Business Events are defined within the context of a particular Member State. In other words, a Business Event groups together a number of public services that need to be delivered for completing that particular event. Class name Mandatory/Optional URI Business Event Optional cv:businessevent 3.5. The Life Event Class The Life Event class represents an important event or situations in a citizen's life where public services may be required. Note the scope: an individual will encounter any number of 'events' in the general sense of the word. In the context of the CPSV- AP, the Life Event class only represents an event for which a Public Service is related. For example, a couple becoming engaged is not a CPSV-AP Life Event, getting married is, since only the latter has any relevance to public services. Class name Mandatory/Optional URI Life Event Optional cv:lifeevent 3.6. The Public Service Dataset Class The Public Service Dataset, is a specialisation of the Dataset class of the Data Catalog Vocabulary (DCAT) 16 and inherits all its properties. The class describes the metadata of where the dataset is being described, for instance on a regional public service portal and/or a national egovernment portal. Class name Mandatory/Optional URI Public Service Dataset Optional cv:publicservicedataset The properties being described in the following sections define the mandatory properties if the class is being instantiated. We refer to DCAT for the definition of the other properties being inherited Page 27

28 Identifier This property represents an Identifier for the Public Service Dataset. Identifier dct:identifier Text Publisher This property represents the Publisher of the Public Service Dataset, i.e. an entity (organisation) responsible for making the Public Service Dataset available. Publisher dct:publisher Agent Name This property contains a name given to the Public Service Dataset. This property can be repeated for parallel language versions of the name. Name dct:title Text 1..n Landing Page This property refers to a web page that provides access to the Public Service Dataset. It is intended to point to a landing page at the original data provider, not to a page on a site of a third party, such as an aggregator. Landing Page dcat:landingpage Document 1..n 3.7. The Participation Class The CPSV-AP recognises a common role connected with public services, i.e. the Competent Authority (section ). However, this simple structure does not allow statements to be made about those participants, such the start and end date of a contract, nor does it support the inclusion of other roles. The Participation class supports this extra complexity if required, for instance, the description of a service user or a service provider. The model is consistent with the CPOV which in turn is based on the W3C Organization Ontology that supports the common cases simply but allows the complex cases where necessary. The Participation class can be mapped to the Organization Ontology s Membership class that allows more complex relationships and richer metadata to be applied to a role filled by a given Agent. Class name Mandatory/Optional URI Participation Optional cv:participation 17 This property should be a URI if it is modelled in RDF. Page 28

29 Identifier This property represents an Identifier for the Participation. Identifier dct:identifier Text Description A free text description of the Participation. Description dct:description Text Role Provides the role played. This should be provided using a controlled vocabulary. Since this is an extension mechanism for the CSPV-AP, the controlled vocabulary should be decided to suit local implementations. Role cv:role Concept 1..n 3.8. The Criterion Requirement Class Not all public services are needed or usable by everyone. For example, the visa service operated by European countries is not needed by European citizens but is needed by some citizens from elsewhere, or public services offering unemployment benefits and grants are targeting specific societal groups. The CPSV reuses the Core Criterion and Core Evidence Vocabulary 19 for this class. The CCCEV provides more details but the Criterion Requirement class has three mandatory properties. Class name Mandatory/Optional URI Criterion Requirement Optional cv:criterionrequirement Identifier This property represents an Identifier for the Criterion Requirement. Identifier dct:identifier Text Name This property represents the official Name of the Criterion Requirement. 18 This property should be a URI if it is modelled in RDF This property should be a URI if it is modelled in RDF. Page 29

30 Name dct:title Text Type This property represents the type of Criterion Requirement as described in a controlled vocabulary. The recommended controlled vocabularies are listed in section 4. Type dct:type Concept 0..n 3.9. The Evidence Class The Evidence class is defined in the Core Criterion and Core Evidence vocabulary (CCCEV) as any resource that can document or support a criterion response. It contains information that proves that a criterion requirement exists or is true, in particular evidences are used to prove that a specific criterion is met. Although the wording of the definition is different, the semantics are an exact match for CPSV's Input class which it replaces. Evidence can be any resource - document, artefact anything needed for executing the Public Service. In the context of Public Services, Evidence is usually administrative documents or completed application forms. A specific Public Service may require the presence of certain Evidence or combinations of Evidence in order to be delivered. In some cases, the Output of one service will be Evidence for another service. Such relationships should be described in the associated Rule(s). Class name Mandatory/Optional URI Evidence Optional cv:evidence Identifier This property represents an Identifier for the piece of Evidence. Identifier dct:identifier Text Name This property represents the official Name of the piece of Evidence. Name dct:title Text This property should be a URI if it is modelled in RDF. Page 30

31 Description This property represents a free text Description of the piece of Evidence. Description dct:description Text Type This property represents the type of Evidence as described in a controlled vocabulary. The recommended controlled vocabularies are listed in section 4. Type dct:type Concept Related Documentation This property represents documentation that contains information related to the Evidence, for instance a particular template for an administrative document, an application or a guide on formatting the Input. Related Documentation foaf:page Document 0..n Language Indicates the language(s) in which the Evidence must be provided. Language dct:language Concept 0..n The Output Class Outputs can be any resource - document, artefact anything produced by the Public Service. In the context of a Public Service, the output provides an official document or other artefact of the Competent Authority (Public Organisation) that permits/authorises/entitles an Agent to (do) something. In some cases, the Output of one Public Service will be used as evidence to fulfil a criterion requirement of another Public Service. Such relationships should be described in the associated Rule(s). Class name Mandatory/Optional URI Output Optional cv:output Identifier This property represents an Identifier for the Output. Page 31

32 Identifier dct:identifier Text Name This property represents the official Name of the Output. Name dct:title Text Description This property represents a free text Description of the Output. Description dct:description Text Type This property represents the type of Output as defined in a controlled vocabulary. The recommended controlled vocabularies are listed in section 4. Type dct:type Concept 0..n The Cost Class The Cost class represents any costs related to the execution of a Public Service that the Agent consuming it needs to pay. Class name Mandatory/Optional URI Cost Optional cv:cost Identifier This property represents an Identifier for the Cost. Identifier dct:identifier Text Value This property represents a numeric value indicating the amount of the Cost. Value cv:value Number Currency This property represents the currency in which the Cost needs to be paid and the value of the Cost is expressed. The possible values for this property are described in 22 This property should be a URI if it is modelled in RDF. 23 This property should be a URI if it is modelled in RDF. Page 32

33 a controlled vocabulary. The recommended controlled vocabularies are listed in section 4. Currency cv:currency Concept Description This property represents a free text description of the Cost. Description dct:description Text Is Defined By This property links the Cost class with one or more instances of the Public Organisation class (section 3.17). This property indicates which Public Organisation is the Competent Authority for defining the costs associated with the delivery of a particular Public Service. Is Defined By cv:isdefinedby PublicOrganisation 0..n If Accessed Through Where the cost varies depending on the channel used, for example, if accessed through an online service cf. accessed at a physical location, the cost can be linked to the channel using the If Accessed Through property. If Accessed cv:ifaccessedthrough Channel 0..1 Through The Channel Class The Channel class represents the medium through which an Agent provides, uses or interacts in another way with a Public Service. Typical examples include online services, phone, walk-in centres etc. Class name Mandatory/Optional URI Channel Optional cv:channel Identifier This property represents an Identifier for the Channel. Identifier dct:identifier Text This property should be a URI if it is modelled in RDF. Page 33

34 Owned By This property links the Channel class with one or more instances of the Agent class (section 3.16). This property indicates the owner of a specific Channel through which a Public Service is being delivered. Note that Public Organisation is a sub class of Agent so that if the owner is the Public Organisation, the ownedby property can link to it. Owned By cv:ownedby Public Organisation 0..n Type This property represents the type of Channel as defined in a controlled vocabulary. The recommended controlled vocabularies are listed in section 4. Type dct:type Concept Has Input In the majority of cases, the evidence required to use a Public Service will be independent of the channel through which the service is accessed. The Has Input property should normally be used to link a Public Service directly to one or more pieces of Evidence (see section 3.9). However, where the type of Evidence required varies according to the channel used to access the Public Service, then the Has Input property may be used at the Channel level. For example, a digital signature may be required for an online channel, whereas a physical signature may be required for a face to face service provision. Has Input cpsv:hasinput Evidence 0..n Opening Hours This property represents the normal opening hours of a channel. The value should follow the flexible format defined for schema.org's opening hours property 25. Following that structure, days of the week are represented by two letter codes (Mo, Tu, We, Th, Fr, Sa, Su). Lists should be comma separated (for example: Mo, We, Fr) and periods separated by a hyphen (for example: Mo-Fr). If it is appropriate to add opening hours then this follows the day so if a phone service is available 08:00 20:00 Monday to Saturday and 08:00 18:00 on Sundays that would be encoded as Mo-Sa 08:00-20:00, Su 08:00-18:00. Opening Hours schema:openinghours Text 0..n 25 Page 34