Conceptual Model v 0.02


 

Following the kick off meeting, I have made changes to the concept model. As ever, this is intended as a dicussion point - what's missing that should be there, what's there that should be removed?

Starting from the Public Service class, we can see that there is an associated process that, new for this version, has inputs and outputs. These could be anything - documents, meetings, actions, life events.

As before, the process is subject to policies, plans and legislation. I've added in a new relationship "compliesWith" that can link a Process or a Service to a piece of legislation or a policy.

I've added in a target Community and the partOf/hasPart relationships to link services that include other services (these are Dublin Core terms). The (new) related relationship links any service to anotehr that is in some way related (more Dublin Core!).

Coverage/Extent is the Dublin Core class that covers temporal, spatial or jurisdictional restrictions on something. i.e. opening hours, area covered etc. DC provides the relevant properties and sub classes for this but doesn't expressly have a concept of something applying to an age bracket so this may not be a perfect fit but it looks pretty close and matches what we've used in other vocabularies. Coverage/Extent is very broad and can be specialised, for example, to a specific location (cf. INSIPRE Team's comments)  and/or temporal (opening hours, seasonal availability etc. - cf. Muriel's comments). 

I've removed the Agreement class.

An Agent can be a user or a provider, a group, organisation or individual. I've re-used the membership/role structure defined in the Organisation Ontology. The same ontology gives us the physical site(s) for a service to which contact information etc. can be added. The specialisation of ORG, the Registered Organisation Vocabulary, RegOrg, that began life here as the Core Business Vocabulary, provides the means to link registered businesses (cf. Fergal's comments). 

Looking back over my notes from the meeting I think that's most of the comments covered. Do you agree? Two areas I'm not sure about:

  1. Periodicity, on demand etc. Does the coverage/extent class cover this or do we need something more specific?
  2. Service specification. My feeling is that the Process(es) and the (natural language) description might be sufficient. But it would be easy to add in a class of "service specification" if the WG felt it needed something specific to cover this?

Comments are very welcome.

Nature of documentation: Unpublished work

Categorisation

Type of document
Document
Licence
European Union Public License, Version 1.1 or later (EUPL) 

Comments

Thu, 06/12/2012 - 12:54

I was thinking about a property for the input or the Public Service. Here in Brazil many services requires a fee for execute the service. Like if you have lost your driver's licence you need to pay a fee for another one.

Fri, 07/12/2012 - 11:09

The existence of Input raises the following question: should Processes be broken down to tasks/sub-processes? Input is sometimes dependent on particular tasks of a process that a public service is responsible for. For instance, iterating through legal documents and signatures between the service user and different members of the public service would suppose that different input is required within tasks of the same process.

Fri, 07/12/2012 - 13:53

@Carlos, I agree with you that input is an essential class in the model. In case of public services, input can be an administrative document, a fee or a piece of information. This was raised as an issue during the 1st online meeting and it was well-spotted by some people that in some cases the input to a service comes from another service. 

@Marios: I agree that the input to a service can vary depending on what is know as the service versioning or service variability issue and that different pieces of input information are actually processed by different steps in the service process. However, modelling this would require process modelling and service (pre)condition modelling (to decide which piece of input is required in which case and is processed by which subprocess or task). I believe that this level of detail is beyond the scope of the Core Public Service Vocabulary.  

Mon, 10/12/2012 - 10:01

Proposals for the conceptual model v. 0.02

Hi,

On the question what could be added/removed, I would like to help by refering to a proposal worked out with as basis many references in civil service reference models.

You may find it here: https://joinup.ec.europa.eu/asset/services/release/release01-initial-version

If you think this would be of any help, please use it freely. Ivo and myself presented this work, framed in the Enterprise Architecture next release.

If we can use any ideas from this working group, we will not hesitate to include it also.

Kind regards

Eddy.

Sun, 24/02/2013 - 16:05

It is good to see the new Community element, which appears to be equivalent to stratml:Stakeholder of the beneficiary type. 

 

However, a link should be drawn between Output and Community, i.e., the output should "benefit" the community (thereby enabling realization of the desired outcome).

 

Is the Community not a group of people, which is also one of the definitions of Agent?  If so, the two concepts could be melded into one, with attribution as to which stakeholder type (performer or beneficiary) applies. 

 

That's how the concept of people as stakeholders is treated in the StratML standard.  Part of the logic for doing so is that -- as human beings -- "we're all in this together" (seeking to produce the desired results) rather than in disconnected, opposing camps viewing each other as aliens.

 

As currently depicted, the concept of Public Service seems to be redundant to the concept Process &/or an Agent. 

 

In the StratML standard, processes may be documented as occurring between inputs and outputs as well as between outputs and outcomes.  Different "agents" (stakeholders of the performer type) may be engaged in carrying out each process.

 

Indeed, to transform outputs into outcomes the stakeholders of the beneficiary type may also be required to serve the performer (agent) role.

The content of this field is kept private and will not be shown publicly.