Navigation path

Core Public Service

(
 
)
4.8/5 | 10 votes
Editor's choice

Available Translations

Available Translations:

Core Public Service Vocabulary 0.07

(
 
)
5/5 | 2 votes | 1596 reads |
Editor's Choice

Description

Draft asset release of the CPSV sent ouf for public review. 

To provide feedback on the CPSV specification, you may: 

The Public Review Period will run between 8 February and 27 February 2013. 

Phil Archer
Posted by Phil Archer on March 05, 2013 at 12:11
"

In reply to Own Ambur.

Thanks very much Owen for your comments here and through 1-1 e-mails. Let me try and collate them and provide some responses.

1) Inputs and Outputs: The StratML definition of these classes is, I think, helpful and fully in line with the CPSV meaning. Therefore I've added the StratML text to the CPSV text directly so that it now says:

"Inputs and outputs can be any resource - document, artefact - anything. This is in line with, for example, StratML [StratML] which defines an input as 'A resource to be processed to produce an output.' and an output as 'An intended result whose required inputs and processes are entirely within the control of the planning organisation.' In a specific context..." 

Where I disagree is that the model suggests that governments and users don't care what the outcome (cf. output) may be. The intention of the CPSV is to model the service itself, not its societal effects. This is made clear with a specific reference to StratML's outcome class in the introductory discussion of the domain model (section 4.1). CPSV can be used within broader model but has a very specific focus.

2 & 3) The use of dcterms:Agent as the class of anything that has the power to act is pretty much universal. It's defined as part of the Dublin Core Metadata Set that comes originally from the library community (the name derives from the location of the first meeting which was not in Dublin itself but the Ohio city of the same name). Conceptually, the StratML concept of Stakeholder is a sub class of dcterms:Agent since a stakeholder is an agent with the added feature of having an interest in the service. I hesitate to estimate the number of instances of dcterms:Agent on the Web (and its equivalent class foaf:Agent and its sub classes foaf:Person, foaf:Organization and foaf:Group) but the debate is whether it's in the billions or tens of billions. My counter recommendation to you is that you consider defining stratml:Stakeholder as a sub class of dcterms:Agent. Doing that brings StratML, Dublin Core, FOAF and, more importantly, common online practice, into alignment.

We use the hasRole property and its sub properties (provides and uses) to indicate that a given Agent is a stakeholder so the concepts are in alignment, i.e. there is an explicit link between an Agent and the Service.

4) Understood. The distinction made is between legislation and the manner in which a particular service operates. The latter will be decided by the service providers (or service commissioners) and do not have legal force. It's that difference that we're capturing. The origin of the rules and legislation is handed by the dcterms:creator.

5) CPSV uses the class dcterms:Location in two ways. One describes the location covered by the service - usually a country or region (US Passports are available in the US, the service that issues UK driving licenes is only available in the UK etc.). The link from the Service to the Location is covered by the dcterms:spatial relationship. Separately, we use a newly minted term of physicallyLocatedAt to link a service to an actual office where you can obtain/interact with the service. So I think we're pretty much in alignment here. 

The label for dcterms:spatial is 'Spatial Coverage' - i.e. the boundary of where the described thing is relevant.

Summary

It seems to me that StratML could be useful in describing the Rules that govern a service and, no doubt in some contexts, describing the service itself. The alignment of the concepts is a good feature and should make transformation from one to the other possible. We're trying here to represent the core elements of a service as a data set, one that would almost certainly only form part of a bigger picture. The re-use of well established and massivley implemented vocabularies like Dublin Core is best practice and one I am confident we should follow.

Phil Archer
Posted by Phil Archer on March 04, 2013 at 16:15
"

In reply to Mauricio Marinho Formiga

Thanks very much Mauricio for your comments. Let me deal with them in turn.

I don't there's much room for confusion over the use of PeriodOfTime but I have amended the description to take account of your comment. What we now say about both dcterms:spatial and dcterms:temporal is:

N.B. These restrictions are not meant to be used to describe eligibility or the speed of operation of the service. These aspects will be covered by the Rule. 

Details of how to contact a service provider will be given as properties of the relevant foaf:Agent class. They are clearly an important part of any information about a service, but these aspects are well modelled using FOAF, the Org Ontology, vCard etc. and so I don't think we need to include them specifically here.

Your last point is very interesting. If I understadn you correctly, you're saying that datya can be published on how you obtain a given output (such as a lost driving licence?). That's actually an interesting use case and I think we have it covered. Suppose we have data on the service for issuing a new driving licence. The Output will be of type Driving Licence' (or Driving License for Americans ;-) ) I can then set up a service that says "here's what you do if you lose your licence" and, because th data is available, I can find out that the class of document known as a Driving Licence is provided by a given service. 

In other words, we meet your use case already because the type of output will be described. In the text we say (emphasis added):

Inputs and outputs can be any resource - document, artefact - anything. In a specific context it is likely to be useful to either define a sub class or declare the particular resource to also be of another type as well. A general case might be a foaf:Document but where possible, it is better to refer to a controlled vocabulary of types. dcterms:type should be used to use to provide this information and, in RDF implementations, it should link to a SKOS Concept [SKOS].

Have I answered your concerns?

Thanks again for taking the time to comment - it is much appreciated.

Phil.

Mauricio Marinho Formiga
Posted by Mauricio Marinho Formiga on February 20, 2013 at 23:40
"

Dear Workgroup Members,

  By government decree, in Brazil organizations should publish information on services provided to citizens with the submission deadline for the completion of the service, ie the commitment of the agency to deliver the result of the service within a specified time. The entity dcterms: PeriodOfTime should not contemplate this concept.

  Another item refers to forms of service provision. There are services that can be performed electronically (url, email, sms), phone or at the physical address of the organization or service stations.

  Could be inserted in the model procedures to receive, serve, manage and respond to suggestions and complaints service. Here in Brazil there is always a department's agency that handles these issues. All contact information for this department should be disseminated to the information service.

  Finally, I believe that we could enter the model services related to a particular service, for example, when the citizen loses some document and opens police report on the website of the police, it would be interesting to help inform citizens of government services related to obtaining another via of the document.

Regards,

Maurício Marinho
IT Analyst
Department of Electronic Government - DGE
Brazil

Owen Ambur
Posted by Owen Ambur on February 20, 2013 at 16:22
"

Nikolaos Loutas asked me to post here the message I sent to Phil Archer on February 7:

Phil, as promised, here are some of my thoughts on some of the touch points between the CPSM and StratML:
 
1)  CPSM positions Public Service between Input & Output.  In StratML, the Value Chain for which Performance Indicators may be documented is comprised of: Input, Input_Processing, Output, Output_Processing, and Outcome (as shown in the screen shot from my InfoPath form below).  So in terms of performance indicators, CPSM’s concept of “public service” may be equivalent to input processing in StratML.  However, CPSM does not appear to contemplate the concepts of output processing or outcomes, which are the desired results for the stakeholders of the beneficiary type.  The thought of CPSM seems to be that government will shove some stuff out the door and whether it achieves the desired results or not is not the government’s concern.
 

[screen shot does not appear in this interface]

      
2)  CPSM uses the term Agent with generally the same meaning as stratml:Stakeholder but CPSM’s focus seems to be more on stakeholders of the performer type rather than of the beneficiary type (thus implying the bureaucracy is more important than the citizen).  In StratML stakeholders can be named and identified and their roles can be named and identified at multiple levels in the schema: Organization (the organization compiling the plan or report), Goal (longer term results to be achieved), and Objective (desired near-term results).  
 
The following screen shot shows how those elements appear in my InfoPath form.  Note that stakeholders may be of the both the performer as well as the beneficiary type. (For example, students are not merely taught but must also learn.  Applicants for unemployment insurance may be expected to look for jobs and/or participate in job training, but nothing may be expected of many recipients of traditional welfare assistance to which they are deemed to be “entitled,” as human beings.)  Each stakeholder may have multiple roles and each role may be named and described.
 

[screen shot does not appear in this interface]

                   
3)  In CPSM agents may be organizations, groups, or persons.  In StratML Parts 1 & 2, stakeholders are not distinguished as those types (merely as performers or beneficiaries or both).  However, in StratML Part 3, we are planning to enable stakeholders to be distinguished as Persons, Organizations, or Generic Groups, as shown in this screen shot:
 

[screenshot does not appear in this interface]
 
 
4)  CPSM includes the concept of Rules as distinguished from Legislation or Policy.  In StratML Part 3 we are planning to include an element for Authority(ies) under which goals are being pursued, as shown in this screen shot:
 

[screen shot does not appear in this interface]
 

From the perspective of StratML, the hierarchy among documentary authorities, e.g., the Constitution, U.S. Code (the law), the U.S. Code of Regulations (rules), and agency “policies” or implementation guidelines is irrelevant.  For anyone who cares about such hierarchies, other sources are available.  The focus of StratML is what is to be accomplished, by whom, and for whose benefit.  The structure of the bureaucracy and the documentary authorities undergirding it are largely irrelevant.
 
5)  The CPSM includes the concept of Location, to be used to indicate where the public service is available “from”.  In StratML Part 3 we plan to enable the identification of places to which goals apply, as shown in the screen shot below.
 

[screen shot does not appear in this interface]
 

For StratML, the place where the service is produced is largely irrelevant.  Again, what matters is results, and to the degree that they may be geo-specific, the places to which they apply may be named. However, in StratML Part 3 we are planning to enable the categorization of both stakeholders and objectives under any and all taxonomies as desired.  So those elements could be used to categorize stakeholders (both performers as well as beneficiaries) as well as objectives under geographical taxonomies.  As shown in this screen shot, point of contact information can also be provided:

 

[screen shot does not appear in this interface] 
 

No doubt, there may be other potential touch points as well, but this is probably enough complexity for now.  I hope this information is useful to you.

Johann Höchtl
Posted by Johann Höchtl on February 20, 2013 at 15:48
"

Thank you for giving the public the opportunity to provide feedback on
the CPSV. Hopefully one or another of my obersavtions might be useful:

  • foaf:homepage (The Web page through which the service is available.) I think this is somewhat limiting. My guess is that this URL will point to a homepage, a service endpoint (API), ...  If this is the case, a broader concept might be better.
  • follows (object type): My speculation is that follows will also describe the terms of service, license, and authentication requirements? If this is the case, the description might be more specific on this point.
  • Input / Output to Service. Clearly every process will require input and result in some form of output. However this conceptional distinction would not allow Output of service A to be input to service B. I think this should be described in more detail or Input / Output renamed to Artefact or Resource or some more generic term.

Johann

Metadata

Type: Interoperability Solution
Solution category:
Framework
Interoperability level:
Semantic
Publisher:
Related solutions:
Solution type:
Semantic View
Status:
Under development
Date of creation:
17 Jan 2013 - 22:06
Date of last modification:
5 Dec 2014 - 15:04