Population Projections in Ontario: The Case for Returning to Life Cycle Groupings

Background

Every year the Ministry of Finance updates its population projections for Ontario and each of its 49 census divisions to reflect the most recent trends and historical data. The Spring 2016 update is based on new 2015 population estimates from Statistics Canada and reflects minor changes in trends in fertility, mortality and migration.

Map of Ontario Census Divisions
Figure 1. Map of Ontario Census Divisions. Source: Ministry of Finance, Ontario Population Projections Update, Spring 2016.

The Ministry of Finance includes several Charts and Tables that reference various demographic groupings in its analysis of these population projections:

Demographic Groupings
Single Years (0, 1, …, 90+) Statistical Table 6
Five-Year Groupings (0-4, 5-9, …, 85-89, 90+) Statistical Tables 7-10
Life Cycle Groupings (0-14, 15-64, 65+) Charts 5-6, 10-12
Statistical Table 2

To assist in planning, delivering, and evaluating human services – particularly those for young people – we want to differentiate Youth (15-24 years old) from Adult (25-64) instead of using the Ministry of Finance’s original definition of “Adult”: 1

  • Children (0- 14 years old)
  • Youth (15 – 24)
  • Adults (25 – 64)
  • Seniors (65+)

For the interested reader, we have compiled a set of Statistical Tables that restate the population projections for Ontario in terms of our Life Cycle Groupings.

Now, let’s review the highlights of the Ministry of Finance’s analysis.

Provincial overview

The Ministry of Finance considers three scenarios of population growth in Ontario. The medium-growth or reference scenario – the most likely to occur if recent trends continue – projects population growth of 30.1 per cent, from 13.8 million in 2015 to more than 17.9 million in 2041 (Chart 1).

Ontario population, 1971 to 2014
Chart 1. Ontario population, 1971 to 2014. Source: Ministry of Finance, Ontario Population Projections Update, Spring 2016.

The rate of population growth in Ontario in the reference scenario is projected to decline gradually from 1.2 per cent to 0.8 per cent annually (Chart 2).

Annual rate of population growth in Ontario, 1971 to 2041
Chart 2. Annual rate of population growth in Ontario, 1971 to 2041. Source: Ministry of Finance, Ontario Population Projections Update, Spring 2016.

Components of population growth

In any given year, the share of population growth due to natural increase versus net migration varies. While natural increase trends evolve slowly, net migration can be more volatile, mostly due to swings in inter-provincial migration and variations in international immigration.

Natural increase

The number of births and deaths in Ontario has been rising slowly and at a similar pace over the last decade. As a result, natural increase has been fairly stable at about 50,000 annually. The rate of population growth due to natural increase over the projection period is affected by two main factors:

  • The passage of the baby boom echo generation (children of baby boomers) through peak fertility years will result in an increased number of births through the late 2010s and early 2020s.
  • The transition of large cohorts of baby boomers into the Seniors group.

Overall, natural increase is projected to be fairly stable around 55,000 over the first decade of the projections, followed by a steady decline to less than 17,000 by 2041. The share of population growth accounted for by natural increase (versus net migration) is projected to decline from 32 per cent in 2016 to 11 per cent by 2041 (Chart 3).

Net migration

Net migration to Ontario has averaged about 77,000 per year in the past decade. Net migration is projected to be higher at the beginning of the projection period than it has been during the past few years, as net losses of population through inter-provincial migration have recently turned to gains and federal immigration targets have been raised significantly.

Ontario’s annual net migration gain is projected to increase from 114,000 in 2016 to 130,000 by 2041. The share of population growth accounted for by net migration (versus natural increase) is projected to rise from 68 per cent in 2016 to 89 per cent by 2041 (Chart 3).

Contribution of natural increase and net migration to population growth in Ontario, 1971 to 2041.
Chart 3. Contribution of natural increase and net migration to population growth, 1971 to 2041. Source: Ministry of Finance, Ontario Population Projections Update, Spring 2016.

Age structure

The Ministry of Finance displays the distribution of age among the people of Ontario in the familiar form of an age pyramid (Chart 4) and shows how age structure impacts the share of population (Chart 5) and the rate of population growth (Chart 6) accounted for by three Life Cycle Groupings (0-14, 15-64, 65+ years old).

Using our four Life Cycle Groupings ((0-14, 15-24, 25-64, 65+ years old), we have redrawn the projected share of population (Chart 5-PGA) and the projected rate of population growth (Chart 6-PGA):

Age pyramid in Ontario, 2015 and 2041.
Chart 4. Age pyramid in Ontario, 2015 and 2041. Source: Ministry of Finance, Ontario Population Projections Update, Spring 2016.
Proportion of population aged 0-14, 15-64, and 65+ in Ontario, 1971 to 2041
Chart 5. Proportion of population aged 0-14, 15-64, and 65+ in Ontario, 1971 to 2041. Source: Ministry of Finance, Ontario Population Projections Update, Spring 2016.
Proportion of population aged 0-14, 15-24, 25-64, and 65+ in Ontario, 2016 to 2041
Chart PGA 5. Proportion of population aged 0-14, 15-24, 25-64, and 65+ in Ontario, 2016 to 2041. Source: Ministry of Finance, Ontario Population Projections Update, Spring 2016.
Annual rate of growth of population age groups 0-14, 15-64, and 65+ in Ontario, 1971 to 2041
Chart 6. Annual rate of growth of population age groups 0-14, 15-64, and 65+ in Ontario, 1971 to 2041. Source: Ministry of Finance, Ontario Population Projections Update, Spring 2016.
Annual rate of growth of population age groups 0-14, 15-24, 25-64, and 65+ in Ontario, 2017 to 2041
Chart PGA 6. Annual rate of growth of population age groups 0-14, 15-24, 25-64, and 65+ in Ontario, 2017 to 2041. Source: Ministry of Finance, Ontario Population Projections Update, Spring 2016.

The Ministry of Finance includes the following analysis (pp. 8-10):

By 2041, there will be more people in every age group in Ontario compared to 2015, with a sharp increase in the number of seniors. Baby boomers will have swelled the ranks of seniors; children of the baby boom echo generation will be of school-age; and the baby boom echo cohorts, along with a new generation of immigrants, will have bolstered the population aged 15–64. ...

The number of children aged 0–14 is projected to increase gradually over the projection period, from 2.2 million in 2015 to almost 2.7 million by 2041. The share of children in the population is projected to decrease from 15.9 per cent in 2015 to 14.9 per cent by 2041. By the late 2030s, the number of children is projected to grow at a much slower pace than other age groups, reflecting the smaller number of women in their 20s and 30s. ...

Within the 15–64 age group, the number of youth aged 15–24 is initially projected to decline slightly, from a high of 1,827,000 in 2015 to a low of 1,725,000 by 2022. The youth population is then projected to resume growing, reaching almost 2.1 million by 2041. The youth share of total population is projected to decline from 13.2 per cent in 2015 to 11.1 per cent by 2033, followed by a small rise to 11.5 per cent by 2041. ...

In this last paragraph, the Ministry of Finance makes its one and only substantial reference to “youth” – yet it’s a pretty important point: While the number of Youth in Ontario is projected to decline over the next five years, their numbers will increase steadily thereafter – in fact, becoming the fastest growing demographic by the end of the projection period. The Ministry’s graphics (Charts 5-6), unfortunately, obscure what’s going on here – as is immediately apparent when we differentiate Youth (15-24 years old) from Adult (25-64) using the Life Cycle Groupings  (Charts PGA 5-6).

Next time: We “drill down” to the level of the region and census division – where the planning, delivery and evaluation of human services take place or where, at least, I’d argue that they should. Meanwhile, the interested reader may want to consult our Statistical Tables that restate the population projections for Ontario in terms of the Life Cycle Groupings.

  1. In fact, Statistics Canada used these four Life Cycle Groupings until 2007. In this sense, we’re arguing for the return to Life Cycle Groupings when it comes to understanding population projections – especially when one is concerned with young people. The Ministry of Finance refers to “youth” only twice – once in passing while noting that some census divisions of Northern Ontario experiencing net out-migration, mostly among youth (p. 12) and once in the context of a more substantial discussion of changes in the annual rate of population growth due to age structure (p. 10, and see below).

Zaino, Jennifer – Ontology Plays a Part in United Nations Sustainable Development Goals Project – 20160303

Zaino, Jennifer – Ontology Plays a Part in United Nations Sustainable Development Goals Project – 20160303

How do you define “basic services”? What’s the difference between them and “essential services”? What is meant by terms like “natural capital”, “raw material” or “essential medicines”? How do these all fit into an ontology?

The truth is that there often aren’t universally accepted or precise definitions for terms like these – or even more simple ones, like “forest” – as they relate to their use in the United Nations Environment Program’s (UNEP) Sustainable Development Goals Project. The Sustainable Development Goals (SDG) – successors to the UN’s Millennial Development Goals, which expired last year – are a set of 17 goals and 169 targets to be achieved by 2030 to promote human prosperity worldwide while protecting the environment and addressing climate change.

For example, within the goal of ending poverty in all its forms everywhere, targets include reducing at least by half the proportion of men, women, and children who live in poverty in all its dimensions (according to national definitions); to implement nationally appropriate social protection systems and measures for all; and, to reduce poor people’s exposure and vulnerability to climate-related extreme events and other economic, social, and environmental shocks and disasters. Each goal’s targets will have one or more indicators, which are linked to specific data points that UN statisticians and the general public can monitor to assess progress on that issue.

For the project to come together in a way that ensures data quality and transparency and sets the stage to enable more accurate analysis and measurement of progress, the Sustainable Development Goals Interface Ontology (SDGIO) is being developed to represent the various facets of the SDGs.

An ontology is a structured set of terms and logical relations that represents not only the data, but what the data is about, says Mark Jensen, who is working on the UNEP ontology effort as a consultant. Jensen is pursuing his Ph.D. in the Department of Biomedical Informatics in the Jacobs School of Medicine and Biomedical Sciences at the University at Buffalo.

“An important distinction that well-made ontologies maintain is one between the information stored in databases and the entities out in the world that are described, measured or designated by that information,” he says.

The SDGIO project employs an approach in creating ontologies based in ontological realism, developed in large part by Barry Smith. Smith, who brought the UN effort to Jensen’s attention, is SUNY Distinguished Professor in the Department of Philosophy and Director of the National Center for Ontological Research at the university.

One use of ontologies in the UN project is to make it possible to intelligently tag incoming data to ensure that users are able to discover and better understand the information they are seeking, even when target and indicator data points intersect across domains and when there are inconsistencies in how member states define data points like “basic services” or “safe access” or, yes, even “forest.” For example, some definitions of “forest” will include palm tree plantations, while others do not, which can potentially impact data that relates to forest acreage, and subsequently, any analysis that occurs when data is aggregated across countries and regions with varying conceptions of what qualifies as a forest.

“As ontologists, we create semantic models that represent knowledge in particular domains of inquiry,” says Jensen. A UNEP ontology will provide a model to represent knowledge that’s relevant to the SDGs with more precision and better consistency, and that will provide a better way of integrating information used in monitoring the status of how various targets and goals are being addressed around the world, he explains.

Steps to the Ontology

Jensen is working closely on the SDGIO project with Pier Luigi Buttigieg, a post-doctoral researcher at the Alfred Wegener Institute for Polar and Marine Research. The lead of the Environment Ontology project (ENVO), Buttigieg was invited to participate in an UNEP-led meeting on integrated measures for global monitoring of the SDG process in 2014, Jensen relates. The value of the ontology in promoting integration and interoperability was recognized at that time by UNEP Chief Scientist Jacqueline McGlade – who is directing the SDG project with Ludgarde Coppens, UNEP head of the SDG Information and Knowledge Management Unit – and other representatives. This, Jensen says, resulted in the formation of a team of ontologists to create the SDGIO. “Pier continues to play a leading role in SDGIO’s evolution and is enhancing ENVO to help meet its aims,” says Jensen.

The aim of creating a better, more uniform approach to representing the data doesn’t mean changing the way member states conceptualize their own understandings of certain terms. But it does mean creating a way to represent the diversity of definitions and make that diversity of usage more transparent to people looking for data that is relevant to indicators. In addition to that, there needs to be a way to show how disparate data is linked together through a variety of common themes that cuts across multiple goals and targets.

An ontology enters the picture because of the advantages it affords of being a precise way to go about defining terms In hierarchical fashion and establishing relationships and formalized links between the lower-level terms in that hierarchy, he says. A top-level general definition for the term “forest,” then, can encapsulate all its different conceptualizations, with the variations between definitions represented as different lower-tier species or versions of what qualifies as a forest. There’s a great deal of unpacking of the semantics, or meaning, behind each indicator that’s required to facilitate the consistency users need to measure progress toward targets by making clear the links between various data and indicators, too. For instance, an indicator that is about the proportion of a population living in households with access to basic services has to account for all kinds of data that could relate to it, including what qualifies as a household and how that differentiates from living in a slum or informal settlement.

Jensen says the team will be finalizing the first phase of the ontology this spring, which will be implemented on the portal UNEPLive:

“An important aspect of the workflow is to elicit the feedback of relevant domain experts to guide their efforts in refining the semantics to better reflect the various domains surrounding the SDGs, such as legal entities, social policies, economic systems, equity and human rights, ecosystems and biodiversity, infrastructure, public health and education,” Jensen says.

This first phase includes the discovery and creation of all the needed terms and definitions and their formal implementation in OWL as an ontology. The team will reuse existing efforts by other groups developing ontologies, including those developed by ENVO (for the environment), CHEBI (for chemicals), OBI (for biomedical investigation), and PCO (for population and communities), and the complete semantics will grow over time as new ontologies are formed to address many of the domains that work on SDGIO has revealed a need for. For example, no ontology yet exists for human rights or financial measures, Jensen explains:

“SDGIO is truly an ‘interface.’ Not only is there a need to interface the data with the goals, targets and indicators, but also to interface the growing community of domain-specific ontologies that are and will be relevant to the SDGs.”

UN statisticians will tag the data using a few terms from the ontology (in addition to metadata such as provenance, geographic location, and so on). The ontology’s value for helping to enhance the discoverability of data should become clear in a few months as users go into the portal and type something like “access to basic services” or simply “basic services.” “We want to provide the ability for them to find data related to basic services in all contexts, not just for one particular indicator,” Jensen says.

Alternately, users might go in looking for data related to “essential services” but be served up data tagged as “basic services” because the two categories overlap very closely and often the distinction is hard to maintain. “We make the links between these terms and formalize that in the ontology so that if you search for one you can also find information tagged with the other,” he says. Researchers can drill down to determine whether information aligned with the other data tag fits their assessment requirements and use it or not, as they see fit.

Users also will be able to leverage the ontology for visualizing terms and the relationships between them. Along with those definitions they’ll find editor notes and comments about variations in usage. Says Jensen, “Hopefully they’ll utilize not just the discovery/search feature the ontology facilitates but also pay attention to the mapping and semantics it affords and the extra annotations we can add.”

Optimizing Ontario’s investments in a “basket” of core mental health services for children and youth – background

Some background

The Ministry of Children and Youth Services (MCYS) in Ontario funds service providers to deliver community-based child and youth mental health (CYMH) services under the authority of the Child and Family Services Act, R.S.O. 1990, c.C.11 (CFSA). The paramount purpose of the CFSA is to promote the best interests, protection and well-being of children.

Some terms

Client

The MCYS defines a client  as “the intended recipient of the child and youth mental health core service.” The client is a child or youth under 18 years of age who is experiencing mental health problems. In addition to mental health needs, clients may also be experiencing additional challenges related to their development or have specific impairments and/or diagnoses, including a developmental disability, autism spectrum disorder or substance use disorder. Other conditions or diagnoses do not preclude clients from receiving mental health services, but may add to the complexity of their needs, and the services they require. Similarly, where children and youth are involved in other sectors (e.g. youth justice and child welfare) these circumstances do not preclude them from receiving core services. Where children and youth have additional needs and are receiving a range of services, the focus must be on how the services connect. A coordinated approach to service delivery must be supported. Families (including parents, caregivers, guardians, siblings and other family members) may also receive services from a core service provider, in order to address the identified needs of the child or youth client. This may occur when the participation in treatment is recommended to support the child or youth’s service plan.

Continuum of needs-based mental health services

Children, youth and their families can benefit from access to a flexible continuum of timely and appropriate mental health services and supports, within their own cultural, environmental and community context. Mental health promotion, prevention, and the provision of services to address mental health problems represent different points along the continuum. Children, youth and their families may enter the continuum of needs-based services and supports at any point. The actual services a child/youth needs will vary. For example, some children/youth may benefit from targeted prevention services, while others will require more specialized mental health services. In addition, a child or youth’s mental health service needs may change over the course of their treatment.

The following schematic outlines the full continuum of needs-based mental health services and supports, and shows how core services fit within this continuum. It also represents the relative demand for services – level one reflects all children and youth, while level four focuses on a smaller subset of the child/youth population with the most severe, complex needs. This schematic is for service planning only – it is not used for diagnosis or for determining the appropriateness of specific mental health interventions.

MCYS - Continuum of core mental health services
Continuum of CYMH Needs-Based Services and Supports. *Includes members of a group that share a significant risk factor for a mental health problem(s).

Service areas

After a thorough review – including an assessment of Statistics Canada’s census divisions – the MCYS has identified 34 service areas in Ontario for the purpose of:

  • ensuring that all clients across the province will be able to access the same core services
  • facilitating planning, and
  • creating pathways to care.

The defined service areas are not barriers to service. Clients will be able to access service from any service area.

Core services

The MCYS has defined a set of core children and youth mental health services (“core services”) to be available within every service area and has established minimum expectations for how core services are planned, delivered and evaluated. Core services may not be available in every service area immediately – the expectation is that they will be made available over time as lead agencies assume their roles and responsibilities.

Core services represent the range of MCYS-funded CYMH services that lead agencies are responsible for planning and delivering across the continuum of mental health needs within each service area. It is recognized that children and youth in receipt of core mental health services may also require other services and supports. For example, children and youth may receive more than one core service as part of a service plan, as well as other services funded by MCYS or other partners.

Seven core services are to be available across all service areas:

  • Targeted Prevention
  • Brief Services
  • Counselling and Therapy
  • Family Capacity Building and Support
  • Specialized Consultation and Assessments
  • Crisis Support Services, and
  • Intensive Treatment Services.

The MCYS funds providers of core services through the following detail codes:

  • A348 – Brief Services
  • A349 – Counselling and Therapy
  • A350 – Crisis Support Services
  • A351 – Family/Caregiver Capacity Building and Support
  • A352 – Coordinated Access and Intake
  • A353 – Intensive Treatment Services
  • A354 – Case Management and Service Coordination
  • A355 – Specialized Consultation and Assessment
  • A356 – Targeted Prevention Term

The MCYS has identified a target population for each core service. This is the population for whom the service is designed, and for whom the service is intended to provide better mental health outcomes. The act of defining a target population is not meant to be exclusionary. Rather, it is a means to support planning and delivery in a way that benefits the children and youth who are in greatest need of the mental health service. In general, the target population for core services includes those children and youth under 18 years of age and their families who are experiencing mental health problems along levels two, three and four of the CYMH continuum. Additional target populations may also be identified within specific core services.

Lead agency

In every service area, the MCYS has identified a lead agency that will be responsible for the planning and delivery of high-quality core services across the continuum of mental health services in the service area.

A lead agency may either directly deliver core services or work with other providers of core services to deliver the full range of core services within the service area. Lead agencies are responsible for engaging cross-sectoral partners in the health and education sectors, including the relevant Local Health Integration Network (LHIN) and school boards. Lead agencies will connect with other providers to plan and enhance mental health service pathways for children and youth and improve transparency, so that everyone will know what to expect.

Providers of core services are required to comply with the Program Guidelines and Requirements #01 (PGR #01): Core Services and Key Processes.

The core services, key processes and functioning of the CYMH service sector will require refinement from time to time as other provincial initiatives and activities are developed and implemented. Within the broader context of these new initiatives, it is important that the roles and responsibilities of all core service providers are made clear and that the linkages between these services are transparent.

Planning to transform child and youth mental health services in Ontario

A key driver of Moving on Mental Health is the need to build a system in which children, youth and their families:

  • Have access to a clearly defined set of core child and youth mental health services
  • Know what services are available in their communities and how they are connected to one another, and
  • Have confidence in the quality of care and treatment. In a mature system, one of the ways in which this vision will be realized is through identification of lead agencies with planning and funding accountability for core child and youth mental health services within defined service areas.

Within each defined service area, the lead agency will be responsible for:

  • Delivering and/or contracting for the range of defined core CYMH services
  • Making them accessible to parents, youth, and children, and

Establishing inter-agency and inter-sectoral partnerships, protocols and transparent pathways to care. These responsibilities fall into two broad categories:

  • Core Service responsibilities – which relate to the defined core services delivered by the community-based child and youth mental health sector, as well as the key processes that enable high-quality service, and
  • Local System responsibilities – which relate to the collaboration of the community-based sector with other parts of the service continuum such as those supports and services delivered by health care providers, schools and others.

The Core Services Delivery Plan and the Community Mental Health Plan for children and youth will set out how the lead agency carries out these responsibilities. The lead agency will be responsible for developing these plans, and is expected to work collaboratively with other mental health service providers and with all sectors that support children and youth and respond to their mental health needs.

The Core Services Delivery Plan will, together with the Community Mental Health Plan, provide critical insight into each service area and guide activities as we move forward with transforming the experience of children, youth and families. The intent is that over time, both of these plans will have a three-year horizon and will be updated annually, since they inform one another. They will also provide content for the Accountability Agreement entered into between the lead agency and MCYS.

Core Services Delivery Plan

The development of a Core Services Delivery Plan (CSDP) is a key planning and communication tool that will document expectations, obligations and commitments for the provision of core services and associated key processes in each defined service area. This reflects the need to establish a consistent approach that will support critical insights into local and provincial child and youth mental health service issues, while recognizing the unique circumstances of lead agencies and service areas. The Core Services Delivery Plan documents how core services will be delivered in the defined service area. It consists of three areas of content:

  • Service Commitments
  • Continuous Improvement Priorities, and
  • Budget.

In developing the plan, the lead agency and child and youth mental health service providers should ask themselves some key questions:

  • Can we demonstrate that the full range of core services is available in our service area, and that minimum expectations set out in the Service Framework are being met?
  • Can we show how our services are getting better at meeting the mental health needs of children and youth in our communities?
  • Are we making the best possible use of limited resources to deliver high-quality services?
A. Service Commitments

This section of the plan will:

  • Identify, with specific activities and time frames:
    • How the lead agency and other child and youth mental health service providers in the service area will address the expectations set out in the Service Framework, including who will deliver what services over the projected three-year time horizon
    • Where changes to services or service providers are proposed, the plan will document how the changes will result in improvement to child and youth mental health outcomes, service quality and efficiencies
  • Indicate how, if a change in service providers or in contracted relationships is proposed, it will be handled in a transparent manner with due regard to minimizing disruption to service
  • Set out how services will be designed and delivered in a culturally responsive manner to address diverse populations including francophone and Aboriginal populations
  • Document how a clear, stable point of contact for children and youth with mental health needs and their families, as well as those seeking services on their behalf, will be established and/or maintained
  • Report on the reach and efficacy of programs and services, including how input from parents and youth has been incorporated to ensure that what has been developed works for them, and
  • Describe the process by which the lead agency has engaged and will continue to engage respectfully with all core child and youth mental health service providers in the service area.
B. Continuous Improvement Priorities

This section of the plan will:

  • Monitor and report on the impact of current programs and services
  • Identify improvement priorities, taking into account priorities established by MCYS and the expectations set out in the Service Framework, in areas such as service quality and outcomes, a purposeful approach to wait list and wait time management, and others over the three-year horizon of the plan
  • Set out specific activities and time frames that will support continuous improvement goals and priorities, and
  • Address matters such as data sharing protocols between the lead agency and other child and youth mental health agencies in the service area, that will support monitoring and reporting on performance indicators in order to enable tracking of trends, challenges and opportunities for continuous improvement.
C. Budget

This section of the plan will:

  • Forecast activities, resource allocations and budget over the three-year horizon, including financial implications of planned changes to service delivery.

Community Mental Health Plan for children and youth

System responsibilities are built on key partnerships and collaborations developed at the local level to support young people and their families across the full continuum of needs. Although service areas may differ in terms of their service profile, service patterns, as well as the degree of pre-existing cooperation and collaboration across systems and sectors, the lead agency will be responsible for bringing partners together to create coherence for children, youth and their families. MCYS is working, together with the Ministry of Health and Long-Term Care and the Ministry of Education, to put in place conditions that will support this important work.

The Community Mental Health Plan for children and youth will be a public document that is developed by the lead agency and describes the processes by which:

The lead agency has engaged and will continue to engage respectfully with sector partners such as organizations funded by Local Health Integration Networks, District School Boards, public health units, hospitals, primary health care providers, and those delivering MCYS-funded services (e.g., child welfare, autism services) and others, and

Input from parents and youth has been incorporated to ensure that what has been developed works for them. It will cover the following topic areas:

  • Understanding current needs and services
  • Collaborative planning, and
  • Pathways to, through and out of care.

In developing the plan, the lead agency, child and youth mental health service providers and partners from all sectors involved with child and youth mental health should ask themselves some key questions:

  • Are all those who serve children and youth working together systematically to address mental health needs in the service area?
  • Are the roles and responsibilities of everyone across the continuum of needs and services clear to parents, youth and those seeking services on their behalf, including how services are accessed?
  • Are there shared commitments to address service gaps and expand on opportunities to better meet identified needs?
A. Understanding current needs and services
  • Report on a needs assessment of the current state of child and youth mental health services across the service area, identifying gaps and opportunities for meeting needs across the continuum, and
  • Identify and maintain an inventory of who is providing which services to meet the needs identified.
B. Collaborative planning
  • Establish mechanisms to explore, on an ongoing basis, opportunities to leverage resources, reduce duplication, enhance outcomes, and create added value for children and youth with mental health needs through collaboration and joint planning, and
  • Identify and document commitments and actions to be taken to address shared and agreed upon priorities, together with associated timelines and measures to assess results.
C. Pathways to, through and out of care

Develop and document protocols, processes and partnerships that exist, or will be developed, that will streamline and strengthen clear pathways to, through and from care across sectors.

Next: Applying Multi-Criteria Decision Analysis to the “basket” of core mental health services for children and youth in Ontario

Accessing services

Possible pathway to service

  1. Apply to CSSS, who refers to ->
  2. Family doctor, who refers to ->
  3. CSSS, who refers to ->
  4. Evaluation-Liaison Module (Douglas), who refers to ->
  5. Anxiety disorders clinic (Douglas), who refers back to ->
  6. CSSS/Family doctor

Accessing services at the Douglas Mental Health University Institute

  1. Accessing a family doctor through CSSS – Main website (French)
  2. Referrals to Douglas Mental Health University Institute
  3. Anxiety disorders clinic at Douglas Institute

Accessing services at the Royal Victoria Hospital

  1. Department of Psychiatry
  2. McGill Department of Psychology at the Royal Victoria Hospital

What’s the sense of Service-Dominant Logic?

My interest in specifying a model of public service has involved me in the study of more general notion of service. I have been most taken with two models of service, in particular:

  • Resource-Event-Agent model (REA)
  • Service-Dominant Logic (S-DL)

The scholarship associated with the Resource-Event-Agent model has included a substantial investment in specifying an REA ontology using both a formal language representation (the Web Ontology Language or OWL) and a graphical representation (the Unified Modeling Language or UML Profile for OWL). The International Standards Organization has incorporated REA into the Open-edi Business Transaction Ontology (OeBTO).

The scholarship associated with Service-Dominant Logic has been less concerned with formal language representation, and more concerned with bringing a certain perspective to bear on the widest-possible range of human behavior – aspiring to be a “unifying and transcending view of business and, more broadly, economic and social organization” (Lusch and Vargo, 2014). The status of Service-Dominant Logic as a model was enhanced when IBM proposed that Service-Dominant Logic should be the foundation of a new, multidisciplinary “science” of service  (Maglio and Spohrer 2008).

There is no doubt that Service-Dominant Logic has had a far greater impact on our thinking about service than has the Resource-Event-Agent model. The primacy of Service-Dominant Logic is even more evident when one considers the design, delivery, and innovation of service in the marketplace.

There is also an aspirational – indeed, an inspirational – quality to the scholarship associated with Service-Dominant Logic that is lacking in somewhat dry, technical approach of the scholarship associated with the Resource-Event-Agent model.

For all that, the formulation of Service-Dominant Logic needs to be tightened up – in the end, the rhetoric may be less inspiring, but it will also be less confusing.

Let’s first consider the formal elements of Service-Dominant Logic – taking Lusch and Vargo’s (2014) book-length treatment of their model and Vargo and Lusch’s (2015) update as our points of reference.

Institutional Logics

Lusch and Vargo begin with the proposition that “part of our nature as humans is to develop belief systems that become handy ways of seeing and understanding the world around us and for ordering our reality.” [Ch 1] Belief systems enable viewing a complex world in what promises to be coherent terms and provide a lens for perceptually separating noise from signal. Thus, belief systems contribute to comfort, understanding and sense-making.

Belief systems become normative and play a key role in guiding and determining our behavior. Lusch and Vargo promote at least some belief systems to the status of “institutional logics”.1 In 2004, they began to formulate a Service-Dominant Logic (S-D Logic) “to contribute to the understanding of the world of economic and social exchange among human actors.” Service-Dominant Logic is a “mindset” that offers an alternative “worldview” to traditional Goods-Dominant Logic (G-D Logic).

Lusch and Vargo have associated Service-Dominant Logic with a set of terms they call a Lexicona set of propositions they call Foundational Premises, and a set of Axioms that represent a subset of the Foundational Premises.

In 2014, Lusch and Vargo identified ten Foundational Premises including four Axioms. In 2015, Vargo and Lusch introduced a fifth Axiom (an eleventh FP) and revised the wording of one other Axiom and three other FPs. We will designate these two versions of the Axioms/Foundational Premises of Service-Dominant Logic as FP-2014 and FP-2015, respectively. The terms of Lexicon are arranged in a hierarchy; the Foundational Premises are also arranged in a hierarchy.

Lusch and Vargo (2014) present the hierarchical structure of the Lexicon of Service-Dominant Logic (hereafter referred to as Lexicon-2014) in Figure 1 …

Lusch and Vargo 2014 - Figure 3.2 S-D Logic lexicon
Figure 1 S-D Logic Lexicon-2014 (Lusch and Vargo 2014).

… and the hierarchical structure of FP-2014 in Figure 2.

Lusch and Vargo 2014 - Figure 3.1 Axioms and foundational premises of S-D Logic
Figure 2. Axioms and foundational premises of S-D Logic – aka FP-2014 – (Vargo and Lusch 2014).

The Lexicon is used to develop and elaborate the Axioms and Foundational Premises [57].

Let’s consider how meaningful or potentially confusing  this last point might be – and examine the overlap between the terms of the Lexicon-2014 and the terms used to express the FP-2014 and the FP-2015. Before we dive in to this exercise, we first need to identify how Lusch and Vargo use the word “lexicon” and then we need to bring in some basic concepts of semantics.

Lexicon

We would highlight six passages where Lusch and Vargo (2014) discuss their idea of the Lexicon of Service-Dominant Logic. Half of these passages speak of the general idea of Lexicon; the other half address the way a shift in thinking about a concept like Service motivates a shift in lexicon – and the difficulties that can and often do immediately ensue in efforts to communicate about the concept.

General idea of Lexicon

A key challenge we have faced in developing and communicating S-D logic is the precision of its lexicon. We soon realized how important words and language are in framing our view and conceptualization of the world and, hence, how it influences our actions or behavior. We found subtle yet important distinctions between terms such as "services" versus "service," "customers" versus "consum­ers," static and tangible resources and dynamic and intangible resources. Thus, much of what is to be learned from this book concerns how to uncompact new and/or revised meanings for old terms - for example, what are a resource, cocreation, and value? But we also found it necessary to develop new "concepts" and language, which we will introduce and explain here. These include "service ecosystems," "resource integration," "resourceness," and "value-in-context." We believe that, although it will take some effort to develop an understanding of the lexicon, most readers will find it worthwhile. [xxii]
All logics are based on premises and assumptions. Often these are not explicit or spoken but are implicit and unspoken. Logics can be observed in everyday practices and language. In the development of service-dominant (S-D) logic we have attempted to be explicit about its premises, assumptions, and language (or what we call its lexicon). [53]
Theories and models are abstractions of reality. Language and words are used to develop abstractions, and these abstractions are then related to each other in order to describe or explain the phenomena of interest. The goal is to be parsimonious, while still being as isomorphic as possible. This implies using as few concepts as necessary to describe and explain the phenomena of interest; while, at the same time, striving for correspondence between the theory or model and real-world phenomena. Predictably, it is very difficult to be both parsimonious and isomorphic with the same theory, model, or logic. We suggest that S-D logic strikes a reasonably good balance between these two objectives.

As noted, we believe S-D logic is reasonably parsimonious in its lexicon. In fact, it deals with only four core, foundational concepts (actors, service, resour­ces, value), and from these we derive ten additional concepts. [55 - also footnote 2 gives "The lexicon of S-D logic is continuing to develop and includes many other emerging terms such as service ecosystems ..."]

A shift in thinking that motivates a shift in Lexicon

All logics also have a lexicon developed by the community that supports and uses the logic. The lexicon comprises the terms and concepts, represented through words or symbols, which communicate meaning and help to coor­dinate thought among the community. To understand S-D logic, its axioms, and FPs, it is critical to become familiar with its lexicon. This can be difficult because some of the language is similar to the language of G-D logic, albeit with nuanced meanings. [54]
From the rapid ascendance and impact of the services marketing and management literature in the 1970s and 1980s, we began to see other currents of change in thinking. As is often the case, when thinking starts to change, it is supplemented or leveraged by the emergence of a new lexicon, which, in turn, further influences thinking and ultimately behavior or action. [202]
Part of the difficulty of mastering S-D logic is the enduring, strong pull of G-D logic. G-D logic is not only embedded in many organizational routines and practices, it is also embodied in our minds, and practices and institutions of society. In fact, even after nearly two decades of intense work on S-D logic and its associated lexicon, we still find ourselves occasionally slipping back to the G-D logic mindset and lexicon. Be forewarned: it takes work and training to see every firm offering, tangible or intangible, as just an input, something whose value is only realized in its use and in the context of and integration with resources from other sources. It is difficult to emancipate oneself from the restricted perspective of the firm-centric model, which treats customers as operand resources, whose role is to be captured for the net present value of their flow of financial resources to the enterprise - what, in G-D logic terms, is referred to as lifetime value of the customer, which is inappropriately paraded as "relationship" marketing. It is difficult not to think about the firm as the center of the wealth creation or as the producer and provider of value. It can be equally difficult to divorce oneself from that view that customers consume and destroy value. It is difficult not to think about innovation as something that primarily occurs in the laboratories and offices of the enterprise, as opposed to something that occurs throughout the service ecosystem, through the social and economic processes of resource inte­gration and service exchange. The pervasive influence of G-D logical lexicon and frameworks on all of the business and management disciplines is a hard one from which to break free. It is extremely difficult not to think about a profit shortfall as the fault of management and employees but rather as due to the inadequacy of the G-D logic model.

We believe commitment to S-D logic and its premises and lexicon, focusing on and understanding its nuances and fully grasping its transcending nature, will reveal not only new solutions to old problems but also unlimited and unbounded opportunities for market expansion and the creation of new markets. That is a fairly bold value proposition but one that we think is achievable through becom­ing untethered to G-D logic and mastering S-D logic. [204]

Terms and hierarchical structure of the S-DL Lexicon

Lusch and Vargo identify four “core, foundational concepts” – Actor, Service, Resource, and Value – in Lexicon-2014, and “derive” from these ten additional “concepts.” As we saw above, Lusch and Vargo characterize Service-Dominant Logic as “reasonably parsimonious” on the basis of the relatively few terms in its Lexicon [55]. It’s disconcerting that, in the same breath (or at least in a related footnote), Lusch and Vargo advise that “The lexicon of S-D logic is continuing to develop and includes many other terms such as service ecosystems …” It’s also disconcerting that Lusch and Vargo do not identify the place of a key term like “service ecosystem” in the hierarchical structure of the Lexicon (Figure 1).

Lexical semantics

In order to take a proper look at the terms of the S-DL Lexicon, we need to draw upon some model of language and meaning – and for this we want to set out some of the basic ideas of lexical semantics.

Wordform An orthographic or phonological form e.g. the written word “sing”, or the spoken word “songs”.
Sense The meaning associated with a wordform.
Lexeme A pairing of a wordform and (one of) its sense(s).
Lemma The grammatical form that is used to represent a lexeme. This is often the base form e.g. carpet is the lemma for “carpets”, or the infinitive form e.g. to sing is the lemma for “sang”.
Lemmatization The process of mapping a wordform to a lemma. Lemmatization is not always deterministic – it may depend on the context e.g. the wordform “found” can map to the lemma find (meaning “to locate”) or the lemma found (meaning “to create an institution”), and on part-of-speech e.g. the wordform “tables” has two possible lemmas, the noun “table” and the verb “table”. Each word sense is represented by placing a superscript on the orthographic form of the lemma, as in table1 and table2.
Lexicon A finite list of lexemes.

Table 1. Lexical semantics: some basic terms and definitions.

We will describe the procedures of lexical semantics only when we need to call upon them in our analysis of Lexicon-2014.

For now, let’s use some of the concepts of lexical semantics to recast Lusch and Vargo’s presentation of Lexicon-2014:2

Wordform Lemma FP-2014 FP-2015
Core concepts
“Actors” Actor 9 9
“Resources” Resource 4, 9 4, 9
“Service” Service 1, 3, 5, 8 1, 3, 5, 8
“Value” Value 6, 7, 10 6, 7, 10
Derived concepts
“Time-bound” Time
To bind1
“Relationally-bound” Relation 8 8
To bind2
“Resource-integrating” Resource 4, 9 4, 9
To integrate 9 9
“Operand” Operand
“Operant” Operant 4 4
“Goods” Good 3 3
“Currency” Currency
“Unique” Unique 10 10
“Co-created” Co- 6 6
To create 6 6
“Proposition” Proposition 7 7

Table 2. Mapping the “core concepts” and “derived concepts” of the Lexicon-2014 to their equivalent wordforms and lemmas.

A few notes about Table 2:

  • we allow that the sense of “to bind” as in “time bound” in different from the sense of “to bind” as in “relationally bound”
  • we associate a single lexeme – resource  with the two wordforms “resources” and “resource integrators”
  • we associate the wordform “cocreated” with two lexemes – to create and co- meaning “along with others

Finally, we note that four (or five) lexemes in Lexicon-2014  –  TimeOperand, Currency, To bind1 (and maybe To bind2) – are not put to use in expressing any members of FP-2014 or FP-2015.

Thus, some of the terms of Lexicon-2014 are not necessary for expressing the terms of FP-2014 or FP-2015.

Table 3 highlights those wordforms that are used to express the terms of FP-2014 and FP-2015 that have no apparent counterpart in Lexicon-2014. Clearly, the Lexicon-2014 is also not sufficient for expressing FP-2014, let alone FP-2015.

Axiom/FP Overlap with Lexicon-2014
FP1 – Axiom 1 2014/15: Service is the fundamental basis of exchange.
FP2 2014/15: Indirect exchange masks the fundamental basis of exchange.
FP3 2014/15: Goods are a distribution mechanism for service provision.
FP4 2014: Operant resources are the fundamental source of competitive advantage.
2015: Operant resources are the fundamental source of strategic benefit.
FP5 2014/15: All economies are service economies.
FP6 – Axiom 2 2014: The customer is always a co-creator of value.
2015: Value is co-created by multiple actors, always including the beneficiary.
FP7 2014: The enterprise can only make value propositions.
2015: Actors cannot deliver value but can participate in the creation and offering of value propositions.
FP8 2014: A service-centred view is customer oriented and relational.
2015: A service-centred view is inherently beneficiary oriented and relational.
FP9 – Axiom 3 2014/15: All economic and social actors are resource integrators.
FP10 – Axiom 4 2014/15: Value is always uniquely and phenomenologicaly determined by the beneficiary.
FP11 – Axiom 5 2015: Value co-creation is co-ordinated through actor-generated institutions and institutional arrangements.

Table 3. Wordforms of the FP-2014 and FP-2015 and their overlap with the Lexicon-2014 of Service-Dominant Logic. Non-overlapping wordforms in FP-2014 are highlighted in blue; additional non-overlapping wordforms in FP-2015 are highlighted in red.

Thus, we see clearly that the terms of the Lexicon are neither necessary nor sufficient for expressing the Foundational Premises of Service-Dominant Logic .

Next time we’ll take up the more complicated challenge of determining (if we can) the exact meaning that Lusch and Vargo want to associate with the lexemes of the Lexicon of Service-Dominant Logic.

References

Lusch, RF and Vargo, SL (2014), Service-Dominant logic: Premises, perspectives, possibilities, Cambridge University Press.

Vargo, SL and Lusch, RF (2015), Institutions and axioms: an extension and update of service-dominant logic, Journal of the Academy of Marketing Science, 1 – 19.

 

  1.   Friedland, R and Alford, RR – Bringing society back in: Symbols, practices, and institutional contradictions (1991).
  2. Lusch and Vargo are inclined to dispense with hyphens – we favour them, and have inserted them here into the wordforms “time-bound,” “relationally-bound,” “resource-integrators,” and “co-created.”

Update of Service-Dominant Logic – 2015

In their recent paper “Institutions and axioms: an extension and update of service-dominant logic,” Stephen Vargo and Robert Lusch summarize key steps in the evolution of Service-Dominant Logic since their original formulation of S-DL appeared in 2004.

Within this one paper, Vargo and Lusch provide several perspectives on the evolutionary path of S-DL.

Motivation

Along its evolutionary path, Service-Dominant logic has recognized and taken steps to address two deficiencies:

  1. An imprecision in delineation of the Foundational Premises (FPs) and specification of the Axioms of S-DL
  2. An absence of a clearly articulated specification of the mechanisms of (often massive-scale) co-ordination and co-operation involved in the co-creation of value through markets and, more broadly, in society.

Present Contribution

To alleviate this limitation and facilitate a better understanding of co-operation (and co-ordination), an eleventh Foundational Premise (Fifth Axiom) is introduced, focusing on:

  • the role of institutions and
  • institutional arrangements
  • in systems of value co-creation (aka service ecosystems)

 

While Vargo and Lusch have collaborated together and separately with many other researchers in the past decade, their tradition has been to come together (on their own) every two years to refine their specification of Service-Dominant Logic (S-DL):

2004
Evolving to a new dominant logic for marketing
The four service marketing myths remnants of a goods-based, manufacturing model
2006
Service-dominant logic
Service-dominant logic: reactions, reflections and refinements
Service-Dominant Logic as a foundation for a general theory
2008
Service-dominant logic: continuing the evolution
Why “service”?
The service-dominant mindset
From goods to service (s): Divergences and convergences of logics
Service-Dominant Logic, market theory and marketing theory
A service logic for service science
2010
SD logic: accommodating, integrating, transdisciplinary
“Relationship” in Transition: An Introduction to the Special Issue on Relationship and Service-Dominant Logic
From repeat patronage to value co-creation in service ecosystems: a transcending conceptualization of relationship
2012
The nature and understanding of value: a service-dominant logic perspective
Gaining competitive advantage with service-dominant logic
The forum on markets and marketing (FMM) Advancing service-dominant logic
2014
Service-dominant logic: Premises, perspectives, possibilities
An introduction to service-dominant logic
Inversions of service-dominant logic
The service-dominant logic of marketing: Dialog, debate, and directions (Book)
Service-Dominant logic as a foundation for a general theory

Table 1. Bi-annual collaboration of Vargo-Lusch on Service-Dominant Logic (2004 – 2014).

Vargo and Lusch have represented the evolution of Service-Dominant Logic in terms of refinements of its Foundational Premises (FPs) and Axioms:

Foundational
Premise
2004 2008 2015
FP1 The application of specialized skills and knowledge is the fundamental unit of exchange. Service is the fundamental basis of exchange No Change – AXIOM STATUS
FP2 Indirect exchange masks the fundamental unit of exchange. Indirect exchange masks the fundamental basis of exchange. No Change
FP3 Goods are distribution mechanisms for service provision. No Change No Change
FP4 Knowledge is the fundamental source of competitive advantage. Operant resources are the fundamental source of competitive advantage. Operant resources are the fundamental source of strategic benefit.
FP5 All economies are service economies. No Change No Change
FP6 The customer is always the co-producer. The customer is always a co-creator of value. Value is co-created by multiple actors, always including the beneficiary – AXIOM STATUS
FP7 The enterprise can only make value propositions. The enterprise cannot deliver value, but only offer value propositions. Actors cannot deliver value but can participate in the creation and offering of value propositions.
FP8 Service-centered view is customer oriented and relational. A service-centered view is inherently customer-oriented and relational. A service-centered view is inherently beneficiaryoriented and relational.
FP9 All social and economic actors are resource integrators. No change – AXIOM STATUS
FP10 Value is always uniquely and phenomenologically determined by the beneficiary. No change. – AXIOM STATUS
FP11 Value co-creation is coordinated through actor-generated institutions and institutional arrangements. – AXIOM STATUS

Table 2. Development of the Foundational Premises of Service-Dominant Logic.

At a more general level of description, we would describe the evolution of Service-Dominant Logic turns on promoting three new classes of objects:

  • actor
  • institution
  • service ecosystem

… and four dynamics of service:

  • the role of co-operation (versus competition) in service provision
  • the role of institutions in value co-creation
  • the role of experience in service evaluation
  • the role of value co-creation in service innovation

The Service-Dominant Logic of today imagines resource-integrating, reciprocal-service-providing actors co-create value through meaning-laden experiences in service ecosystems governed and evaluated through institutional arrangements.

The major components of this emerging narrative are presented in Figure 1.

Vargo and Lusch 2015 - Fig 1 The narrative and process of S-D Logic

Figure 1. The narrative and process of Service-Dominant Logic.

We’d now like to consider the innovative elements of this narrative, beginning with the three new classes of objects (Actor, Institution, and Service Ecosystem) in Service-Dominant Logic.

References

Abernathy, W. J., & Clark, K. (1985). Innovation: mapping the winds of creative destruction. Research Policy, 14(1), 3–22.

Akaka, M. A., Vargo, S. L., & Lusch, R. F. (2013). The complexity of context: a service ecosystems approach for international marketing. Journal of International Marketing, 21(4), 1–20.

Alderson, W. (1957). Marketing behavior and executive action. Homewood: Richard D. Irwin.

Alderson, W. (1965). Dynamic marketing behavior. Homewood: Richard D. Irwin.

Alderson, W., & Cox, R. (1948). Towards a theory of marketing. Journal of Marketing, 8(2), 137–152.

Araujo, L., & Spring, M. (2006). Services, products, and the institutional structure of production. Industrial Marketing Management, 35(7), 797–805.

Arndt, J. (1981). The political economy of marketing systems: reviving the institutional approach. Journal of Macromarketing, 1(2), 36–47.

Arnould, E. J. (2006). Service-dominant logic and consumer culture theory: natural allies in and emerging paradigm. Marketing Theory, 6(3), 293–298.

Arrow, K. J. (1987). Reflections on the essays. In G. Feiwel (Ed.), Arrow and the foundations of the theory of economic policy (pp. 727–34). NY: NYU Press.

Arthur, B. W. (2009). The nature of technology: What it is and how it evolves. New York: Free Press.

Arthur, B. W. (2013). Complexity economics: A different framework for economic thought. Santa Fe Institute Working Paper 2013-04-012. Santa Fe: Santa Fe Institute.

Arthur, B. W. (2014). Complexity and the economy. Oxford: Oxford University Press.

Battilana, J., & D’Aunno, T. (Eds.). (2009). Institutional work and the paradox of embedded agency. New York: Cambridge University Press.

Beinhocker, E. D. (2006). The origins of wealth: evolution, complexity, and the radical remaking of economics. Boston: Harvard Business School Press.

Beinhocker, E. D. (2010). Evolution as computation: Implications for economic theory and ontology. Santa Fe Working Paper 2010-12037. Santa Fe: Santa Fe Institute.

Bello, D. C., Lohtia, R., & Sangtani, V. (2004). An institutional analysis of supply chain innovations in global marketing channels. Industrial Marketing Management, 33(1), 57–64.

Bernstein, W. J. (2004). The birth of plenty: How the prosperity of the world was created. New York: McGraw-Hill.

Bettencourt, L., Lusch, R. F., & Vargo, S. L. (2014). A service lens on value creation: how marketing should enable strategic advantage. California Management Review, 57(1), 44–66.

Bill, J. A., & Hardgrave, R. L., Jr. (1981). Comparative politics: The Quest for theory. Washington, DC: Bell and Howell.

Bourdieu, P. (1977). Outline of a theory of practice. Cambridge: The Press Syndicate of the University of Cambridge.

Brodie, R. J., Glynn, M. S., & Little, V. (2006). The service brand and the service-dominant logic: missing fundamental premise or the need for stronger theory? Marketing Theory, 6(3), 363–379.

Brodie, R. J., Saren, M., & Pels, J. (2011). Theorizing about the service dominant logic: the bridging role of middle range theory. Marketing Theory, 11(March), 175–191.

Cannon, J. P., Achrol, R. S., & Gundlach, G. T. (2000). Contracts, norms, and plural form governance. Journal of the Academy of Marketing Science, 28(2), 180–194.

Carson, S. J., Devinney, T. M., Dowling, G. R., & John, G. (1999). Understanding institutional designs within marketing value systems. The Journal of Marketing, 63(Special Issue), 115–130.

Chandler, J., & Lusch, R. F. (2015). Service systems: a broadened framework and research agenda on value propositions, engagement and service experience. Journal of Service Research, 18(1), 6–22.

Chandler, J., & Vargo, S. L. (2011). Contextualization: network intersections, value-in-context, and the co-creation of markets. Marketing Theory, 11(1), 35–49.

Coase, R. H. (1937). The nature of the firm. Economica, 4(16), 386–405. Coase, R. H. (1972). Industrial organization: A proposal for research. V. Fuchs (ed.) in Policy Issues and Research Opportunities in Industrial Organization: National Bureau of Economic Research (pp. 59–73).

Commons, J. R. (1934). Institutional economics: its place in political economy. New York: Macmillan.

Davis, L. E., & North, D. C. (1971). Institutional change and American economic growth. Cambridge: Cambridge University Press.

DiMaggio, P. J. (1988). Interest and agency in institutional theory. In L. Zucker (Ed.), Institutional patterns and organizations: Culture and environment (pp. 3–21). Cambridge: Ballinger.

DiMaggio, P. J., & Powell, W. W. (1983). The iron cage revisited: institutional isomorphism and collective rationality in organizational fields. American Sociological Review, 48(2), 147–160.

DiMaggio, P. J., & Powell, W. W. (Eds.). (1991). BIntroduction^. The New Institutionalism in Organizational Analysis (pp. 1–38). Chicago: University of Chicago Press.

Duddy, E. A., & Revzan, D. A. (1953). Marketing: An institutional approach. New York: McGraw-Hill.

Durkheim, E. (1912/2008). The elementary forms of the religious life [1912]. Oxford World’s Classics.

Edvardsson, B., Tronvol, B., & Gruber, T. (2011). Expanding understanding of service exchange and value co-creation: a social construction approach. Journal of the Academy of Marketing Science, 39(2), 327–39.

Friedland, R., & Alford, R. R. (1991). Bringing society back in: Symbols, practices and institutional contradictions. In P. DiMaggio & W. W. Powell (Eds.), The New Institutionalism in Organizational Analysis (pp. 232–263). Chicago: University of Chicago Press.

Giddens, A. (1984). The constitution of society. Berkeley: University of California Press.

Giesler, M. (2008). Conflict and compromise: drama in marketplace evolution. Journal of Consumer Research, 34(April), 739–753.

Granovetter, M. (1985). Economic action and social structure: the problem of embeddedness. American Journal of Sociology, 91(3), 481– 510.

Grewal, R., & Dharwadkar, R. (2002). The role of the institutional environment in marketing channels. The Journal of Marketing, 66(3), 82–97.

Gronroos, C. (2008). Service logic revisited: who creates value? And who co-creates? European Business Review, 20(40), 298–314.

Gronroos, C., & Voima, P. (2013). Critical service logic: making sense of value creation and co-creation. Journalofthe AcademyofMarketing Science, 41(2), 133–150.

Gundlach, G. T., & Achrol, R. S. (1993). Governance in exchange: contract law and its alternatives. Journal of Public Policy & Marketing, 12(2), 141–155.

Hakansson, H., Ford, D., Gadde, L. E., Snehota, I., & Waluszewski, A. (2009). Business in networks. Chichister: John Wiley and Sons.

Harrison, D., & Kjellberg, H. (2010). Segmenting a market in the making: Industrial market segmentation as construction. Industrial Marketing Management, 39(5), 784–792.

Hawley, A. H. (1968). Human ecology. In D. L. Sills (Ed.), International encyclopedia of the social sciences (pp. 328–337). New York: Macmillan.

Heide, J. B., & John, G. (1992). Do norms matter in marketing relationships? The Journal of Marketing, 56(2), 32–44.

Hinings, C., Tolbert, P. S., Greenwood, R., & Oliver, C. (2008). Organizational institutionalism and sociology: A reflection. The Sage handbook of organizational institutionalism (pp. 473–490).

Holland, J. (2014). Complexity: A very short introduction. Oxford: Oxford University Press.

Humphreys, A. (2010). Megamarketing: the creation of markets as a social process. Journal of Marketing, 74, 1–19.

Hunt, S. D. (1983). General theories and the fundamental explananda of marketing. Journal of Marketing, 47, 9–17.

Hunt, S. D. (2012). Toward the institutionalization of macromarketing. Journal of Macromarketing, 32(4), 404–411.

Kates, S. M. (2004). The dynamics of brand legitimacy: an interpretive study in the gay men’s community. Journal of Consumer Research, 31(2), 455–464.

Kjellberg, H., & Helgesson, C.-F. (2006). Multiple versions of markets: multiplicity and performativity in market practice. Industrial Marketing Management, 35(7), 839–855.

Kjellberg, H., & Helgesson, C.-F. (2007). On the nature of markets and their practices. Marketing Theory, 7(2), 137–162.

Koestler, A. (1973). The tree and the candle. In W. Gray & N. D. Rizzo (Eds.), Unity through Diversity, pt I (pp. 287–314). New York: Gordon and Breach Science Publishers.

Korkman, O., Storbacka, K., & Harald, B. (2010). Practices as markets: value co-creation in e- invoicing. Australasian Marketing Journal, 18(4), 236–247.

Latour, B. (2005). Reassembling the Social: An introduction to actornetwork-theory. Oxford: Oxford University Press.

Lawrence, T. B., & Suddaby, R. (Eds.). (2006). Institutions and institutional work. London: Sage.

Lawrence, T. B., Suddaby, R., & Leca, B. (2009). Introduction: Theorizing and studying institutional work. In T. B. Lawrence, R. Suddaby, & B. Leca (Eds.), Institutional work: Actors and agency in institutional studies of organizations (pp. 1–28). New York: Cambridge University Press.

Layton, R. A. (2011). Towards a theory of marketing systems. European Journal of Marketing, 45(1/2), 259–267.

Lewin, K. (1939). Field theory and experiment in social psychology. American Journal of Sociology, 44(6), 868–896.

Loasby, B. J. (2000). Market institutions and economic evolution. Journal of Evolutionary Economics, 10(3), 297–309.

Loasby, B. J. (2001). Knowledge, institutionsand evolution ineconomics. New York: Routledge.

Lusch, R. F., & Brown, J. R. (1996). Interdependency, contracting, and relational behavior in marketing channels. Journal of Marketing, 60, 19–38.

Lusch, R. F., & Nambisan, S. (2015). Service innovation: a servicedominant (s-d) logic perspective. Management Information Systems Quarterly, 39(1), 155–175.

Lusch, R. F., & Tay, N. (2004). Agent-based modeling: Gaining insight into firm and industry performance. In C. Moorman & D. R. Lehman (Eds.), Assessing marketing strategy performance (pp. 213–227). Cambridge: Marketing Science Institute.

Lusch, R. F., & Vargo, S. L. (2006). Service-dominant logic as a foundation for a general theory. In R. F. Lusch & S. L. Vargo (Eds.), The service-dominant logic of marketing: Dialog, debate, and directions (pp. 381–420). Armonk: ME Sharpe.

Lusch, R. F., & Vargo, S. L. (2014). Service-dominant logic: Premises, perspectives, possibilities. Cambridge: Cambridge University Press.

Lusch, R. F., & Webster, F. E. (2011). A stakeholder-unifying, cocreation philosophy for marketing. Journal of Macromarketing, 31(2), 129– 134.

Lusch, R. F., Vargo, S. L., & O’Brien, M. (2007). Competing through service: insights from service-dominant logic. Journal of Retailing, 83(1), 5–18.

Lusch, R. F., Vargo, S. L., & Tanniru, M. (2010). Service, value-networks, and learning. Journal of the Academy of Marketing Science, 38(1), 19–31.

Macneil, I. R. (1980). The new social contract: An inquiry into modern contractual relations. London: Yale University Press.

Maglio, P., Vargo, S. L., Caswell, N., & Spohrer, J. (2009). The service system is the basic abstraction of service science. Information Systems and e-Business Management, 7(4), 395–406.

McAlexander, J. H., Dufault, B. L., Martin, D. M., & Schouten, J. W. (2014). The marketization of religion: field, capital, and consumer identity. Journal of Consumer Research, 41(3), 858–875.

McColl-Kennedy, J. R., Vargo, S. L., Dagger, T. S., Sweeney, J. C., & van Kasteren, Y. (2012). Health care customer value co-creation practice styles. Journal of Service Research, 15(November), 370–89.

Menard, C. (1996). Markets as institutions versus organizations as markets? Disentangling some fundamental concepts. Journal of Economic Behavior and Organization, 28(2), 161–82.

Merriam Webster Online: An encyclopedia of the Britannica Co. (2015) http://www.merriam-webster.com/dictionary/interaction.

Merz, M., He, Y., & Vargo, S. L. (2009). The evolving brand logic: a service-dominant logic perspective. Journal of the Academy of Marketing Science, 37(3), 338–44.

Meyer, J. W., & Rowan, B. (1977). Institutionalized organizations: formal structure as myth and ceremony. American Journal of Sociology, 83(2), 340–363.

Mitchell, W. C. (1937). The backward art of spending money and other essays. New York: Augustus M. Kelley, Inc.

Mitchell, M. (2009). Complexity: A guided tour. New York: Oxford University Press.

Moeller, S. (2008). Customer integration – a key to an implementation perspective of service provision. Journal of Service Research, 11(November), 197–210.

Mokyr, J. (2002). The gifts of Athena: Historical origins of the knowledge economy. Princeton: Princeton University Press.

Nicolini, D. (2009). Zooming in and out: studying practices by switching theoretical lenses and trailing connections. Organization Studies, 30(12), 1391–1418.

North, D. C. (1990). Institutions, institutional change, and economic performance. Cambridge: Cambridge University Press.

Orlikowski, W. J. (2007). Sociomaterial practices: exploring technology at work. Organization Studies, 28(9), 1435–1448.

Ostrom, E. (1990). Governing the commons: The evolution of institutions of collective action. Cambridge: Cambridge University Press.

Ostrom, E. (2005). Understanding institutional diversity. Princeton: Princeton University Press.

Payne, A., Storbacka, K., & Frow, P. (2008). Managing the co-creation of value. Journal of the Academy of Marketing Science, 36(1), 83–96.

Payne, A., Storbacka, K., Frow, P., & Knox, S. (2009). Co-creating brands: diagnosing and designing the relationship experience. Journal of Business Research, 62(3), 379–389.

Peters, B. G. (2012). Institutional theory in political science: The new institutionalism. New York: Continuum International Publishing Group.

Polanyi, K. (1968). The economy as instituted process. In E. LeClair & H. Schneider (Eds.), Economic anthropology (p. 126). New York: Holt, Rinehart and Winston.

Ramaswamy, V., & Ozcan, K. (2014). The co-creation paradigm. Redwood City: Stanford University Press.

Rand, W., & Rust, R. T. (2011). Agent-based modeling in marketing: guidelines for rigor. International Journal of Reserch in Marketing, 28(3), 181–193.

Randall, W. S., Pohlen, T. L., & Hanna, J. B. (2010). Evolving a theory of performance based logistics using insights from service-dominant logic. Journal of Business Logistics, 31(2), 35–61.

Reckwitz, A. (2002). Toward a theory of social practices: a development in culturalist theorizing. European Journal of Social Theory, 5(2), 243–263.

Revzan, D. A. (1968). The holistic-institutional approach to marketing. In J. B. Kernan & M. S. Sommers (Eds.), Perspectives in marketing (pp. 97–136). New York: Appleton.

Rindfleisch, A., & Moorman, C. (2003). Interfirm cooperation and customer orientation. Journal of Marketing Research, 40(4), 421–436. Schumpeter, J. A. (1934, 1980). The theory of economic development. London: Oxford University Press.

Scott, W. R. (2001). Institutions and organizations. Thousand Oaks: Sage.

Scott, W. R. (2008). Institutions and organizations: Ideas and interests. Los Angeles: Sage.

Shaw, E. H., Brian Jones, D. G., & McLean, P. A. (2010). The early schools of marketing thought. In P. Maclaran, M. Saren, B. Stern, & M. Tadajewski (Eds.), The Sage handbook of marketing theory (pp. 27–41). Los Angeles: Sage.

Shaw, G., Bailey, A., & Williams, A. (2011). Aspects of service-dominant logic and its implications for tourism management: examples from the hotel industry. Tourism Management, 32(2), 207–214.

Sheth, J. N., & Parvatiyar, A. (1995). Relationship marketing and consumer markets: antecedents and consequences. Journal of Academy of Marketing Science, 23(4), 255–271.

Simon, H. A. (1945/1997). Administrative behavior: A study of decisionmaking processes in administrative organizations. New York: The Free Press.

Simon, H. A. (1957). A behavioral model of rational choice. in Models of man, social and rational: mathematical essays on rational human behavior in a social setting. New York: Wiley.

Simon, H. A. (1978). Rationality as process and as product of thought. The American Economic Review, 68(2), Papers and Proceedings of the Ninetieth Annual Meeting of The American Economic Association. 1–16.

Simon, H. A. (1996). The sciences of the artificial. Cambridge: The MIT Press.

Smith, A. (1980). The principles which lead and direct philosophical enquiries: Illustrated by the history of astronomy. In W. P. D. Wightman (Ed.), Essays on philosophical subjects (pp. 33–105). Oxford: Oxford University Press.

Spencer, H. (1910). The principles of sociology. London: Appleton.

Spohrer, J., & Maglio, P. P. (2008). Fundamentals of service science. Journal of the Academy of Marketing Science, 36(1), 18–20.

Spohrer, J., Maglio, P. P., Bailey, J., & Gruhl, D. (2007). Towards a science of service systems. Computer, 40(1), 71–77.

Stern, L. W., & Reve, T. (1980). Distribution channels as political economies: a framework for comparative analysis. Journal of Marketing, 44(Summer), 52–64.

Swedberg, R. (1991). Major traditions of economic sociology. Annual Review of Sociology, 17, 251–276.

Tay, N., & Lusch, R. F. (2005). A preliminary test of Hunt’s general theory of competition: using artificial adaptive agents to study complex and ill-defined environments. Journal of Business Research, 58(9), 1155–1168.

Tesfatsion, L. (2002). Agent-based computational economics: growing economies from the ground Up. Artificial Life, 8(1), 55–82.

Thornton, P. H., Ocasio, W., & Lounsbury, M. (2012). The institutional logics perspective: A new approach to culture, structure and process. Oxford: Oxford University Press.

Vargo, S. L. (2007). On a theory of markets and marketing: from positively normative to normatively positive. Australasian Marketing Journal, 15(1), 53–60.

Vargo, S. L. (2008). Customer integration and value creation: paradigmatic traps and perspectives. Journal of Service Research, 11(November), 211–215.

Vargo, S. L. (2009). Towards a transcending conceptualization of relationship: a service dominant logic perspective. Journal of Business and Industrial Marketing, 24(5), 373–78.

Vargo, S. L., & Lusch, R. F. (2004). Evolving to a new dominant logic for marketing. Journal of Marketing, 68(January), 1–17.

Vargo, S. L., & Lusch, R. F. (2006). Service-Dominant Logic: What it is, what it is not, what it might be. In R. F. Lusch & S. L. Vargo (Eds.), The service-dominant logic of marketing: Dialog, debate, and directions (pp. 43–56). Armonk: ME Sharpe.

Vargo, S. L., & Lusch, R. F. (2008). Service-dominant logic: continuing the evolution. Journal of the Academy of Marketing Science, 36(1), 1–10.

Vargo, S. L., & Lusch, R. F. (2010). From repeat patronage to value cocreation in ecosystems: a transcending conceptualization of relationship. Journal of Business Market Management, 4(4), 169–79.

Vargo, S. L., & Lusch, R. F. (2011). It’s all b2b and beyond…: toward a systems perspective of the market. Industrial Marketing Management, 40(2), 181–187.

Vargo, S. L., & Morgan, F. W. (2005). Services in society and academic thought: an historical perspective. Journal of Macromarketing, 25(1), 42–53.

Vargo, S. L., Maglio, P. P., & Akaka, M. A. (2008). On value and value co-creation: a service systems and service logic perspective. European Management Journal, 26(3), 145–52.

Vargo, S. L., Wieland, H., & Akaka, M. A. (2015). Institutions in innovation: a service ecosystems perspective. Industrial Marketing Management, 44(1), 63–72.

Veblen, T. (1899/1934). The theory of the leisure class: an economic study of institutions. New York: The Modern Library.

Venkatesh, A., Penaloza, L., & Firat, A. (2006). The market as a sign system and the logic of the market. In R. F. Lusch & S. L. Vargo (Eds.), The service-dominant logic of marketing: Dialog, debate, and directions (pp. 251–265). Armonk: ME Sharpe.

von Mises, L. (2008/1949). Human action. The scholar’s edition. The Ludwig von Mises Institute, Alabama.

Weld, L. D. H. (1916). The marketing of farm products. New York: Macmillan.

Whitehead, A. N. (1911). An introduction to mathematics. Cambridge: Cambridge University Press.

Williamson, O. E. (1975). Markets and hierarchies: Analysis and antitrust implications. New York: Free Press.

Williamson, O. E. (1981). The modern corporation: origins, evolution, attributes. Journal of Economic Literature, 19(4), 1537–1568.

Williamson, O. E. (1985). The economic institutions of capitalism. New York: Free Press.

Williamson, O. E. (1988). The logic of economic organization. Journal of Law, Economics, and Organization, 4(1), 65–93.

Williamson, O. E. (1991). Comparative economic organization: the analysis of discrete structural alternatives. Administrative Science Quarterly, 36(2), 269–296.

Williamson, O. E. (2000). The new institutional economics: taking stock, looking ahead. Journal of Economic Literature, 38(3), 595–613.

Yan, J., Ye, K., Wang, H., & Hua, Z. (2010). Ontology of collaborative manufacturing: alignment of service-oriented framework with service-dominant logic. Expert Systems with Applications, 37(2), 2222–2231.

Yang, Z., Su, C., & Fam, K. S. (2012). Dealing with institutional distances in international marketing channels: governance strategies that engender legitimacy and efficiency. Journal of Marketing, 76(3), 41–55.

 

SL Vargo, RF Lusch – Recent developments of Service-Dominant Logic (readings)

Foundations of Service-Dominant Logic

Service Ecosystems

Innovation, Institutionalization, and Technology

Value Co-creation

Experience and Engagement

Stephen P Osborne – The New Public Governance (readings)

Modeling Service Systems with LSS-USDL

After Cardoso, Lopes, and Poels – Service systems, concepts, and modeling – Ch 4 Modeling and programming (2014).

Here we consider how a service system can be modeled with LSS-USDL using semantic web languages and technologies. Later we will consider:

  • how a service system model can be accessed and queried programmatically (we chose Python because stable software libraries to access and modify RDF models are available)
  • how a service system model can be annotated with background knowledge from the Linked Data Cloud (we chose DBpedia since it is one of the largest existing knowledge basis)

1

The methodology we have followed consisted in

  • looking at the IM service as a flow of interactions
  • using the LSS-USDL model to capture each interaction

In other words, each interaction was analyzed by answering the questions: who, why, where, when, what, and how. The answers to these questions provided detailed information about the more relevant interaction features, such as: roles, goals, locations, time, resources, and processes, completing the model information.

2

The modeling exercise with Turtle and using the LSS-USDL model begins by specifying a set of prefixes. Prefixes are a convenient method for representing a name space URI with a short string. Prefixes facilitate the reference to other ontologies in an easy and unambiguous way. Each prefix refers to a basilar ontology which is used to model the service.

There are some common ontologies used by many models or instances: rdf, rdfs, owl, and xml. The most specialized ontologies we have used are:

  • GoodRelations (gr) [1] references the GoodRelations ontology, a standardized vocabulary to describe product, price, store, and company data.
  • Friend of a Friend (foaf) is an ontology describing persons, their activities, and their relations to other people and objects.
  • Time Ontology (time) covers basic temporal relations. The ontology allows to capture temporal relationships such as before and during.

The use of external vocabularies and ontologies enables to integrate the service instance to a large base of knowledge made available by many organizations and initiatives.

3

As a first step to build our IM service instance, we define a new instance of service system named IncidentManagementService. It is a new class that inherits all the properties of the class lss-usdl:ServiceSystem. To provide descriptive information to this new service, we used the RDFS predicates label, comments, and the LSS-USDL term hasGoal. See lines 1–4 of Listing 4.2.

The incident management service handles incidents (e.g., failures, questions, or queries reported by users) and consists of the following steps:

  1. Identification
  2. Logging
  3. Classification
  4. Prioritization
  5. Diagnosis
  6. Escalation
  7. Investigation and diagnosis
  8. Resolution and recovery
  9. Closure

Steps were captured as instances of lss-usdl:Interaction with the predicate hasInteraction (Listing 4.2, lines 6–14). Thus, IncidentIdentification, IndicentLogging, etc. are instances of lss-usdl:Interaction.

  1. :IncidentManagementService  an lss-usdl:ServiceSystem ;
  2. rdfs:label “ITIL Incident Management Service”;
  3. rdfs:comment “A service system for Incident Management, based on ITIL specs. The main objective of the incident management process is to resume the regular state of affairs as quickly as possible and minimize the impact on business processes.” ;
  4. lss-usdl:hasGoal :SolveIncident ;
  5. lss-usdl:hasInteraction
  6. :IncidentIdentification ,
  7. :IncidentLogging ,
  8. :IncidentClassification ,
  9. :IncidentPrioritization ,
  10. :InitialDiagnosis ,
  11. :IncidentEscalation ,
  12. :InvestigationDiagnosis ,
  13. :ResolutionRecovery ,
  14. :IncidentClosure .

Listing 4.2 The first building block to construct a service system.

The following sections will detail how each interaction was modeled.

4.2.3 Interactions

Since there are nine interactions (i.e. nine instances of lss-usdl:Interaction, we will only describe two of them, which is sufficient to illustrate how modeling is performed: IncidentLogging and Initial Diagnosis. The complete specification of the interactions can be found at http:// eden.dei.uc.pt/~jcardoso/rdf/lss-usdl-eg/ITIL_IM_service.ttl. Each interaction answers to six questions: who (roles), why (goals), where (locations), what (resources), when (time), and how (processes).

4.2.3.1 Incident Logging

Essential step in managing incidents is to receive and record them. This is carried out by the Incident Logging interaction. When it is determined that an incident has occurred through a Service Desk telephone call or automatically detected via an event alert, the logging interaction will document the incident. All relevant information describing the incident must be logged so that a full historical record is maintained. Logging should at a minimum record the date and time of the incident, the person/system reporting the incident, and a description of the problem. Listing 4.3 shows the complete specification for this interaction.

  1. :IncidentLogging  a lss-usdl:BackstageInteraction ;
  2. rdfs:label “An incident is logged”;
  3. rdfs:comment”Incidents reported to the Service Desk must be logged with the date and time stamp when they were generated.” ;
  4. lss-usdl:performedBy :ServiceDeskManager ;
  5. lss-usdl:hasGoal :DealWithReportedIncident ;
  6. lss-usdl:hasLocation :ABCompany ;
  7. lss-usdl:belongsToProcess :ITServiceIncidentManagement ;
  8. lss-usdl:consumesResource :ReportData ;
  9. lss-usdl:consumesResource :IncidentData ;
  10. lss-usdl:createsResource :IncidentID ;
  11. lss-usdl:createsResource :IncidentRecord .
  12. lss-usdl:hasTime
  13. [a lss-usdl:Time ;
  14. lss-usdl:hasTemporalEntity :IncidentLoggingTime] ;
  15. :IncidentLoggingTime a time:ProperInterval ;
  16. time:intervalAfter :IncidentIdentificationTime ;
  17. time:intervalBefore :IncidentCategorizationTime .

Listing 4.3 The Incident Identification interaction.

The example illustrates that the interaction is described as a Backstage Interaction, which is performed by the ServiceDeskManager role; it has the DealWithReportedIncident goal; it is performed at the ABCompany location; it belongs to the ITServiceIncidentManagement process; it consumes two knowledge resources (IncidentData and ReportData) and it creates two knowledge resources (IncidentID and IncidentRecord). The interaction has also a temporal entity associated which allows specifying that this interaction occurs before the IncidentCategorization interaction and after the Incident Identification interaction.

The knowledge resources IncidentData and ReportData typically include the following information:

  • Basic information needed to handle the incident, such as date and time of the occurrence, description of the incident, and systems affected.
  • Supporting information for the resolution of the incident that may be asked to the submitter using, possibly, a specific form.

The IncidentRecord will aggregate these information and will assign a reference to the incident to uniquely identify it in both internal processes and when communicating with the person affected by the incident.

4.2.3.2 Initial Diagnosis

The Initial Diagnosis is the fourth step in the incident management process.It follows the incident categorization. The initial diagnosis is the first attempt at resolving an incident. Typically, the technical staff of the Service Desk will carry out an initial diagnosis and will try to understand the incident being reported.He will try to discover the full symptoms of the incident, determine what went wrong, and how to solve the problem. If available, diagnostic scripts and known error information is valuable in allowing an earlier and accurate diagnosis. The interaction described in Listing 4.4 represents the initial diagnosis of an incident performed by the technical staff of the Service Desk.

  1. :InitialDiagnosis a lss-usdl:BackstageInteraction ;
  2. rdfs:label “An initial diagnosis for the incident is performed”;
  3. rdfs:comment”The initial diagnosis of incidents is mainly a human process. The Service Desk technical staff looks at the information within the incident and communicates with the user to diagnose the problem.” ;
  4. lss-usdl:performedBy :TechnicalStaff ;
  5. lss-usdl:hasGoal :HandleIncident ;
  6. lss-usdl:hasTime [a lss-usdl:Time ;
  7. lss-usdl:hasTemporalEntity :InitialDiagnosisTime] ;
  8. lss-usdl:hasLocation :ABCompany ;
  9. lss-usdl:belongsToProcess :ITServiceIncidentManagement ;
  10. lss-usdl:consumesResource :IncidentRecord .
  11. :IncidentInitialDiagnosisTime a time:ProperInterval ;
  12. time:intervalAfter :DetermineIfIncidentIsMajorTime ;
  13. time:intervalBefore :DetermineIfFunctionalScalationIsNeededTime .

Listing 4.4 The Initial Diagnosis.

The interaction is described as a BackstageInteraction which is performed by the ServiceDeskStaff role; it has the HandleIncident goal; it is performed at the ABCompanylocation;it belongs to the ITServiceIncident Management process and it consumes the knowledge resource Incident Report.The interaction has also a temporal entity associated, which allows specifying that it occurs before the DetermineIfFuntionalScalationIsNeeded Time interaction and after the DetermineIfIncidentIsMajorTime interaction.

4.2.4 Roles

Each interaction has a performedBy predicate indicating who is participating in the interaction. In some cases, there are many roles for the same interaction. Roles can belong to an entity. In such a case, the concept Business Entities from GoodRelations is used. While the number of roles depends on the ITIL implementation that a company chooses to make, we have compiled a list of 5 roles which are typical:

  • Service Desk Manager. Functions as the primary point of contact for incidents reported from users. The role owns the results of the service desk function.
  • Problem Manager. Responsible for managing the life-cycle of all problems. The primary objectives are to prevent incidents from happening and to minimize the impact of incidents that cannot be prevented.
  • Incident Manager. The role assigned to the person who owns the results of the Incident Management service and of its effective implementation.
  • Technical Staff. Aggregates the first,second,and third-tier support groups,including specialist support groups and external service providers.
  • End User. The end users and employees of a company that experience difficulties with IT and which rely on services to restore a normal processing as quickly as possible after an incident has occurred.

Listing 4.5 describes these roles using the LSS-USDL model.Each role has a label and a brief description as well as an assignment to a business entity it belongs to.Most of the roles belong to the ABCompany company, except the role ProblemManager which belong to the ExtCompany company.

  1. :ServiceDeskManager a lss-usdl:Role ;
  2. rdfs:label “Service Desk Manager”;
  3. rdfs:comment”Functions as the primary point of contact for incidents reported from users.”;
  4. lss-usdl:belongsToBusinessEntity :ABCompany.
  5. :ProblemManager a lss-usdl:Role ;
  6. rdfs:label”Problem Manager”;
  7. rdfs:comment”Responsible for managing the lifecycle of all problems.”;
  8. lss-usdl:belongsToBusinessEntity :ExtCompany .
  9. :IncidentManager a lss-usdl:Role ;
  10. rdfs:label”Incident Manager”;
  11. rdfs:comment”The person who owns the results of the Incident Management service”;
  12. lss-usdl:belongsToBusinessEntity :ABCompany .
  13. :TechnicalStaff a lss-usdl:Role ;
  14. rdfs:label”Technical Staff”;
  15. rdfs:comment”Support technical staff”;
  16. lss-usdl:belongsToBusinessEntity :ABCCompany .
  17. :EndUser a lss-usdl:Role ;
  18. rdfs:label”End User”;
  19. rdfs:comment”The end users and employees of a company that experience difficulties with IT.” ;
  20. lss-usdl:belongsToBusinessEntity :ABCompany .

Listing 4.5 Modeling roles and business entities

Not all the roles defined were used in the examples of this chapter. The objective was to show how role modeling can be achieved. To structure and organize the many roles that can exist, the knowledge organization systems SKOS can be used to construct a classification schema or a taxonomy.

4.2.5 Goals

The concept of goal has been used in many domains such as business sciences and strategic planning. The objective is to provide a planning framework which links goals with interactions. It is intended to assist ITIL service owners in understanding the effects of interactions on services.

Each interaction has a one, or more, hasGoal predicate(s), indicating the goal(s) a specific interaction occurs. Listing 4.6 shows examples of several goals.

  1. :ReportIncident a lss-usdl:Goal ;
  2. rdfs:label “Report Incident”;
  3. rdfs:comment”A user, technical staff or system reports an incident regarding an IT service.”.
  4. :HandleIncident a lss-usdl:Goal ;
  5. rdfs:label”Handle Incident”;
  6. rdfs:comment”Execute several actions to deal with a reported incident.”.
  7. :RestoreNormalOperation a lss-usdl:Goal ;
  8. rdfs:label”Restore Operation”;
  9. rdfs:comment”Restore the normal service operation as quickly as possible.” .

Listing 4.6 Modeling the goals of interactions.

Since goals are targets for achievements, they should be written in such a way that they express the rationale for the interactions that exist and guides decisions at various levels within the enterprise. Here again, the SKOS can be used to organize goals using, e.g., structured controlled vocabularies.

4.2.6 Locations

The class lss-usdl:Location is concerned with the geographical location of the IM service interactions. Locations can be expressed simply as a list of the places where interactions occur, or they can take a more detailed form by describing how locations are related or detailing the facilities/IT that are available in each location.

Each interaction has a hasLocation predicate indicating where the interaction happens. For the IM service, we have identified two locations: the ServiceDesk Office and the UserOffice. The ServiceDeskOffice represents the location where a user or system can report an incident and the UserOffice location refers to the location where the company staff is working.

  1. :ServiceDeskOffice a lss-usdl:Location ;
  2. rdfs:label “Service Desk Office”.
  3. :UserOffice a lss-usdl:Location ;
  4. rdfs:label”User Office” .

Listing 4.7 Modeling locations within a service system.

The Listing 4.7 shows the definition of both locations. While these locations are concepts that only have a meaning for the company implementing the IM service, another approach to use geographical descriptions. This can be achieved by using, e.g., the GeoNames ontology, a data structure containing over 8.5 million geographical names. The information covers coordinates, administrative divisions, postal codes, amongst others. GeoNames can answer questions such as what are the coordinates for a location; which region or province does a location belong to; and what city or address is near a given GPS latitude / longitude.

4.2.7 Time

Each interaction uses a hasTime predicate to indicate when it occurs. The Time ontology is used for temporal reasoning. Typically, two time modeling options can be defined. The first one, used in this example, defines temporal relationships between interactions using constructs such as before or after.The second,uses time intervals of times point to define when an interaction can occur or occurs. Listing 4.8 exemplifies the use of the concept ProperInterval to describe the temporal dependencies between interactions.

  1. :IncidentIdentificationTime a time:ProperInterval;
  2. time:intervalAfter :IncidentCategorizationTime .
  3. :IncidentCategorizationTime a time:ProperInterval;
  4. time:intervalBefore :IncidentIdentificationTime;
  5. time:intervalAfter :IncidentPrioritizationTime .
  6. :IncidentPrioritizationTime a time:ProperInterval;
  7. time:intervalBefore :IncidentCategorization;
  8. time:intervalAfter :InitialDiagnosisTime .
  9. :InitialDiagnosisTime a time:ProperInterval;
  10. time:intervalBefore :IncidentPrioritizationTime;
  11. time:intervalAfter :InvestigationDiagnosisTime .
  12. time:intervalBefore :InitialDiagnosisTime;
  13. time:intervalAfter :ResolutionRecoveryTime;
  14. time:intervalEquals :scalationFirstTime .
  15. :ResolutionRecoveryTime a time:ProperInterval;
  16. time:intervalBefore :InvestigationDiagnosisTime;
  17. time:intervalAfter :IncidentClosureTime;
  18. time:intervalEquals :scalationSecondTime .
  19. :IncidentClosureTime a time:ProperInterval;
  20. time:intervalBefore :ResolutionRecoveryTime.
  21. :scalationFirstTime a time:TemporalEntity;
  22. rdfs:label “Scalation time for first level”;
  23. rdfs:comment”Need to define hasDurationDescription”.
  24. :scalationSecondTime a time:TemporalEntity;
  25. rdfs:label”Scalation time for second level”;
  26. rdfs:comment”Need to define hasDurationDescription” .

Listing 4.8 Modeling time within a service system.

4.2.8 Resources

Interactions can use the receivesResource, consumesResource, createsResource, or returnsResource predicate to indicate the resources received, consumed, created, or returned. For the IM service, we have defined that the interaction IncidentLogging consumes knowledge from the user in the form of ReportData and IncidentData and creates two new resources: IncidentID and IncidentRecord. Listing 4.9 defines the resource IncidentRecord.

  1. :IncidentRecord a lss-usdl:KnowledgeResource ;
  2. rdfs:label “Incident Record”;
  3. rdfs:comment”An Incident Record generated during the IncidentLogging” ;
  4. owl:sameAs dbpediar:Incident_report .
  5. :Severity a rdf:Property ;
  6. rdfs:domain :IncidentRecord ; 8 rdfs:range xsd:integer .

Listing 4.9 Modeling the resources associated with interactions.

Naturally, the IncidentRecord should include more fields, besides Severity, to reflect the complexity of records, which describe an incident. Our example is simple to convey the principle of resource and their descriptions.

4.2.9 Process

Each interaction belongs to a business process model (concept), which can be specified using the property belongsToProcess (see Listing 4.3). In turn, the process model can be associated with an implementation, which can be made using, e.g., the Business Process Modeling Notation (BPMN) or Event-driven Process Chain (EPC) notations.

  1. :ITServiceIncidentManagement a lss-usdl:Process ;
  2. rdfs:label “Incident Management Business Process Model” ;
  3. lss-usdl:hasBPMN bpmnrep:IM_BPMN .

Listing 4.10 Modeling the process to which interactions belong.

Listing 4.10 shows a process model ITServiceIncidentManagement created to exemplify the use of the property hasBPMN to associate an implementation with the model, which, in this case, can be accessed at bpmnrep:IM_BPMN. While LSS-USDL only includes one property to attach BPMN processes to a service system, this was done as a proof of concept and additional properties can be specified to relate interactions with other process modeling languages.

References

  1. Jan Van Bon, Arjen de Jong, and Axel Kolthof. Foundations of IT Service Management based on ITIL. Van Haren Publishing, 2007.
  2. Kerstin Gerke, Jorge Cardoso, and Alexander Claus. Measuring the compliance of processeswith reference models. In 17th International Conference on Cooperative Information Systems (CoopIS), Algarve, Portugal, 2009. Springer.
  3. Martin Hepp. Goodrelations: An ontology for describing products and services offers on theweb. In Knowledge Engineering: Practice and Patterns, pages 329–346. Springer, 2008.
  4. ITIL Service Operation. ITIL Series. Stationery Office, 2007.
  1. 2 Step-by-step modeling
  2. 2.1 Prefixes and external vocabularies
  3. 2.2 The Service System

Transparency of services

After Cardoso, J, R Lopes, and G Poels – Service systems: Concepts, modeling, and programming – Ch 1 White-box service systems – 2014

Where this is going (in terms of the family of USDL specifications):

The USDL specification proved too complex, and had little up take in the field. Linked USDL was developed to be simpler, and to incorporate Linked Data principles (e.g. URIs) and the Web of Data (e.g. reusable vocabularies). The Linked USDL specification continues to be viable, but it's a "black box" model of service, i.e. it doesn't model the "internals" of the service, but stops at the user interface. So Cardoso et al developed the Linked Service Systems USDL (LSS-USdL) as a "white box" model that allows the user to see and modify the "internals" of the service (also note: a "gray box" model allows the user to see and modify "some" of the internals, which is probably best, so as not to overwhelm the user with too many details).

Why does an effort to model "Service Systems" lead to the development of a "white box" model like LSS-USDL? Cardoso et al focus on the fact that the "upfront" Service in a Service System (i.e. the Service requested by the User) may engage another Service to provide some "internal component" in a manner that's best exposed to the User.

Service modeling approaches can be described and classified according to the degree to which the internal and external elements of a service system are visible to and modifiable by consumers in the outside world.The visibility of a service system can be studied from an external and internal perspective. The modifiability of a service system can be studied from an internal perspective. These two important variables, visibility and modifiability, have their origin in software engineering.

Example

Imagine that a consumer needs to interact with a particular service. For example, a service that calculates and prepares a tax return form for the fiscal year. The service is housed in a black box and has an interface with buttons, form fields, and status fields on the outside that allow consumers to download forms, upload forms, pay for the use of the service, and to check the status of the forms submitted. Consumers can only interact with the service without opening the black box and cannot see beyond its surface. It is only possible to see how the service works by pressing the buttons (inputs), filling form fields (inputs), and seeing what happens to the status fields (outputs or outcomes). The service takes certain inputs and produces outputs in response to the inputs. Perhaps because we do not know, or are not interested, or cannot afford extra time to understand, we make a deliberate decision not to consider what happens inside the black box that presents the system. The internal structure, in this case, is not considered or analyzed. A service that exhibits this behavior is termed a black-box service (Figure 1).

On the other hand, a service can also enable consumers to see and modify its internal elements. Consumers can potentially explore a service internally and also explore its subparts. Internal elements can be composed of business process models, people, business rules, infrastructure, IT, and security aspects, which are involved during service provision. By analogy, services that exhibit this behavior are called white-box service. In this situation, it is possible to look inside the white box and try to identify some of the elements that occur in the service, analyze them, and represent them with a series of models.

It should be noted, though, that it may happen that white-box services are composed at some point by black boxes. It is never possible to describe all the details of all the elements of a service. It is possible to go gradually into further depth in the service (which can be seen as having an element tree structure), providing more detail about its elements. As a greater level of detail is achieved, it is possible to find certain black boxes which we do not wish to, or cannot, consider in more detail. If that were not the case, the models of the service under study would end up being as complex as the original real-world service, and therefore would deliver little value for the purposes of service modeling.

The transparency of service

Figure 1. The transparency of service.

Classification of transparency

With respect to visibility and modifiability, four main types of service modeling approaches can be identified: black box, glass box, grey box, and white box. For all these types, interfaces are visible externally. If a service is a black box, it is not possible to modify or see its internal elements: it is used as-is. White-box service internal elements can be modified, even though this does not need to always happen. The term glass-box service means that a service has a white-box visibility but a black-box modifiability. A grey box derives from a white box for which only partial elements are visible and modifiable.

  • Black-box service
    • access to external interface
    • consumers have no knowledge of internal structures and processes
    • consumers cannot modify internal elements
    • external visibility from a consumers point of view
    • “as-is” service
  • White-box service (aka Clear-box service)
    • access to external interface
    • consumers have full knowledge of internal structures and processes
    • consumers can modify internal elements
  • Glass-box service
    • access to external interface
    • consumers have full knowledge of internal structures and processes
    • consumers cannot modify internal elements
    • functionalities can be discovered by inspecting internal structures
    • “as-is” service
  • Grey-box service
    • access to external interface
    • consumers have some knowledge on visible internal elements
    • compromise between black- and white-box services
    • services have a degree of “greyness”
    • consumers can modify visible internal elements

Black-Box Service A black-box approach allows describing a service with interface information that is externally visible to consumers. Nonetheless, the internal details of services are hidden. The black box implies that a service is used without seeing, knowing, or being able to modify any of its internal elements. The service provides an interface that contains all the information needed for its utilization. Therefore, it is not possible to make any assumptions about the internal behavior, governing rules, business processes, or state of a service. The implementation is hidden and cannot be modified by the consumer. On the other hand, the implementation of its internal elements can be changed by the provider without any effects on consumers.

White-Box Service A white-box approach is at the opposite extreme of a black-box one. It allows to completely expose service internal elements to consumers, beside exposing its external interface. With respect to the interface, white-box services have the same characteristics as black-box services. On the other hand, with white-box services, consumers are allowed to “peek” inside the service and modify internal structures and processes. The term “clear box” is also used in the field of software testing to describe this behavior.

Glass-Box Service The term glass-box service classifies services that are used “as-is”, like black-box services, but with internal elements that can be seen from the outside. Nonetheless, internal elements cannot be modified. This gives consumers information about how a service works without the ability to modify it. This internal visibility can be crucial for understanding how certain operations are carried out and finding the rules that govern a service.

Grey-Box Service When a service is viewed as a grey box, consumers have access to information that describes only part of its internals. Depending on the incidence degree of the “greyness”, a grey-box service can provide different levels of exposure of the service internal elements to consumers. They can see and modify the internal parts which were explicitly exposed by providers.

Benefits and limitations

Since the black-box view has limitations when it is necessary to discuss aspects of a service that do not appear in the interface description (for example, aspects related to the behavior of a service), this approach may not be always suitable for service system modeling, especially when consumers need to fully understand services. The approach falls down when a service needs to interact with third parties during execution since these interactions are not made visible to consumers. For example, when a front-end service has a back-end process representing its execution, the interactions with third parties expressed in the process are an integral part of the service. However, the black-box approach has positive aspects since it allows developing highly modular services and service compositions (i.e., business process models). As a consequence, any original service can be replaced with an alternative service as long as it has an equivalent interface.

White-box and glass-box services may in some cases be undesirable approaches since a consumer should be able to understand a service without being overwhelmed with the full complexity of services’ internal structures, processes, and implementations. This high degree of internal visibility may lead to dependencies on certain implementation details which become fatal when the internal elements of services are changed. Unfortunately, giving consumers detailed information about a service’s internal elements is often a compensation of nonexistent or insufficient documentation. While white and glass boxes enable defining exactly what a service does, and how it does it, they may in some cases be over-specified. On the other hand, this internal visibility can be crucial for understanding how certain operations are carried out. It may also give consumers confidence from being able to see inside a service and capture how it works. The observable internal elements may, for example, be state variables or interaction patterns. A suitable description should provide to consumers only the required information to understand a service, but no more than needed.

White-box modeling

One of the goals of the Linked USDL and USDL family was to provide service description languages for managers to formalize their organization’s services in a common, uniform format. However, USDL is limited to the description of a service from a black-box perspective, so a complete service system representation is not possible. Figure 2 illustrates this limitation. In other words, USDL views a service as a black-box and internal details are not modeled. For example, while the characterization of the provider, the technical interfaces to access the system, and the price of the service are all defined, no information is given about the roles and skills of the people which need to be involved, the physical and information resources required, or the physical location where activities occur. A white-box approach would enable to model in detail the information describing how a service works internally.

Relationships between business models, service systems, service models, service instances, and service descriptions

Figure 2. Relationships between business models, service systems, service models, service instances, and service descriptions.

A model that could formalize and describe a service system’s operations would result in many benefits, such as:

Transparency. A white-box description lets stakeholders to better understand how service systems work. In many situations, transparency increases organizations’ credibility, sustainability, and enables governments to clarify how taxpayers’ money is spent. Recent movements such as Open Data [20] and Open Innovation [21] claim for a greater level of transparency. Business regulations, such as Basel and Sarbanes-Oxley, which define a “pillar” for how a business should function, can also benefit from making their services more transparent to managers.

Analysis. Only after modeling a complete service system it is possible to get an overall picture while also being able to look at all the details. Using techniques for analysis, it is possible to identify potential drawbacks such as bottlenecks and fail points, and study solutions to overcome them. By using computer-understandable languages, it is possible to conduct simulations of interactions and behavior of service systems to aid managerial and operational decisions. Methods similar to process mining [22] can be used to obtain insights on how services are provisioned.

Multi-perspective. A white-box service system modeling tool can generate different service description views based on the stakeholder accessing the model and its objective. In other words, service systems can have multi-perspectives. Hence, customers may obtain a service description such as the one provided by Linked USDL; staff can obtain a description view depicting internal operations; and so forth. Those are all different views of the same service system.

Automation. The use of computer-understandable languages also enables to increase the level of automation of tasks, e.g., the automated generation of service documentation for customers and staff to better understand services. Documentation facilitates staff training and customers knowledge about service offerings. It is also possible to read service models, schedule and dispatch workers, and assign resources to complete service provisioning.

These benefits can foster the development of theories, methods, and tools to enable organizations and societies to converge towards economies which are truly service-based and service-driven.

[Additional from R Lopes, LaNDLESS: Integrating Linked Data with Linked Services, 2013:

One of the original goals of USDL was to address this issue and provide a service description language for managers to formalize their organization’s services in a standardized format. However, USDL is limited to the description of the service’s customer interactions, so a complete service system description is still not possible. In other words, USDL treats a service as a blackbox where internal details are not known.

A model that could formalize and describe the whole service system operations would thus facilitate managers’ transition from the currently chaotic service management to a formalized one. This would result in many bene fits, such as:

  • Documentation: Service systems would be modeled in a machine-readable language, which would make it possible to generate service descriptions for people to analyze and better understand it. This documentation generation facilitates staff formation, customers knowledge about the service off erings and so forth.
  • Transparency: A whitebox service system description would let stakeholders better understand what is happening. This would prove organizations’ credibility and sustainability and would let foundations and governments clarify where is people’s money being spent and justify potential decisions.
  • Bottlenecks and fail points identi fication: Only after modeling a complete service system it is possible to get a big picture view while also being able to look at all the details. If a service is well described, it should be possible to identify potential drawbacks such as bottlenecks and fail points and study solutions to overcome it.
  • Automation: If a service system is fully modeled in a machine-readable language, then all requirements are met for an automation tool to read that model and dispatch worker processes for certain inputs.
  • Simulation: Since we can model the full length of a service system in a machine-readable language, it is possible to conduct service system behavior simulations to aid managerial and operational decisions. Such simulations could be executed using the principles of System Dynamics.
  • Integration: USDL may already have some of the aforementioned bene ts, but lacks good integration of services with data and external services. Linked USDL tries to solve that problem by using Semantic Web technologies and integration with Linked Data, but it cannot fully address that problem because it still describes the service system as a blackbox. A whitebox service model, however, would be able to fully integrate with other data and services because it can provide the description of all its components.
  • Discovery: One of the goals of the Internet of Services (IoS) and USDL is to be able to describe services in such a standardized way that it might be possible to browse them in a generic online services marketplace. However, USDL can only provide a single service description, since it only models customer interactions. In other words, one service system generates only one service description, and thus it is not possible to generate a view or description for a manager with specifi c skills and another for an engineer with a di fferent set of skills and interests. A complete service system model would be able to generate dynamic service descriptions depending on what is relevant to display. Those service descriptions could then be aggregated in service marketplaces for easier discovery and comparisons.

Finally, a whitebox service system modeling tool could be able to generate diff erent service descriptions based on who is accessing it and what goals is the description trying to address at that moment. As such, customers could interact with a service description of customer interactions (such as USDL), staff could interact with a service description for internal operations and so forth. Those would be di fferent views of the same service system. Such an achievement might prove to be a very important advancement in the fi eld, potentially putting previous service models that generate a single service description to obsolesce.]

Previous: Linked Service System USDL (LSS-USDL) – Introduction
Next: Linked Service System USDL (LSS-USDL) – Perspectives, Definitions and Objectives

References

  1. Robert Glushko and Lindsay Tabas. Designing service systems by bridging the front stage andback stage. Information Systems and e-Business Management, 7:407–427, 2009.
  2. Jim Spohrer, Paul Maglio, John Bailey, and Daniel Gruhl. Steps toward a science of servicesystems. Computer, 40(1):71–77, January 2007.
  3. Holger Luczak, Christian Gill, and Bernhard Sander. Architecture for Service Engineering TheDesignandDevelopmentofIndustrialServiceWork.InDieterSpathandKlaus-PeterFähnrich, editors, Advances in Services Innovations, pages 47–63. Springer, Berlin Heidelberg, 2007.
  4. Henry Chesbrough and Jim Spohrer. A research manifesto for services science. Communications of the ACM, 49(7):35–40, 2006.
  5. Paul Maglio, Savitha Srinivasan, Jeffrey Kreulen, and Jim Spohrer. Service systems, servicescientists, SSME, and innovation. Communications of the ACM, 49(7):81–85, 2006.
  6. Stephen Vargo and Robert Lusch. Evolving to a new marketing dominant logic for marketing.Journal of Marketing, 68(1):1–17, 2004.
  7. Andreas Zolnowski, Martin Semmann, and Tilo Böhmann. Introducing a Co-Creation Perspective to Service Business Models. In Enterprise Modelling and Information Systems Architectures (EMISA), page 243, 2011.
  8. Thomas Erl. Service-Oriented Architecture: Concepts, Technology, and Design. Prentice HallPTR, Upper Saddle River, NJ, USA, 2005.
  9. Carlos Pedrinaci, John Domingue, and Amit Sheth. Handbook on Semantic Web Technologies,volume Semantic Web Applications, chapter Semantic Web Services. Springer, 2010.
  10. Service oriented architecture Modeling Language (SoaML) Specification, 2012.
  11. Matthew MacKenzie, Ken Laskey, Francis McCabe, Peter Brown, and Rebekah Metz. Reference Model for Service Oriented Architecture 1.0.
  12. The Open Group. Service-Oriented Architecture Ontology, 2010.
  13. John Domingue, Michal Zaremba, Barry Norton, Mick Kerrigan, Adrian Mocan, AlessioCarenini,EmiliaCimpian,MarcHaines,andJamesScicluna.ReferenceOntologyforSemantic Service Oriented Architectures Version 1.0, 2008.
  14. Mike Papazoglou. Web Services: Principles and Technology. Prentice Hall, 2012.
  15. Hans Akkermans, Ziv Baida, Jaap Gordijn, Nieves Pena, Ander Altuna, and Inaki Laresgoiti. Value webs: Using ontologies to bundle real-world services. IEEE Intelligent Systems, 19(4):57–66, July 2004.
  16. Martin Hepp. GoodRelations Language Reference, 2011.
  17. Carlos Pedrinaci, Jorge Cardoso, and Torsten Leidig. Linked USDL: A Vocabulary for Webscale Service Trading. In 11th Extended Semantic Web Conference, Crete, Greece, May 2014.
  18. Jorge Cardoso, Alistair Barros, Norman May, and Uwe Kylau. Towards a unified servicedescription language for the internet of services: Requirements and first developments. In Services Computing (SCC), 2010 IEEE International Conference on, pages 602–609. IEEE, 2010.
  19. Jorge Cardoso, Konrad Voigt, and Matthias Winkler. Service Engineering for The Internet ofServices. In Enterprise Information Systems X, volume 19, pages 17–25. Springer, 2008.
  20. ChristianBizer,TomHeath,andTimBerners-Lee.LinkedData-TheStorySoFar.InternationalJournal on Semantic Web and Information Systems, 5(3):1–22, 2009.
  21. Henry Chesbrough. Open innovation: The new imperative for creating and profiting fromtechnology. Harvard Business Press, 2003.
  22. Wil van der Aalst. Process Mining: Discovery, Conformance and Enhancement of BusinessProcesses. Springer Publishing Company, Incorporated, 1st edition, 2011.
  23. Roberta Ferrario, Nicola Guarino, Christian Janiesch, Tom Kiemes, Daniel Oberle, and FlorianProbst. Towards an ontological foundation of services science: The general service model. Wirtschaftsinformatik, Switzerland, pages 16–18, 2011.
  24. The Official Introduction to the ITIL Service Lifecycle. ITIL Series. Stationery Office,2007.
  25. Web services glossary, 2004.
  26. Peter Hill. On Goods and Services. Review of Income and Wealth, 23(4):315–38, 1977.
  27. Steven Alter. Service system fundamentals: Work system, value chain, and life cycle. IBMSystems Journal, 47(1):71–85, 2008.
  28. Roberta Ferrario and Nicola Guarino. Towards an ontological foundation for services science.Future Internet-FIS 2008, pages 152–169, 2009.
  29. Paul Maglio, Stephen Vargo, Nathan Caswell, and Jim Spohrer. The service system is the basicabstraction of service science. Information Systems and e-business Management, 7(4):395– 406, 2009.
  30. Manuel Mora, Rory O’Connor, Mahesh Raisinghani, Jorge Macías-Luévano, and Ovsei Gelman. An it service engineering and management framework (its-emf). International Journal of Service Science, Management, Engineering, and Technology (IJSSMET), 2(2):1–15, 2011.
  31. Ketki Dhanesha, Alan Hartman, and Anshu Jain. A model for designing generic services. InServices Computing, 2009. SCC’09. IEEE International Conference on, pages 435–442. IEEE, 2009.
  32. Manuel Mora, Mahesh Raisinghani, Ovsei Gelman, and Miguel-Angel Sicilia. Onto-servsys: A service system ontology. The Science of Service Systems, pages 151–173, 2011.
  33. Robert Glushko. Seven contexts for service system design. Handbook of service science, pages219–249, 2010.
  34. Introduction to OMG’s Unified Modeling Language (UML), 2012.
  35. Bran Selic. UML 2.0: Exploiting Abstration and Automation, 2004.
  36. Eva Söderström, Birger Andersson, Paul Johannesson, Erik Perjons, and Benkt Wangler.Towards a framework for comparing process modelling languages. In Advanced Information Systems Engineering, pages 600–611. Springer, 2006.
  37. Jang-Eui Hong and Doo-Hwan Bae. Software modeling and analysis using a hierarchicalobject-oriented Petri net. Information Sciences, 130(1):133–164, 2000.
  38. Jorge Cardoso, Carlos Pedrinaci, Torsten Leidig, Paulo Rupino, and Peter De Leenheer. Opensemantic service networks. In International Symposium on Services Science (ISSS), Leipzig, Germany, 2012.
  39. Paul Timmers. Business models for electronic markets. Electronic markets, 8(2):3–8, 1998.
  40. Alexander Osterwalder and Yves Pigneur. Business model generation: a handbook for visionaries, game changers, and challengers. Wiley, 2010.
  41. MutazAl-Debei.Thedesignandengineeringofinnovativemobiledataservices:AnontologicalFramework founded on business model thinking. School of Information Systems, Computing and Mathematics, 2010.
  42. Edward Faber, Pieter Ballon, Harry Bouwman, Timber Haaker, Oscar Rietkerk, and MarcSteen. Designing business models for mobile ict services. In Workshop on concepts, metrics & visualization, at the 16th Bled Electronic Commerce Conference eTransformation, Bled, Slovenia, 2003.
  43. Joan Magretta. Why business models matter. Harvard business review, 80(5):86–93, 2002.
  44. Alexander Osterwalder, Yves Pigneur, and Christopher Tucci. Clarifying business models: Origins, present, and future of the concept. Communications of the association for Information Systems, 16(1):1–25, 2005.
  45. Rainer Alt and Hans-Dieter Zimmermann. Preface: introduction to special section-businessmodels. Electronic Markets, 11(1):3–9, 2001.
  46. Erwin Fielt. An Extended Business Model Canvas for Co-Creation and Partnering. http:// blogspot.pt/2010/12/extended-business-model-canvas-for-co.html, 2010
  47. Jim Spohrer and Paul Maglio. Service science: Toward a smarter planet. Introduction to serviceengineering, pages 3–30, 2009.
  48. Reuven Karni and Maya Kaner. An engineering tool for the conceptual design of servicesystems. Advances in Services Innovations, pages 65–83, 2007.
  49. Reasoningaboutsubstitutechoicesandpreferenceorderingin e-services. In Advanced Information Systems Engineering, pages 390–404. Springer, 2008. 50. Tim Berners-Lee. Linked Data – Design Issues, 2006.
  50. Sebastian Speiser and Andreas Harth. Towards linked data services. In Proceedings of the 9th International Semantic Web Conference (ISWC), 2010.

Linked Service System USDL (LSS-USDL) – Perspectives, definitions and objectives

After Cardoso, J, R Lopes, and G Poels – Service systems: Concepts, modeling, and programming – Ch 1 White-box service systems – 2014

Perspectives

Research on services has been approached from different directions, although some strands are more mature than others. This section provides an overview of the main contributions.

Technical Perspective

From a technical perspective there is a lot of work done regarding the description of software-based services, the description of service-based architectures, and service composition into higher-level business processes [8].

The interfaces of the popular web services have long been described using WSDL (Web Service Description Language), a machine-readable format that allows systems to find out how to perform invocations and what results to expect. Later efforts focused on adding semantics to those descriptions, giving rise to initiatives such as SAWSDL, OWL-S, and WSMO [9]. It became possible to account for domain knowledge and not just technical syntax.

Standards for the organization and behavior of registries (in essence, catalogs of available services) also emerged, notably UDDI, which, again, was later complemented by semantic extensions or variants that enabled the search of services by business goals and not just strictly by the service name. Several other standards, collectively known as the WS-* family, addressed issues such as policy, security, reliability, among others.

The shift from silo applications to pools of services, that could be recombined as needed, called for efforts to describe service-oriented architectures (SOA). SoaML [10] is such an initiative for the model-driven software engineering of services. It addresses, for instance, service requirements, dependencies, functional capabilities, policies for use and provision, partitioning, or constraints.Soon the need for a Reference Model for Service Oriented Architecture was felt, and SOA-RM was created [11]. SOA Ontology [12] is an alternative, in the form of ontology. Along the lines of SOA-RM, there is also the Reference Ontology for Semantic Service Oriented Architectures (RO-SOA) [13]. Orchestrating or choreographing services to achieve the end goal of a business process has been the focus of initiatives such as BPEL, BPMN, or WS-CDL [14].

All these efforts show the considerable progress that has been done so far in service-orientation from a technical point of view.

Business Perspective

From a business perspective, the most notable effort to represent and reason about business models, services, and value networks was the e3 family of ontologies, which included the e3service and e3value ontologies [15]. These initiatives constituted perhaps the most evolved suite able to reason about services and value networks from an economic perspective. The research has, however, not been much concerned with the computational and operational perspectives covering the actual enactment or interaction with services, nor with the technical issues related to enabling a web-scale deployment and adoption of these solutions.

Complementary work in this area is GoodRelations [16] (GR), which focused precisely on this last concern by introducing a vocabulary to describe products and services in a structured way so that, for example, web searches and comparisons could be more easily and systematically done by customers. Nonetheless, although GR originally aimed to support both services and products, in practice it has mostly been centered on products to the detriment of its coverage for modeling services.

Multiple Perspectives

Linked USDL (Unified Service Description Language) [17] was developed to fill an existing gap in service descriptions by proposing a specification language, which enabled the unified formalization of business, operational, and technical aspects. It takes a multi-perspective approach.The goal was to propose a language for describing business, software, or real-world services using computer-understandable specifications to make them tradable on the web [18].

Linked USDL takes the form of a normalized schema which is an approach used in many fields to facilitate the exchange of data and integration of information systems. For example, online social networks rely on FOAF to describe people and relationships; computer systems use WSDL to describe distributed software-based services; eCl@ss is used to describe products; and business-to-business systems use ebXML to describe transactions, orders, and invoices. Adding to these existing standards, Linked USDL describes services in a comprehensive way by providing a business or commercial envelope around services. Therefore, Linked USDL is seen has one of the foundational technologies for setting up emerging infrastructures for the Future Internet, web service ecosystems, and a web of services [19].

Definitions

Despite the importance of the service sector, there is still no accepted definitions for the various terms related to the concept of service [2]. Different meanings have generated inconsistencies not only across disciplines, but also within them [23]. Therefore, it is necessary to disambiguate the meaning of service terms and provide clarifications to be used as a shared understanding.

According to the ITIL library, “a service is a means of delivering value to customers by facilitating outcomes customers want to achieve without the ownership of specific costs and risks” [24]. The W3C defines service as “an abstract resource that represents capability of performing tasks that form a coherent functionality from the point of view of provider entities and requester entities. To be used, a service must be realized by a concrete provider agent” [25]. Hill states that “a service may be defined as a change in the condition of a person, or a good belonging to some economic unit, with the prior agreement of the former person or economic unit” [26].

Based on these definitions from various fields (e.g., IT management, computer science, and economics) and also from other authors (c.f. [2, 23, 27–29]), we can provide the following definition for the term service (from R Lopes, LaNDLESS: Integrating Linked Data with Linked Services, 2013):

Definition 1 service is a previously agreed exchange of competences and knowledge between a provider and a customer in order to provide value to both parties.

When studying services, we are faced with other terms that need clarification, namely service system, service model, service instances, service description, and business model.

A service system is described in the literature as “[…] a system comprised of facilitator and appraiser systems for generating value through the provision and consumption of services” [30], “[…] complex adaptive systems made up of people, […] dynamic and open, rather than simple and optimized” [2], among other definitions (e.g., [27, 29, 31–33]). Therefore, we can provide the following definition:

Definition 2 A service system is a collection of resources, stakeholders, processes and other service assets that, combined, enable value co-creation between producer and consumer.

Models “[…] help by letting us work at a higher level of abstraction […]by hiding or masking details, bringing out the big picture, or by focusing on different aspects”[34]. Their essence is abstraction: “[…] the removal of fickle and distracting detail of implementation technologies as well as the use of concepts that allow more direct expression of phenomena in the problem domain. […] the only effective means that we have of dealing with complexity that overwhelms our cognitive capacities” [35]. Crossing these statements with others in the literature (e.g., [36, 37]), we reach the following definition for service model:

Definition 3 A service model is an abstraction of a service system that highlights its structure, its elements, and the relations between elements, hiding its complex nature from who does not need to know it.

Modeling is the activity of creating abstractions and representations, i.e., models, of a service system to provide guidelines for its design, implementation, deployment, and management. Each service model is created to answer important questions about the characteristics, behavior, and structure of a service: M is a model of a service S if M can be used to answer questions about the characteristics and structures of service S.

Each service model is an abstraction of a service system. It is created through abstraction by ignoring some aspects of a service to highlight other more important characteristics. An abstraction is a generalization of content and/or suppression of details to allow for a broader view, decrease complexity, or focus on a specific viewpoint. A common way to raise the level of abstraction is to rely on models, architectures, business rules, and meta-models. The best model, indeed, should be the result of a balance between realism and simplicity since it is an abstract representation of reality. As a rule, and in most modeling efforts, details that are unnecessary are not included.

While the model consists of classes, representing things of significance for a service system and relationship assertions about associations between pairs of classes, a service instance assigns actual values for those classes.

[Note: R Lopes, LaNDLESS: Integrating Linked Data with Linked Services, 2013 provides a different discussion of Service model and a definition for service architecture:

The term architecture is defined by IEEE 1471 as “… the fundamental organization of a system embodied in its components, their relationships to each other and to the environment, and the principles of its design and evolution.” Zachman, while explaining his framework for enterprise architecture, defines architecture as “… that set of design artifacts, or descriptive representations, that are relevant for describing an object such that it can be produced to requirements (quality) as well as maintained over the period of its useful life (change).” [Zachman, J, Enterprise architecture: The issue of the century, 1997].  Cardoso et al states that service architectures “… look into the organization of software-based services, how they are connected, and what service information is exchanged between consumers and providers.” [Cardoso, J et al, Open Semantic Service Networks, 2012] Building on top of our service definition and these architecture definitions (including Kruchten’s contribution [Kruchten, P, The rational unified process: An introduction, 2004]), we can define service architecture as:

Definition 4 Service architecture is the set of rules and guidelines for the components, relationships and interfaces of the structural elements of a software-based service that guides the organization of that service.

Lopes then jumps to definition of business model.]

Definition 5 A service instance (or service description) is an instance of a model. It captures the information describing a particular service. It is the result or output of the activity of service modeling.

Service descriptions “[…] bring various ways to describe services ’interfaces using schema, models and semantics” [38]. A service description is a descriptive representation of (part of) a service system used to educate the different stakeholders about its properties and interactions.

[R Lopes adds: A WSDL service description “… indicates how potential clients are intended to interact with the described service. It represents an assertion that the described service fully implements and conforms to what the WSDL 2.0 document describes.” [Chinnici, R et al, Web services description language (WSDL) version 2.0 part 1, 2007]. Oberle et al argue that “Information systems such as a service marketplace will manage descriptions of a service and not the service itself. The service itself is an event (…) that can be executed arbitrary times used by different consumers” [Oberle, D, et al, Countering service information challenges in the internet of services, 2009]. Cardoso et al state that service descriptions “… bring various ways to describe services’ interfaces using schema, models and semantics” [Cardoso, J et al, Open Semantic Service Networks, 2012]. Hence we can define service description as follows: {and leads to definition of service instance (service description)}]

A business model is defined by Timmers [39] as “[…] an architecture for the product, service and information flows, including a description of the various business actors and their roles, a description of the potential benefits for the various business actors, and a description of the sources of revenue”. Osterwalder and Pigneur [40] state that “a business model describes the rationale of how an organization creates, delivers, and captures value”. Based on these descriptions and other definitions found in the literature (e.g., [41–44]), we can summarize the definition of business model as follows:

Definition 6 A business model is a conceptual representation of the business of an organization intended to describe its services, stakeholders, interactions, value propositions, explanations on how the organization meets customer goals, and how it makes profit.

Figure 1 builds on the terms explored previously to contextualize the scope of a service system model like the one we intend to develop. A business model is a higher-level model that contains many service systems. A service system is modeled by one or more service models, which may contain models for its internal elements, such as process models.

Levels of abstraction with business models, service models, and process models

Figure 1. Levels of abstraction with business models, service models, and process models.

Different stakeholders can “see” a service system from different views or perspectives by accessing various service descriptions (Figure 2).

Business models, service systems, service models, process models, and service descriptions

Figure 2. Business models, service systems, service models, process models, and service descriptions.

Since previous work mainly took a black-box approach, we now take the challenge of defining a model to describe a service system using a white-box approach. The model opens new doors for Service Science including service simulation and analytics and the automatic comparisons of different service systems. This is still a recent research field and, thus, not many contributions have been made so far. Most of them are conceptual.

This book approaches the development and implementation of a service system model by fulfilling four partial objectives:

  1. Conceptual Framework.The first objective was to conduct an extensive research to identify the most common service model concepts found in the literature (c.f. [7, 40, 45–49]). A framework was developed to compare and contrast existing approaches. The most important concepts and building blocks were identified and a conceptual model to capture service systems was developed.
  2. Model Implementation. The second objective was to implement the conceptual model. The implemented model, called Linked Service System for USDL (LSS-USDL), was built using Semantic Web technologies and its construction followed Linked Data principles [50]. The model was build with RDF, the standard for Linked Data, and reused existing vocabularies found in the Linked Data Cloud (to maximize compatibility and reusability and minimize engineering efforts) making use of the recent developments towards organizations and governments publishing data on the web [51].
  3. Service Programming. A third objective was to demonstrate how a real-world service system could be modeled with LSS-USDL and how it could be accessed and queried programmatically. The service system modeled was the Incident Management (IM) service from the Information Technology Infrastructure Library (ITIL), a set of best practices for IT service management widely adopted by large enterprises. The programming language used was Python since libraries to access and modify RDF models are available and are stable.
  4. Service Tooling. For the model to be accepted by managers, and other nontechnical service system modelers, tools need to be available. Hence, the fourth objective was to develop a tool that hides technical details and is easy to use and understand. This creates the challenge of hiding as much complexity as possible while still making full use of the capabilities of the model. It also requires a basic understanding about what is cognitively difficult for users and what metaphors may be used. Ideally, service description languages capturing different views should interoperate. It is possible to export/import an LSS-USDL service model into/from the Linked USDL service description language. This type of interoperability demonstrates that a black-box and white-box perspectives can co-exist.

The white-box perspective on services given by LSS-USDL brings several benefits for organizations. The degree of automation of service delivery and provisioning can increase since service systems are fully modeled with a computer-understandable language.

Previous: Linked Service System USDL (LSS-USDL) – Transparency of services
Next: x

References

  1. Robert Glushko and Lindsay Tabas. Designing service systems by bridging the front stage andback stage. Information Systems and e-Business Management, 7:407–427, 2009.
  2. Jim Spohrer, Paul Maglio, John Bailey, and Daniel Gruhl. Steps toward a science of service systems. Computer, 40(1):71–77, January 2007.
  3. Holger Luczak, Christian Gill, and Bernhard Sander. Architecture for Service Engineering The Design and Development of Industrial Service Work. In Dieter Spath and Klaus-Peter Fähnrich, editors, Advances in Services Innovations, pages 47–63. Springer, Berlin Heidelberg, 2007.
  4. Henry Chesbrough and Jim Spohrer. A research manifesto for services science. Communications of the ACM, 49(7):35–40, 2006.
  5. Paul Maglio, Savitha Srinivasan, Jeffrey Kreulen, and Jim Spohrer. Service systems, service scientists, SSME, and innovation. Communications of the ACM, 49(7):81–85, 2006.
  6. Stephen Vargo and Robert Lusch. Evolving to a new marketing dominant logic for marketing. Journal of Marketing, 68(1):1–17, 2004.
  7. Andreas Zolnowski, Martin Semmann, and Tilo Böhmann. Introducing a Co-Creation Perspective to Service Business Models. In Enterprise Modelling and Information Systems Architectures (EMISA), page 243, 2011.
  8. Thomas Erl. Service-Oriented Architecture: Concepts, Technology, and Design. Prentice HallPTR, Upper Saddle River, NJ, USA, 2005.
  9. Carlos Pedrinaci, John Domingue, and Amit Sheth. Handbook on Semantic Web Technologies,volume Semantic Web Applications, chapter Semantic Web Services. Springer, 2010.
  10. Service oriented architecture Modeling Language (SoaML) Specification, 2012.
  11. Matthew MacKenzie, Ken Laskey, Francis McCabe, Peter Brown, and Rebekah Metz. Reference Model for Service Oriented Architecture 1.0.
  12. The Open Group. Service-Oriented Architecture Ontology, 2010.
  13. John Domingue, Michal Zaremba, Barry Norton, Mick Kerrigan, Adrian Mocan, Alessio Carenini, EmiliaCimpian, Marc Haines, and James Scicluna. Reference Ontology for Semantic Service Oriented Architectures Version 1.0, 2008.
  14. Mike Papazoglou. Web Services: Principles and Technology. Prentice Hall, 2012.
  15. Hans Akkermans, Ziv Baida, Jaap Gordijn, Nieves Pena, Ander Altuna, and Inaki Laresgoiti. Value webs: Using ontologies to bundle real-world services. IEEE Intelligent Systems, 19(4):57–66, July 2004.
  16. Martin Hepp. GoodRelations Language Reference, 2011.
  17. Carlos Pedrinaci, Jorge Cardoso, and Torsten Leidig. Linked USDL: A Vocabulary for Webscale Service Trading. In 11th Extended Semantic Web Conference, Crete, Greece, May 2014.
  18. Jorge Cardoso, Alistair Barros, Norman May, and Uwe Kylau. Towards a unified service description language for the internet of services: Requirements and first developments. In Services Computing (SCC), 2010 IEEE International Conference on, pages 602–609. IEEE, 2010.
  19. Jorge Cardoso, Konrad Voigt, and Matthias Winkler. Service Engineering for The Internet ofServices. In Enterprise Information Systems X, volume 19, pages 17–25. Springer, 2008.
  20. ChristianBizer,TomHeath,andTimBerners-Lee.LinkedData-TheStorySoFar.InternationalJournal on Semantic Web and Information Systems, 5(3):1–22, 2009.
  21. Henry Chesbrough. Open innovation: The new imperative for creating and profiting fromtechnology. Harvard Business Press, 2003.
  22. Wil van der Aalst. Process Mining: Discovery, Conformance and Enhancement of BusinessProcesses. Springer Publishing Company, Incorporated, 1st edition, 2011.
  23. Roberta Ferrario, Nicola Guarino, Christian Janiesch, Tom Kiemes, Daniel Oberle, and FlorianProbst. Towards an ontological foundation of services science: The general service model. Wirtschaftsinformatik, Switzerland, pages 16–18, 2011.
  24. The Official Introduction to the ITIL Service Lifecycle. ITIL Series. Stationery Office,2007.
  25. Web services glossary, 2004.
  26. Peter Hill. On Goods and Services. Review of Income and Wealth, 23(4):315–38, 1977.
  27. Steven Alter. Service system fundamentals: Work system, value chain, and life cycle. IBMSystems Journal, 47(1):71–85, 2008.
  28. Roberta Ferrario and Nicola Guarino. Towards an ontological foundation for services science. Future Internet-FIS 2008, pages 152–169, 2009.
  29. Paul Maglio, Stephen Vargo, Nathan Caswell, and Jim Spohrer. The service system is the basic abstraction of service science. Information Systems and e-business Management, 7(4):395– 406, 2009.
  30. Manuel Mora, Rory O’Connor, Mahesh Raisinghani, Jorge Macías-Luévano, and Ovsei Gelman. An it service engineering and management framework (its-emf). International Journal of Service Science, Management, Engineering, and Technology (IJSSMET), 2(2):1–15, 2011.
  31. Ketki Dhanesha, Alan Hartman, and Anshu Jain. A model for designing generic services. InServices Computing, 2009. SCC’09. IEEE International Conference on, pages 435–442. IEEE, 2009.
  32. Manuel Mora, Mahesh Raisinghani, Ovsei Gelman, and Miguel-Angel Sicilia. Onto-servsys: A service system ontology. The Science of Service Systems, pages 151–173, 2011.
  33. Robert Glushko. Seven contexts for service system design. Handbook of service science, pages219–249, 2010.
  34. Introduction to OMG’s Unified Modeling Language (UML), 2012.
  35. Bran Selic. UML 2.0: Exploiting Abstration and Automation, 2004.
  36. Eva Söderström, Birger Andersson, Paul Johannesson, Erik Perjons, and Benkt Wangler.Towards a framework for comparing process modelling languages. In Advanced Information Systems Engineering, pages 600–611. Springer, 2006.
  37. Jang-Eui Hong and Doo-Hwan Bae. Software modeling and analysis using a hierarchical object-oriented Petri net. Information Sciences, 130(1):133–164, 2000.
  38. Jorge Cardoso, Carlos Pedrinaci, Torsten Leidig, Paulo Rupino, and Peter De Leenheer. Opensemantic service networks. In International Symposium on Services Science (ISSS), Leipzig, Germany, 2012.
  39. Paul Timmers. Business models for electronic markets. Electronic markets, 8(2):3–8, 1998.
  40. Alexander Osterwalder and Yves Pigneur. Business model generation: a handbook for visionaries, game changers, and challengers. Wiley, 2010.
  41. Mutaz Al-Debei. The design and engineering of innovative mobile data services: An ontological Framework founded on business model thinking. School of Information Systems, Computing and Mathematics, 2010.
  42. Edward Faber, Pieter Ballon, Harry Bouwman, Timber Haaker, Oscar Rietkerk, and MarcSteen. Designing business models for mobile ict services. In Workshop on concepts, metrics & visualization, at the 16th Bled Electronic Commerce Conference eTransformation, Bled, Slovenia, 2003.
  43. Joan Magretta. Why business models matter. Harvard business review, 80(5):86–93, 2002.
  44. Alexander Osterwalder, Yves Pigneur, and Christopher Tucci. Clarifying business models: Origins, present, and future of the concept. Communications of the association for Information Systems, 16(1):1–25, 2005.
  45. Rainer Alt and Hans-Dieter Zimmermann. Preface: introduction to special section-businessmodels. Electronic Markets, 11(1):3–9, 2001.
  46. Erwin Fielt. An Extended Business Model Canvas for Co-Creation and Partnering. http:// blogspot.pt/2010/12/extended-business-model-canvas-for-co.html, 2010
  47. Jim Spohrer and Paul Maglio. Service science: Toward a smarter planet. Introduction to serviceengineering, pages 3–30, 2009.
  48. Reuven Karni and Maya Kaner. An engineering tool for the conceptual design of service systems. Advances in Services Innovations, pages 65–83, 2007.
  49. Reasoning about substitute choices and preference ordering in e-services. In Advanced Information Systems Engineering, pages 390–404. Springer, 2008. 50. Tim Berners-Lee. Linked Data – Design Issues, 2006.
  50. Sebastian Speiser and Andreas Harth. Towards linked data services. In Proceedings of the 9th International Semantic Web Conference (ISWC), 2010.

Business-models and models of service systems

After Cardoso, J, R Lopes, and G Poels – “The LSS-USDL Model” in Service Systems: Concepts, modeling, and programming (2014).

1

In Chapter 2, we studied four theories that provided a comprehensive view of service. This chapter starts by complementing the study made by looking into business model conceptualizations to create an evaluation framework that will help in identifying a set of concepts to be used for the creation of a service system model.

Related research has proposed several business model conceptualizations. We briefly present eight of these proposals that are relevant to our research as they define concepts that pertain to both external and internal views of service systems. We do not explain these conceptualizations in detail, but merely list concepts relevant to a service system model. It should be noted that these proposals are unrelated to the service theories reviewed in the previous section, hence, both types of related work will be used in the next section to derive the most common service system concepts.

2

Alt and Zimmermann [4] distinguished six generic elements as a comprehensive framework to develop business models: Mission, Structure, Processes, Revenues, Legal issues and Technology. Published in 2001, this is the earliest proposal in our study, but as we can see by analyzing Table 1 it already mentions most of the generic concepts that newer models used the most. This indicates that it had an impact in the field.

Table 3.1 Service model evaluation framework

Table 1 Service model evaluation framework.

Petrovic et al. [5] divided a business model into seven sub-models: Value model, Resource model, Production model, Customer relations model (it was further divided into Distribution model, Marketing model and Service model), Revenue model, Capital model, and Market model. The naming of this model’s elements hints at a lower level description for each of them. However, the authors do not identify any further characteristics.

Kaner and Karni [6, 7] proposed CAIOPHYKE, a service model based on 9 major classes: Customers, Goals, Inputs, Outputs, Processes, Human enablers, Physical enablers, Information enablers, and Environment. Each of these major classes can be further described by main classes, which can then be further described by their respective minor classes. This model was developed based on a study with 150 student projects that covered around 100 service domains [8]. This is one of the most comprehensive models found in the literature. However, it features a high level of complexity without a proper formalization, which prevents from creating an abstraction to handle complexity.

In e3service [9, 10], Kinderen and Gordijn focused on satisfying consumer needs and displaying the various value offerings from different services for an easier comparison. Therefore, the elements of this model are different from other approaches. This model is a valuable contribution to the state of the art as it is represented by a machine-readable ontology, the level of formality we envision for our model. However, its scope is customer-oriented, while we seek a manager-oriented approach that provides a view on how a service system operates.

Spohrer and Maglio [11] defined a service as value co-creation and list ten related foundational concepts: Ecology, Entities, Interactions, Outcomes, Value proposition based interactions, Governance mechanism based interactions, Stakeholders, Measures, Resources, Access rights and Questions [11]. Table 3.1 shows that it is one of the most complete models of our study.

Osterwalder and Pigneur [12] propose the Business Model Canvas, a high level graphical tool for business modeling. The model uses the concepts Value proposition, Customer segments, Channels, Customer relationships, Key activities, Key resources, Key partners, Cost structure, and Revenue Streams. This model and its tool are very simple and easy to understand and enjoy some popularity.

Fielt [13] extended the Business Model Canvas by addressing its strongest limitations: the lack of partnering (c.f. [14]) and co-creation (c.f. [15]) concepts. This increased the complexity of the original model. However, Table 1 shows that this new model only contributes to one more element of the common concepts, so there is a risk that this increase in complexity might not be beneficial.

Zolnowski et al. [16] tried to tackle the issue of lack of elements of the original Business Model Canvas to describe co-creation. This proposed approach focuses on a redistribution of the elements and their connections, rather than changing them as seen in Fielt’s approach. Hence, this model shares the same concepts as the original Business Model Canvas, but their organization changes ([16] p.158).

3

Comparing the related work reviewed in the previous chapter and section, it is possible to identify common concepts for describing service systems and, thus, derive a service evaluation framework of the most frequent and relevant concepts. The most common concepts identified are:

  • Goals
  • Stakeholders
  • Processes
  • Inputs
  • Outputs
  • Resources
  • Measures
  • Legal
  • Financial

Goals are one of the most used concepts in the studied models. There is no doubt that this is a critical element for a service model, not only because of its wide acceptance among the studied approaches, but also because it states the objectives of the service system and its value proposition to consumers.

Stakeholders are one of the most important concepts of a service, since it is conditioned by the people and organizations involved. This concept is used by almost all the studied approaches due to its importance. In most service models, there is an attribute for service customers. In the Business Model Canvas from Osterwalder [12] and the two studied improved approaches there is also an attribute for service partners [12, 13, 16]. Spohrer and Maglio [11] propose additional attributes which specialize stakeholders into authorities and competitors.

Processes are, along with Goals, a concept that all studied approaches share. This concept is of utmost importance when describing services from an internal organization, because corporations must have a strong knowledge of the processes needed for their services, to identify bottlenecks, and other issues.

Inputs are described in a small set of service models. Spohrer and Maglio [11] refer to them using the concept of Ecology. Fielt [13], when extending the Business Model Canvas, adds Partner activities and Customer activities, which act as an input for the service. Karni and Kaner’s CAIOPHYKE model [7] features the major class Inputs.

Outputs are also described in a small set of service models. Spohrer and Maglio [11] refer to them using the concept of Outcomes. e3service [10] features outputs in the classes Consequence, Benefit, and Value derivation. Karni and Kaner [7] feature the major class Outputs.

Resources are described in most service description models, being absent just in e3service. Alt and Zimmermann’s approach [4] is the only model that does a partial description of this concept, focusing only on technology.

Measures refer to how the company can know its services’ performance receive feedback of their operations. Only a small number of models were found in the literature that addressed this concept, as shown in Table 1.

Legal is the concept for the legal aspects of a service or business. It has a surprisingly low presence in the literature. Exceptions are Alt and Zimmermann [4] who propose Legal issues as one of their six generic elements of a business model; Karni and Kaner [7] use the main class Legal factors in the major class Environment; and Spohrer and Maglio identify Governance mechanism based interactions and Access rights [11].

Financial is the concept for the financial aspects of a service. This concept is used in most of the studied approaches. Hence, it is also an important concept for developing a comprehensive service model and evaluation framework.

References

  1. Stephen Vargo and Robert Lusch. Evolving to a new marketing dominant logic for marketing.Journal of Marketing, 68(1):1–17, 2004.
  2. Scott Sampson and Craig Froehle. Foundations and implications of a proposed unified services theory. Production and Operations Management, 15(2):329–343, 2006.
  3. Steven Alter. Work system theory: Overview of core concepts, extensions, and challenges for the future. Journal of the Association for Information Systems, 14(2), 2013.
  4. Rainer Alt and Hans-Dieter Zimmermann. Preface: introduction to special section – business models. Electronic Markets, 11(1):3–9, 2001.
  5. Otto Petrovic, Christian Kittl, and Ryan Teksten. Developing business models for e-business. Available at SSRN 1658505, 2001.
  6. Maya Kaner and Reuven Karni. Design of service systems using a knowledge-based approach.Knowledge and Process Management, 14(4):260–274, 2007.
  7. Reuven Karni and Maya Kaner. An engineering tool for the conceptual design of service systems. Advances in Services Innovations, pages 65–83, 2007.
  8. Teaching innovative conceptual design. Technological Forecasting and Social Change, 64(2):225–240, 2000.
  9. Sybren Kinderen and Jaap Gordijn. e3service: An ontological approach for deriving multi-supplier IT-service bundles from consumer needs. In Proceedings of the 41st annual Hawaii international conference on system sciences, 2008.
  10. Reasoning about substitute choices and preference ordering in e-services. In Advanced Information Systems Engineering, pages 390–404. Springer, 2008.
  11. Jim Spohrer and Paul Maglio. Service science: Toward a smarter planet. Introduction to service engineering, pages 3–30, 2009.
  12. Alexander Osterwalder and Yves Pigneur. Business model generation: a handbook for visionaries, game changers, and challengers. Wiley, 2010.
  13. Erwin Fielt. An Extended Business Model Canvas for Co-Creation and Partnering, 2010.
  14. Erwin Fielt. To what extent is the Business Model Canvas constraining? A Co-Creation Canvas example. http://fieltnotes.blogspot.pt/2010/11/to-what-extent-is-business-model-canvas. html, 2010
  15. Erwin Fielt. Alternative business model canvasses: A Partnering Canvas example. http:// blogspot.pt/2010/12/alternative-business-model-canvasses.html, 2010
  16. Andreas Zolnowski, Martin Semmann, and Tilo Böhmann. Introducing a Co-Creation Perspective to Service Business Models. In Enterprise Modelling and Information Systems Architectures (EMISA), page 243, 2011.
  1. 1 Service System Evaluation Framework
  2. 1.1 Business Model Conceptualizations of Service Systems
  3. 1.2 Evaluation Framework

Conceptual models of service and service system

After Cordoso, J, R Lopes, and G Poels – “Conceptual frameworks” in Service Systems: Concepts, modeling, and programming (2014).

1

This chapter presents four theories from different academic disciplines that provide a comprehensive view of service. According to Gregor’s taxonomy of theory types [6], the theories presented are theories for analysis. This means that they offer concepts to describe, understand and analyze an object of study (i.e., what is), but do not explain or predict phenomena (i.e., why something is or what will be), nor provide prescriptions to create objects or cause events (i.e., how to do something).

The four reviewed theories are suitable for developing a concept base that can be used for selecting concepts when designing a conceptual service system model as the basis for the LSS-USDL service description language. The service concepts described by these theories constitute an interdisciplinary knowledge base that allows achieving rigor when designing the intended model and language, providing a theoretical foundation and justification for their construction [8].

The theories selected for this chapter are:

The Service-Dominant Logic is a descriptive theory of service from the Marketing discipline. It has been proposed as the philosophical basis of the new inter-disciplinary field of Service Science, Management, and Engineering (SSME) – Service Science in short – which studies service systems with the aim of creating the systemic knowledge required for sustainable service innovation [19].

To complement the marketing perspective of service, with its strong emphasis on the creation of customer benefits, the second reviewed theory is drawn from the Operations Management discipline. The Unified Services Theory describes the service production process and allows analyzing the efficiency and quality of this process. Thirdly, a “work system” perspective, i.e., viewing an object of study as a system in which work is performed, allows understanding service as a system (socio-technical or automated) in an organizational context [3]. The Work system metamodel provides an operational view of service systems (and work systems in general) that offers the basis for detailed analysis of the system’s form, function and environment [2].

This operational view is finally complemented by an economic view that also considers aspects related to the exchange of service. This view is obtained through application of the Resource-Event-Agent ontology, originally from the Accounting discipline, as a model of economic exchange. Applying this ontology to service systems has resulted in the Resource-Service-System model of service exchange, which is the fourth theory presented in this chapter.

The combination of theories from multiple disciplines, each offering a partial perspective on service, leads to the creation of a more complete concept base that covers different economic, management, and engineering aspects related to service. This ambition is fully in line with the purpose of the new SSME field as it is with the design of a conceptual model of service system that can serve as the foundation of a white-box service description language. The next sections will present the selected descriptive theories of service. To build the concept base for the intended service system conceptualization, an integrated concept map with concepts from the different theories is gradually constructed throughout Sects. 2.2 to 2.5.

2

The growing importance of service and service systems and the rising demand for service innovation and, hence, increasing investments in service R&D have often been motivated by the global sectorial shift in gross domestic product and employment from agriculture and industry to service (see, e.g., [9]). The difference between the declining second economic sector and the rising third sector is traditionally (and officially in governmental reports) made on the basis of the output of economic actors, producing either goods (second sector) or services (third sector).

Services are seen as products that are different from goods in terms of the IHIP characteristics: intangibility, heterogeneity, inseparability (of production and consumption), and perishability [13]. From a management perspective, the IHIP characteristics are considered as shortcomings, making it more di cult to properly handle services, e.g., with respect to their design, production, quality assurance, and marketing. To find answers to these shortcomings, dedicated service research disciplines like service management, service operations, service design, service engineering, etc. emerged.

3

ServiceDominant Logic [20, 10, 22] promotes an economic world view in which all economic exchange is seen as the exchange of service for service. Service is the application of one’s competences for the benefit of someone else. The benefits of service are determined by the beneficiary in terms of value-in-use (i.e., what utility is assigned to the application of competences) and value-in-context (i.e., how are the benefits experienced in the subjective ad hoc context of the beneficiary), rather than value-in-exchange (i.e., what is the monetary value of the service).

4

The descriptive theory of Service-Dominant Logic is expressed through ten foundational premises (FPs) [23]:

FP1. Service is the fundamental basis of exchange.

FP2. Indirect exchange masks the fundamental basis of exchange.

FP3. Goods are a distribution mechanism for service provision.

FP4. Operant resources are the fundamental source of competitive advantage.

FP5. All economies are service economies.

FP6. The customer is always a co-creator of value.

FP7. The enterprise cannot deliver value, but only offer value propositions.

FP8. A service-centered view is inherently customer-oriented and relational.

FP9. All social and economic actors are resource integrators.

FP10. Value is always uniquely and phenomenologically determined by the beneficiary.

FP1 asserts that what economic actors exchange in service is the application of each other’s competences. Economic actors specialize in what they are best at doing based on their own knowledge and skills. Economic exchange occurs when actors apply their own specialized competences for the benefit of others; thus, all economies are service economies (FP5). FP6 (value co-creation) asserts that the service beneficiary is always involved in the creation of value as he is the sole determiner of value (value-in-use and value-in-context) (FP10) and the actor who applies specialized competences (i.e., operant resources) can only offer value propositions (FP7) which help to create value with and for the beneficiary. FP9 (resource integration) asserts that economic actors need to integrate the resources they acquire as service beneficiaries into their own resources in order to survive and prosper, and to continue being able to apply specialized competences themselves.

5

The concept map of Figure 1 summarizes the key concepts that Service-Dominant Logic uses to describe service. Resources are of two kinds as determined by the service context under consideration: operant resources represent competences (i.e., knowledge and skills) or their embodiments (e.g., persons, organizational units, software agents, automated devices) that act upon other resources; Operand resources are resources that are acted upon or with like passive resources such as tools, materials, and data, but possibly also resources that may be active in another service context like persons, machines, and software. Actors exchange services by providing resources. The acting of operant resources on operand resources is what is called service, meaning an actor applying competences for the benefit of another actor. Through the exchange of service for service actors integrate resources that are made available, accessible or more valuable (as determined by the service beneficiary) by other actors, into their own resources. Value is always co-created by the beneficiary actor. It is the beneficiary actor who determines whether a service resulted in value. Therefore, an actor can only offer a value proposition concerning some service and cannot solely create value for the beneficiary actor.

Concept map Service-Dominant Logic

Figure 1. Concept map Service-Dominant Logic.

6

The Unified Services Theory [18] was developed for providing a distinctive, yet integrative paradigm and common language for service management researchers. It is meant as a descriptive theory that defines concepts relevant to service management from a primarily, though not exclusive production perspective. As opposed to the Service-Dominant Logic, the Unified Services Theory recognizes the distinction between services and non-services. Its operational implications, therefore, address the challenges that are unique to the management of service processes.

7

The theory does not define the concept of service directly, but talks about service processes. The object of study is the production process. An enterprise is a production system consisting of possibly multiple production processes.

The basic tenet of the Unified Services Theory is that a service process is a production process in which each individual consumer provides significant inputs. Inputs are resources available to production. Consumer inputs can be of three kinds: the consumer himself (e.g., going to a hairdresser), information provided by the consumer (e.g., providing information to a solicitor for preparing a legal case) or tangible belongings of the consumer (e.g., getting one’s car repaired). Inputs that are not considered significant and hence do not allow qualifying a production process as a service process are general consumer feedback (e.g., a market research that provides ideas and requirements for a new product and, thus, informs production processes) and selecting and consuming the output from production processes. The latter activity is part of a consumption process in which consumers extract value by interacting with the output of production processes or with the service providers themselves.

The operational implications of the theory for service management focus strongly on what makes a production process a service process, i.e., the necessity of consumer inputs. For instance, according to the theory service quality depends in large part on the quality of the inputs that the consumer provides. Also, service processes can be made more efficient by reducing the variability in consumer inputs. Overall, it is the presence of consumer inputs that makes service processes harder to manage than non-service processes. The consumer-producer interaction required for service processes implies that consumers are also suppliers and, hence, service supply chains are always bidirectional [16].

8

The main concepts of the Unified Services Theory are shown in Figure 2. A process is a series of actions. Amongst different kinds of processes are production and consumption processes. Note that the theory also defines other kinds of processes like business processes and IT processes [17], but these are at this moment not relevant for understanding service.

A production process is a process that transforms inputs into outputs. An input is a resource available to production. Generally, the producers that own the production processes provide inputs to these processes.

Service processes are production processes in which also consumers provide or make available input resources (either themselves or information they have or their property). An output is a result of production. Consumers select outputs from production processes to satisfy their needs. The extraction of value, which is the satisfaction of consumers’ needs, is performed in consumption processes.

A concept not explicitly shown but present in the chain of relations in the concept map is that of consumer-producer interaction, which is bi-directional. Consumers influence producers by providing production inputs and producers influence consumers by acting on the consumer inputs.

Concept map Unified Services Theory

Figure 2. Concept map Unified Services Theory.

9

Joining the concept maps of the Service-Dominant Logic and the Unified Services Theory is not an easy operation, given their fundamentally different view of service. While service is defined as a process in the Service-Dominant Logic, it is not the same as the service process as intended by the Unified Services Theory which employs a more restricted meaning and distinguishes between service and non-service situations (such distinction would be nonsense in Service-Dominant Logic). While service in the Service-Dominant Logic requires co-creation between the producer/provider and consumer/beneficiary, the acts of the service provider (or producer) and beneficiary (or consumer) might overlap completely or partially but also be completely independent in space and time; hence, the resource integration and resulting value capture by the beneficiary might happen long after and in a different location than the provider’s activities.

This scenario is consistent with what happens in the consumption process of the Unified Services Theory where the consumer may extract value from outputs of non-service production processes without any interaction with the producer. However, to qualify as a service process, the production process needs consumer inputs, which implies some degree of overlap in time and space between producer and consumer activities. As noted in [18], this interaction is, however, not as restrictive as requiring co-production as the provision of the consumer’s labor is only one possible type of consumer input into the production process.

10

The notion of value as satisfying needs in the Unified Services Theory is close to the notion of value-in-use in the Service-Dominant Logic, hence, value seems a common concept in both maps. Also in both theories it is the consumer/beneficiary that determines and captures the value. The resource integration in the Service-Dominant Logic and the value extraction to satisfy needs in the Unified Services Theory are, therefore, similar. To integrate both concept maps, value can, therefore, be used an anchor point. Further we see that consumer and producer in the Unified Services Theory are specializations (and actually roles) of actor in the Service-Dominant Logic. The inputs in the Unified Services Theory are resources in the Service-Dominant Logic.

As the purpose of the conceptual model we develop in this chapter is the creation of a concept base for the design of a white-box service description language and the Unified Services Theory offers more details on the “internals” of service, we start the integration from the concept map of this theory. Given the differences between both theories, the integrated concept map should allow for multiple interpretations of concepts to co-exist. Hence, we include in the concept map of Figure 3 concepts from the Service-Dominant Logic to extend the concept map for the Unified Services Theory (Figure 2), without claiming to have integrated the theories themselves.

Additions from the Service-Dominant Logic are the concepts of service, value co-creation and value proposition (though the latter concept is a component of the Unified Services Theory concept of business process, not shown here). Also, the distinction between operant and operand resources is added, e.g., a consumer providing his labor to the service process (i.e., co-production) would allow qualifying the consumer as an operant resource that is applied in the service (process). Also service exchange is a new element not covered by the Unified Services Theory. A further elaboration of the exchange nature of service is given in Sect. 2.5, where we introduce the Resource-Service-System Model. In general we can see that the extension with concepts from the Service-Dominant Logic allows widening the Unified Services Theory’s scope of service processes to service exchanges.

11

The Work System Meta-model [4] is an extension of the Work System Theory [1]. The Work System Theory defines a work system as a “system in which human participants and/or machines perform work (processes and activities) using information, technology, and other resources to produce specific products/services for specific internal and/or external customers” (p. 75, [1]). Services are defined as acts performed to produce outcomes for the benefit of others. The Work System Theory encompasses a descriptive framework called Work System Framework that can be used to describe and analyze work systems. Given that service systems are work systems and most work systems are service systems (except those work systems not directed at others), the Work System Framework can be used to describe service systems. While the Work System Framework is intended to provide summary-level descriptions of work systems, the Work System Meta-model expresses a more detailed operational view on work systems. In the remainder we will focus our discussion on concepts that might provide for interesting new additions to our current concept base (as in Figure 3).

Integrated concept map of the Unified Services Theory and the Service-Dominant Logic

Figure 3. Integrated concept map of the Unified Services Theory and the Service-Dominant Logic.

12

The main concepts of interest of the Work system meta-model are shown in Figure 4. A service system is a work system in which work is performed for the benefit of internal or external customers to the enterprise that offers the service. The benefits for an internal customer are other than for performing work activities within the service system itself. The service system contains service system activities that use resources and produce products/services. Resources can be technological entities, informational entities, (human) participants or other resources. The term product/service refers to a bundle of tangible and/or intangible acts and outcomes that may be more goods-like or more services-like. Note that Work System Theory recognizes the traditional distinction between goods and services but does not consider it important to understand service systems. Service system activities are performed by actor roles which can be performed by automated agents (which is a technological entity and a totally automated service system on its own right), non-customer participants (e.g., an employee of the enterprise) or customer participants (i.e., in case of co-production). Products/services may be used as resources for other activities within the same service system, however, at least one product/service produced by an activity of the service system contributes to a product/service to the customer, meaning physical things, information, acts and/or outcomes used or received by a customer work system in which they facilitate the creation of value for the customer.

Concept map of Work System Meta-model - simplified

Figure 4. Concept map of Work System Meta-model (simplified).

13

Comparing the Work System Meta-model with the Unified Services theory, we see that the distinction between provider service system and customer work system is similar to that of production process and consumption process in the Unified Services Theory. Though not shown in Figure 4, the Work System Meta-model includes the concept of (business) process when two or more service system activities “are sufficiently interrelated and sequential enough to be considered a process” [4]. Hence, the production and consumption process are part of the provider, respectively customer work systems and contain themselves work system activities. A work system perspective, thus, allows describing Unified Services Theory processes in more detail, for instance by showing that the outputs of production process activities might be used as inputs for other activities within the same or different production process (belonging to the same provider work system), and, thus, not all outputs are directed at internal or external customers. Likewise, it can also show the resources of different kinds that are used as inputs in individual production process activities, whereas the Unified Services Theory focuses on different kinds of consumer inputs into the overall service process.

14

The Work System Meta-model is also interesting as it can help bridging the Unified Services Theory and the Service-Dominant Logic. The service brought about by the provider service system does not directly create value for the customer, but “facilitates” value creation [7], which is done in the customer work system. The product/service for customer is, thus, similar to the output of production processes that is selected for consumption processes in which value is extracted to satisfy consumer needs. Although the customer always has certain responsibilities, customer participation in service system activities (in the sense of co-production) is optional, so the absence of a distinction between service systems (or service production processes as in the Unified Services Theory) and “non-service” systems (or non-service production processes as in the Unified Services Theory) is similar to the Service-Dominant Logic where all economic activity is service (i.e., Foundational Premise FP5). Also, the definition of service is very similar to that of the Service Dominant Logic.

An apparent difference with the Service-Dominant Logic is the view of value co-creation which is optional in the Work System Meta-model but strictly required for service in the Service-Dominant Logic. The difference is actually more a difference in definition as the value creation in the customer work system based on the products/services of the provider service system is what resource integrators (FP9) do and what qualifies as value co-creation in the Service-Dominant Logic. The Work System Meta-model employs a more restrictive notion of value co-creation as customer work system activities that coincide in time and location with provider service system activities, implying that value co-creation is a more narrow form of co-production. More important is that the service system produces a “service as a process” (as in the Service-Dominant Logic), which facilitates value creation by customers/consumers (as in the Unified Services Theory).

The concept map in Figure 5 shows how the Work System Meta-model can be linked to both the Unified Services Theory and the Service-Dominant Logic. The product/service for customer is equated with the output that the consumer selects for the consumption process in the Unified Services Theory. Hence, the value for customer created by the customer work system is the value that is extracted in the consumption process performed by the consumer. The link with the Service-Dominant Logic is that service is performed by the service system.

Concept map of the Unified Services Theory, Service-Dominant Logic, and the Work System Meta-model

Figure 5. Concept map of the Unified Services Theory, Service-Dominant Logic, and the Work System Meta-model.

15

The Resource-Service-System model [15, 14] interprets the Resource-Event-Agent (REA) Model of economic exchange [5] according to the Service-Dominant Logic. In REA, economic exchange results from the economic reciprocal actions (called economic events) of independent entities (called economic agents) that provide each other the resources that they control (called economic resources).

16

Rooted in Accounting, REA employs the traditional economic classification of products as goods and services, hence, services are a type of resource exchanged between economic agents. This means that a service resource (e.g., a consulting service) and the event that transfers this resource from a providing agent to a receiving agent (e.g., the contracting and executing of the consulting service) are explicitly distinguished, whereas such distinction is not recognized in the Service-Dominant Logic (i.e., the consulting process is the service).

The Resource-Service-System model, therefore, replaces the REA notion of economic resource by the Service-Dominant Logic notion of operant/operand resource (see the concept map in Figure 6), the REA notion of economic event by the Service-Dominant Logic notion of service (as operant resources acting upon operand resources (e.g., as service target) or with operand resources (e.g., as tools or appliances)), and the REA notion of economic agent by that of service system entity. The latter concept is inspired by systems thinking in Service Science [12], where service systems are seen as supra-systems composed of sub-systems (i.e., service system entities) that improve their state (and, hence, the state of the supra-system) through service exchange.

As dynamic configurations of resources, service system entities possess the means to engage in service exchanges with other service system entities. Based on the REA axiom of economic reciprocity in economic exchange, also described as the duality of economic events, the Resource-Service-System model posits that service exchange is the reification of the dual relationship between economic reciprocal events as a series of actions and interactions undertaken by service system entities. Figure 6 shows that a service exchange is composed of service system interactions which are described by an interaction episode [11]. Such an interaction episode represents a series of activities, separately or jointly performed by the service system entities, as they occur in reality and, thus, lead to a certain outcome or interaction episode type. The purpose of service exchange is mutually beneficial value co-creation, meaning that service system entities engaging in service exchange employ their resources to integrate them with the exchange partner’s resources in order to jointly create value for all parties. Whereas mutually beneficial value co-creation is the intended favorable outcome of service exchange, the model recognizes other possible (and unfavorable) outcomes in line with the ISPAR model of service interaction outcomes [11].

Concept map of the Resource-Service-System Model

Figure 6. Concept map of the Resource-Service-System Model.

17

The Resource-Service-System Model fully adheres to the service-dominant economic world view put forward by the Service-Dominant Logic. Therefore, both descriptive theories are very similar and concepts like operant/operand resource and service are shared. Further, while the Service-Dominant Logic does not employ the term service system, it is clear that the actor concept is the same as the service system entity concept in the Resource-Service-System Model. The integrated concept map of Fig. 2.7, therefore, replaces the actor concept by the service system entity concept. Nevertheless, adding the Resource-Service-System Model further enriches the conceptual model of service that we gradually built throughout this section. First, the Resource-Service-System Model stresses more than the Service-Dominant Logic does that in an economic context, service is exchanged for service through interactions between service system entities. The kernel concept of the model is service exchange, not service. As a corollary, while the Service-Dominant Logic focuses on value co-creation as the creation of value by two actors for one of them, the Resource-Service-System Model clarifies that the purpose of service exchange is mutually beneficial value co-creation, i.e., value is created jointly for both service beneficiaries. Second, the Resource-Service-System Model recognizes (like the work system perspective described in [4] does) that this intended outcome might differ from the actual outcome of the interactions between service system entities.

18

The detailing of service exchange in terms of interactions between service system entities, in the form of joint and/or separate activities, provides for bridges with the two theories that focus more on the production/operational side of service processes and systems. Clearly, a service system activity as in the Work System Meta-model is an activity as defined by the Resource-Service-System Model, however, this is also true for an activity in the customer work system (coinciding or not with a provide service system activity). The concept of interaction episode is defined similarly to the concept of process in the Unified Services Theory, though it is used to represent the actual conduct of the activities in a single instance of service execution and should, therefore, be distinguished from a process “model”. The service system concept of the Work System Meta-model is different from the service system entity in the Resource-Service-System model as a service system entity (or actor in the Service-Dominant Logic; hence, producer/consumer in the Unified Services Theory) needs a work system (containing production processes) to perform a service.

A service system entity can itself be a resource in a “larger” work system. This is consistent with the systemic view of the Resource-Service-System Model (i.e. a service system entity can be used as an operant resource that acts in a service that is exchanged by the supra-entity controlling the entity), but also covers scenarios like consumers that are used as input in service processes according to the Unified Services Theory and fully automated service systems that perform actor roles in activities of a higher-level service system as made possibly by the Work System Meta-model. The operational details of the Work System Meta-model surpass that of the Resource-Service-System model, but on the other hand service exchange as a concept is missing, which makes the integration valuable as it allows creating a more complete concept base for identifying the elements that compose a service system conceptualization for designing the intended white-box service description language.

19

At the end of this chapter we wish to stress that the concept map shown in Figure 7 was obtained by gradually integrating the concept maps of the selected theories. Where possible, concepts from different theories with identical or very similar definitions were united. This way also relationships that cross theoretical boundaries could be established. The map shown in Figure 7 is, however, not a conceptual model of an integrated descriptive theory of service due to some fundamental differences in view on the nature of service and value creation. Therefore, multiple interpretations of service and value creation coexist.

Integrated concept map of four theories of service

Figure 7. Integrated concept map of four theories of service.

All four theories consider service as an “occurrent” or “perdurant” rather than a “continuant” or “endurant”, meaning something that happens rather than something that exists. While the definition of service in the ServiceDominant Logic, the Work System Meta-model, and the Resource-Service-System Model is (almost) identical, i.e., service is defined as a process in which something is done that benefits someone else, the Unified Services Theory, which does not directly define the concept of service, recognizes the existence of non-service processes. But as those non-service processes still produce outputs that consumers turn into benefits, the other three theories would argue that service was brought about.

The real difference in view on service depends on how service is “produced”. The Unified Services Theory is clearly the most restrictive as service processes need individual consumer inputs, which, given the many kinds in which those inputs can exist, is still much broader than requiring services to be co-produced. Co-production is recognized by the Work System Meta-model as customers participating as actors in the provider’s service system activities, however, it is optional. There can be service without co-production, even without individual customer inputs that are made available to the provider’s service system.

All four theories agree that the determination of value is the consumer/customer’s business. For the Service-Dominant Logic and the Resource-Service-System model, this value capture by the service beneficiary is co-creation of value. For the Work System Meta-model, this value capture, by the customer work system (or as in the Unified Services Theory, consumer’s consumption process) is not co-creation unless activities in the customer work system coincide with activities in the provider service system. So there is a fundamental difference in the definition of value co-creation between on the one hand the Work System Meta-model and on the other hand the Service-Dominant Logic and the Resource-Service-System model. Despite this different conceptualization of value co-creation, the notion of service is almost the same in these three theories.

The Resource-Service-System model adheres to the same service-dominant economic worldview as promoted by the Service-Dominant Logic and, hence, does not differ from that theory. It does stress, more than the Service-Dominant Logic does, the praxeology of service. Economic actors exchange service for their mutual benefit, hence, the exchange of service for service is a mutually beneficial value co-creation phenomenon. Further, it also recognizes, like the Work System Meta-model does, that service is an outcome which is not always achieved, even when intended.

Despite these differences, we believe that the end result of our analysis and modeling exercise (Figure 7), is a rich, multi-perspective concept base for designing a service system model that provides a conceptual foundation for the LSS-USDL language. Each of the reviewed theories has the ability to add concepts that are potentially relevant to a white-box service system conceptualization. The Service-Dominant Logic emphasizes that service is a process of operant resources acting upon operand resources. The Unified Services Theory sees the service production process as different from the value extraction process. The Work System Meta-model adds operational details to service production, involving different kinds of operant and operand resources, and puts forward the notion of service system. Finally, the Resource-Service-System Model adds the service exchange aspect and stresses that, in an economic context, value co-creation should be mutually beneficial. From a white-box perspective, this mutually beneficial value co-creation results from a series of activities, separately or jointly performed by service system entities, where these activities are part of the provider service system and/or customer work system, and can be organized as processes. Processes, activities, and resources used as inputs or produced as outputs, are all relevant concepts for a white-box service system conceptualization.

References

  1. Steven Alter. Work system theory: Overview of core concepts, extensions, and challenges for the future. Journal of the Association for Information Systems, 14(2), 2013.
  2. Steven Alter. Disentangling service: Using a work system perspective to reconcile different but overlapping portrayals of service and service systems. Working Paper, 2014.
  3. Steven Alter. Viewing services as service systems: basic premises of an operational model for service innovation, engineering, and management. Working Paper, 2014.
  4. Steven Alter. Work system perspective on service, service systems, it services, and service science. Business Analytics and Information Systems, 2014.
  5. Guido Geerts and William McCarthy. An ontological analysis of the economic primitives of the extended rea enterprise information architecture. International Journal of Accounting Information Systems, 3(1):1– 16, 2002.
  6. Shirley Gregor. The nature of theory in information systems. MIS Q., 30(3):611–642, September 2006.
  7. Christian Grönroos. Value co-creation in service logic: a critical analysis. Marketing Theory, pages 279–301, 2011.
  8. Alan Hevner, Salvatore March, Jinsoo Park, and Sudha Ram. Design science in information systems research. MIS Q., 28(1):75–105, March 2004.
  9. IfM and IBM. Succeeding through Service Innovation: A Service Perspective for Education, Research, Business and Government. University of Cambridge Institute for Manufacturing, Cambridge, United Kingdom, 2008.
  10. Robert Lusch and Stephen Vargo. Service-dominant logic: reactions, reflections and refinements. Marketing Theory, 6:281–288, 2006.
  11. Paul Maglio, Stephen Vargo, Nathan Caswell, and Jim Spohrer. The service system is the basic abstraction of service science. Information Systems and e-business Management, 7(4):395–406, 2009.
  12. Manuel Mora, Mahesh Raisinghani, Rory O’Connor, and Ovsei Gelman. Toward an integrated conceptualization of the service and service system concepts: A systems approach. IJISSS, 1(2):36–57, 2009.
  13. Arun Parasuraman, Valarie Zeithaml, and Leonard Berry. A Conceptual Model of Service Quality and Its Implications for Future Research. The Journal of Marketing, 49(4):41–50, 1985.
  14. Geert Poels. A conceptual model of service exchange in service-dominant logic. In Jean-Henry Morin, Jolita Ralyt´e, and Mehdi Snene, editors, Exploring Services Science, volume 53 of Lecture Notes in Business Information Processing, pages 224–238. Springer, 2010.
  15. Geert Poels. The resource-service-system model for service science. In Juan Trujillo, Gillian Dobbie, Hannu Kangassalo, Sven Hartmann, Markus Kirchberg, Matti Rossi, Iris Reinhartz-Berger, Esteban Zimnyi, and Flavius Frasincar, editors, Advances in Conceptual Modeling Applications and Challenges, volume 6413 of Lecture Notes in Computer Science, pages 117–126. Springer, 2010.
  16. Scott Sampson. Customer-supplier duality and bidirectional supply chains in service organizations. International Journal of Service Industry Management, 11:348–364, 2000.
  17. Scott Sampson. A unified services theory paradigm for service science, June 2007.
  18. Scott Sampson and Craig Froehle. Foundations and implications of a proposed unified services theory. Production and Operations Management, 15(2):329–343, 2006.
  19. Jim Spohrer, Paul Maglio, John Bailey, and Daniel Gruhl. Steps toward a science of service systems. Computer, 40(1):71–77, January 2007.
  20. Stephen Vargo and Robert Lusch. Evolving to a new marketing dominant logic for marketing. Journal of Marketing, 68(1):1–17, 2004.
  21. Stephen Vargo and Robert Lusch. The four service marketing myths: Remnants of a goods-based, manufacturing model. Journal of Service Research, 6(4):324–335, 2004.
  22. Stephen Vargo and Robert Lusch. From goods to service(s): Divergences and convergences of logics. Industrial Marketing Management, 37(3):254– 259, May 2008.
  23. Stephen Vargo and Robert Lusch. Service-dominant logic: continuing the evolution. Journal of the Academy of Marketing Science, 36(1):1–10, 2008.
  24. Stephen Vargo, Paul Maglio, and Melissa Akaka. On value and value co-creation: A service systems and service logic perspective. European Management Journal, 26(3):145 – 152, 2008.
  1. 1 Major Theories
  2. 2 Service-Dominant Logic
  3. 2.1 A New Service Definition
  4. 2.2 Foundational Premises
  5. 2.3 Service-Dominant Logic Concepts
  6. 3 Unified Services Theory
  7. 3.1 Defining the Service Process
  8. 3.2 Unified Services Theory Concepts
  9. 3.3 Service Process versus Service as Process
  10. 3.4 From Service Process to Service Exchange
  11. 4 Work System Meta-model
  12. 4.1 Work System Meta-model Concepts
  13. 4.2 From Service Process to Service System
  14. 4.3 Reconciling Value Co-creation Definitions
  15. 5 Resource-Service-System Model
  16. 5.1 Resource-Service-System Model Concepts
  17. 5.2 Mutually Beneficial Value Co-creation
  18. 5.3 Service System to Service Exchange between Service System Entities
  19. 6 Summary and Conclusions

Linked USDL – Introduction

After Pedrinaci, C, J Cardoso, and T Leidig – Linked USDL – A vocabulary for web-scale service trading – 2014

Introduction

The importance of real-world services, that is business activities of a mostly intangible nature (e.g., life insurance, consulting), has grown over the last 50 years to dominate economic activity [1]. Because of their intangible nature, services can often be bundled, adapted, and traded in an automated manner. In an attempt to exploit the Web as a service trading platform a number of service marketplaces have emerged, ranging from purely technical registries like UDDI [2], to business-oriented marketplaces such as Google Helpouts. Technical registries have for the most part focused on the computer science aspects of services which is limiting as it ignores fundamental characteristics of services including the economic, social, and business contexts [3]. Business-oriented marketplaces on the other hand have focussed on providing silos that offer limited search and comparison capabilities through an essentially human-oriented storefront [4]. As a result, common and essential economic activities in the service sector such as the generation of customised offerings, the creation and trading of possibly cross-domain and multi-provider service bundles, or simply the communication between customer and provider remain largely manual activities [4].

Supporting the trading of services over the Web in an open, scalable, and automated manner enabling the opportunistic engagement of multiple crossdomain providers requires a shared means for capturing and reasoning upon the economic, social, and technical aspects governing service exchanges [1,3,4]. The Unified Service Description Language (USDL) is the most comprehensive attempt in this direction but it has received limited adoption due to its complexity, while it also exhibited limitations with respect to the level of extensibility and automation supported. In this paper we present Linked USDL, a new vocabulary which builds upon the results and experience gained with USDL combined with prior research on Semantic Web Services, business ontologies, and Linked Data to better support Web-scale automated service trading. We present the methodology and main decisions adopted for transforming the complex USDL specification into a network of vocabularies that is anchored on simplicity as well as on vocabulary and data reuse. The resulting vocabulary is thoroughly evaluated in terms of domain coverage, suitability for purpose, and its current level of adoption.

Related Work

Service Science aims to reach a better understanding of services, service networks, value co-creation and service innovation, to name a few of the main research topics [1]. These efforts, which encompass several disciplines, are geared towards establishing solid foundations for advancing our ability to design, create, and analyse service systems with both business and societal purposes in mind.

Relevant work in Computer Science includes service-oriented systems, which approach the development of complex applications by integrating networked software components called Web services [2]. This area has been prolific in terms of both tooling and specifications including a number of approaches for describing technical services semantically, e.g., OWL-S, SAWSDL, and WSMO [5,6]. Although (semantic) Web services work provides advanced support for discovering or composing technical services, it disregards the fundamental socio-economic context of real-world services (e.g., value chains and offerings), and does not cover the widespread manual services (e.g., consulting) [3]. Complementary work on Workflow and Business Process Management has focussed on the operationalisation of the processes within enterprises [2,3,5], which has more recently also incorporated human activities [7]. This work is, however, centred on a procedural view on how activities are carried out within an organisation which is orthogonal to the business characteristics of the services offered (e.g., speed of internet connection offered) which are essential to service trading.

The most notable effort able to represent and reason about business models, services, and value networks is the e3 family of ontologies which includes the e3service and e3value ontologies [3,8]. This research has, however, not been much concerned with the computational and operational perspectives covering for instance the actual interaction with services. Likewise, the technical issues related to enabling a Web-scale deployment and adoption of these solutions were not core to this work. GoodRelations [9] (GR) on the contrary is a popular vocabulary for describing semantically products and offerings. Although GR originally aimed to support both services and products, it is mostly centred on products to the detriment of its coverage for modelling services, leaving aside for instance the coverage of modes of interaction, or the support for value chains.

USDL [4,10] is, to date, the most comprehensive approach to supporting the description of services for automated processing. USDL consists of 9 modules modelled in eCore capturing services, interaction interfaces, pricing models, service level agreements, and related legal issues. Despite its comprehensive support, this effort underestimated the need for such an all encompassing model to be widely open, highly flexible and extensible, and yet simple in nature [11]. On the one hand, the rather centralised and controlled nature of the approach led to an overly complex model hard to grasp and apply. On the other hand, eCore exhibited technical limitations towards its extensibility and its use as a lingua franca on the Web where Linked Data and light semantics are currently considered a more adequate technology.

Requirements Analysis

Informed by research carried out on services, including the related work covered earlier, we have elicited a number of requirements that Linked USDL and any other language or vocabulary with such an ambitious purpose should address. This includes notably coverage requirements, which we shall cover first. We also present additional criteria that we identified during the standardisation activities of USDL as potential issues and limitations for its Web-scale adoption [11].

Description Requirements

One of the essential difficulties when dealing with services beyond mere technical interfaces, is the fact that they are at the intersection of many diverse disciplines that range from technical aspects, to operational ones, socio-economic concerns, or even legal issues. Being able to move across each of these domains is essential to support the trading of services online. We detail the main dimensions next.

Functionality Services are business activities that normally take place through (possibly technology mediated) interactions between stakeholders, resulting in benefits to the actors involved. Fundamental to the notion of service is therefore its functionality in terms of what it does, requires, and provides. Given the highly diverse nature of services this should cover the entire spectrum from fully automated provisioning (e.g., Spotify) to those essentially manual (e.g., car repair service). Depending on the stakeholder, the level of abstraction could vary from a detailed operational view (provider), to a high-level one for customers.

Agents and Networks Services delivery engages several stakeholders in (possibly ephemeral) ad-hoc business networks, e.g., banks often engage in partnerships with insurances to provide accounts with integrated travel insurance. The modelling of services should seamlessly support both the emergence and analysis of such networks in order to enable the dynamic co-creation of value through Web-wide service trading. Important aspects to be covered are thus the agents involved in a certain network and the role(s) they play.

Service Relationships Thanks to their intangible nature, services can be combined, repurposed, and adapted to better fulfil customer needs. Services are often related to other services and products. For instance, services can often be enhanced with others, or there can be variations over established types. Services are often bundled, i.e., aggregated and offered jointly in packages like broadband and TV services. And in the case of automated services, services may be composed according to specific data and control flow to achieve a complex objective out of simpler components.

Operational and Delivery The delivery of services is often subject to restrictions or conditions. These may range from geographical concerns (e.g., the insured individual should live in the UK), temporal availability, legal issues, variable pricing, and so on. From a service provider operational perspective, there may well be limitations due to the resources required, e.g., staffing, that need to be tracked as they determine the costs and the capacity for providing a service.

Consumption Services are most often accessed or “consumed” through interactions by means of designated communication channels. For example, making an insurance claim may require the customer to phone the insurance company, or fill up a form online. These communication channels may vary during the service delivery process (e.g., initially claim by phone and check the progress online), and there may exist restrictions on how interactions should take place. For instance a car repair service may require you to bring the car to the garage whereas in other cases the service may take care of sending a mechanic within some geographical boundaries.

Language Requirements

In addition to the aforementioned coverage requirements, research in the area has highlighted further requirements that the language should meet. First and foremost given the complexity of the domain and the fact that the aim is to maximise to the extent possible the level of automation that can be achieved during the life-cycle of services, the modelling of services needs to rely on a conceptual model with formal foundations that can enable automated processing [3, 10]. Nonetheless the language should be modular and extensible in order to be able to accommodate different domains and the many facets of services while minimising the complexity for users and tool developers.

Our subsequent work on standardisation highlighted that although necessary, these requirements did not appear to be sufficient for Web-scale adoption:

An Open Solution To support the engagement of any business entity across any domain the technological approach should be open. It should be open so as to allow anybody to engage and trade services online, as well as towards its evolution in order to cater for new requirements, accommodate new ways of doing business, or support new domains.

A Web-based solution A scenario like the one envisaged requires an approach that can support the engagement of millions of service providers and consumers in exposing, locating, interpreting, and contracting services. This necessarily calls for highly interoperable and scalable solutions in terms of data sharing, data processing, and communication protocols.

Promoting uptake While providing an open solution is likely to have a positive impact on technology take up, adoption will largely be determined by the simplicity with which any business entity could adopt a solution based on these technologies and the compatibility with existing legacy systems.

Linked USDL Vocabulary

Driven by the aforementioned requirements and informed by the drawbacks exhibited by USDL we worked on Linked USDL focussing essentially on reducing the complexity underlying USDL and fostering its wider adoption through the use of Web-centric technologies that are more amenable to extension, modification, and automation at large scale.

Design Decisions

First, due to the success, scale, growth, and current adoption of the Web for worldwide telecommunication and electronic commerce we believe that any technology hoping to enable service trading online should necessarily embrace and build upon the Web principles and technologies [12]. Notably Linked USDL should also embrace principles like i) the establishment of global identifiers, e.g., by using URIs to identify services and providers; ii) the use of links to other resources on the Web to enrich a particular datum with reusable and externally provided information, e.g., pointing to complementary services; iii) the use of HTTP as a simple uniform protocol for supporting interactions; and iv) the decoupling between resources and their representation. Doing so brings a technology stack that has proven to support large scale, efficient, multi-party interactions, as well as it directly provides an integration point with open, standard technologies that are already widely used and supported.

Second, to enable effective interactions at the business level, we need to provide standards that go beyond data transportation and syntactic representation [1].

To this end, Linked USDL embraces the use of formal ontology representation languages to capture the semantics of services such that they are amenable to automated reasoning. Linked USDL goes one step forward in the adoption of Web technologies to embrace the emerging standard approach for data sharing online, namely Linked Data [13]. Adopting these principles enables Linked USDL to capture, share, and interlink data about services of highly heterogeneous nature and domains, in an open, scalable, and uniform manner. Linked Data principles promote and support reuse which in turn helps to reduce the data modelling overhead (e.g., by reusing conceptual models and existing data sets), and maximise the compatibility with existing tooling. Both aspects are major challenges earlier versions of USDL faced which this work aims to alleviate.

Design Methodology

Following common Knowledge Engineering best practices [14], we aimed at creating a modular solution based on well-designed, widely adopted vocabularies that did not introduce substantial ontological commitments away from the core topics of interest. Thus, considerable effort was devoted to identifying and evaluating reusable ontologies.

First, we identified the main topics to be covered given the original USDL specification and determined some core terms characterising each of these topics. Informed by the topics and terms identified, we carried out both a manual and semi-automated search to determine potentially relevant reusable ontologies. On the one hand, we performed a state of the art analysis to identify ontologies that were relevant for the modelling of services, see [11] and Section 2. On the other hand, we used Swoogle [15], Watson [16], LOD Stats [17], and the Linked Open Vocabularies (LOV) engines to search for ontologies covering the main terms identified. For each of the queries asked, we kept the top 10 results. The resulting list was eventually enriched with widely-used general purpose vocabularies such as Dublin Core (DC) and Simple Knowledge Organisation Scheme (SKOS).

Second, for each of the vocabularies identified, we used both LOD Stats and LOV to figure out the number of datasets using these terms, the number of instances of the main concepts of interest present in datasets on the Web, and the number of times the vocabulary is reused elsewhere. The search for reusable ontologies provided us pointers to existing vocabularies of potential interest together with indications regarding their use and popularity. Table 1 shows the results obtained for the vocabularies for which there was at least one instance found on the Web[1]. Indeed, the statistics should not be taken as an exact value of the overall use of these vocabularies (e.g., GR is used more frequently than what is reflected by this analysis), but rather as a relative indication. Indeed we also took into account the properties defined by these vocabularies which are in some cases (e.g., DC Terms) the main constructs reused.

The design of Linked USDL was driven by these statistics, and a manual assessment of the quality, coverage, and potential alignments of the vocabularies.

Topic Vocabulary # Datasets # Instances LOV Reuse
LOD LOV LOD LOV
Service GR 6 45 146 0 6
MSM 2 0 41,368 0 0
OSLC 2 0 2 0 0
COGS N/A 5 N/A 0 3
Offering GR 6 8 824 656 4
Location vCard (v3 & v4) 5 0 + 2 3,684 3,686 + 3 0 + 2
WGS84 11 1 3,204 1,7651 1
AKT Signage 18 0 11,789 0 0
DC Terms 1 9 39 39 6
Schema.org 1 5 1
Business Entities Schema.org 2 4 1,570,778 1,570,778 3
FOAF 60 135 14,613 14,557 29
GR 1 N/A 3,918 N/A N/A
W3C Org. 1,050 11 2 1,050 2
Time W3C Time 9 N/A 236,433 N/A N/A

Table 1. Top Vocabularies per Topic.

Model

Informed by the aforementioned analysis, Linked USDL, which is publicly available together with further examples in GitHub, builds upon a family of complementary networked vocabularies that provide good coverage of necessary aspects and are widely used on the Web for capturing their particular domains. In particular Linked USDL builds upon:

  • DC Terms to cover general purpose metadata such as the creator of a certain description, its date of creation or modification, etc.
  • The vocabulary has been modelled mostly using RDF/RDFS constructs and we have limited the inclusion of abstract foundational concepts, so as to attain a model that is simple enough for its adoption online. The reader is referred to [19] for indications on how this model could be mapped to a foundational ontology.
  • SKOS providing low-cost support for capturing knowledge organisation systems (e.g., classifications and thesauri) in RDF.
  • Time Ontology (Time) for covering basic temporal relations. The ontology allows us to capture temporal relationships such as before and during.
  • vCard vocabulary a vCard 4 compatible vocabulary to support providing location and contact information for people and organisations.
  • Minimal Service Model (MSM) [18] to provide coverage for automated service-based interactions including Remote Procedure Call solutions (e.g., WSDL services) and RESTful services.
  • GR [9] to provide core coverage for services, business entities, offerings, and products.

Linked USDL Core Schema
Figure 1. Linked USDL Core Schema.

As the core and initial module of a set of vocabularies for supporting service trading online Linked USDL Core, see Figure 1, aims to cover four essential aspects: offerings, services, the business entities involved in the delivery chain, and the actual interaction points allowing consumers to contract or trigger the benefits of contracted services.

Linked USDL extends GR which is nowadays the de facto standard vocabulary for publishing semantic descriptions for products. It is worth noting that although services are accommodated within GR, their coverage is rather basic at this stage. Extending GR enables linking services and products descriptions which is particularly useful since many products are often sold in combination with a service, e.g., a repair or replace service. Additionally, it also ensures that an initial alignment with the increasingly popular vocabulary Schema.org is in place, for GR is already largely aligned to it.

Core Concepts

The most important concepts provided by Linked USDL are:

Service is a refinement of gr:ProductOrService and subsumes all classes describing service types. Examples of subclasses of Service could be “internet provisioning service” and “insurance service”. Instances of Service may define i) prototypical services part of a portfolio, e.g., “BT unlimited broadband service”, as covered by ServiceModel, ii) one-of services custom tailored for a potential customer, or iii) actually contracted services, e.g., “your concrete life insurance provided by AXA”, as covered by gr:ServiceIndividual.

ServiceModel is a refinement of gr:ProductOrServiceModel which specifies common characteristics (e.g., download speed) of a family of services. ServiceModel thus defines families of Services sharing common characteristics, e.g., “BT unlimited broadband services share the characteristic of supporting unlimited download”. An actual service instance shares the properties of its service model. This is a feature that requires non-standard reasoning which specific implementations should take care of.

ServiceIndividual is a subclass of gr:Individual and Service. Instances of ServiceIndividual are actual services that are creating value to a network of business entities. For instance, “your concrete life insurance provided by AXA” is a ServiceIndividual which is providing value to yourself and AXA.

ServiceOffering is a subclass of gr:Offering and represents essentially offerings by a business entity including at least one Service. ServiceOffering may have limited validity over geographical regions or time.

EntityInvolvement is introduced in Linked USDL in order to enable capturing service value networks. In a nutshell, Entity Involvement allows capturing a ternary relationship expressing that a business entity, e.g., “AXA”, is involved in a service, e.g., “basic life insurance” playing a business role, e.g., “provider”. Linked USDL provides a reference SKOS taxonomy of basic business roles that covers the most typical ones encountered such as regulator and intermediary.

InteractionPoint link services to interactions that may be possible or required between the members of a service value network and the service during its life cycle. This allows answering questions such as “what is the sequence of interactions I may expect if I want to make an insurance claim and what communication channels are available to that end?”.

CommunicationChannel is the class of all different communication channels that business entities could use for communication. Linked USDL covers the most widely used channels by means of 2 vocabularies: vCard (e.g., email, phone), and MSM (e.g., Web services, and RESTful services). Communication channels are additionally characterised by their interaction type. Linked USDL provides 2 reference SKOS taxonomies covering the main modes (e.g., automated) and the interaction space (e.g., on-site).

EntityInteraction links interaction points to business entities or types (e.g., provider), and the role they play within the interaction (e.g., initiator). EntityInteraction allows expressing things like “to make a claim, the consumer should first contact the insurance provider and provide the policy number”.

Classifications Classifications or taxonomies of entities are most often used when describing services to capture, for instance, service types, business entity roles, e.g., “provider”, as well as interaction related issues, e.g., “manual vs automated”. We also expect that classifications will be needed in forthcoming modules addressing strategic issues or the internals of delivery chains.

This could be approached directly using subclassing which is directly supported by RDFS. However, the use of a hierarchy of classes establishes strict relationships which may not adequately match existing organisation schemes. For this reason, in Linked USDL we have accommodated the use of SKOS, which enables capturing classification schemes and taxonomies. Indeed, this mechanism does not prevent users from providing their own domain-specific categorisations through subsumption if they wish to. This approach thus enriches Linked USDL with a powerful, yet flexible and extensible means for creating categorisations.

The current version of Linked USDL includes three SKOS schemes with reference categorisations for BusinessRoles, InteractionRoles, and InteractionTypes, see Figure 1. These schemes have been, however, kept as separate modules so that different schemes can be used if necessary.

Evaluation

Coverage Evaluation

Ontologies are often evaluated by comparing them to a gold standard ontology [20]. In our case, we have done such an evaluation by comparing the resulting model to USDL, the most comprehensive model available for describing services. Doing so allows us to get a clear indication of the overall coverage of the domain, and to identify as well the main deviations from USDL.

A fundamental goal of this work is providing a conceptual model that would be easy to grasp, populate, process, and ultimately be adopted for Web-scale use. Thus, out of the 9 modules of USDL we have essentially deferred covering the following modules: Service, Legal, Service Level, and Pricing. Nonetheless, for every module we have checked the coverage of the main concepts defined in order to get an indication of both module-specific and the overall coverage of Linked USDL. [The results of this analysis are summarised in Table 2 of the original paper].

This analysis shows that thanks to integrating an reusing existing vocabularies we have managed to cover the vast majority of USDL, by providing a vocabulary consisting of 12 concepts and 3 complementary SKOS categorisations. In particular, from an original specification with 125 concepts we cover 74%, if we limit ourselves to the specific modules we targeted, and 60% overall, which shall contribute towards reducing the overhead related to understanding and adopting Linked USDL. It is worth noting that out of the concepts not explicitly covered several are sometimes redundant (e.g., Condition is subclassed in many modules), or were seldom properly understood and used (e.g., Functions, Phases of interactions, Service Level Agreements).

Suitability for Tasks and Applications

Given that Linked USDL does not cover all concepts present in USDL it is worth assessing the impact of such decisions. [Again, see Table 2 in the original article]. In qualitative terms, the decisions adopted are such that Linked USDL does not currently provide support for capturing how providers deliver services in terms of resources needed, complex internal workflows, or strategic decisions (e.g., targeted markets). The reason for this is two-fold. First, such aspects are often not automated and when they are, providers already have mechanisms in place to this end. Second, these are private concerns that are orthogonal to the trading of services. Similarly, Linked USDL does not currently include support for conceptualising complex agreements including legal requirements and guarantees as these were barely used or understood by users. Finally, we have opted for a simple mechanism for capturing prices and have deferred to a separate module the modelling of more complex dynamic pricing that are less often used and usually remain private to the provider.

Despite these changes, Linked USDL provides advanced support for modelling, comparing, discovering, and trading services and service bundles. It provides means for tracking and reasoning about the involvement of entities within delivery chains which informs the trading and comparison of services as well as it enables the tracing and analysis of service value networks. It provides advanced support for automating the interactions between actors during the life-cycle of services. Additionally it includes support for capturing service offerings, for combining services and products (e.g., a car often comes with a warranty), and for applying temporal reasoning, which were not previously available. Finally, and most importantly, these activities can be achieved with a greater level of automation benefitting from automated reasoning and they can be performed on a Webscale across Web-sites and service providers thanks to capturing and sharing the semantics of services as Linked Data.

Empirically, the suitability of the language for supporting the automation of key tasks has been evaluated by two main means. On the one hand, we have reused and developed tools that provide support for these tasks, and, on the other hand, we are continuously applying Linked USDL in a number of domains. In terms of reuse, thanks to the adoption of existing Linked Data vocabularies,

Linked USDL benefits from general purpose tooling, e.g., SPARQL engines and RDF stores, but also from vocabulary-specific solutions. This notably concerns existing advanced machinery for discovering, composing, and invoking technical services (i.e., RESTful and WSDL services) described in terms of MSM [18].

Additionally, general purpose infrastructure has been developed specifically for Linked USDL. A Web-based Linked USDL editor is currently available to help providers to easily generate Linked USDL descriptions. There is also an advanced multi-party dynamic and open service marketplace developed in the context of the FI-WARE project, able to gather, combine, and exploit rich service descriptions from distributed providers to help match offer and demand. Notably the marketplace supports consumers in searching for service offerings, comparing them, and contracting them.

Finally, from the perspective of its suitability for supporting service trading across domains, Linked USDL is currently being applied in a variety of domains. For instance, in the field of Software as a Service we have explored the use of Linked USDL in conjunction with TOSCA[21]. Linked USDL was used to formalise, structure, and simplify the discovery and selection of services of the Web-based customer relationship management (CRM) platform SugarCRM, while TOSCA supported the automated deployment and management of the services.

Additionally this work helped us evaluate the extensibility of Linked USDL by integrating it with complementary third party specifications such as TOSCA. In the FI-WARE project Linked USDL is used to support a service infrastructure supporting service ecosystems in the cloud covering both the technical and business perspectives. The FINEST project aims to support the transport and logistics (T&L) ecosystem, in which many service providers collaborate in order to transport goods over what is referred to as a “chain of legs”. Therein Linked USDL is being exploited in the planning of chains of legs to support searching and matching transport service offerings in a transparent, distributed, and multi-party manner.

Across the diverse domains where Linked USDL is being applied (see list of projects next), it has proven to be a valuable resource as a means to provide shared and globally accessible service descriptions integrating both technical and business aspects. The genericity, modularity, and extensibility of the approach has enabled extending the vocabulary with dedicated domain-specific vocabularies in the areas of SaaS and T&L, while generic software infrastructure was easily reused across domains.

Vocabulary Adoption and Use

When evaluating ontologies and vocabularies, one aspect that is often taken into account is their adoption and use. This evaluation may be carried over the ontology itself and/or over the different ontologies that are imported. The former gives an indication of the acceptance and adoption of the ontology in its entirety whereas the latter provides a more granular assessment over the reused ontologies. In this section we mainly address the latter but also provide preliminary indications of the overall adoption of Linked USDL.

The methodology that was followed was centred on the reuse of widely adopted vocabularies. Table 1 presented earlier shows the main vocabularies that were identified through search engines, together with core indicators of their use on the Web. These figures highlight that Linked USDL is based on vocabularies that are the most used in their respective domains of interest. Only two exceptions exist, AKT Signage which was not adopted for it was not dereferenceable, and Schema.org which is indirectly aligned via GR. This approach in turn reduces the potential overhead one would incur when using Linked USDL: frequently reused vocabularies are likely to have greater acceptance and support by people and existing systems.

Additionally, the availability of datasets with instances in terms of the vocabularies reused guarantees that new descriptions could reuse and link to existing resources, e.g., allowing the reuse of descriptions of companies. Doing so provides clear benefits from the perspective of data acquisition which was one of the main concerns Linked USDL was trying to address. Additionally, by linking to existing instances the data provided is enriched which may in turn enable further advanced processing as well as it may increase the discoverability of services.

Providing a substantial account of the adoption of Linked USDL would require a reasonable wait from its first release, which coincides with this publication. Nonetheless, Linked USDL is currently already in use within more than 10 research projects, namely FI-WARE, FINEST, Value4Cloud, Deutsche Digitale Bibliothek, MSEE, FIspace, FITMAN, FI-CONTENT, ENVIROFI, OUTSMART, SMARTAGRIFOOD, IoT-A, Broker@Cloud, and GEYSERS. These projects are using Linked USDL as the core vocabulary for describing services, contributing to validate the suitability, genericity, and extensibility of Linked USDL for different domains. This also highlights that despite its youth, Linked USDL is already witnessing a promising adoption.

Conclusion

Despite the importance of services in developed economies, the widespread adoption of world-wide electronic commerce over the Web, most service trading is still essentially carried out via traditional and often manual communication means. A fundamental reason for this is the difficulty for capturing the abundant information and knowledge governing services and their related transactions in a way amenable to computer automation. Out of the wealth of work around services, USDL is the most comprehensive solution proposed thus far for enabling (semi)automated service trading. Yet, work on its standardisation highlighted a number of limitations for Web-scale service trading.

We have presented Linked USDL, the next evolution of USDL centred on fostering its wider adoption and better automation support through the (re)use of Linked Data. Linked USDL has been developed following a methodology centred on maximising the reuse of existing vocabularies and datasets and minimising the complexity. The resulting vocabulary has been evaluated in terms of domain coverage, suitability for purpose, and vocabulary adoption.

Despite the good evaluation results obtained, Linked USDL is to be regarded as one step towards enabling Web-scale service trading, albeit a fundamental one. Further work is required for covering aspects such as complex dynamic pricing models and agreements which are common in certain domains such as Cloud services. Additionally, from the tooling perspective, developing advanced mechanisms able to support steps such as the negotiation between service providers and consumers, or the bundling of services would also be necessary. We expect in this last regard to take inspiration and adapt solutions developed for the e3 family of ontologies.

[1] These statistics were last retrieved in November 2013.

Next: Linked Service System USDL (LSS-USDL) – Transparency of services

References

  1. Chesbrough, H., Spohrer, J.: A research manifesto for services science. Communications of the ACM 49(7) (July 2006) 35.
  2. Papazoglou, M.P., Traverso, P., Dustdar, S., Leymann, F.: Service-Oriented Computing: State of the Art and Research Challenges. Computer 40(11) (2007) 38–45.
  3. Akkermans, H., Baida, Z., Gordijn, J., Peña, N., Altuna, A., Laresgoiti, I.: Value Webs: Ontology-Based Bundling of Real-World Services. IEEE Intelligent Systems 19(4) (2004) 57–66.
  4. Cardoso, J., Barros, A., May, N., Kylau, U.: Towards a Unified Service Description Language for the Internet of Services: Requirements and First Developments. IEEE International Conference on Services Computing (SCC) (2010) 602–609.
  5. Cardoso, J., Sheth, A.: Semantic e-workflow composition. Journal of Intelligent Information Systems (JIIS) 21(3) (2003) 191–225.
  6. Pedrinaci, C., Domingue, J., Sheth, A.: Semantic Web Services. In: Handbook on Semantic Web Technologies. Volume Semantic Web Applications. Springer (2010) 7. Oppenheim, D.V., Varshney, L.R., Chee, Y.M.: Work as a service. In: ICSOC’11: Proceedings of the 9th international conference on Service-Oriented Computing, Springer-Verlag (2011).
  7. Gordijn, J., Yu, E., van der Raadt, B.: e-service design using i* and e3value modeling. IEEE Software 23 (2006) 26–33.
  8. Hepp, M.: GoodRelations: An Ontology for Describing Products and Services Offers on the Web. In: Knowledge Engineering: Practice and Patterns. Springer (2008) 329–346.
  9. Oberle, D., Barros, A., Kylau, U., Heinzl, S.: A unified description language for human to automated services. Information Systems (2012).
  10. Kadner, K., Oberle, D., Schaeffler, M., Horch, A., Kintz, M., Barton, L., Leidig, T., Pedrinaci, C., Domingue, J., Romanelli, M., Trapero, R., Kutsikos, K.: Unified Service Description Language XG Final Report. Technical report (2011).
  11. Jacobs, I., Walsh, N.: Architecture of the World Wide Web, Volume One. W3C Recommendation (2004).
  12. Bizer, C., Heath, T., Berners-Lee, T.: Linked Data – The Story So Far. International Journal on Semantic Web and Information Systems (IJSWIS) (2009).
  13. Suarez-Figueroa, M.C., Gómez-Perez, A., Motta, E., Gangemi, A., eds.: Ontology Engineering in a Networked World. Springer (2011).
  14. Ding, L., Finin, T., Joshi, A., Pan, R., Cost, R.S., Peng, Y., Reddivari, P., Doshi, V.C., Sachs, J.: Swoogle: A Search and Metadata Engine for the Semantic Web. In: CIKM ’04: Thirteenth ACM international conference on Information and Knowledge Management. (2004).
  15. d’Aquin, M., Motta, E.: Watson, more than a Semantic Web search engine. Semantic Web 2(1) (2011) 55–63.
  16. Auer, S., Demter, J., Martin, M., Lehmann, J.: LODStats — an extensible framework for high-performance dataset analytics. In: EKAW’12: Proc. of the 18th international conference on Knowledge Engineering and Knowledge Management, Springer (2012).
  17. Pedrinaci, C., Domingue, J.: Toward the Next Wave of Services: Linked Services for the Web of Data. Journal of Universal Computer Science 16(13) (2010) 1694–1719.
  18. Ferrario, R., Guarino, N., Janiesch, C., Kiemes, T., Oberle, D., Probst, F.: Towards an ontological foundation of services science: The general service model. Wirtschaftsinformatik (February 2011) 16–18.
  19. Sabou, M., Fernandez, M.: Ontology (network) evaluation. In Suarez-Figueroa, M.C., Gómez-Perez, A., Motta, E., Gangemi, A., eds.: Ontology Engineering in a Networked World. Springer (2012) 193–212.
  20. Cardoso, J., Binz, T., Breitenbücher, U., Kopp, O., Leymann, F.: Cloud Computing Automation: Integrating USDL and TOSCA. In: 25th Conf. on Advanced Inf. Systems Engineering (CAiSE 2013). Volume 7908 of LNCS., Springer (2013) 1–16.

Jorge Cardoso – *-USDL Models, Open Semantic Service Networks

Biographical Note

Jorge Cardoso is Associate Professor at the University of Coimbra (Portugal), and affiliated to the Information Systems Group. He is also Lead Architect for Cloud Management at Huawei’s European Research Center in Munich, Germany.

His current research involves the development of the next generation of Cloud Management Platforms (CPM), Cloud Automation solutions, Cloud Business Process Management (BPM), and High Performance BPM systems.

More information about his research on Cloud Computing, BPM, Semantic Web, Web Services, and Enterprise Systems at: LinkedIn, Google Scholar, DBLP.

Publications

Academic Advisor

*-USDL Related by Others

Linked Services for the Web of Data

After Pedrinaci, C and J Domingue, Toward the next wave of services: Linked Services for the Web of Data, 2010.

Introduction

Web Services and Service-Oriented Architecture are lauded as a silver bullet for Enterprise Application Integration, implementation of inter-organizational business processes, and even as a general solution for the development of all complex distributed applications. Despite the appealing characteristics of serviceorientation principles and technologies, their uptake on a Web-scale has been significantly less prominent than initially anticipated [Davies et al., 09]. First and foremost Web services, despite their name, are hardly a Web-oriented technology [Vinoski, 2002] but rather one suited for enterprises which so far have been reluctant to publish functionality on the Web. Secondly, from a technical perspective, current technologies are such that software developers need to devote a significant effort to discovering sets of suitable services, interpreting them, developing software that overcomes their inherent data and process mismatches, and finally combining them into a complex composite process.

Semantic Web Services (SWS) [McIlraith et al., 2001] have long tried to overcome Web services limitations by enriching them with semantic annotations in order to better support their discovery, composition, and execution. Up until now, however, the impact of SWS on the Web has been minimal. In the Web, semantics are used to mark up a wide variety of data-centric resources but are not used to annotate online functionality in any form in significant numbers. In fact, although SWS technologies have already shown their benefits, e.g., in discovery [Pilioura and Tsalgatidou, 2009], research in the area has failed to take into account the socio-economic aspects devoted to the creation and annotation of services. First, research has mostly focused on devising highly expressive conceptual models and has given birth to a number of diverging and largely incompatible solutions. These efforts have essentially glossed over the complexity they introduce, the additional effort demanded of users, and they have brought additional heterogeneity to an already overwhelming stack of specifications. Second, SWS research has for the most part targeted WSDL/SOAP based Web services which are not prevalent on the Web [Davies et al., 09]. As a consequence, SWS is instead a niche technology only accessible to highly trained experts and the benefits obtained are most often not considered worth the additional investment.

In parallel, the Web is currently witnessing a dramatic change with the advent of Web 2.0 [O’Reilly, 2005] and Linked Data technologies [Bizer et al., 2009]. The former is “socialising” the Web, putting individuals at the core of the Web as both data producers and consumers. Web 2.0 technologies have shown that collaboration over the Web can produce outstanding results with a low cost, and it is also encouraging enterprises and institutions to offer their data and services publicly at a previously unprecedented scale and pace [Hendler and Golbeck, 2008, Chi, 2008, Davies et al., 09]. Second, Linked Data technologies, which derive from research on the Semantic Web, have given birth to the Web of Data, “a Web of things in the world, described by data on the Web” [Bizer et al., 2009]. The Web of Data, impelled by the current trend towards an open Web, has recently experimented an outstanding growth and currently provides publicly large amounts of interconnected data concerning a wide range of domains and described in terms of light weight ontologies for supporting automated processing [Bizer et al., 2009].

In this paper we explore the relationship between services and the Web of Data. We identify the potential benefits that can be obtained by adequately integrating these so far rather disconnected worlds. We anticipate that this integration will mitigate the existing limitations of both services and the Web of Data, giving birth to a new wave of services dubbed Linked Services, that will ultimately lead to an explosion in the publication and use of services on the Web. We outline how this integration could take place by using simpler vocabularies for describing services and through the adoption of Linked Data principles for publishing services on the Web. Finally, we outline how Linked Services will be able to provide the additional necessary building blocks for appropriately exploiting the wealth of information exposed in the Web of Data.

The remainder of this paper is organised as follows. First, we present the technological background around services and the Web. We then discuss why, in our opinion, the current situation can give birth to a new wave of services. We then present how the use of light weight semantics can allow us to bring services into the Web enabling their discovery through state of the art Linked Data technologies. Next, we focus on how services can contribute to the Web of Data both generating new data and processing existing one. Finally, we conclude the paper and outline key topics for further research.

Background and Related Work

The current technological landscape is characterised by a number of highly complementary technologies that have so far remained disconnected. In this section we review existing work in the area of Web Services, Web 2.0, Semantic Web, the Web of Data, and Semantic Web Services presenting the main results achieved so far and highlighting the main trends, challenges, and opportunities.

Web Services

The idea of deploying and providing services on the Web has been tightly bound to Web service technologies. Web services are software systems offered over the Internet via platform and programming-language independent interfaces defined on the basis of a set of open standards such as XML, SOAP, and WSDL [Erl, 2007]. Fundamental advantage of this technology lies in the support it brings to developing complex distributed systems maximising the reuse of loosely coupled components. Several languages for Web service composition have been proposed over the years in order to combine services in a process-oriented way, among which the most prominent is BPEL4WS [Andrews et al., 2003]. Additionally, the stack of technologies is completed by a large and rather overwhelming number of specifications dubbed WS-*, which deal with aspects such as security, transactions, messaging, and notification [Erl, 2007]. This stack has brought a considerable level of complexity and yet suffers from the fact that descriptions are purely syntactic. As a consequence discovering, composing, and mediating Web services remains a predominantly manual task.

A fundamental tenet of Service-Oriented Architectures is the notion of service registries for programmatic access and discovery of suitable services. Service publication has therefore been at the core of research and development in this area since the very beginning. The Universal Business Registry part of Universal Description Discovery and Integration (UDDI) [Hately et al., 2004] is perhaps the most well-known effort towards supporting the publication of services on the Web. On the basis of UDDI, large companies like SAP, IBM and Microsoft created a universal registry for enterprise services that could be accessed publicly but it did not gain enough adoption and it was discontinued in 2006 after five years of use.

One of the main reasons for the lack of success of UDDI was the fact that, although these registries are relatively complex, they do not support expressive queries [Pilioura and Tsalgatidou, 2009]. Another fundamental reason is the fact that, as we saw earlier, the work around services has essentially focussed on enterprises which have thus far been reluctant to publish their services on the Web. Today, Seekda.com provides one of the largest indexes of publicly available Web services which currently accounts for 28,500 Web services with their corresponding documentation. The number of services publicly available contrasts significantly with the billions of Web pages available, and interestingly is not significantly bigger than the 4,000 services estimated to be deployed internally within Verizon [Stollberg et al., 2007]. Other academic efforts in crawling and indexing Web services on the Web have found far lower numbers of services [Al-Masri and Mahmoud, 2008].

Web 2.0

The term Web 2.0, commonly attributed to OReilly [O’Reilly, 2005], was first defined on the basis of the technologies used, e.g., AJAX. More recently, however, it is increasingly used to account for the central role users play within these applications [Hendler and Golbeck, 2008, Chi, 2008]. Most successful Web 2.0 web sites are largely based on exploiting user-provided content and on the elicitation and use of the social networks created among them. For instance, Wikipedia and Flickr are largely based on content provided by their users in a rather altruistic manner. This new way of providing content is based on dropping the unnecessarily limiting distinction between providers and consumers, giving birth instead to what is often referred to as prosumers. Additionally, and thanks to the close integration of prosumers in the provisioning process, networks among users are elicited and exploited by sites such as Last.fm or Amazon to provide highly accurate recommendations.

Impelled by the Web 2.0 phenomenon, the world around services on the Web, thus far limited to “classical” Web services based on SOAP and WSDL, has significantly evolved with the proliferation of Web APIs, also called RESTful services [Richardson and Ruby, 2007] when they conform to the REST architectural style [Fielding, 2000]. This newer kind of services is characterised by the simplicity of the technology stack they build upon, i.e., URIs, HTTP, XML and JSON, and their natural suitability for the Web. Nowadays, an increasingly large quantity of Web sites offer (controlled) access to part of the data they hold through simple Web APIs, see for instance Flickr[1], Last.fm[2], and Facebook[3]. This trend towards opening access to previously closed data silos has generated a new wave of Web applications, called mashups, which obtain data from diverse Web sites and combine it to create novel solutions [Benslimane et al., 2008].

ProgrammableWeb.com, the most popular directory of Web APIs lists at the time of this writing lists 2,000 APIs and 4,800 mashups. This directory is based on the manual submission of APIs by users and currently provides simple search mechanisms based on keywords, tags, or a simple classification, none of which are particularly expressive. In fact, Web APIs are generally described using plain, unstructured HTML, except for a few that use the XML-based format WADL [Hadley, 2009]. As a consequence, and despite their popularity, discovering Web APIs or developing mashups that integrate disparate services in this manner suffers from a number of limitations similar to those we previously outlined for “classical” Web services, with an increased complexity since most often no machine-processable description is available. Discovering services, handling heterogeneous data, and creating service compositions are largely manual, tedious tasks which result in the development of custom tailored solutions on a case by case basis.

The Semantic Web and the Web of Data

The Semantic Web [Berners-Lee et al., 2001] can be an extension of the current human-readable Web, adding formal knowledge representation so that intelligent software can reason with the information in an automatic and flexible way. Semantic Web research has therefore largely focussed on defining languages and tools for representing knowledge in a way that can be shared, reused, combined, and processed over the Web. This research has led to a plethora of standards such as RDF(S) [Brickley and Guha, 2002], OWL [Patel-Schneider et al., 2004], as well as tools, e.g., ontology editors [Noy et al., 2001], RDF(S) storage systems [Broekstra et al., 2002] and reasoners [Haarslev and Mo¨ller, 2003], to name a few.

The Web of Data is a relatively recent effort derived from research on the Semantic Web, whose main objective is to generate a Web exposing and interlinking data previously enclosed within silos. The Web of Data is based upon four simple principles, known as the Linked Data principles, which essentially dictate that every piece of data should be given an HTTP URI which, when looked up, should offer useful information using standards like RDF and SPARQL [Bizer et al., 2009]. Additionally, data should be linked to other relevant resources therefore allowing humans and computers to discover additional information.

Since Linked Data principles were outlined in 2006, there has been a uptake most notably by the Linking Open Data project[4] through DBpedia [Auer, 2008] and ulterior additions of data about reviews [Heath and Motta, 2008], scientific information and geographical information, to name a few. Large companies like the BBC and governments from countries like the United Kingdom or the United States of America have also joined this initiative and are gradually releasing large amounts of data they have.

This outstanding growth of the Web of Data is urging researchers to devise means to exploit the valuable information it exposes. Among the main applications produced so far there are a number of data browsers that help people navigate through the data like Disco and Tabulator [Berners-Lee et al., 2007]. There are systems that crawl, index and provide intelligent search support over the Web of data like Sindice [Oren et al., 2008] and Watson [d’Aquin et al., 08]. And finally, there are a few domain-specific applications such as Revyu.com or DBPedia Mobile [Becker and Bizer, 2008] that provide domain-specific functionality by gathering and mashing up data. Although useful these applications hardly go beyond presenting together data gathered from different sources leaving the great potential of this massive data space unexploited. It is therefore becoming of crucial importance to devise ways in which smart applications that exploit the Web of Data could be systematically developed.

2.4        Semantic Web Services

Semantic Web services were initially proposed in order to pursue the vision of the semantic Web presented in [Berners-Lee et al., 2001] whereby intelligent agents would be able to exploit semantic descriptions in order to carry out complex tasks on behalf of humans. Early on, however, the research efforts focussed on combining Web services and semantic Web technologies so that tasks such as the discovery, negotiation, composition and invocation of services could have a higher level of automation.

The landscape of semantic Web services is characterized by a number of conceptual models that, despite a few common characteristics, remain essentially incompatible due to the different representation languages and expressivity utilized as well as because of conceptual differences. WSMO and OWL-S adopt a top-down view over services, covering the data models, behavioural aspects, nonfunctional properties, and supporting the definition of processes. The means for describing these are significantly different, though. In contrast, SAWSDL adopts a bottom-up approach and simply provides hooks for linking to particular ontologies and transformation definitions. In practice, the heterogeneity of the existing approaches has prevented their integration, leading to a significant fragmentation in the field and thus harming the adoption of SWS.

On the basis of the aforementioned conceptual models, many researchers have worked on enhancing service registries using semantic technologies, see for instance [Kawamura et al., 2004, Srinivasan et al., 2004], many of which have built upon UDDI. Despite demonstrating the advantages of semantic annotations in discovering services, particularly in terms of accuracy and in dealing with heterogeneous data models, SWS work has downplayed the additional complexity involved in creating semantic annotations for services. Consequently, the Web does not contain a significant body of service annotations: the largest public repository today is probably OPOSSum [Ku¨ster and K¨onig-Ries, 2008] which includes a test collection with approximately 2500 service annotations and provides programmatic access to its content solely through direct access to the database management system [Ku¨ster and K¨onig-Ries, 2008].

Regardless of the differences at the semantic level, the majority of the SWS initiatives are predicated upon the semantic enrichment of WSDL Web services and, as we saw earlier, these have turned out not to be prevalent on the Web. The Web services ecology has recently seen a major evolution with the advent and proliferation of Web APIs and RESTful services [Richardson and Ruby, 2007], and there has not been much progress on, or even concern with, means for providing structured descriptions and discovering these newer kinds of services. Only recently have researchers started focusing on Web APIs and RESTful services, the main examples being hRESTS/MicroWSMO [Kopecky´ et al., 2008, Maleshkova et al., 2009a] and SA-REST [Sheth, 2007].

Services and the Web of Data: An Unexploited Symbiosis

The advent of Web services and related technologies was quickly followed by considerable hype and grandiose expectations with respect to the impact Web services would have for enterprises and the economy in general. It was often assumed that Web services would ultimately lead to the creation of a servicebased economy over the Web. However, Web services are nowadays mostly used within controlled environments such as large enterprises rather than on the Web. One could argue that a reason for this lack of take up is the fact that Web services, despite their name, were not really thought for the Web [Vinoski, 2002]. In fact, the considerable complexity of the WS-* stack did hamper their adoption on the Web as recent practice, based instead on the use of simpler approaches such as Web APIs, shows. Another reason is however the fact that Web services have essentially targeted enterprises, which tend not to publicly publish Web services in any significant numbers.

Research on SWS has managed to alleviate some of the technical drawbacks of existing Web services technologies. Despite the advanced results obtained, none of the approaches devised thus far have gained widespread adoption for three main reasons. First and foremost, all SWS approaches have built upon Web services technologies that are not prevalent on the Web. Secondly, SWS add complex logics to an already complex WS-* stack. SWS require complex architectures, highly advanced reasoning machinery, and rich semantic annotations that, up until now, had to be provided mostly from scratch by highly trained IT staff. Finally, the existing dichotomy between the syntactic level and the semantic level requires devoting significant effort to providing transformation mechanisms between semantic and syntactic representations of information which add further need for manual labour and are highly sensitive to minor variations on data representation.

We believe that the advent of the Web of Data together with the rise of Web 2.0 technologies and social principles constitute the final necessary ingredients that will ultimately lead to a widespread adoption of services on the Web. In the remainder of this paper we shall refer to this new kind of services as Linked Services. The main reasons for this are the existing technical symbiosis between services, semantics, and the Web of Data [Pedrinaci et al., 2010a], as well as the rise of the prosumer and the global movement towards an open Web driven by the current unprecedented sharing of data and functionality openly on the Web.

On the one hand, from a technological perspective, the evolution of the Web of Data is highlighting the fact that light weight semantics yield significant benefits that justify the investment in annotating data and deploying the necessary machinery. This initiative is contributing to generate an outstanding body of knowledge (light weight ontologies and data expressed in their terms) that can help to significantly reduce the effort for creating semantic annotations for services. Furthermore, it also represents a significant use case for the application of services technologies on a Web scale in order to process this wealth of data which remains nowadays largely unexploited. On the other hand, from a socio-economic perspective, the recent evolution around Web 2.0 has shown that collaboration over the Web can lead to large quantities of very useful data with a low cost. Similarly, both Web 2.0 and more recently Linked Data technologies are encouraging enterprises and institutions to offer their data and services publicly at a previously unprecedented scale and pace. This new scenario provides in our view suitable technologies and data, as well as the necessary economic and social interest for the wide application of services technologies on a Web scale.

Linked Services

The vision toward the next wave of services – Linked Services – presented herein is based on two simple ideas: publishing service annotations in the Web of Data, and creating services for the Web of Data, i.e., services that process Linked Data and generate Linked Data. In a nutshell, Linked Services are services described as Linked Data. Therefore, these are service descriptions whereby their inputs and outputs, their functionality, and their non-functional properties are described in terms of (reused) light weight RDFS vocabularies and exposed following Linked Data principles. In fact, as such, Linked Services descriptions represent highly valuable information which is still to be provided in the Web of Data: data about reusable functionality on the Web. Secondly, by virtue of these descriptions, Linked Services are therefore services that, with appropriate infrastructure support, can consume RDF from the Web of Data, and, if necessary, can also generate additional RDF to be fed back to the Web of Data. In other words, Linked Services constitute a processing layer on top of the wealth of information currently available in the Web of Data which remains unexploited.

In the remainder of this paper we shall describe in more detail how this new wave can be supported and promoted technically, we explain which are the essential principles one needs to build upon and, where appropriate, we shall illustrate how our current research is taking us in this direction. Although in this section we present concrete technologies, the reader should note that the vision presented herein could perfectly be achieved by other means. The essential aspects are, however, the publication of service descriptions in the Web of Data for their discovery and reuse, and the provisioning of processing functionality on top Linked Data.

Services on the Web of Data

We previously called attention to the scarcity of publicly available Web services. We highlighted the lack of success of prior service registries on the Web as one of the reasons behind this, and highlighted several aspects that have hampered the adoption of UDDI as a suitable standard for service registries. We also pointed out the fragmentation currently affecting SWS research as well as the proliferation of Web APIs as a simpler and increasingly more popular alternative over “traditional” Web services.

Before any significant uptake of services can take place on the Web, proper mechanisms for creating, publishing and discovering services must be in place. In this respect, our previous review of the state of the art shows that:

  • Semantics are essential to reach a sufficient level of automation during the life-cycle of services,
  • finding an adequate trade-off between the expressivity of the service model used and the scalability from a computational and knowledge acquisition perspective is key for a wide adoption of service technologies,
  • the annotation of services should be simplified as much as possible, and “crowdsourcing” appears to be a particularly effective and cheap solution to this end,
  • on the Web, light weight ontologies together with the possibility to provide custom extensions prevail against more complex models,
  • any solution to deploying services that aspires to be widely adopted should build upon the various approaches and standards used on the Web, including Web APIs, RDF, and SPARQL,
  • Linked Data principles [Bizer et al., 2009] represent nowadays the best practice for publishing data on the Web both for human and machine consumption,
  • links between publicly available datasets are essential for the scalability and the value of the data exposed.

The principles we have just highlighted have an impact in a wide range of activities during the life-cycle of services. Notably, in the remainder of this section we shall tackle how Web services and Web APIs can be annotated, we shall describe how we can better support the annotation of services and finally we described how we are currently supporting the homogeneous publication and discovery of Web services and Web APIs on the Web using light weight semantics.

Annotation of WSDL Services with WSMO-Lite

W3C produced in 2007 the Semantic Annotations for WSDL and XML Schema specification [Farrell and Lausen, 2007], a minimal bottom-up approach to annotating services semantically which has gained further uptake than more ambitious solutions like OWL-S and WSMO. SAWSDL provides simple hooks for pointing to semantic descriptions from WSDL and XML elements. In particular, it supports three kinds of annotations, namely model reference, lifting schema mapping and lowering schema mapping which allow pointing to semantic elements described elsewhere on the Web, or to specifications of data transformations from a syntactic representation to the semantic counterpart and back respectively. SAWSDL does not advocate for a particular representation language for these documents nor does it provide any specific vocabulary that users should adopt.

WSMO-Lite [Vitvar et al., 2008] builds upon SAWSDL overcoming some of its limitations while remaining light weight. In a nutshell, WSMO-Lite provides a very simple RDFS ontology together with a methodology for expressing functional and nonfunctional semantics, and an information model for WSDL services based on SAWSDL model reference hooks. WSMO-Lite makes explicit the intended meaning for model reference annotations without modifying SAWSDL but rather informing users on how they should structure the models their annotations point to.

The WSMO-Lite ontology includes the means for specifying the functionality of a service with respect to a hierarchy of functional categories (e.g., eCl@ss [Hepp, 2006]) through the notion of Functional Classification Root. Additionally, it provides hooks for more advanced definition of non-functional properties as well as Conditions and Effects. The ontology is entirely expressed in RDF(S) and where the expressivity of RDFS is not sufficient (notably for expressing conditions and effects) other languages such as WSML [Fensel et al., 2007] and those produced by the W3C Rule Interchange Format Working Group[5] can be used.

Annotation of Web APIs with MicroWSMO

As we previously introduced, Web APIs and RESTful services are increasingly used on the Web. Therefore any approach to using services on the Web that would disregard them would be unnecessarily limiting. Annotating this kind of service does, however, bring additional complexity given that in most of the cases services are solely described through unstructured HTML pages aimed at humans.

MicroWSMO is a microformat-like[6] notation that forms the basis for our work on describing Web APIs [Kopecky´ et al., 2008, Maleshkova et al., 2009a]. MicroWSMO builds upon the hRESTS (HTML for RESTful services) microformat. hRESTS enables the creation of machine-processable Web API descriptions based on available HTML documentation [Kopecky´ et al., 2008]. As a microformat hRESTS provides a number of HTML classes that allow one to structure APIs descriptions by identifying services, operations, methods, inputs, outputs, and addresses. It therefore supports, by simple injections of HTML code within Web pages, to turn unstructured HTML-based descriptions of Web APIs into structured services descriptions similar to those provided by WSDL.

With the hRESTS structure in place, HTML service descriptions can be annotated further by including pointers to the semantics of the service, operations, and data manipulated. To this end MicroWSMO extends hRESTS with three additional properties, namely model, lifting and lowering that are taken from SAWSDL and have the same semantics. MicroWSMO also adopts WSMO-Lite as the reference ontology for annotating RESTful services semantically.

Supporting Services Annotation

Arguably, one of the main limitations of previous approaches to integrating services in the Semantic Web, has been the difficulty from an annotation perspective. SWS approaches like WSMO and OWL-S, mostly focussed on devising highly expressive frameworks able to capture formally the semantics of services in a considerable detail, overlooked the bottleneck they were introducing with respect to the annotation of services. Indeed, the creation of SWS based on these frameworks requires a significant manual labour devoted to devising domain models, taxonomies, orchestrations, and other rules that can only be created at a slow pace by highly trained IT personnel.

Some effort has been devoted by previous research toward the automation of service annotation, notably [Heß et al., 2004] and [Sabou, 2006]. However, although useful, the support provided still needs to be complemented with substantial manual editing, the creation of ontologies and rules. The use of light weight ontologies as opposed to highly expressive conceptual models reduces considerably the effort involved and the amount of annotations to be provided. Additionally, and more importantly, the Web of Data is significantly changing the environment from an annotation and usage point of view.

On the one hand, the wide range of ontologies and semantic data publicly available on the Web is an increasingly valuable source of knowledge. The Web of Data can be used as background knowledge [d’Aquin et al., 08] in order to provide suitable ontologies that can be used, extended, and combined to create domain ontologies for annotating services in an easier manner as highlighted in [Maleshkova et al., 2009b]. Furthermore, the existence of increasingly large quantities of information expressed in terms of ontologies can effectively be exploited to support the identification of the domain of a service based for instance on its documentation as well as it can, for instance, support the matching of ontologies when creating new domain models or when integrating different services [Sabou et al., 2008].

On the other hand, generating service annotations by reusing existing ontologies directly contributes to increasing services usability and presumably their uptake. For instance services may be classified with respect to well-known service classifications such as the previously mentioned eCl@ss ontology, better supporting their discovery by software and humans aware of that particular ontology. Furthermore, annotating services inputs and outputs with respect to existing vocabularies ensures the direct applicability of services over data already available as well as it allows Linked Data application developers to carry out data driven discovery of services by simply checking the input and output types of services. From a more abstract perspective, this process ensures that services modeled in this way are linked to the Web of Data as encouraged by Linked Data principles. Finally, Web 2.0 applications have highlighted the advantages that the social side of the Web can bring when a significant body of users and data has been gathered [Hendler and Golbeck, 2008]. The same way we can exploit the growing body of knowledge generated by the Semantic Web, we expect that as the number of service annotations grow, we would also be able to exploit them in order to contribute to the overall annotation process by i) ranking the domain models with respect to their popularity thus indirectly contributing to increasing services compatibility; and ii) by refining the identification of the domain of a service based on prior decisions by other users.

We are devoting significant efforts to creating tools that support users in the annotation of services based on the principles introduced above. One such application is SWEET [Maleshkova et al., 2009b] which is, to the best of our knowledge, the first tool that enables the creation of semantic annotations for Web APIs and RESTful services. SWEET provides user support for creating hRESTS/MicroWSMO annotations over any HTML page describing Web APIs, therefore supporting a non-intrusive incremental annotation of existing resources. The tool, assisted by Watson [d’Aquin et al., 08], supports users in browsing the Semantic Web while annotating services so that they can identify suitable vocabularies such as FOAF [Brickley and Miller, 2007], and use them for the annotation. A tool called SOWER, based on the same principles but focussing on the annotation of WSDL services, has also been developed. Currently, the social aspects are not exploited by these tools since it is first necessary to gather a significant body of service annotations.

Homogeneous Publication and Discovery of Services on the Web of Data

Syntactic and semantic descriptions of Web services aim at providing information about services in a way that can automatically be processed by machines. However, at present, these descriptions can only be retrieved through the Web of documents, which is essentially designed for human beings, or through specific interfaces to registries such as UDDI that have failed to gain significant uptake.

A fundamental step for bringing services closer to the Web is their publication based on current best practices. We view service annotations as a particular kind of highly valuable data: data that informs us about existing reusable functionality exposed somewhere on the Web that processes and/or generates data. As such, services should therefore be published on the Web according to current best practices for publishing data – the Linked Data principles – so that applications can easily discover and process their descriptions on the basis of the very same technologies they use for retrieving data.

In order to explore and validate these principles we have developed iServe [Pedrinaci et al., 2010b], a public platform that unifies service publication and discovery on the Web through the use of light weight semantics. iServe builds upon lessons learnt from research and development on the Web and on service discovery algorithms to provide a generic semantic service registry able to support advanced discovery over different kinds of services described using heterogeneous formalisms. The registry is, to the best of our knowledge, the first system able to homogeneously publish and provide advanced discovery support for SWS expressed in several formalisms. It is also the first one to provide advanced discovery over Web APIs and Web services homogeneously.

In the remainder of this section we first outline the conceptual model iServe builds upon and we then present the overall approach implemented by the platform in order to support the homogeneous publication and discovery of services.

Minimal Service Model

In order to publish services on the Web of Data it is necessary to provide a common vocabulary based on existing Web standards able to describe services in a way that allows machines to automatically locate and filter services according to their functionality or the data they handle, and to appropriately support their automated invocation. Additionally, as opposed to most SWS research to date, it is of utmost importance to support the annotation of both “classical” WSDL Web services, as well as the increasing number of Web APIs and RESTful services which appear to be preferred on the Web.

To this end our research is based on the Minimal Service Model (MSM), originally introduced together with hRESTS [Kopecky´ et al., 2008] and WSMOLite [Vitvar et al., 2008], and slightly modified for the purposes of this work. The MSM, driven by Semantic Web best practices, builds upon existing vocabularies, namely SAWSDL, WSMO-Lite and hRESTS, depicted in Figure 1 with the sawsdl, wl, and rest namespaces respectively. In a nutshell, the MSM is a simple RDF(S) integration ontology based on the principle of minimal ontological commitment; it captures the maximum common denominator between existing conceptual models for services. Thus, the MSM does not aim to be yet another service model to bring further heterogeneity to the SWS landscape; it is instead an integration model at the intersection of existing formalisms, able to capture the core semantics of both Web services and Web APIs in a common model, homogeneously supporting publication and discovery. Still, the MSM is devised in a way such that framework-specific extensions can remain attached, to the benefit of clients able to comprehend and exploit those formalisms.

The MSM, denoted by the msm namespace in Figure 1, defines Services which have a number of Operations. Operations in turn have input, output and fault MessageContent descriptions. MessageContent may be composed of mandatory or optional MessageParts[7]. The intent of the message part mechanism is to support finer-grained input/output discovery, as available in SAWSDL, OWL-S and WSMO, especially including support for optional parts.

Minimum Service Model

Figure 1: Minimal Service Model.

SWS frameworks [Sheth, 2003, Vitvar et al., 2008] thus far have provided support for semantically describing different subsets of the following aspects of services:

  • Functional semantics defines service functionality, that is, the function a service offers to its clients when it is invoked. This information is of particular relevance when finding services and when composing them.
  • Nonfunctional semantics defines any specific details concerning the implementation or running environment of a service, such as its price or quality of service. Nonfunctional semantics provide additional information about services that can help rank and select the most appropriate one.
  • Behavioural semantics specifies the protocol (i.e., ordering of operations) that a client needs to follow when invoking a service.
  • Information model defines the semantics of input, output, and fault messages.

To attach these semantics to the service model, we adopt the RDF mapping of SAWSDL introduces earlier, which defines three kinds of annotations over WSDL and XML Schema, namely model reference, lifting schema mapping, and lowering schema mapping. The schema mapping annotations provide grounding from the service’s Information Model to the concrete on-the-wire messages, whereas the model references can be used for pointing to ontologies covering functional semantics, nonfunctional semantics , behavioural semantics and the information model.

The WSMO-Lite vocabulary [Vitvar et al., 2008] completes the MSM by providing classes for significantly describing the above four aspects of service semantics and by supplying type information to the generic model references. In particular, WSMO-Lite captures nonfunctional semantics through the concept of Nonfunctional Parameter, and functional semantics via the concepts

Condition, Effect, and Functional Classification Root. The reader may note that WSMO does not have direct support for functional classifications; still, the majority of discovery engines for WSMO have indirectly applied the notion of classifications through hierarchies of Web Services or Goals (e.g. in [Stollberg et al., 2007, Domingue et al., 2008]).

Behavioural semantics are likely the biggest source of heterogeneity between SWS frameworks; SAWSDL even omits this aspect altogether. We therefore do not prescribe any particular approach to describing behavioural semantics of services and defer this instead to specific applications and frameworks. Thanks to its simplicity, the MSM captures the essence of services in a way that can support service matchmaking and invocation, while remaining largely compatible with WSMO-based descriptions of Web services, with OWL-S services, and with services annotated according to SAWSDL, WSMO-Lite, and MicroWSMO.

iServe: a Linked Services Publishing and Discovery Platform

iServe uses as its core conceptual model the MSM and it currently includes a number of import mechanisms able to deal with WSDL files including SAWSDL annotations, with descriptions adopting the WSMO-Lite specific extensions, with MicroWSMO annotations of Web APIs as well as with OWL-S service descriptions. These import mechanisms transform the service descriptions into the appropriate terms according to the MSM. Additionally, iServe automatically generates rdfs:definedBy links – pointing to the definition file in case additional information is required – and rdfs:seeAlso links – pointing to documentation.

Once imported, iServe publishes the semantic annotations of services as Linked Data. Thus every service is assigned a resolvable HTTP URI, through which, humans and machines can access the service descriptions in HTML or in RDF using content negotiation. The registry additionally provides a SPARQL endpoint allowing advanced querying over the services annotations, as well as a read and write RESTful API so that services can easily be retrieved and published from remote applications. The RESTful API is completed with a number of semantic discovery methods that provide more refined discovery than that supported directly via SPARQL, by exploiting the semantic descriptions of services, RDFS inferencing, and similarity measures for more accurate results.

iServe architecture

Figure 2: High-level architecture of iServe.

On top of iServe’s RESTful API, the registry is complemented by a crawler. Currently it has only been used for targeted import for there are not many SWS descriptions available on the Web. At the time of this writing, iServe registers about 2000 SWS coming from the OWL-S test collection[8] and the SAWSDL test collection[9], 50 services coming from the Jena Geography Dataset[10] annotated manually for evaluation purposes, a test import of around 30 services indexed by Seekda.com, and around 20 real services annotated in the context of the use cases of the EU projects SOA4All and NoTube. The current implementation already shows how Web services and Web APIs can be described by means of an homogeneous conceptual model – the Minimal Service Model – and how they can be published as Linked Data, therefore better promoting their discovery based on the use of the well established and adopted Linked Data principles.

Services for the Web of Data

The notion of services as well-defined, independent, invokable and distributed pieces of functionality is indeed a very powerful architectural notion for developing distributed systems. Providing functionality in this way independently from the underlying technology provides the capacity for maintaining a loose coupling between integrated components which, when it comes to an environment like the Web, appears as a highly beneficial (if not necessary) feature. Services, may they be traditional Web services or RESTful services, provide therefore a suitable architectural abstraction for the integration of processing capabilities over the Web of Data in a loosely coupled manner. In the remainder of this section we shall cover what services can provide to the Web of Data both as a means for providing new sources of data as well as for processing existing assertions.

Integrating Legacy Systems

Currently a good part of the Web of Data is generated from existing databases by using tools such as D2R [Bizer et al., 2009]. Indeed, this allows exposing large amounts of data which would otherwise remain private or, in the best case, offered through means that are not that convenient for automated processing. In other cases data is already stored in RDF and can be exposed easily[11]. There is, however, a large body of information owned by companies which are either not interested in offering the information publicly on the Web given its commercial value and/or its sensitivity, or because they do not have the technical skills or interest in exposing the information as Linked Data. Similarly, there is a growing number of streams of data provided by sensors through highly heterogeneous formats and interfaces, which exhibits considerable integration and processing limitations [Sheth et al., 2008].

Web 2.0 developers have long realised the value of Web APIs for accessing highly valuable data on demand. Additionally, Semantic Web researchers have acknowledged the benefit that could be brought by adapting or wrapping these additional sources of information like Web APIs and sensors, so that they can be turned into Linked Data producers, see for instance [Sheth et al., 2008, Sequeda and Corcho, 2009] and the Flickr Wrappr[12]. To a certain extent, the work on sensors is more advanced since there already exists proposals for exposing sensors observations as Linked Data [Page et al., 2009]. The work around exposing Web APIs as Linked Data is, however, more an art than a science due to the lack of standard description languages and the extreme heterogeneity characterising Web APIs.

We previously highlighted that Linked Services are such that their inputs and outputs are RDF. As a consequence, they represent a natural means for exposing as Linked Data valuable information previously enclosed within silos, through the annotation of existing Web APIs and WSDL services. Web APIs could in this way be invoked by interpreting their semantic annotations (see Section 4.2), and RDF information could be obtained on demand. In this way, data from legacy systems, state of the art Web 2.0 sites, or sensors, which do not embrace Linked Data principles could be made available as Linked Data easily.

This approach is explored in the context of several use cases from European projects such as SOA4All [Davies et al., 09] and NoTube [Qing et al., 2010]. Our current experience, although preliminary at this stage, shows already the applicability and potential of bringing legacy systems to the Web of Data in this manner. Indeed proper care should be taken in order to ensure that Linked Data principles are followed in these cases (see Section 2.3). We anticipate, however, that at least for services strictly adhering to REST principles this should be relatively straight-forward since they should already define URIs for the resources and offer convenient means for exposing and exploring them.

Processing Linked Data

Integration and fusion of disparate data coming from the Web of Data hardly takes place nowadays and therefore applications do not perform any ulterior processing of this data other than for presenting it to the user [Bizer et al., 2009]. Generating new data based on what has been found or the provisioning of addedvalue services that exploit this data thus remains a pending issue. For instance, something as simple and useful as a unit transformation service is still to be provided for the Web of Data. To a certain extent this is natural since the Web of Data is precisely about data; and storing an RDF triple per possible transformation result would simply be absurd since there are infinite possibilities. There is, however, a clear need for enabling the processing of Linked Data in ways such that application developers could conveniently apply them over data gathered at runtime to carry out computations as simple as unit transformations, more complex as deriving similarities between products or services based on the reviews published by users on Revyu.com, or even more advanced as envisioned for the Semantic Web [Berners-Lee et al., 2001].

The Web of Data provides large amounts of machine-processable data ready to be exploited and, as we saw earlier, services provide a suitable abstraction for encapsulating functionality as platform and language independent reusable software. It therefore seems natural to approach the development of systems that process Linked Data by composing Linked Services. These services should be able to consume RDF data (either natively or via lowering mechanisms), carry out the concrete activity they are responsible for (e.g., unit conversion), and return the result, if any, in RDF as well. The invoking system could then store the result obtained or continue with the activity it is carrying out using these newly obtained RDF triples combined with additional sources of data. In a sense this is quite similar to the notion of service mashups [Benslimane et al., 2008] and RDF mashups [Phuoc et al., 2009] with the important difference that services are, in this case, RDF-aware and their functionality may range from RDF-specific manipulation functionality up to highly complex processing beyond data fusion. The use of services as the core abstraction for constructing Linked Data applications is therefore more generally applicable than that of current data integration oriented mashup solutions.

It is worth noting in this respect the benefit brought by having services annotations available on the cloud as we saw earlier. When developing applications that process Linked Data, discovering useful services could be driven by the data that needs to be manipulated. For instance, developers could easily discover services that manipulate a concrete kind of data or those that produce a certain type by sending SPARQL queries to service registries like iServe [Pedrinaci et al., 2010b], or using advanced semantic discovery mechanisms. And, as opposed to traditional Web services repositories like UDDI-based ones, developers would benefit from the existence of semantic annotations in order to filter them based on the semantics of inputs, outputs, their classification with respect to well-known taxonomies, etc. The reuse of ontologies and vocabularies would in turn contribute towards increasing the compatibility of services. In this way, Linked Data application developers would have access to an ever growing body of reusable components ready to be combined and exploited.

The Services Ecosystem

Integrating services with the Web of Data as depicted before would give birth to a services ecosystem on top of Linked Data, whereby people would be able to collaboratively and incrementally construct complex systems by reusing the results of others, gradually taking us closer to the ambitious vision initially presented for the Semantic Web. In this process, we anticipate that two main families of services will emerge depending on whether they are domain-independent or not.

On the one hand, task-specific yet domain-independent services will allow developers to perform some of the typical tasks involved when processing Linked Data. These activities range from relatively basic activities such as transforming data between different schemas to more complex actions such as determining how trust-worthy a piece of data is or even, eventually, to carry out knowledge intensive tasks, e.g., Parametric Design or Diagnosis [Schreiber et al., 1999]. These domain-independent services which are already starting to appear (for example, [Euzenat, 2004]) can in fact be seen from a Knowledge Engineering perspective as a new generation of Problem-Solving Methods (PSM) adapted to the Web as some researchers already start considering [van Harmelen et al., 2009].

This new family of PSMs for the Web of Data will, however, require adapting prior techniques to the new environment, notably with respect to the location, size, and quality of the data to be manipulated. In fact, traditional PSMs were applied within closed environments often with small amounts of manually curated data, whereas in this new scenario data would be obtained automatically from the Web for automated processing, and it would therefore have to be validated, fused, cleaned, and filtered prior to any execution since this would otherwise yield execution errors or incorrect results. We expect that a good deal of domain-independent services will precisely be devoted to performing these tasks. For instance entity resolution, ontology alignment, data cleansing, data fusion, provenance analysis, and trust analysis are some of the domain-independent services that we anticipate would be necessary to develop for the Web of Data. As a side effect, though, it is likely that data quality in the Web of Data will increase as software matures, and especially as it starts being processed by applications which would indirectly detect inconsistencies and incorrect data.

On the other hand, we refer as domain-dependent services to those abstracted away from the technicalities and specificities of Linked Data and generic tasks. This kind of services will be for example those directly providing access to traditional systems in order to obtain some data and carry out actions like sending an SMS or booking a hotel. These services will only be relevant for a particular domain, e.g., hotel services, and will mostly be populated by services directly addressing end-users and therefore better showcasing the potential of the Semantic Web from an end-user perspective. It is worth noting, however, that a wide proliferation of advanced domain-specific solutions for end-users will only occur when a sufficient set of stable domain-independent services able to solve complex tasks will be available. For instance, cross organisational business integration would most likely have to build upon on advanced ontology alignment support for transforming data between different schemas [Jung, 2009]. The systematic development of these applications in a sustainable, efficient, and robust manner shall only be achieved through reuse, and services are a particularly suitable abstraction to carry this out on a Web scale.

6        Conclusions and Outlook

Despite the appealing characteristics of service-orientation principles and technologies, their uptake on a Web-scale has been significantly less prominent than initially anticipated. This limited adoption is due to a number of issues of both socio-economic and technical nature. From a socio-economic perspective service orientation has for the most part targeted enterprises which, thus far, have been reluctant to publish functionality of the Web. From a technical perspective, service technologies have exhibited a limited level of support for automating activities such as service discovery and composition. SWS have managed to overcome some of the technical limitations of Web services but have in turn introduced additional complexity and overheads. Consequently, SWS have not gained any significant adoption either.

In parallel, the Web is witnessing a dramatic evolution with the advent of Web 2.0 and Linked Data technologies. Web 2.0 has triggered a socialisation of the Web which has placed individuals at the centre of the Web and is widely based on somewhat altruistic contributions of free data and manual labour from users. The Linked Data initiative is in turn devoted to creating what is referred to as the Web of Data, which already provides publicly large amounts of interconnected data concerning a wide range of domains described in terms of light weight ontologies for supporting automated processing.

We have argued that the advent of the Web of Data together with the rise of Web 2.0 technologies and social principles constitute the final necessary ingredients that will give birth to a new wave of services on the Web, which we refer to as Linked Services. We have explored the relationship between services and the Web of Data. In particular we have highlighted that Linked Data represent appropriate principles for publishing services on the Web. We have illustrated how Web services and RESTful services can be brought into the Web of Data by means of simple RDF vocabularies and supporting tools. We have highlighted the fact that the current evolution of the Web of Data is gathering the necessary motivation for the development of advanced applications that process Linked Data. We have outlined that Linked Services are particularly well-suited for supporting developers in creating applications that process Linked Data. We have discussed how the evolution towards more complex Linked Data applications could be supported and we have identified the need for making publicly available domain-independent services that carry out common tasks such Data Cleansing or Trust Analysis [Jung, 2010].

The overall vision outlined herein represents the roadmap for the research we are currently carrying out trying to expand the capabilities of the Linked Data applications as well as trying to promote and support the use of services on the Web through light weight semantic annotations. This research, like the principles it builds upon, will strive to provide data, resources, tools and engines publicly on the Web in order to eventually lead to the wider uptake of services on a Web scale.

References

[Andrews et al., 2003] Andrews, T., Curbera, F., Dholakia, H., Goland, Y., Klein, J., Leymann, F., Liu, K., Roller, D., Smith, D., Thatte, S., Trickovic, I., and Weerawarana, S.: Business Process Execution Language for Web Services Version 1.1; http://www-128.ibm.com/developerworks/library/specification/wsbpel/, May 2003.

[Auer, 2008] Auer, S., Kobilarov, C. B. G., Lehmann, J., Cyganiak, R., and Ives, Z.: DBpedia: A Nucleus for a Web of Open Data; In Proceedings of 6th International Semantic Web Conference, 2nd Asian Semantic Web Conference (ISWC+ASWC 2007), pages 722–735. November 2008.

[Al-Masri and Mahmoud, 2008] Al-Masri, E. and Mahmoud, Q.: Investigating Web Services on the World Wide Web; In 17th International World Wide Web Conference, pages 795–804, 2008.

[Becker and Bizer, 2008] Becker, C. and Bizer, C.: DBpedia Mobile: A LocationEnabled Linked Data Browser; In Linked Data on the Web (LDOW2008), 2008.

[Benslimane et al., 2008] Benslimane, D., Dustdar, S., and Sheth, A.: Services Mashups: The New Generation of Web Applications; IEEE Internet Computing, 12(5):13–15, 2008.

[Brickley and Guha, 2002] Brickley, D. and Guha, R. V.: RDF Vocabulary Description Language 1.0: RDF Schema;, 2002 http://www.w3.org/TR/rdf-schema.

[Bizer et al., 2009] Bizer, C., Heath, T., and Berners-Lee, T.: Linked Data – The Story So Far; International Journal on Semantic Web and Information Systems (IJSWIS), 2009.

[Broekstra et al., 2002] Broekstra, J., Kampman, A., and van Harmelen, F.: Sesame: A Generic Architecture for Storing and Querying RDF and RDF Schema; International Semantic Web Conference (ISWC 2002), 2002.

[Berners-Lee et al., 2001] Berners-Lee, T., Hendler, J., and Lassila, O.: The Semantic Web; Scientific American, (5):34–43, May 2001.

[Berners-Lee et al., 2007] Berners-Lee, T., Hollenbach, J., Lu, K., Presbrey, J., d’ommeaux, E. P., and m.c. schraefel: Tabulator redux: Writing into the semantic web; 2007.

[Brickley and Miller, 2007] Brickley, D. and Miller, L.: FOAF Vocabulary Specification 0.91; http://xmlns.com/foaf/spec/, November 2007.

[Chi, 2008] Chi, E.: The Social Web: Research and Opportunities; Computer, 41(9):88 – 91, Sep 2008.

[Domingue et al., 2008] Domingue, J., Cabral, L., Galizia, S., Tanasescu, V., Gugliotta, A., Norton, B., and Pedrinaci, C.: IRS-III: A Broker-based Approach to Semantic Web Services; Web Semantics: Science, Services and Agents on the World Wide Web, 6(2):109–132, 2008.

[Davies et al., 09] Davies, J., Domingue, J., Pedrinaci, C., Fensel, D., GonzalezCabero, R., Potter, M., Richardson, M., and Stincic, S.: Towards the Open Service Web; BT Technology Journal, 26(2), 2009.

[d’Aquin et al., 08] d’Aquin, M., Motta, E., Sabou, M., Angeletou, S., Gridinoc, L., Lopez, V., and Guidi, D.: Toward a New Generation of Semantic Web Applications; IEEE Intelligent Systems, 23(3):20–28, 2008.

[Erl, 2007] Erl, T.: SOA Principles of Service Design The Prentice Hall ServiceOriented Computing Series. Prentice Hall, July 2007.

[Euzenat, 2004] Euzenat, J.: An API for ontology alignment; In 3rd conference on International Semantic Web Conference (ISWC), 2004.

[Fielding, 2000] Fielding, R. T.: Architectural Styles and the Design of Network-based Software Architectures PhD thesis, University of California, Irvine, 2000.

[Farrell and Lausen, 2007] Farrell, J. and Lausen, H.: Semantic Annotations for WSDL and XML Schema (SAWSDL); Recommendation, W3C, August 2007.

[Fensel et al., 2007] Fensel, D., Lausen, H., Polleres, A., de Bruijn, J., Stollberg, M., Roman, D., and Domingue, J.: Enabling Semantic Web Services: The Web Service Modeling Ontology Springer, 2007.

[Hadley, 2009] Hadley, M.: Web Application Description Language; Member submission, W3C, August 2009.

[Hepp, 2006] Hepp, M.: Products and Services Ontologies: A Methodology for Deriving OWL Ontologies from Industrial Categorization Standards; International Journal on Semantic Web and Information Systems (IJSWIS), 2(1):72–99, 2006.

[Hendler and Golbeck, 2008] Hendler, J. and Golbeck, J.: Metcalfe’s law, Web 2.0, and the Semantic Web; Web Semantics: Science, Services and Agents on the World Wide Web, Jan 2008.

[Heß et al., 2004] Heß, A., Johnston, E., and Kushmerick, N.: ASSAM: A Tool for Semi-automatically Annotating Semantic Web Services; In McIlraith et al. [McIlraith et al., 2004], pages 320–334.

[Haarslev and Möller, 2003] Haarslev, V. and Möller, R.: Racer: A Core Inference Engine for the Semantic Web; In Second International Semantic Web Conference ISWC 2003, Florida, October 2003.

[Heath and Motta, 2008] Heath, T. and Motta, E.: Revyu: Linking reviews and ratings into the Web of Data; Web Semantics: Science, Services and Agents on the World Wide Web, 6(4):266–273, 2008.

[Hately et al., 2004] Hately, L. C. A., von Riegen, C., and Rogers, T.: UDDI Specification Version 3.0.2; Technical report, OASIS, 2004.

[Jung, 2008] Jung, J. J.: Query transformation based on semantic centrality in semantic social network; Journal of Universal Computer Science, 14(7):1031–1047, 2008.

[Jung, 2009] Jung, J. J.: Semantic Business Process Integration based on Ontology Alignment; Expert Syst. Appl., 36(8):11013–11020, 2009.

[Jung, 2010] Jung, J. J.: Reusing Ontology Mappings for Query Segmentation and Routing in Semantic Peer-to-Peer Environment; Information Sciences, 180(17):3248–3257, 2010.

[Kawamura et al., 2004] Kawamura, T., Blasio, J.-A. D., Hasegawa, T., Paolucci, M., and Sycara, K. P.: Public Deployment of Semantic Service Matchmaker with UDDI Business Registry; In McIlraith et al. [McIlraith et al., 2004], pages 752–766.

[Kopecky´ et al., 2008] Kopeck´y, J., Gomadam, K., and Vitvar, T.: hRESTS: an HTML Microformat for Describing RESTful Web Services; In The 2008 IEEE/WIC/ACM International Conference on Web Intelligence (WI2008), Sydney, Australia, November 2008. IEEE CS Press.

[Küster and König-Ries, 2008] Küster, U. and König-Ries, B.: Towards Standard Test Collections for the Empirical Evaluation of Semantic Web Service Approaches; Int. J. Semantic Computing, 2(3):381–402, 2008.

[Martin et al., 2004] Martin, D., Burstein, M., Hobbs, J., Lassila, O., McDermott, D., McIlraith, S., Narayanan, S., Paolucci, M., Parsia, B., Payne, T., Sirin, E., Srinivasan, N., and Sycara, K.: OWL-S: Semantic Markup for Web Services; Member submission, W3C, 2004 W3C Member Submission 22 November 2004.

[Maleshkova et al., 2009a] Maleshkova, M., Kopecky´, J., and Pedrinaci, C.: Adapting SAWSDL for Semantic Annotations of RESTful Services; In Workshop: Beyond SAWSDL at OnTheMove Federated Conferences & Workshops, 2009.

[Maleshkova et al., 2009b] Maleshkova, M., Pedrinaci, C., and Domingue, J.: Supporting the Creation of Semantic RESTful Service Descriptions; In Workshop: Service Matchmaking and Resource Retrieval in the Semantic Web (SMR2) at 8th International Semantic Web Conference, 2009.

[McIlraith et al., 2004] McIlraith, S. A., Plexousakis, D., and van Harmelen, F., editors The Semantic Web – ISWC 2004: Third International Semantic Web Conference,Hiroshima, Japan, November 7-11, 2004. Proceedings, volume 3298 of Lecture Notes in Computer Science. Springer, 2004.

[McIlraith et al., 2001] McIlraith, S., Son, T., and Zeng, H.: Semantic web services; Intelligent Systems, IEEE, 16(2):46 – 53, Jan 2001.

[Noy et al., 2001] Noy, N. F., Sintek, M., Decker, S., Crub´ezy, M., Fergerson, R. W., and Musen, M. A.: Creating Semantic Web Contents with Protégé-2000; IEEE Intelligent Systems, 2(16):60–71, March/April 2001.

[Oren et al., 2008] Oren, E., Delbru, R., Catasta, M., Cyganiak, R., Stenzhorn, H., and Tummarello, G.: Sindice.com: a Document-oriented Lookup Index for Open Linked Data; IJMSO, 3(1):37–52, 2008.

[O’Reilly, 2005] O’Reilly, T.: What Is Web 2.0: Design Patterns and Business Models for the Next Generation of Software; http://oreilly.com/web2/archive/what-isweb-20.html, 2005.

[Pedrinaci et al., 2010a] Pedrinaci, C., Domingue, J., and Krummenacher, R.: Services and the Web of Data: An Unexploited Symbiosis; In Linked AI: AAAI Spring Symposium ”Linked Data Meets Artificial Intelligence”, 2010 Accepted for publication.

[Pedrinaci et al., 2010b] Pedrinaci, C., Liu, D., Maleshkova, M., Lambert, D., Kopecky´, J., and Domingue, J.: iServe: a Linked Services Publishing Platform; In Proceedings of Ontology Repositories and Editors for the Semantic Web at 7th ESWC, 2010.

[Phuoc et al., 2009] Phuoc, D. L., Polleres, A., Hauswirth, M., Tummarello, G., and Morbidoni, C.: Rapid Prototyping of Semantic Mash-ups Through Semantic Web Pipes; In Quemada, J., Leo´n, G., Maarek, Y. S., and Nejdl, W., editors, WWW, pages 581–590. ACM, 2009.

[Page et al., 2009] Page, K., Roure, D. D., Martinez, K., Sadler, J., and Kit, O.: Linked Sensor Data: RESTfully serving RDF and GML; In 2nd International Workshop on Semantic Sensor Networks (SSN09), collocated with the 8th International Semantic Web Conference (ISWC-2009), 2009.

[Patel-Schneider et al., 2004] Patel-Schneider, P. F., Hayes, P., and Horrocks, I.: OWL Web Ontology Language Semantics and Abstract Syntax; http://www.w3.org/TR/owl-semantics/, February 2004 Last Visited: March 2005.

[Pilioura and Tsalgatidou, 2009] Pilioura, T. and Tsalgatidou, A.: Unified Publication and Discovery of Semantic Web Services; ACM Trans. Web, 3(3):1–44, 2009.

[Qing et al., 2010] Qing, H., Benn, N., Dietze, S., Siebes, R., Pedrinaci, C., Liu, D., Lambert, D., and Domingue, J.: Two-staged Approach for Semantically Annotating and Brokering TV-related Services; In The IEEE International Conference on Web Services (ICWS), 2010.

[Richardson and Ruby, 2007] Richardson, L. and Ruby, S.: RESTful Web Services O’Reilly Media, Inc., May 2007.

[Schreiber et al., 1999] Schreiber, G., Akkermans, H., Anjewierden, A., de Hoog, R., Shadbolt, N., de Velde, W. V., and Wielinga, B.: Knowledge Engineering and Management: The CommonKADS Methodology MIT Press, 1999.

[Sabou, 2006] Sabou, M.: Building Web Service Ontologies PhD thesis, Vrije Universiteit Amsterdam, 2006.

[Sequeda and Corcho, 2009] Sequeda, J. and Corcho, O.: Linked Stream Data: A Position Paper; In 2nd International Workshop on Semantic Sensor Networks (SSN09), collocated with the 8th International Semantic Web Conference (ISWC2009), 2009.

[Sabou et al., 2008] Sabou, M., d’Aquin, M., and Motta, E.: Exploring the Semantic Web as Background Knowledge for Ontology Matching; Journal of Data Semantics, (Accepted for publication) 2008.

[Sheth, 2003] Sheth, A.: Semantic Web Process Lifecycle: Role of Semantics in Annotation, Discovery, Composition and Orchestration; Invited Talk at WWW 2003 Workshop on E-Services and the Semantic Web, May 2003.

[Sheth, 2007] Sheth, A.: Beyond SAWSDL: A Game Plan for Broader Adoption of Semantic Web Services; IEEE Intelligent Systems Trends & Controversies, 22(6), November–December 2007.

[Stollberg et al., 2007] Stollberg, M., Hepp, M., and Hoffmann, J.: A Caching Mechanism for Semantic Web Service Discovery; In 6th International and 2nd Asian Semantic Web Conference (ISWC2007+ASWC2007), pages 477–490, November 2007.

[Sheth et al., 2008] Sheth, A., Henson, C., and Sahoo, S.: Semantic Sensor Web; Internet Computing, IEEE, 12(4):78–83, 2008.

[Srinivasan et al., 2004] Srinivasan, N., Paolucci, M., and Sycara, K.: Adding OWL-S to UDDI: Implementation and throughput; In Proceedings of 1st International Conference on Semantic Web Services and Web Process Composition (SWSWPC 2004), 2004.

[van Harmelen et al., 2009] van Harmelen, F., ten Teije, A., and Wache, H.: Knowledge Engineering Rediscovered: Towards Reasoning Patterns for the Semantic Web; In K-CAP ’09: Proceedings of the fifth international conference on Knowledge capture, pages 81–88, New York, NY, USA, 2009. ACM.

[Vinoski, 2002] Vinoski, S.: Putting the “Web” into Web Services: Interaction Models, Part 2; IEEE Internet Computing, 6(4):90–92, 2002.

[Vitvar et al., 2008] Vitvar, T., Kopecky, J., Viskova, J., and Fensel, D.: WSMO-Lite Annotations for Web Services; In Hauswirth, M., Koubarakis, M., and Bechhofer, S., editors, Proceedings of the 5th European Semantic Web Conference, LNCS, Berlin, Heidelberg, June 2008. Springer Verlag.

[1] See http://www.flickr.com/services/api/

[2] See http://www.last.fm/api

[3] See http://developers.facebook.com/docs/

[4] See http://linkeddata.org/

[5] See http://www.w3.org/2005/rules/wiki/RIF Working Group

[6] See http://www.microformats.org

[7] The addition of message parts is a small extension to the original MSM.

[8] See http://projects.semwebcentral.org/projects/owls-tc/

[9] See http://projects.semwebcentral.org/projects/sawsdl-tc/

[10] See http://fusion.cs.uni-jena.de/professur/jgd/

[11] See http://backstage.bbc.co.uk/

[12] See http://www4.wiwiss.fu-berlin.de/flickrwrappr/

All things service

My day job as clinical leader of a large children’s mental health centre in Ontario, Canada presents me with the constant challenge of working with other professionals to devise and resource treatment plans for children and youth with complex emotional, behavioral, and learning needs.

I have been trained formally in the philosophy of language, cognitive psychology, and experimental design and statistics, though at this stage of my life I would describe myself as self-taught. Most recently, I have been studying two domains connected to my professional work – the concepts of “service” and “network”  – with the  idea of specifying more clearly a popular but particularly slippery concept – the “service network”.

In one case study, I intend to examine a database of human services in Ontario that is maintained online at http://211ontario.ca – and explore the “meaning” embedded in this sort of database using semantic web technologies, e.g.  the evolving Core Public Service Vocabulary of the European Commission and an ontology of government services included in a recent release of schema.org.

This is a work in progress.

Originally I had thought about working away under these broad headings:

While these headings still represent reasonable divisions of labour for me, there are three distinct but just-close-enough-to-be-confusing senses in which the term “service” is used in the literature:

  • a software service, like the SSL/HTTPS service, that secures the transfer of data packets over the Internet
  • a “real” world service, like a banking service, that allows someone to pay a monthly utility bill at a local branch
  • a “real” world service that is mediated by a software service, like an online banking service, that uses the SSL/HTTPS service to allow someone to pay a monthly utility bill securely over the Internet

Early on, the metaphor “software as a service” inspired pioneers in computer science to explore and elaborate one concept (software) that was novel and abstract in terms of another concept (service) that was familiar and grounded in human experience.

In the past two decades, our understanding of the concept of software, the concept of service, and the metaphor “software as a service” have advanced tremendously. Indeed, an entire industry has emerged around “Software as a Service” (SaaS) in “cloud computing.”

Finally, in much the same way that humans have moved from using the metaphor “computer as a brain” to using as readily the metaphor “brain as a computer” – the metaphor “service as a software” is used as readily as the metaphor “software as a service” in our thinking.

Today the prime driver for clarifying the semantics of “real world” service comes from software engineering – and seeks to improve the design and deployment of Web services that are (somehow) meant to facilitate the delivery of “real world” services.

My original thought was to enlist the technologies of software services – e.g. service-oriented computing, service-oriented architecture, service-oriented semantics – to describe and model more clearly and formally the defining features of “real” world services – especially human services, like social assistance, mental health counselling, and so on.

I still believe there is great potential in this exercise – and in the closely related exercise of elaborating how software services can support “real” human services – though we are liable to miss the mark if we take the metaphor “service as a software” too literally.

 

ISA Core Vocabularies – Readings

Publications on the Core Vocabularies

Navigating the SOA Landscape

Source: OASIS – Navigating the SOA Open Standards Landscape Around Architecture , June 2009

Take-away for use:

  • OASIS – Reference Model for SOA (SOA-RM)
  • The Open Group – SOA Ontology (SOA-O)
  • Open Management Group – Service Oriented Architecture Modeling Language (SoaML)

Introduction

This document is written to provide guidance to readers of various Service Oriented Architecture (SOA) standards and specifications written by the Organization for the Advancement of Structured Information Standards (OASIS), The Open Group, and the Object Management Group (OMG), on how these standards and specifications relate to each other:

  • Reference models – e.g. the OASIS Reference Model for SOA.
  • Reference architectures – e.g. the OASIS Reference Architecture for SOA, The Open Group SOA Reference Architecture.
  • Ontologies – e.g. The Open Group SOA Ontology.
  • Maturity models – e.g. The Open Group Service Integration Maturity Model (OSIMM).
  • Modeling profiles – e.g. the Open Management Group SoaML, SysML.

Technical Products Related to Core SOA Concepts

The OASIS Reference Model for SOA (SOA-RM) is intended to capture the “essence” of SOA, as well as provide a vocabulary and common understanding of the SOA. The goals of the reference model include a common conceptual framework that can be used consistently across and between different SOA implementations, common semantics that can be used unambiguously in modeling specific SOA solutions, and definitions that should apply to all SOA. The reference model provides a normative reference that remains relevant for SOA as an abstract, power model, regardless of the inevitable technology changes that have influenced or will influence SOA deployment.

The Open Group SOA Ontology is similar to the OASIS Reference Model for SOA in that it captures a set of related concepts within the SOA space and explains what they are and how they relate to each other. The objectives are to facilitate understanding of these terms and concepts within the context of SOA, and potentially to facilitate model-driven implementation. The ontology is represented in OWL to enable automation and allow tools to process it; e.g. reasoning applications could use the SOA ontology to drive service consumer and provider matching, service value chain analysis, and impact analysis. The formal representation enables integration with other concerns such as business motivation modeling, business process modeling, operations modeling, portfolio management, etc.

Note that the OASIS Reference Model for SOA and The Open Group SOA Ontology are very closely aligned, although some terms may represent different views.

[skip: Technical products related to SOA Maturity; Governance]

Technical Products Related to Architecture

Modeling Profiles – Business and IT architects also employ methodologies for modeling and building architectures. As such, architectural methodologies have emerged with the advent of Model Driven Architecture (MDA), a product of the OMG. For working with SOA and using the Unified Modeling Language (UML) as the primary syntax, the OMG SoaML specification provides guidance to help architects and other strategic thinkers link the design of real world SOA-based systems into their architecture work.

The Service Oriented Architecture Markup Language (SoaML) is an OMG standard that defines extensions to UML for services modeling adn provides functional, object-oriented, and component modeling capabilities. SoaML extends UML in order to provide additional capabilities for managing cohesion and coupling afforded by an SOA style. SoaML is applicable across a broad range of domains and levels of abstraction from business services to detailed IT services. Using a common language for these different purposes simplifies systems modeling and integration of separate concerns in order to enable business agility. SoaML can be viewed as support instantiation of the OASIS Reference Model for SOA that provides a concrete platform for services modeling integrated with UML and supported OMG MDA.

The purpose of the SoaML standard is to address service modeling, not methodologies for determining what the services model should be, or how it would be used in any particular context. The standard is intended to be sufficiently detailed to define platform-independent SOA models (PIMs) that can be transformed into platform-specific models (PSMs) for particular technical architectures.

The fundamental element of SoaML is the participant, representing a service consumer and/or provider. Participants express their goals, needs, and expectations through requests for services as defined by service interfaces or service contracts. Other participants express their value propositions, capabilities, and commitments through services. Participants are then assembled into service value chains where participant requests are connected to the compatible services of other participants through service channels through which they interact. SoaML uses facilities of UML to define the services interfaces and method behaviors for carrying out and using services. SoaML also defines autonomous agents that can choreograph participants in a service value chain while adapting to the changing needs of the community of collaborating participants. SoaML provides a means of defining milestones that indicate the achievement of progress toward achieving the desired real-world effect of the services value chain, and for evaluating different approaches to achieving progress by different participants.

Since the OASIS Reference Architecture for SOA, The Open Group SOA Ontology, and the OMG SoaML were all based on the OASIS Reference Model for SOA with refinements and extensions, there is some natural affinity between these works.

How the Technical Products Fit Together

These technical products represent different perspectives and levels of discussion within the overall SOA landscape. A reference model, much like an ontology, is a high-level conceptualization of a domain but without formal semantics and rules to support automated reasoning that would be characteristic of an ontology. A formal ontology could be created for a particular reference model or a reference model could be formally described by an ontology. Both capture the core concepts within that domain and explain how they relate to each other devoid of implementation details. They are useful to capture and preserve knowledge that helps users to understand the “essence” of the domain. Reference models and ontologies guide architectures and reference architectures.

The OASIS Reference Model is the most abstract, with The Open Group SOA Ontology being slightly less abstract, since it provides a normative expression of the SOA Reference Model with extensions. The OASIS Reference Architecture for SOA is less abstract than the OASIS Reference Model for SOA and The Open Group SOA Ontology, since it provides significantly more detail on architectural components and their relationships, but provides a subset of the architectural views available. The Open Group Reference Architecture is less abstract than the OASIS Reference Architecture for SOA and provides more coverage of an enterprise architecture.

The open standards organizations referenced in this White Paper agree on the following fundamental concepts of SOA:

SOA – We agree that SOAs support thinking and organizing in terms of services with distributed capabilities which may be under the control of different ownership domains, and is an architectural style as well as a paradigm for business and IT architecture.
Service – We agree that services correspond to repeatable activities that can be characterized as capabilities or the access to capabilities, that capabilities satisfy specific needs, that services are self-contained, that services are described, and that access and interaction with services are constrained by policies and contracts. We agree that the service implementation is opaque to service consumers who interact with the service.
Effect (or real-world effect) – We agree that interacting with services has a purpose and therefore has some outcome which potentially provides exchange of value between consumers and providers.
Visibility – We agree that participants, more specifically providers with capabilities and consumers with needs, are able to interact with each other. We agree that availability of service descriptions and policies support these interactions.
Service Description – We agree that services are described with sufficient information in order to determine whether they meet the needs of prospective consumers as well as how to access and interact with them, including but not limited to interfaces, policies, and contracts.
Policies and Contracts – We agree that service policies represent some constraint or condition expectation on the use of services represented by a consuming participant or commitment of a providing participant, and that service contracts represent an agreement by two or more parties.
Execution Context – We agree that in order for services to be invoked, there must be an established path between consumers and providers. In other words, to realize described effects, consumers and providers must acknowledge and comply with a consistent set of agreements in order to have a successful service interaction.
Interaction – We agree that there is some activity involved in making use of capabilities offered by services in order to achieve desired effects.

Guidance and Usage of Architectural Products

Understanding SOA Core Concepts – The OASIS Reference Model for SOA provides a common vocabulary for understanding the “essence” of SOA. It is, by design, a highly abstract model targeting a large, cross-cutting audiences that includes non-technical readers as much as it does technical readers. The Open Group SOA Ontology builds on the OASIS Reference Model for SOA and provides additional SOA concepts and relationships taken from the viewpoints of different stakeholders as well as an enterprise-wide perspective. It also provides as a common language for formally describing SOA concepts that can be leveraged by abstract as well as solution-oriented reference architectures.

[skip Architectures; Maturity]

Modeling Languages – The SoaML provides a UML profile for modeling SOA artifacts and services for your SOA as part of the transformation from a reference architecture to your SOA solution architecture.

Conclusion

An abundance of specifications and standards have emerged from the open standards organizations OASIS, OMG, and The Open Group on the subject of SOA. Fortunately, there is a great deal of agreement on the foundational core concepts across the many independent open specifications and standards for SOA.

 

 

Reference Model for Service Oriented Architecture (SOA-RM) Introduction

Introduction

The notion of Service Oriented Architecture (SOA) has received significant attention within the software design and development community. The result of this attention is the proliferation of many conflicting definitions of SOA. Whereas SOA architectural patterns (or reference architectures) may be developed to explain and underpin a generic design template supporting a specific SOA, a reference model is intended to provide an even higher level of commonality, with definitions that should apply to all SOA.

A reference model is an abstract framework for understanding significant relationships among the entities of some environment. It enables the development of specific reference or concrete architectures using consistent standards or specifications supporting that environment. A reference model consists of a minimal set of unifying concepts, axioms and relationships within a particular problem domain, and is independent of specific standards, technologies, implementations, or other concrete details.

What is Service Oriented Architecture?

Entities (people and organizations) create capabilities to solve the problems they face in the course of their business; one person’s needs may be met by capabilities offered by someone else. SOA provides a framework for matching needs and capabilities and for combining capabilities to address those needs.

SOA is a means of organizing solutions that promotes reuse, growth and interoperability. It is not itself a solution to domain problems, but rather an organizing and delivery paradigm that enables one to get more value from use both of capabilities which are locally “owned” and those under the control of others.  It also enables one to express solutions in a way that makes it easier to modify or evolve the identified solution or to try alternate solutions.  SOA does not provide any domain elements of a solution that do not exist without SOA.

Service

The central concept of SOA is the service. The noun “service” is defined in dictionaries as “The performance of work (a function) by one for another.”  However, service, as the term is generally understood, also combines the following related ideas:

  • The capability to perform work for another
  • The specification of the work offered for another
  • The offer to perform work for another

These concepts emphasize a distinction between a capability and the ability to bring that capability to bear. In SOA, services are the mechanism by which needs and capabilities are brought together.

While a service brings together needs and capabilities, the provider of the underlying capability may not be the same entity that eventually provides the service which accesses that capability.  In reality, the entity with the domain expertise to create, maintain, and evolve a given capability may not have the expertise or the desire to create, maintain, and evolve its service access.

Visibility

Visibility refers to the capacity for those with needs and those with capabilities to be able to see each other.  Visibility is promoted through the service description which describes functions and requirements, related constraints and policies, and mechanisms for access or response.  The descriptions need to be in a form in which their syntax and semantics are accessible and understandable.

Interaction

Whereas visibility introduces the possibilities for matching needs to capabilities (and vice versa), interaction is the activity of using a capability.  Typically mediated by the exchange of messages, an interaction proceeds through a series of information exchanges and invoked actions. There are many facets of interaction; but they are all grounded in a particular execution context – the set of technical and business elements that form a path between those with needs and those with capabilities. The service description provides the information necessary to interact with the service and describes this in such terms as the service inputs, outputs, and associated semantics. This permits service providers and consumers to interact and provides a decision point for any policies and contracts that may be in force.

Effect

The purpose of using a capability is to realize one or more real world effects.  At its core, an interaction is “an act” as opposed to “an object” and the result of an interaction is an effect (or a set/series of effects). This effect may be the return of information or the change in the state of entities (known or unknown) that are involved in the interaction. The service description conveys what is accomplished when the service is invoked and the conditions for using the service.

We distinguish between public actions and private actions; private actions are inherently unknowable by other parties. On the other hand, public actions result in changes to the state that is shared between at least those involved in the current execution context and possibly shared by others. Real world effects are, then, couched in terms of changes to this shared state.

The expected real world effects form an important part of the decision on whether a particular capability matches similarly described needs.  At the interaction stage, the description of real world effects establishes the expectations of those using the capability.   Note, it is not possible to describe every effect from using a capability. A cornerstone of SOA is that capabilities can be used without needing to know all the details.

Service Providers and Service Consumers

In general, entities (people and organizations) offer capabilities and act as service providers.  Those with needs who make use of services are referred to as service consumers.  The service description allows prospective consumers to decide if the service is suitable for their current needs and establishes whether a consumer satisfies any requirements of the service provider.

Service providers and service consumers are sometimes referred to jointly as service participants.1

Figure 1 illustrates the principal concepts of the Reference Model of SOA:

Principle concepts of the Reference Model of SOA

Figure 1. Principal components in the Reference Model of SOA (SOA-RM).

The relationships between the principal concepts are developed as each concept is defined in turn:

Source: OASIS – Reference Model for Service Oriented Architecture – 2006

Previous: OASIS – Navigating the SOA Landscape Through Architecture
Next: SOA-RM – Service

  1.  In most discussions of SOA, the terms “loose coupling” and “coarse-grained” are commonly applied as SOA concepts, but these terms have intentionally not been used in the current discussion because they are subjective trade-offs and without useful metrics. In terms of needs and capabilities, granularity and coarseness are usually relative to detail for the level of the problem being addressed, e.g. one that is more strategic vs. one down to the algorithm level, and defining the optimum level is not amenable to counting the number of interfaces or the number or types of information exchanges connected to an interface.

SOA-RM – Dynamics of services

From a dynamic perspective, there are three fundamental concepts that are important in understanding what is involved in interacting with services: the visibility between service providers and consumers, the interaction between them, and the real world effect of interacting with a service.

SOA-RM - Concepts around the dynamics of service

Figure 1. Concepts around the dynamics of service.

Visibility

For a service provider and consumer to interact with each other they have to be able to ‘see’ each other. This is true for any consumer/provider relationship – including in an application program where one software program calls another. In the case of SOA, visibility needs to be emphasized because it is not necessarily obvious how service participants can see each other.

SOA-RM - Concepts around visibility

Figure 5. Concepts around visibility.

Visibility is the relationship between service consumers and providers that is satisfied when they are able to interact with each other. Preconditions to visibility are awareness, willingness and reachability. The initiator in a service interaction MUST be aware of the other parties, the participants MUST be predisposed to interaction, and the participants MUST be able to interact.

Awareness

Both the service provider and the service consumer MUST have information that would lead them to know of the other’s existence. Technically, the prime requirement is that the initiator of a service interaction has knowledge of the responder. The fact of a successful initiation is often sufficient to inform the responder of the other’s existence.

Awareness is a state whereby one party has knowledge of the existence of the other party. Awareness does not imply willingness or reachability. Awareness of service offerings is often effected by various discovery mechanisms. For a service consumer to discover a service, the service provider must be capable of making details of the service (notably service description and policies) available to potential consumers; and consumers must be capable of becoming aware of that information. Conversely, the service provider may want to discover likely consumers and would need to become aware of the consumer’s description.  In the following, we will discuss awareness in terms of service visibility but the concepts are equally valid for consumer visibility.

Service awareness requires that the service description and policy – or at least a suitable subset thereof – be available in such a manner and form that, directly or indirectly, a potential consumer is aware of the existence and capabilities of the service. The extent to which the description is “pushed” by the service provider, “pulled” by a potential consumer, subject to a probe or another method, will depend on many factors.

For example, a service provider may advertise and promote their service by either including it in a service directory or broadcasting it to all consumers; potential consumers may broadcast their particular service needs in the hope that a suitable service responds with a proposal or offer, or a service consumer might also probe an entire network to determine if suitable services exist. When the demand for a service is higher than the supply, then, by advertising their needs, potential consumers are likely to be more effective than service providers advertising offered services.

One way or another, the potential consumer must acquire sufficient descriptions to evaluate whether a given service matches its needs and, if so, the method for the consumer to interact with the service.

Willingness

Associated with all service interactions is intent – it is an intentional act to initiate and to participate in a service interaction. For example, if a service consumer discovers a service via its description in a registry, and the consumer initiates an interaction, if the service provider does not cooperate then there can be no interaction. In some circumstances it is precisely the correct behavior for a service to fail to respond.

The extent of a service participant’s willingness to engage in service interactions may be the subject of policies. Those policies may be documented in the service description.

Willingness on the part of service providers and consumers to interact is not the same as a willingness to perform requested actions. A service provider that rejects all attempts to cause it to perform some action may still be fully willing and engaged in interacting with the consumer.

Reachability

Reachability is the relationship between service participants where they are able to interact; possibly by exchanging information. Reachability is an essential pre-requisite for service interaction – participants MUST be able to communicate with each other.

A service consumer may have the intention of interacting with a service, and may even have all the information needed to communicate with it. However, if the service is not reachable, for example if there is not a communication path between the consumer and provider, then, effectively, the service is not visible to the consumer.

Previous: SOA-RM – Service
Next: SOA-RM – Interacting with services

SOA-RM – Interacting with services

Interacting with a service involves performing actions against the service. In many cases, this is accomplished by sending and receiving messages, but there are other modes possible that do not involve explicit message transmission. For example, a service interaction may be effected by modifying the state of a shared resource. However, for simplicity, we often refer to message exchange as the primary mode of interaction with a service.

SOA-RM - Service interaction concepts

Figure 1. Service interaction concepts.

Figure 1 illustrates the key concepts that are important in understanding what it is involved in interacting with services; these revolve around the service description – which references a information model and a behavior model.

Information model

The information model of a service is a characterization of the information that may be exchanged with the service.  Only information and data that are potentially exchanged with a service are generally included within that service’s information model.

The scope of the information model includes the format of information that is exchanged, the structural relationships within the exchanged information and also the definition of terms used.

Particularly for information that is exchanged across an ownership boundary, an important aspect of the service information model is the consistent interpretation of strings and other tokens in the information.

The extent to which one system can effectively interpret information from another system is governed by the semantic engagement of the various systems. The semantic engagement of a system is a relationship between the system and information it may encounter. This is highly variable and application dependent.

Loosely, one might partition the interpretation of an informational block into structure (syntax) and semantics (meaning); although both are part of the information model.

Structure

Knowing the representation, structure, and form of information required is a key initial step in ensuring effective interactions with a service. There are several levels of such structural information; including the encoding of character data, the format of the data and the structural data types associated with elements of the information.

A described information model typically has a great deal to say about the form of messages.  However, knowing the type of information is not sufficient to completely describe the appropriate interpretation of data. For example, within a street address structure, the city name and the street name are typically given the same data type – some variant of the string type. However, city names and street names are not really the same type of thing at all.  Distinguishing the correct interpretation of a city name string and a street name string is not possible using type-based techniques – it requires additional information that cannot be expressed purely in terms of the structure of data.

Semantics

The primary task of any communication infrastructure is to facilitate the exchange of information and the exchange of intent. For example, a purchase order combines two somewhat orthogonal aspects: the description of the items being purchased and the fact that one party intends to purchase those items from another party. Even for exchanges that do not cross any ownership boundaries, exchanges with services have similar aspects.

Especially in the case where the exchanges are across ownership boundaries, a critical issue is the interpretation of the data. This interpretation MUST be consistent between the participants in the service interaction. Consistent interpretation is a stronger requirement than merely type (or structural) consistency – the tokens in the data itself must also have a shared basis.

There is often a huge potential for variability in representing street addresses. For successful exchange of address information, all the participants must have a consistent view of the meaning of the address tokens if address information is to be reliably shared.

The formal descriptions of terms and the relationships between them (e.g., an ontology) provides a firm basis for selecting correct interpretations for elements of information exchanged.  For example, an ontology can be used to capture the alternate ways of expressing the name of a city as well as distinguishing a city name from a street name.

Note that, for the most part, it is not expected that service consumers and providers would actually exchange descriptions of terms in their interaction but, rather, would reference existing descriptions – the role of the semantics being a background one – and these references would be included in the service descriptions.

Specific domain semantics are beyond the scope of this reference model; but there is a requirement that the service interface enable providers and consumers to identify unambiguously those definitions that are relevant to their respective domains.

Behavioral model

The second key requirement for successful interactions with services is knowledge of the actions invoked against the service and the process or temporal aspects of interacting with the service. This is characterized as knowledge of the actions on, responses to, and temporal dependencies between actions on the service.

The sequences of actions involved are a critical aspect of the knowledge required for successful use of the service.

Action model

The action model of a service is the characterization of the actions that may be invoked against the service. Of course, a great portion of the behavior resulting from an action may be private; however, the expected public view of a service surely includes the implied effects of actions.

Process model

The process model characterizes the temporal relationships and temporal properties of actions and events associated with interacting with the service.

Note that although the process model is an essential part of this Reference Model, its extent is not completely defined. Some process models MAY include aspects that are not strictly part of SOA – for example, in this Reference Model we do not address the orchestration of multiple services, although orchestration and choreography may be part of the process model. At a minimum, the process model MUST cover the interactions with the service itself.

The reason that orchestration (and choreography) are not part of the SOA RM is that the focus of the RM is on modeling what service is and what key relationships are involved in modeling service.

Beyond the straightforward mechanics of interacting with a service there are other, higher-order, attributes of services’ process models that are also often important. These can include whether the service is idempotent, whether the service is long-running in nature and whether it is important to account for any transactional aspects of the service.

Previous: SOA-RM – Dynamics of services
Next: SOA-RM – Real world effect

SOA-RM – Real world effect

There is always a particular purpose associated with interacting with a service. Conversely, a service provider (and consumer) often has a priori conditions that apply to its interactions.  The service consumer is trying to achieve some result by using the service, as is the service provider. At first sight, such a goal can often be expressed as “trying to get the service to do something”.  This is sometimes known as the “real world effect” of using a service. For example, an airline reservation service can be used to learn about available flights, seating and ultimately to book travel – the desired real world effect being information and a seat on the right flight.

A real world effect can be the response to a request for information or the change in the state of some defined entities shared by the service participants. In this context, the shared state does not necessarily refer to specific state variables being saved in physical storage but rather represents shared information about the affected entities.  So in the example of the airline reservation, the shared state  – that there is a seat reserved on a particular flight – represents a common understanding between a future passenger and the airline. The details of actual state changes – whether on the part of the passenger (e.g. fund balances required to pay for the ticket) or of the airline (e.g. that a seat is sold for that flight)  – are not shared by the other.

SOA-RM Real world effect and shared state

Figure 1. Real world effect and shared state.

In addition, the internal actions that service providers and consumers perform as a result of participation in service interactions are, by definition, private and fundamentally unknowable. By unknowable we mean both that external parties cannot see others’ private actions and, furthermore, SHOULD NOT have explicit knowledge of them. Instead we focus on the set of facts shared by the parties – the shared state. Actions by service providers and consumers lead to modifications of this shared state; and the real world effect of a service interaction is the accumulation of the changes in the shared state.

There is a strong relationship between the shared state and the interactions that lead up to that state. The elements of the shared state SHOULD be inferable from that prior interaction together with other context as necessary. In particular, it is not required that the state be recorded; although without such recording it may become difficult to audit the interaction at a subsequent time.

Previous: SOA-RM – Interacting with services
Next: SOA-RM – Service description

SOA-RM – Service description

In support of the dynamics of interacting with services are a set of concepts that are about services themselves. These are the service description, the execution context of the service and the contracts and policies that relate to services and service participants.

SOA-RM - About services

Figure 1. About services.

Service description

One of the hallmarks of a Service Oriented Architecture is the large amount of associated documentation and description.

The service description represents the information needed in order to use a service. In most cases, there is no one “right” description but rather the elements of description required depend on the context and the needs of the parties using the associated entity. While there are certain elements that are likely to be part of any service description, most notably the information model, many elements such as function and policy may vary.

SOA-RM  - Service description

Figure 2. Service description.

The purpose of description is to facilitate interaction and visibility, particularly when the participants are in different ownership domains, between participants in service interactions. By providing descriptions, it makes it possible for potential participants to construct systems that use services and even offer compatible services.

For example, descriptions allow participants to discriminate amongst possible choices for service interaction; such as whether the service provides required capabilities, how to access the service, and negotiate over specific service functionality. In addition, descriptions can be used to support the management of services, both from the service provider’s perspective and the service consumer’s perspective.

Best practice suggests that the service description SHOULD be represented using a standard, referenceable format. Such a format facilitates the use of common processing tools (such as discovery engines) that can capitalize on the service description.

While the concept of a SOA supports use of a service without the service consumer needing to know the details of the service implementation, the service description makes available critical information that a consumer needs in order to decide whether or not to use a service.  In particular, a service consumer needs to possess the following items of information:

  1. That the service exists and is reachable;
  2. That the service performs a certain function or set of functions;
  3. That the service operates under a specified set of constraints and policies;
  4. That the service will (to some implicit or explicit extent) comply with policies as prescribed by the service consumer;
  5. How to interact with the service in order to achieve the required objectives, including the format and content of information exchanged between the service and the consumer and the sequences of information exchange that may be expected.

While each of these items SHOULD be represented in any service description, the details can be included through references (links) to external sources and are NOT REQUIRED to be incorporated explicitly.  This enables reuse of standard definitions, such as for functionality or policies.

Other sections of this document deal with these aspects of a service, but the following subsections discuss important elements as these relate to the service description itself.

Service reachability

Reachability is an inherently pairwise relationship between service providers and service consumers. However, a service description SHOULD include sufficient data to enable a service consumer and service provider to interact with each other. This MAY include metadata such as the location of the service and what information protocols it supports and requires. It MAY also include dynamic information about the service, such as whether it is currently available.

Service functionality

A service description SHOULD unambiguously express the function(s) of the service and the real world effects (see Section 3.2.3) that result from it being invoked.  This portion of the description SHOULD be expressed in a way that is generally understandable by service consumers but able to accommodate a vocabulary that is sufficiently expressive for the domain for which the service provides its functionality.  The description of functionality may include, among other possibilities, a textual description intended for human consumption or identifiers or keywords referenced to specific machine-processable definitions.  For a full description, it MAY indicate multiple identifiers or keywords from a number of different collections of definitions.

Part of the description of functionality may include underlying technical assumptions that determine the limits of functionality exposed by the service or of the underlying capability.  If the assumptions are not valid, the user may need to use another service to access the capability.

Policies related to a service

A service description MAY include support for associating policies with a service and providing necessary information for prospective consumers to evaluate if a service will act in a manner consistent with the consumer’s constraints.

Service interface

The service interface is the means for interacting with a service.  It includes the specific protocols, commands, and information exchange by which actions are initiated that result in the real world effects as specified through the service functionality portion of the service description.

The specifics of the interface SHOULD be syntactically represented in a standard referenceable format. These prescribe what information needs to be provided to the service in order to access its capabilities and interpret responses.  This is often referred to as the service’s information model.  It should be noted that the particulars of the interface format are beyond the scope of the reference model. However, the existence of interfaces and accessible descriptions of those interfaces are fundamental to the SOA concept.

While this discussion refers to a standard referenceable syntax for service descriptions, it is not specified how the consumer accesses the interface definition nor how the service itself is accessed.  However, it is assumed that for a service to be usable, its interface MUST be represented in a format that allows interpretation of the interface information by its consumers.

The limits of description

There are well-known theoretic limits on the effectiveness of descriptions – it is simply not possible to specify, completely and unambiguously, the precise semantics of and all related information about a service.

There will always be unstated assumptions made by the describer of a service that must be implicitly shared by readers of the description. This applies to machine processable descriptions as well as to human readable descriptions.

Fortunately, complete precision is not necessary – what is required is sufficient scope and precision to support intended use.

Another kind of limit of service descriptions is more straightforward: whenever a repository is searched using any kind of query there is always the potential for zero or more responses – no matter how complete the search queries or the available descriptions appear to be. This is inherent in the principles involved in search.

In the case that there is more than one response, this set of responses has to be converted into a single choice. This is a private choice that must be made by the consumer of the search information.

Previous: SOA-RM – Real world effect
Next: SOA-RM – Policies related to a service

SOA-RM – Policies and contracts

A policy represents some constraint or condition on the use, deployment or description of an owned entity as defined by any participant. A contract, on the other hand, represents an agreement by two or more parties. Like policies, agreements are also about the conditions of use of a service; they may also constrain the expected real world effects of using a service. The reference model is focused primarily on the concept of policies and contracts as they apply to services.  We are not concerned with the form or expressiveness of any language used to express policies and contracts.

SOA-RM - Policies and contractsFigure 1. Policies and contracts.

Service policy

Conceptually, there are three aspects of policies: the policy assertion, the policy owner (sometimes referred to as the policy subject) and policy enforcement.

For example, the assertion: “All messages are encrypted” is an assertion regarding the forms of messages. As an assertion, it is measurable: it may be true or false depending on whether the traffic is encrypted or not. Policy assertions are often about the way the service is realized; i.e., they are about the relationship between the service and its execution context.

A policy always represents a participant’s point of view. An assertion becomes the policy of a participant when they adopt the assertion as their policy. This linking is normally not part of the assertion itself. For example, if the service consumer declares that “All messages are encrypted”, then that reflects the policy of the service consumer. This policy is one that may be asserted by the service consumer independently of any agreement from the service provider.

Finally, a policy may be enforced. Techniques for the enforcement of policies depend on the nature of the policy. Conceptually, service policy enforcement amounts to ensuring that the policy assertion is consistent with the real world. This might mean preventing unauthorized actions to be performed or states to be entered into; it can also mean initiating compensatory actions when a policy violation has been detected.  An unenforceable constraint is not a policy; it would be better described as a wish.

Policies potentially apply to many aspects of SOA: security, privacy, manageability, Quality of Service and so on. Beyond such infrastructure-oriented policies, participants MAY also express business-oriented policies – such as hours of business, return policies and so on.

Policy assertions SHOULD be written in a form that is understandable to, and processable by, the parties to whom the policy is directed. Policies MAY be automatically interpreted, depending on the purpose and applicability of the policy and how it might affect whether a particular service is used or not.

A natural point of contact between service participants and policies associated with the service is in the service description. It would be natural for the service description to contain references to the policies associated with the service.

Service contract

Whereas a policy is associated with the point of view of individual participants, a contract represents an agreement between two or more participants. Like policies, contracts can cover a wide range of aspects of services: quality of service agreements, interface and choreography agreements and commercial agreements. Note that we are not necessarily referring to legal contracts here.

Thus, following the discussion above, a service contract is a measurable assertion that governs the requirements and expectations of two or more parties.  Unlike policy enforcement, which is usually the responsibility of the policy owner, contract enforcement may involve resolving disputes between the parties to the contract. The resolution of such disputes may involve appeals to higher authorities.

Like policies, contracts may be expressed in a form that permits automated interpretation. Where a contract is used to codify the results of a service interaction, it is good practice to represent it in a machine processable form. Among other purposes, this facilitates automatic service composition. Where a contract is used to describe over-arching agreements between service providers and consumers, then the priority is likely to make such contracts readable by people.

Since a contract is inherently the result of agreement by the parties involved, there is a process associated with the agreement action. Even in the case of an implicitly agreed upon contract, there is logically an agreement action associated with the contract, even if there is no overt action of agreement. A contract may be arrived at by a mechanism that is not directly part of an SOA – an out of band process. Alternatively, a contract may be arrived at during the course of a service interaction – an in-band process.

Previous: SOA-RM – Service description
Next: SOA-RM – Execution context.

SOA-RM – Execution context

The execution context of a service interaction is the set of infrastructure elements, process entities, policy assertions and agreements that are identified as part of an instantiated service interaction, and thus forms a path between those with needs and those with capabilities.

SOA-RM - Execution context

 

Figure 1. Execution context.

As discussed in previous sections of this document, the service description (and a corresponding description associated with the service consumer and its needs) contains information that can include preferred protocols, semantics, policies and other conditions and assumptions that describe how a service can and may be used.  The participants (providers, consumers, and any third parties as noted below) must agree and acknowledge a consistent set of agreements in order to have a successful service interaction, i.e. realizing the described real world effects.  The execution context is the collection of this consistent set of agreements.

The consumer and provider can be envisioned as separate places on a map and, for a service to actually be invoked, a path must be established between those two places.  This path is the execution context.  As with a path between places, it can be a temporary connection (e.g. a tenuous footbridge of an ad hoc exchange) or a well-defined coordination (e.g. a super highway) that can be easily reused in the future.

The execution context is not limited to one side of the interaction; rather it concerns the totality of the interaction – including the service provider, the service consumer and the common infrastructure needed to mediate the interaction. While there may be third parties, for example, government regulators, who set some of the conditions for the execution context, this merely increases the conditions and constraints needing to be coordinated and may require additional information exchange to complete the execution context.

The execution context is central to many aspects of a service interaction. It defines, for example, a decision point for policy enforcement relating to the service interaction. Note that a policy decision point is not necessarily the same as an enforcement point: an execution context is not by itself something that lends itself to enforcement. On the other hand, any enforcement mechanism of a policy is likely to take into account the particulars of the actual execution context.

The execution context also allows us to distinguish services from one another. Different instances of the same service – denoting interactions between a given service provider and different service

consumers for example – are distinguished by virtue of the fact that their execution contexts are different.

Finally, the execution context is also the context in which the interpretation of data that is exchanged takes place. A particular string has a particular meaning in a service interaction in a particular context – the execution context.

An execution context often evolves during a service interaction. The set of infrastructure elements, the policies and agreements that apply to the interaction, may well change during a given service interaction. For example, at an initial point in an interaction, it may be decided by the parties that future communication should be encrypted. As a result the execution context also changes – to incorporate the necessary infrastructure to support the encryption and continue the interaction.

Previous: SOA-RM – Policies and contracts

End of series on SOA-RM.

Service Oriented Architecture Ontology (SOA-O) – Introduction

Sources

Service Oriented Architecture Ontology version 1.0 – 2010
Service Oriented Architecture Ontology version 2.0 – 2014

Overview

The purpose of the SOA Ontology (SOA-O) is to develop and foster common understanding of the SOA in order to improve alignment between the business and information technology communities, and facilitate SOA adoption:

  1. The SOA-O defines the concepts, terminology, and semantics of SOA in both business and technical terms, in order to:
    1. Create a foundation for further work in domain-specific areas.
    2. Enable communications between business and technical people.
    3. Enhance the understanding of SOA concepts in the business and technical communities.
    4. Provide a means to state problems and opportunities clearly and unambiguously to promote mutual understanding.
    5. The SOA-O potentially contributes to model-driven SOA implementation.

    The OWL ontology is available online.

    The SOA-O is designed for use by:

    • Business people, to give them a deeper understanding of SOA concepts and how they are used in the enterprise and its environment.
    • Architects, as metadata for architectural artifacts.
    • Architecture methodologists, as a component of SOA meta-models.
    • System and software designers for guidance in terminology and structure.

    This standard defines a formal ontology for SOA. The ontology is represented in the Web Ontology Language (OWL) – using OWL-DL, one of three sub-languages that provides the greatest expressiveness possible while retaining computational completeness and decidability.

    The ontology contains classes and properties corresponding to the core concepts of SOA. The formal OWL definitions are supplemented by natural language descriptions of the concepts, with graphic illustrations of the relations between them, and with examples of their use. For purposes of exposition, the ontology also includes UML diagrams that graphically illustrate its classes and properties of the ontology. The natural language and OWL definitions contained in this specification constitute the authoritative definition of the ontology; the diagrams are for explanatory purposes only.

    SOA Ontology - UML Class Diagram

    Figure 1. SOA-O – Graphical Overview.

    The class hierarchy is as follows:

    SOA Ontology Class Hierarchy

    Figure 2. The SOA-O Class Hierarchy.

  2. Applications

    The SOA-O was developed in order

    1. to aid understanding, and
    2. potentially to be a basis for model-driven implementation.

    To aid understanding, this specification can simply be read. To be a basis for model-driven implementation, it should be applied to particular usage domains and application to example usage domains will aid understanding.

    The SOA-O can be used as a core for domain-specific ontologies that apply to the use of the SOA in particular sectors of commerce and industry. The ontology is applied to a particular usage domain by adding SOA OWL class instances of things in that domain. This is sometimes referred to as "populating the ontology". In additional, an application can add definitions of new classes and properties, can import other ontologies into the SOA-O, and can import the SOA-O into other ontologies.

    The ontology defines the relations between terms, but does not prescribe exactly how they should be applied.

    Previous: SOA-RM Service Oriented Architure Reference Model – Introduction
    Next: SOA-O – Element and System Classes

SOA-O – Element and System Classes

Element and system are two of the core concepts of the SOA Ontology (SOA-O).

Here we will describe two classes:

  1. Element
  2. System

and the following properties:

  1. uses and usedBy
  2. represents and representedBy

Element Class

An element is an opaque entity that is indivisible at a given level of abstraction. The element has a clearly defined boundary. The concept of element is captured by the Element OWL class.

SOA Ontology - Class Element

Figure 1. The SOA-O Element Class.

In the SOA-O, we consider in detail only functional elements that belong to the SOA domain.

There are other kinds of elements than members of the four named subclasses (System, HumanActor, Task, and Service). Examples of other kinds of elements are things like software components or technology components.

uses and usedBy Properties

Elements may use other elements in various ways. An element uses another element if it interacts with it in some fashion. Interacts here is interpreted very broadly:

  • An element simply being a member of (or used by) some system
  • An element interacting with (using) another element (such as a service) in an ad hoc fashion
  • Strongly coupled dependency in a composition

The uses, and its inverse usedBy, capture the abstract notion of an element using another. These properties capture not just transient relations. Instantiation of the property can include “uses at this instant”, “has used”, and “may in future use”.

We have chosen not to attempt to enumerate and formally define the multitude of different possible semantics of a uses relationship. We leave the semantic interpretations to a particular sub-domain, application, or even design approach.

Example

Using an organizational example, typical instances of Element are organizational units and people. Whether to perceive a given part of an organizational unit or as the set of people within that organizational unit is an important choice of abstraction level:

  • Inside the boundary of the organizational unit, we want to express the fact that an organizational unit uses the people that are members of it. Note that the same person can be a member of (be used by) multiple organizational units.
  • Outside the boundary, the internal structure of an organizational unit must remain opaque to an external observer, as the enterprise wants to be able to change the people within the organizational unit without having to change the definition of the organizational unit itself.

This simple example expresses that some elements have an internal structure. In fact, from an internal perspective, they are an organized collection of other simpler things (captured by Class System).

System Class 

A system is an organized collection of other things. Things in a system collection are instances of Element, each such instance being used by the system. The concept of system is captured by the System OWL Class:

SOA Ontology - Class System

Figure 2. The SOA-O System Class.

The SOA-O considers in detail only functional systems that belong to the SOA domain. Note that a fully described instance of System should have by its nature (as a collection) a uses relationship to at least one instance of Element.

Since System is a subclass of Element, all systems have a boundary and are opaque to an external observer (black box view). This excludes from the System class any structure that has no defined boundary.

Having System as a subclass of Element allows us to express the notion of “systems of systems” – the lower-level levels are elements used by the higher-level system.

At the same time as supporting an external viewpoint (black box view), all systems must also support an internal viewpoint (white box view) expressing how they are an organized collection. E.g. for the notion of a service, this would typically correspond to a service specification view versus a service realization view (similar to the way that SoaML defines services as having both a black box/specification part and a white box/realization part).

It is important to realize that even though systems using elements express an important aspect of the uses property, it is not necessary to “invent” a system just to express that some element uses another. In fact, even for systems, we may need to be able to express that they can use elements outside their own boundary – though this in many cases will preferably be expressed not at the system level, but rather by an element of the system using that external Element instance.

System is defined as disjoint with the Service and Task classes. Instances of these classes are considered not to be collections of other things. System is specifically not defined as disjoint with the HumanActor class since an organization in many cases is in fact just a particular kind of system. We choose not to define a special intersection class to represent this fact.

Example

Continuing the organizational example from above, we can now express that an organizational unit as an instance of System has the people in it as members (and instances of Element).

Service Composition

Using a service composition example, services A and B are instances of Element and the composition of A and B is an instance of System (that uses A and B). It is important to realize that the act of composing is different than composition as a thing – it is in the latter sense that we are using the term composition here. See below for a formal definition of the concepts of service and service composition.

represents and representedBy Properties

The environment described by an SOA is intrinsically hierarchically composite – the elements of SOA systems can be repeatedly composed to ever higher levels of abstraction.

One aspect of this has already been addressed by the uses and usedBy properties – we can use these properties to express the notion of systems of systems. This is still a very concrete relationship though, and does not express the concept of architectural abstraction. We find the need for architectural abstraction in various places, such as a role representing the people playing that role, an organizational unit representing the people within it (subtly different from that same organizational unit using the people within it, as the represents relationship indicates the organizational unit using the people within it, as the represents relationship indicates the organizational unit as a substitute interaction point, an architectural building block representing an underlying construct (e.g. important to enterprise architects wanting to explicitly distinguish between constructs and building blocks), and an Enterprise Service Bus (ESB) representing the services that are accessible through it (for instance, relevant when explicitly modeling operational interaction and dependencies). The concept of such an explicitly changing viewpoint, or level of abstraction, is captured by the represents and representedBy properties:

SOA Ontology - Properties represents and representedBy

Figure 3. The SOA-O represents and representedBy Properties.

It is important to understand the distinction between using an element (E1) and using another element (E2) that represents E1. If E1 changes, then anyone using E1 directly would experience a change, but someone using E2 would not experience any change.

When applying the architectural abstraction via the represents property there are three different architectural choices that can be made:

  1. An element represents another element in a very literal way, simply by hiding the existence of that element and any changes to it. There will be a one-to-one relationship between the instance of Element and the (different) instance of Element that it represents. E.g. a broker acting as an intermediary between a seller (who does not wish to be known) and a buyer.
  2. An element represents a particular aspect of another element. There will be a many-to-one relationship between many instances of Element (each of which represents a different aspect), and one (different) instance of Element. A simple real-world example is the notion that the same person can play (be represented by) many different roles.
  3. An element is an abstraction that can represent many other elements. There will be a one-to-many relationship between one instance of Element (as an abstraction) and many other instances of Element. A simple real-world example is the notion of an architectural blueprint representing an abstraction of many different buildings being built according to that blueprint.

Note that in most cases an instance of Element will represent only one kind of thing. Specifically, an instance of Element will typically represent instances of at most one of the classes System, Service, HumanActor, and Task (with the exception of the case where the same thing is both an instance of System and an instance of Actor).

Example

Assume a company wants to form a new organizational unit (O1). There are two ways of doing this:

  1.  Define the new organization directly as a collection of people P1, P2, P3, and P4. This means that the new organization is perceived to be a leaf in the organizational hierarchy, and that any exchange of personnel means that its definition needs to change.
  2. Define the new organization as a higher-level organizational construct, joining together two existing organizations O3 and O4. Coincidentally, O3 and O4 between them may have the same four people P1, P2, P3, P4, but the new organization really doesn’t know, and any member of O3 and O4 can be changed without needing to change the definition of the new organization. Furthermore, any member of O3 is intrinsically not working in the same organization as the members of O4 (in fact, need not even be aware of them) – contrary to the first option where P1, P2, P3, P4 are all colleagues in the same new organization. In this way the abstraction aspect of the represent property induces an important difference in the semantics of the collection defining the new organization. Any instantiation of the ontology can and should use the represents and representedBy properties to define the implied semantics and lines of visibility/change crisply.

Previous: Service Oriented Architecture Ontology – SOA-O – Introduction
Next: SOA-O – HumanActor and Task Classes

SOA-O – HumanActor and Task Classes

People, organizations, and the things they do are important aspects of SOA systems. HumanActor and Task capture this as another set of core concepts of the ontology. Both are concepts that are generic and have relevance outside the domain of SOA. For the purposes of the SOA-O we have chosen to give them specific scope in that tasks are intrinsically atomic (corresponding to, for instance, the Business Process Modeling Notation (BPMN) 2.0 definition of task) and human actors are restricted to people and organizations.

This chapter describes the following classes of the SOA-O:

  • HumanActor
  • Task

In addition, it defines the following properties:

  • does and doneBy

HumanActor Class

 

A human actor is a person or an organization. The concept of human actor is captured by the HumanActor OWL class, which is illustrated below:

SOA-O - HumanActor Class

Figure 1. SOA-O HumanActor Class.

HumanActor is defined as disjoint with the Service and Task classes. Instances of these classes are considered not to be people or organizations. HumanActor is specifically not defined as disjoint with System since an organization in many cases is in fact just a particular kind of system. We choose not to define a special intersection class to represent this fact.

The uses and usedBy Properties Applied to HumanActor

In one direction, a human actor can itself use things such as services, systems, and other human actors. In the other direction, a human actor can, for instance, be used by another actor or by a system (as an element within that system such as a human actor in a process).

The represents and representedBy Properties Applied to HumanActor

Human actors are intrinsically part of systems that instantiate SOAs. Yet in many cases as an element of an SOA system we talk about not the specific person or organization, rather an abstract representation of them that participates in processes, provides services, etc. In other words, we talk about elements representing human actors.

As examples, a broker (instance of HumanActor) may represent a seller (instance of HumanActor) who wishes to remain anonymous, a role (instance of Element) may represent (the role aspect of) multiple instances of HumanActor, and an organizational unit (instance of HumanActor) may represent the many people (all instances of HumanActor) that are part of it.

Note that we have chosen not to define a “role class”, as we believe that using Element with the represents property is a more general approach which does not limit the ability to also define role-based systems. For all practical purposes there is simply a “role subclass” of Element, a subclass that we have chosen not to define explicitly.

Organizational Example

Continuing the organizational example, we can now express that P1 (John), P2 (Jack), P3 (Joe), and P4 (Mary) as instances of Element are in fact (people) instances of HumanActor. We can also express (if we so choose) that all of O1 (CarWashBusiness), O3 (CarWash), and O4 (Administration) are (organization) human actors from an action perspective at the same time that they are systems from a collection/composition perspective.

Task Class

A task is an atomic action which accomplishes a defined result. Tasks are done by people or organizations, specifically by instances of HumanActor.

The Business Process Modeling Notation (BPMN) 2.0 defines task as follows: “A task is an atomic Activity within a Process flow. A task is used when the work in the process cannot be broken down to a finer level of detail. Generally, an end-user and/or applications are used to perform the task when it is executed.” For the purposes of the ontology we have added precision by formally separating the notion of doing from the notion of performing. Tasks are (optionally) done by human actors, furthermore (as instances of Element) tasks can use services that are performed by technology components.

The concept of task is captured by the Task OWL class, which is illustrated below:

SOA-O - Task Class

Figure 2. SOA-O Task Class.

Task is defined as disjoint with the System, Service, and HumanActor classes. Instances of these classes are considered not to be atomic actions.

does and doneBy Properties

Tasks are naturally thought of as being done by people or organizations. If we think of tasks as being the actual things done, then the natural cardinality is that each instance of Task is done by at most one instance of HumanActor. Due to the atomic nature of instances of Task we rule out the case where such an instance is done jointly by multiple instances of HumanActor. The cardinality can be zero if someone chooses not to instantiate all possible human actors. On the other hand, the same instance of HumanActor can (over time) easily do more than one instance of Task. The does property, and its inverse doneBy, capture the relation between a human actor and the tasks it performs.

uses and usedBy Applied to Task

In one direction, the most common case of a task using another element is where an automated task uses a service as its realization. In the other direction, a task can, for instance, be used by a system (as an element within that system, such as a task in a process).

represents and representedBy Applied to Task

As mentioned in the introduction to this section, tasks are intrinsically part of SOA systems. Yet in many cases as an element of an SOA system we talk about not the actual thing being done, rather an abstract representation of it that is used as an element in systems, processes, etc. In other words, we talk about elements representing tasks.

As a simple example, an abstract activity in a process model (associated with a role) may represent a concrete task (done by a person fulfilling that role). Note that due to the atomic nature of a task it does not make sense to talk about many elements representing different aspects of it.

Organizational Example

Continuing the organizational example from above, we can now express which tasks that are done by human actors (people) P1, P2, P3, and P4, and how those tasks can be elements in bigger systems that describe things such as organizational processes.

Previous: SOA-O – Element and System Classes
Next: SOA-O – ServiceClass

SOA-O – Service Class

Service is another core concept of this ontology. It is a concept that is fundamental to SOA and always used in practice when describing or engineering SOA systems, yet it is not easy to define formally. The SOA-O is based on the following definition of service:

“A service is a logical representation of a repeatable activity that has a specified outcome. It is self-contained and is a ‘black box’ to its consumers.”

This corresponds to the existing official Open Group definition of the term.

The word “activity” in the definition above is here used in the general English language sense of the word, not in the process-specific sense of that same word (i.e., activities are not necessarily process activities). The SOA-O purposefully omits “business” as an intrinsic part of the definition of service. The reason for this is that the notion of business is relative to a person’s viewpoint – as an example, one person’s notion of IT is another person’s notion of business (the business of IT). Service as defined by the ontology is agnostic to whether the concept is applied to the classical notion of a business domain or the classical notion of an IT domain.

Other current SOA-specific definitions of the term service include:

  • “A mechanism to enable access to one or more capabilities, where the access is provided using a prescribed interface and is exercised consistent with constraints and policies as specified by the service description.” (Source: OASIS SOA Reference Model)
  • “A capability offered by one entity or entities to others using well-defined ‘terms and conditions’ and interfaces.” (Source: OMG SoaML Specification)

Within the normal degree of precision of the English language, these definitions are not contradictory; they are stressing different aspects of the same concept. All three definitions are SOA-specific though, and represent a particular interpretation of the generic English language term service.

A service is a logical representation of a repeatable activity that has a specified outcome. It is self-contained and is a ‘black box’ to its consumers. The concept of service is captured by the Service OWL class:

SOA-O - Service Class

Figure 1. SOA-O Service Class.

In the context of the SOA-O we consider only SOA-based services. Other domains, such as Integrated Service Management, can have services that are not SOA-based and hence are outside the intended scope of the SOA ontology.

Service is defined as disjoint with the System, Task, and HumanActor classes. Instances of these classes are considered not to be services themselves, even though they may provide capabilities that can be offered as services.

performs and performedBy Properties

As a service itself is only a logical representation, any service is performed by something. The something that performs a service must be opaque to anyone interacting with it, an opaqueness which is the exact nature of the Element class. This concept is captured by the performs and performedBy properties as illustrated in The Service Class (Figure 1). This also captures the fact that services can be performed by elements of other types than systems. This includes elements such as software components, human actors, and tasks.

Note that the same instance of Service can be performed by many different instances of Element. As long as the service performed is the same, an external observer cannot tell the difference (for contractual obligations, SLAs, etc. Conversely, any instance of Element may perform more than one service or none at all.

While a service can be performed by other elements, the service itself (as a purely logical representation) does not perform other services.

Service Consumers and Service Providers

Terminology used in an SOA environment often includes the notion of service providers and service consumers. There are two challenges with this terminology:

  • It does not distinguish between the contractual obligation aspect of consume/provide and the interaction aspect of consume/provide. A contractual obligation does not necessarily translate to an interaction dependency, if for no other reason than because the realization of the contractual obligation may have been sourced to a third party.
  • The above are the reasons why the ontology has chosen not to adopt consume and provide as core concepts, rather instead allows consume or provide terms used with contractual obligations and/or interaction rules described by service contracts. In its simplest form, outside the context of a formal service contract, the interaction aspect of consuming and providing services may even be expressed simply by saying that some element uses (consumes) a service or that some element performs (provides) a service.
  • Consuming or providing a service is a statement that only makes sense in context – either a contractual context or an interaction context. These terms are consequently not well suited for making statements about elements and services in isolation.

uses and usedBy Properties Applied to Service

In one direction, it does not really make sense to talk about a service that uses another element. While the thing that performs the service might very well include the use of other elements (and certainly will in the case of service composition), the service itself (as a purely logical representation) does not use other elements.

In the other direction, we find the most common of all interactions in an SOA environment: the notion that some element uses a service by interacting with it. Note that from an operational perspective this interaction actually reaches somewhat beyond the service itself by involving the following typical steps:

  • Picking the service to interact with (this statement is agnostic as to whether this is done dynamically at runtime or statically at design and/or construct time)
  • Picking an element that performs that service (in a typical SOA environment, this is most often done “inside” an Enterprise Service Bus (ESB))
  • Interacting with the chosen element (that performs the chosen) service (often also facilitated by an ESB)

represents and representedBy Properties Applied to Service

Concepts such as service mediations, service proxies, ESBs, etc. are natural to those practitioners that describe and implement the operational aspects of SOA systems. From an ontology perspective all of these can be captured by some other element representing the service – a level of indirection that is critical when we do not want to bind operationally to a particular service endpoint, rather we want to preserve loose-coupling and the ability to switch embodiments as needed. Note that by leveraging the represents and representedBy properties in this fashion we additionally encapsulate the relatively complex operational interaction pattern that was described in the section above (picking the service, picking an element that performs the service, and interacting with that chosen element).

While a service being represented by something else is quite natural, it is harder to imagine what the service itself might represent. To some degree we have already captured the fact that a service represents any embodiment of it, only we have chosen to use the performs and performedBy properties to describe this rather than the generic represents and representedBy properties. As a consequence, we do not expect practical applications of the ontology to have services represent anything.

Exemplifying the Difference between Doing a Task and Performing a Service

The distinction between a human actor doing a task and an element (technology, human actor, or other) performing a service is important. The human actor doing the task has the responsibility that it gets done, yet may in fact in many cases leverage some service to achieve that outcome:

  • John is an instance of HumanActor.
  • WashWindows is an instance of Task and is done by John.
  • SoapWater is an instance of Service.
  • WaterTap is an instance of Element.
  • WaterTap performs SoapWater.
  • John uses SoapWater (to do WashWindows).

Note how clearly SoapWater does not do WashWindows, nor does WaterTap do WashWindows.

Previous: SOA-O – HumanActor and Task Classes
Next: SOA-O – ServiceContract and Effect Classes

SOA-O ServiceContract and Effect Classes

ServiceContract Class

In many cases, specific agreements are needed in order to define how to use a service. This can either be because of a desire to regulate such use or can simply be because the service will not function properly unless interaction with it is done in a certain sequence. A service contract defines the terms, conditions, and interaction rules that interacting participants must agree to (directly or indirectly). A service contract is binding on all participants in the interaction, including the service itself and the element that provides it for the particular interaction in question. The concept of service contract is captured by the ServiceContract OWL class:

SOA-O - ServiceContract Class

Figure 1. SOA-O ServiceContract Class.

interactionAspect and legalAspect Datatype Properties

Service contracts explicitly regulate both the interaction aspects (see the hasContract and isContractFor properties) and the legal agreement aspects (see the involvedParty and isPartyTo properties) of using a service. The two types of aspects are formally captured by defining the interactionAspect and legalAspect datatype properties on the ServiceContract class. Note that the second of these attributes, the legal agreement aspects, includes concepts such as Service-Level Agreements (SLAs).

If desired, it is possible as an architectural convention to split the interaction and legal aspects into two different service contracts. Such choices will be up to any application using this ontology.

hasContract and isContractFor Properties

The hasContract property, and its inverse isContractFor, capture the abstract notion of a service having a service contract. Anyone wanting to use a service must obey the interaction aspects (as defined in the interactionAspect datatype property) of any service contract applying to that interaction. In that fashion, the interaction aspects of a service contract are contextindependent; they capture the defined or intrinsic ways in which a service may be used.

By definition, any service contract must be a contract for at least one service. It is possible that the same service contract can be a contract for more than one service; for instance, in cases where a group of services share the same interaction pattern or where a service contract (legally – see the involvesParty and isPartyTo properties below) regulates the providing and consuming of multiple services.

involvesParty and isPartyTo Properties

In addition to the rules and regulations that intrinsically apply to any interaction with a service (the interaction aspect of service contracts captured in the interactionAspect datatype property) there may be additional legal agreements that apply to certain human actors and their use of services. The involvesParty property, and its inverse isPartyTo, capture the abstract notion of a service contract specifying legal obligations between human actors in the context of using the one or more services for which the service contract is a contract.

While the involvesParty and isPartyTo properties define the relationships to human actors involved in the service contract, the actual legal obligations on each of these human actors is defined in the legalAspect datatype property on the service contract. This includes the ability to define who is the provider and who is the consumer from a legal obligation perspective.

There is a many-to-many relationship between service contracts and human actors. A given human actor may be party to none, one, or many service contracts. Similarly, a given service contract may involve none, one, or multiple human actors (none in the case where that particular service contract only specifies the interactionAspect datatype property). Note that it is important we allow for sourcing contracts where there is a legal agreement between human actor A and human actor B (both of which are party to a service contract), yet human actor B has sourced the performing of the service to human actor C (aka human actor C performs the service in question, not human actor B).

The involvesParty property together with the legalAspect datatype property on ServiceContract capture not just transient obligations. They include the ability to express “is obliged to at this instant”, “was obliged to”, and “may in future be obliged to”.

Effect Class

Interacting with something performing a service has effects. These comprise the outcome of that interaction, and are how a service (through the element that performs it) delivers value to its consumers. The concept of effect is captured by the Effect OWL class:

SOA-O Effect Class

Figure 2. SOA-O Effect Class.

Note that the Effect class purely represents how results or value is delivered to someone interacting with a service. Any possible internal side-effects are explicitly not covered by the Effect class.

Effect is defined as disjoint with the ServiceInterface class. (The ServiceInterface class is defined later in this document.) Interacting with a service through its service interface can have an outcome or provide a value (an instance of Effect), but the service interface itself does not constitute that outcome or value.

specifies and isSpecifiedBy Properties

While a service intrinsically has an effect every time someone interacts with it, in order to trust the effect to be something in particular, the effect needs to be specified as part of a service contract. The specifies property, and its inverse isSpecifiedBy, capture the abstract notion of a service contract specifying a particular effect as part of the agreement for using a service. Note that the specified effect can apply to both the interactionAspect datatype property (simply specifying what will happen when interacting with the service according to the service contract) and the legalAspect datatype property (specifying a contractually promised effect).

Anyone wanting a guaranteed effect of the interaction with a given service must ensure that the desired effect is specified in a service contract applying to that interaction. By definition, any service contract must specify at least one effect. In the other direction, an effect must be an effect of at least one service contract; this represents that fact that we have chosen only to formalize those effects that are specified by service contracts (and not all intrinsic effects of all services).

ServiceContract Examples

Service-Level Agreements

A Service-Level Agreement (SLA) on a service has been agreed by organizations A and B. It is important to realize that an SLA always has a context of the parties that have agreed to it, involving at a minimum one legal “consumer” and one legal “provider”. This can be represented in the ontology as follows:

  • A and B are instances of HumanActor.
  • Service is an instance of Service.
  • ServiceContract is an instance of ServiceContract.
  • ServiceContract isContractFor Service.
  • ServiceContract involvesParty A.
  • ServiceContract involvesParty B.

The legalAspect datatype property on ServiceContract describes the SLA.

Service Sourcing

Organizations A and B have agreed on B providing certain services for A, yet B wants to source the actual delivery of those services to third-party C. This can be represented in the ontology as follows:

  • A, B, and C are instances of HumanActor.
  • Service is an instance of Service.
  • C provides Service.
  • ServiceContract is an instance of ServiceContract.
  • ServiceContract isContractFor Service.
  • ServiceContract involvesParty A.
  • ServiceContract involvesParty B.

The legalAspect datatype property on ServiceContract describes the legal obligation of B to provide Service for A.

Previous: SOA-O – Service Class
Next: SOA-O- ServiceInterface and InformationType Classes

SOA-O ServiceInterface and Informationtype Classes

ServiceInterface Class

An important characteristic of services is that they have simple, well-defined interfaces. This makes it easy to interact with them, and enables other elements to use them in a structured manner. A service interface defines the way in which other elements can interact and exchange information with a service. This concept is captured by the ServiceInterface OWL class:

SOA-O ServiceInterface Class
Figure 1. SOA-O ServiceInterface Class.

The concept of an interface is in general well understood by practitioners, including the notion that interfaces define the parameters for information passing in and out of them when invoked. What differs from domain to domain is the specific nature of how an interface is invoked and how information is passed back and forth. Service interfaces are typically, but not necessarily, message-based (to support loose-coupling). Furthermore, service interfaces are always defined independently from any service implementing them (to support loose-coupling and service mediation).

From a design perspective interfaces may have more granular operations or may be composed of other interfaces. We have chosen to stay at the concept level and not include such design aspects in the ontology.

ServiceInterface is defined as disjoint with the Service, ServiceContract, and Effect classes. Instances of these classes are considered not to define (by themselves) the way in which other elements can interact and exchange information with a service. Note that there is a natural synergy between ServiceInterface and the interactionAspect datatype property on ServiceContract, as the latter defines any multi-interaction and/or sequencing constraints on how to use a service through interaction with its service interfaces.

Constraints Datatype Property

The Constraints datatype property on ServiceInterface captures the notion that there can be constraints on the allowed interaction such as only certain value ranges allowed on given parameters. Depending on the nature of the service and the service interface in question, these constraints may be defined either formally or informally (the informal case being relevant at a minimum for certain types of real-world services).

hasInterface and isInterfaceOf Properties

The hasInterface property, and its inverse isInterfaceOf, capture the abstract notion of a service having a particular service interface.

In one direction, any service must have at least one service interface; anything else would be contrary to the definition of a service as a representation of a repeatable activity that has a specified outcome and is a ‘black box’ to its consumers. In the other direction, there can be service interfaces that are not yet interfaces of any defined services. Also, the same service interface can be an interface of multiple services. The latter does not mean that these services are the same, nor even that they have the same effect; it only means that it is possible to interact with all these services in the manner defined by the service interface in question.

InformationType Class

A service interface can enable another element to give information to or receive information from a service (when it uses that service); specifically the types of information given or received. The concept of information type is captured by the InformationType OWL class:

SOA-O InformationType Class

Figure 2. SOA-O InformationType Class

In any concrete interaction through a service interface the information types on that interface are instantiated by information items, yet for the service interface itself it is the types that are important. Note that the constraints datatype property on ServiceInterface, if necessary, can be used to express constraints on allowed values for certain information types.

hasInput and isInputAt Properties

The hasInput property, and its inverse isInputAt, capture the abstract notion of a particular type of information being given when interacting with a service through a service interface.

Note that there is a many-to-many relationship between service interfaces and input information types. A given information type may be input at many service interfaces or none at all. Similarly, a given service interface may have many information types as input or none at all. It is important to realize that some services may have only inputs (triggering an asynchronous action without a defined response) and other services may have only outputs (elements performing these services execute independently yet may provide output that is used by other elements).

hasOutput and isOutputAt Properties

The hasOutput property, and its inverse isOutputAt, capture the abstract notion of a particular type of information being received when interacting with a service through a service interface.

Note that there is a many-to-many relationship between service interfaces and output information types. A given information type may be output at many service interfaces or none at all. Similarly, a given service interface may have many information types as output or none at all. It is important to realize that some services may have only inputs (triggering an asynchronous action without a defined response) and other services may have only outputs (elements performing these services execute independently yet may provide output that is used by other elements).

Examples

Interaction Sequencing

A service contract on a service expresses that the services interfaces on that service must be used in a certain order:

  • Service is an instance of Service.
  • ServiceContract is an instance of ServiceContract.
  • ServiceContract isContractFor Service.
  • X is an instance of ServiceInterface.
  • X isInterfaceOf Service.
  • Y is an instance of ServiceInterface.
  • Y isInterfaceOf Service.

The interactionAspect datatype property on ServiceContract describes that X must be used before Y may be used.

Previous: SOA-O – ServiceContract and Effect Classes
Next: SOA-O – Composition Class

SOA-O Composition Class

The notion of composition is a core concept of SOA. Services can be composed of other services. Processes are composed of human actors, tasks, and possibly services. Experienced SOA practitioners intuitively apply composition as an integral part of architecting, designing, and realizing SOA systems; in fact, any well structured SOA environment is intrinsically composite in the way services and processes support business capabilities. What differs from practitioner to practitioner is the exact nature of the composition – the composition pattern being applied.

A composition is the result of assembling a collection of things for a particular purpose. Note in particular that we have purposefully distinguished between the act of composing and the resulting composition as a thing, and that it is in the latter sense we are using the concept of composition here. The concept of composition is captured by the Composition OWL class:

SOA-O Composition Class

Figure 1. SOA-O Composition Class.

Being intrinsically (also) an organized collection of other, simpler things, the Composition class is a subclass of the System class. While a composition is always also a system, a system is not necessarily a composition in that it is not necessarily a result of anything – note here the difference between a system producing a result and the system itself being a result. A perhaps more tangible difference between a system and a composition is that the latter must have associated with it a specific composition pattern that renders the composition (as a whole) as the result when that composition pattern is applied to the elements used in the composition. One implication of this is that there is not a single member of a composition that represents (as an element) that composition as a whole; in other words, the composition itself is not one of the things being assembled. On the other hand, composition is in fact a recursive concept (as are all subclasses of System) – being a system, a composition is also an element which means that it can be used by a higher-level composition.

In the context of the SOA-O we consider in detail only functional compositions that belong to the SOA domain. Note that a fully described instance of Composition must have by its nature a uses relationship to at least one instance of Element. (It need not necessarily have more than one as the composition pattern applied may be, for instance, simply a transformation.) Again (as for System) it is important to realize that a composition can use elements outside its own boundary.

Since Composition is a subclass of Element, all compositions have a boundary and are opaque to an external observer (black box view). The composition pattern in turn is the internal viewpoint (white box view) of a composition. As an example, for the notion of a service composition this would correspond to the difference between seeing the service composition as an element providing a (higher-level) service or seeing the service composition as a composite structure of (lower-level) services.

compositionPattern Datatype Property

As discussed above, any composition must have associated with it a specific composition pattern, that pattern describing the way in which a collection of elements is assembled to a result. The concept of a composition pattern is captured by the compositionPattern datatype property. Note that even though certain kinds of composition patterns are of special interest within SOA, the compositionPattern datatype property may take any value as long as that value describes how to assemble the elements used by the composition with which it is associated.

The Orchestration Composition Pattern

One kind of composition pattern that has special interest within SOA is an orchestration. In an orchestration (a composition whose composition pattern is an orchestration), there is one particular element used by the composition that oversees and directs the other elements. Note that the element that directs an orchestration by definition is different than the orchestration (Composition instance) itself.

Think of an orchestrated executable workflow as an example of an orchestration. The workflow construct itself is one of the elements being used in the composition, yet it is different from the composition itself – the composition itself is the result of applying (executing) the workflow on the processes, human actors, services, etc. that are orchestrated by the workflow construct.

A non-IT example is the foreman of a road repair crew. If the foreman chooses to exert direct control over the tasks done by his crew, than the resulting composition becomes an orchestration (with the foreman as the director and provider of the composition pattern). Note that under other circumstances, with a different team composition model, a road repair crew can also act as a collaboration or a choreography. (See below for definitions of collaboration and choreography.) As the last example clearly shows, using an orchestration composition pattern is not a guarantee that “nothing can go wrong”. That would, in fact, depend on the orchestration director’s ability to handle exceptions.

The Choreography Composition Pattern

Another kind of composition pattern that has special interest within SOA is a choreography. In a choreography (a composition whose composition pattern is a choreography) the elements used by the composition interact in a non-directed fashion, yet with each autonomous member knowing and following a predefined pattern of behavior for the entire composition.

Think of a process model as an example of a choreography. The process model does not direct the elements within it, yet does provide a predefined pattern of behavior that each such element is expected to conform to when “executing”.

The Collaboration Composition Pattern

A third kind of composition pattern that has special interest within SOA is a collaboration. In a collaboration (a composition whose composition pattern is a collaboration) the elements used by the composition interact in a non-directed fashion, each according to their own plans and purposes without a predefined pattern of behavior. Each element simply knows what it has to do and does it independently, initiating interaction with the other members of the composition as applicable on its own initiative. This means that there is no overall predefined “flow” of the collaboration, though there may be a run-time “observed flow of interactions”.

A good example of a collaboration is a work meeting. There is no script for how the meeting will unfold and only after the meeting has concluded can we describe the sequence of interactions that actually occurred.

orchestrates and orchestratedBy Properties

As defined above, an orchestration has one particular element that oversees and directs the other elements used by the composition. This type of relationship is important enough that we have chosen to capture the abstract notion in the orchestrates property and its inverse orchestratedBy.

In one direction, a composition has at most one element that orchestrates it, and the cardinality can only be one (1) if in fact the composition pattern of that composition is an orchestration. In the other direction, an element can orchestrate at most one composition which then must have an orchestration as its composition pattern.

Note that in practical applications of the ontology, even though Service is a subclass of Element, a service (as a purely logical representation) is not expected to orchestrate a composition.

Previous: SOA-O ServiceInterface and InformationType Classes
Next: SOA-O ServiceComposition and Process Classes

SOA-O ServiceComposition and Process Classes

ServiceComposition Class

A key SOA concept is the notion of service composition, the result of assembling a collection of services in order to perform a new higher-level service. The concept of service composition is captured by the ServiceComposition OWL class:

SOA-O ServiceComposition Class

Figure 1. SOA-O ServiceComposition Class.

As a service composition is the result of assembling a collection of services, ServiceComposition is naturally a subclass of Composition.

A service composition may, and typically will, add logic (or even “code”) via the composition pattern. Note that a service composition is not the new higher-level service itself (due to the System and Service classes being disjoint); rather it performs (as an element) that higher-level service.

Process Class

Another key SOA concept is the notion of process. A process is a composition whose elements are composed into a sequence or flow of activities and interactions with the objective of carrying out certain work. This definition is consistent with, for instance, the Business Process Modeling Notation (BPMN) 2.0 definition of a process. The concept of process is captured by the Process OWL class:

SOA-O Process Class

Figure 2. SOA-O Process Class.

Elements in process compositions can be things like human actors, tasks, services, other processes, etc. A process always adds logic via the composition pattern; the result is more than the parts. According to their collaboration pattern, processes can be:

  • Orchestrated: When a process is orchestrated in a business process management system, then the resulting IT artifact is in fact an orchestration; i.e., it has an orchestration collaboration pattern. This type of process is often called a process orchestration.
  • Choreographed: For example, a process model representing a defined pattern of behavior. This type of process is often called a process choreography.
  • Collaborative: No (pre)defined pattern of behavior (model); the process represents observed (executed) behavior.

Examples

Simple Service Composition Example

Using a service composition example, services A and B are instances of Service and the composition of A and B is an instance of ServiceComposition (that uses A and B):

  • A and B are instances of Service.
  • X is an instance of ServiceComposition.
  • X uses both A and B (composes them according to its service composition pattern).

Note that there are various ways in which the service composition pattern can compose A and B, all of which are relevant in one situation or another. For example, interfaces of X may or may not include some subset of the interfaces of A and B. Furthermore, the interfaces of A and B may or may not also be (directly) invocable without going through X – that is a matter of the service contracts and/or access policies that apply to A and B. Finally, X may also use other elements that are not services at all (examples are composition code, adaptors, etc.).

Process Example

Using a process example, tasks T1 and T2 are instances of Task, roles R1 and R2 are instances of Element, and the composition of T1, T2, R1, and R2 is an instance of Process (that uses T1, T2, R1, and R2):

  • T1 and T2 are instances of Task.
  • R1 and R2 are instances of Element.
  • Y is an instance of Process.
  • Y uses all of T1, T2, R1, and R2 (composes them according to its process composition pattern).

Process and Service Composition Example

Elaborating on the process example above, if T1 is done using service S then:

  • S is an instance of Service.
  • T1 uses S.

Note that depending on the particular design approach chosen (and the resulting composition pattern), Y may or may not use S directly. This depends on whether Y carries the binding between T1 and S or whether that binding is encapsulated in T1.

Previous: SOA-O Composition Class
Next: SOA-O Policy Class

SOA-O Policy Class

Policies, the human actors defining them, and the things that they apply to are important aspects of any system, certainly also SOA systems with their many different interacting elements. Policies can apply to any element in a system. The concept of policy is captured by the Policy class and its relationships to the HumanActor and Thing classes.

A policy is a statement of direction that a human actor may intend to follow or may intend that another human actor should follow. Knowing the policies that apply to something makes it easier and more transparent to interact with that something. The concept of policy is captured by the Policy OWL class:

SOA-O Policy Class

Figure 1. SOA-O Policy Class.

Policy as a concept is generic and has relevance outside the domain of SOA. For the purposes of this SOA ontology it has not been necessary or relevant to restrict the generic nature of the Policy class itself. The relationships between Policy and HumanActor are of course bound by the SOA-specific restrictions that have been applied on the definition of HumanActor.

From a design perspective policies may have more granular parts or may be expressed and made operational through specific rules. We have chosen to stay at the concept level and not include such design aspects in the ontology.

Policy is distinct from all other concepts in this ontology, hence the Policy class is defined as disjoint with all other defined classes. In particular, Policy is disjoint with ServiceContract. While policies may apply to service contracts – such as security policies on who may change a given service contract – or conversely be referred to by service contracts as part of the terms, conditions, and interaction rules that interacting participants must agree to, service contracts are themselves not policies as they do not describe an intended course of action.

appliesTo and isSubjectTo Properties

Policies can apply to things other than elements; in fact, policies can apply to anything at all, including other policies. For instance, a security policy might specify which actors have the authority to change some other policy. The appliesTo property, and its inverse isSubjectTo, capture the abstract notion that a policy can apply to any instance of Thing. Note specifically that Element is a subclass of Thing, hence policies by inference can apply to any instance of Element.

In one direction, a policy can apply to zero (in the case where a policy has been formulated but not yet explicitly applied to anything), one, or more instances of Thing. Note that having a policy apply to multiple things does not mean that these things are the same, only that they are (partly) regulated by the same intent. In the other direction, an instance of Thing may be subject to zero, one, or more policies. Note that where multiple policies apply to the same instance of Thing this is often because the multiple policies are from multiple different policy domains (such as security and governance).

The SOA ontology does not attempt to enumerate different policy domains; such policy-focused details are deemed more appropriate for a policy ontology. It is worth pointing out that a particular policy ontology may also restrict (if desired) the kinds of things that policies can apply to.

setsPolicy and isSetBy Properties

The setsPolicy property, and its inverse isSetBy, capture the abstract notion that a policy can be set by one or more human actors.

In one direction, a policy can be set by zero (in the case where actors setting the policy by choice are not defined or captured), one, or more human actors. Note specifically that some policies are set by multiple human actors in conjunction, meaning that all these human actors need to discuss and agree on the policy before it can take effect. A real-world example would be two parents in conjunction setting policies for acceptable child behavior. In the other direction, a human actor may potentially set (or be part of setting) multiple policies.

The SOA ontology purposefully separates the setting of the policy itself and the application of the policy to one or more instances of Thing. In some cases these two acts may be inseparably bound together, yet in other cases they are definitely not. One such example is an overall compliance policy that is formulated at the corporate level yet applied by the compliance officer in each line of business.

Also, while a particular case of interest for this ontology is that where the provider of a service has a policy for the service, a policy for a service is not necessarily owned by the provider. For example, government food and hygiene regulations (a policy that is law) cover restaurant services independently of anything desired or defined by the restaurant owner.

Previous: SOA-O ServiceComposition and Process Classes
Next: SOA-O Event Class

SOA-O Event Class

An event is something that happens, to which an element may choose to respond. Events can be responded to by any element. Similarly, events may be generated (emitted) by any element. Knowing the events generated or responded to by an element makes it easier and more transparent to interact with that element. Note that some events may occur whether generated or responded to by an element or not. The concept of event is captured by the Event OWL class:

SOA-O Event Class

Figure 1. SOA-O Event Class.

Event as a concept is generic and has relevance to the domain of SOA as well as many other domains. For the purposes of this ontology, event is used in its generic sense.

From a design perspective events may have more granular parts or may be expressed and made operational through specific syntax or semantics. We have chosen to stay at the concept level and not include such design aspects in the ontology.

generates and generatedBy Properties

Events can, but need not necessarily, be generated by elements. The generates property, and its inverse generatedBy, capture the abstract notion that an element generates an event.

Note that the same event may be generated by many different elements. Similarly, the same element may generate many different events.

respondsTo and respondedToBy Properties

Events can, but need not necessarily, be responded to by elements. The respondsTo property, and its inverse respondedToBy, capture the abstract notion that an element responds to an event.

Note that the same event may be responded to by many different elements. Similarly, the same element may respond to many different events.

Previous: SOA-O Policy Class
Next: Service Oriented Architecture Modeling Language (SoaML) – Introduction

Service oriented architecture Modeling Language (SoaML) – Introduction

Overview

Service Oriented Architecture (SOA) is a paradigm for defining how people, organizations and systems provide and use services to achieve results.

The Service oriented architecture Modeling Language (SoaML) provides a metamodel for specifying and designing services within a service-oriented architecture. 1

The SoaML extends the capabilities of the Unified Modeling Language (UML) to support:

  • Identifying services, the requirements they are intended to fulfill, and the anticipated dependencies between them
  • Specifying services, including the functional capabilities they provide, what capabilities consumers are expected to provide, the protocols or rules for using them, and the service information exchanged between consumers and providers
  • Defining service consumers and providers, what requisition and services they consume and provide, how they are connected, and how the service functional capabilities are used by consumers and implemented by providers in a manner consistent with both the service specification protocols and fulfilled requirements
  • The policies for using and providing services
  • The ability to define classification schemes having aspects to support a broad range of architectural, organizational, and physical partitioning schemes and constraints
  • Defining service and service usage requirements, and linking them to related metamodels, e.g. the Business Motivation Model (BMM), the UML UseCase model

Previous: SOA-O Event Class
Next: SOA-3 Overview

Resources

Next: Identifying services

  1. The SoaML focuses on basic service modeling concepts. The intention is to use this as a foundation for further extensions both related to integration with other metamodels like the Ontology Definition Metamodel (ODM), the Organization Structure Metamodel (OSM), the Semantics of Business Vocabulary and Business Rules (SBVR), the Business Process Definition Metamodel (BPDM), and the Business Process Model Notation (BPMN).

SOA-3 Overview

We bring together our presentations of the SOA-RM, the SOA-O, and the SoaML under two categories:

  1. Conformance with the Reference Model
  2. Cross-coverage of core concepts

Conformance

The authors of the Conformance Guidelines of the Reference Model for Service Oriented Architecture (SOA-RM, section 4) expect that any design for a system that adopts the SOA approach will:

  • Have entities that can be identified as services as defined by this Reference Model;
  • Be able to identify how visibility is established between service providers and consumers;
  • Be able to identify how interaction is mediated;
  • Be able to identify how the effect of using services is understood;
  • Have descriptions associated with services;
  • Be able to identify the execution context required to support interaction; and
  • It will be possible to identify how policies are handled and how contracts may be modeled and enforced.

SoaML’s Conformance with SOA-RM

Be able to identify how visibility is established between service providers and consumer

SoaML defines a Service metaclass –  a kind of UML Port, which establishes the interaction point between service consumers and providers. A Service’s type is a ServiceInterface that provides all the information needed by a consumer to use a service. Mechanisms for discovering existing services and descriptions consumers would use to determine the applicability of availability of existing services for their needs (awareness) are out of scope.

Be able to identify how interaction is mediated

Interaction between a service consumer and provider connected through a service channel is mediated by the protocol specified by the service provider. The protocol is defined by the service interface used as the type of the service and may include a behavior that specifies the dynamic aspects of service interaction. The interfaces  realized and used by a service specification define the operations, parameters, preconditions, post conditions (real world effect), exceptions and other policy constraints that make up the static portion of the service specification.

Be able to identify how the effect of using services is understood

The effect of a service is specified by the post conditions of the provided service operations assuming the consumer follows the policies, preconditions, and protocols specified by the service interface.

Have descriptions associated with services

This specification includes a service interface for describing the means of interacting with a service. Service discovery and applicability are out of scope.

Be able to identify the execution context required to support interaction

The execution context is specified by the semantics for UML2 as extended by this specification.

It will be possible to identify how policies are handled and how contracts may be modeled and enforced

Policies are constraints that can be owned rules of any model element, including in particular service ports and service participant components. The actual form of these policies is out of scope.

The authors of the SoaML have also collected other definitions around services and SOA and are analyzing this with respect to further need for harmonization between the standardization groups, in particular for the use of the concept service.

SOA-O Conformance with SOA-RM

The Open Group SOA Ontology extends, refines, and formalizes some of the core concepts of the SOA RM. It is used for understanding of core SOA concepts and facilitates a model-driven approach to SOA development.

Cross Coverage of Core Concepts

The authors of the Service Oriented Architecture Modeling Language (SoaML, Appendix A) provided a table that compared the definition of the main concepts of the SOA-RM, the SOA-O (older version), and the SoaML:

Concept SoaML SOA-RM SOA-O
Service Oriented Architecture An architectural paradigm for defining how people, organizations and systems provide and use services to achieve results. A paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains. An architectural style that supports service orientation.  An architectural style is the combination of distinctive features in which architecture is performed or expressed.
Service Service is defined as a resource that enables access to one or more capabilities. Here, the access is provided using a prescribed interface and is exercised consistent with constraints and policies as specified by the service description.  This access is provided using a prescribed interface and is exercised consistent with constraints and policies as specified by the service description. A service is provided by an entity—called the provider—for use by others.  The eventual consumers of the service may not be known to the service provider and may demonstrate uses of the service beyond the scope originally conceived by the provider. A mechanism to enable access to one or more capabilities, where the access is provided using a prescribed interface and is exercised consistent with constraints and policies as specified by the service description. A logical representation of a repeatable business activity that has a specified outcome (e.g., check customer credit; provide weather data, consolidate drilling reports). It is self-contained, may be composed of other services, and is a “black box” to its consumers.
Service Contract A ServiceContract is the formalization of a binding exchange of information, goods, or obligations between parties defining a service. A ServiceContract is the specification of the agreement between providers and consumers of service as to what information, products, assets, value, and obligations will flow between the providers and consumers of that service – it specifies the service without regard for realization or implementation. A contract represents an agreement by two or more parties. A service contract is a measurable assertion that governs the requirements and expectations of two or more parties. Adopts SOA-RM definition
Service Interface Defines the interface to a Service or Request. A ServiceInterface defines the interface and responsibilities of a participant to provide or consume a service. It is used as the type of a Service or Request port. A ServiceInterface is the means for specifying how to interact with a Service. Service Description The information needed in order to use, or consider using, a service. Description An information item that is represented in words, possibly accompanied by supporting material such as graphics. The Description class corresponds to the concept of a description as a particular kind of information item that applies to something in particular – the thing that it describes. It is not just a set of words that could apply to many things.
Collaboration Collaboration from UML is extended to describe ServiceContracts and ServicesArchitectures. Interaction: The activity involved in making using of a capability offered, usually across an ownership boundary, in order to achieve a particular desired real-world effect.
CollaborationUse CollaborationUse shows how a Collaboration (ServiceContracts and ServiceArchitectures) is fulfilled.
Capability Identifies or specifies a cohesive set of functions or capabilities that a service provides. The ability to act and produce an outcome that achieves a result. As such, capability involves the capacity, power, or fitness for some specified action or operation. This implies that the entity must have physical, mental, or legal power to generate an outcome that achieves a real world effect. (synonymous with capability). A Capability models the capability for providing, or provided by, a service specified by a ServiceContract or ServiceInterface.
Participant The type of a provider and/or consumer of services.  In the business domain a participant may be a person, organization, or system.  In the systems domain a participant may be a system or component. Not explicitly defined
Request Port (port stereotype) A request port defines the port through which a Participant makes requests and uses or consumes services.
Service Port (port stereotype) The service port stereotype of a port defines the connection point the point of interaction on a Participant where a service is actually provided or consumed.
ServiceChannel A communication path between Requests and Services.
Real World Effect Defined as “service operation post condition.” The actual result of using a service, rather than merely the capability offered by a service provider. Defined as Effect. Comprises the outcome of performance of the service, and is the value delivered.

Previous: SoaML – Introduction
Next: SOA-3 Service

SOA-3 – Service

Definitions of Service

Service Oriented Architecture (SOA) is, above all, an approach that specifies how entities can best work together to meet a set of objectives. SOA separates what needs to get done from how it gets done, where it gets done, and what or who gets it done.

Current SOA-related standards stress different aspects of the meaning of “service”:

  • “A mechanism to enable access to one or more capabilities, where the access is provided using a prescribed interface and is exercised consistent with constraints and policies as specified by the service description.” (OASIS SOA Reference Model – SOA-RM)
  • “A service is a logical representation of a repeatable activity that has a specified outcome. It is self-contained and is a ‘black box’ to its consumers.” (The Open Group: Service Oriented Architecture Ontology – SOA-O)
  • “A service is value delivered to another through a well-defined interface and available to a community (which may be the general public). A service results in work provided to one by another.” (Object Management Group: Service Oriented Architecture Modeling Lanaguage – SoaML)

A consumer accesses a service by means of a service interface, comprising the specific of how to access an underlying capability offered by the .

A consumer may be unknown to the provider.

A service is opaque, that is, its implementation is typically hidden from the service consumer (“black box”) except for the information required by service consumers to determine whether a given service is appropriate to their needs, and for the behavior model exposed through the service interface (“white box”).

The consequence of invoking a service is a realization of some real world effect that may include:

  1. information returned in response to a request for that information,
  2. a change to the shared state of defined entities, or
  3. some combination of (1) and (2).

Typically the consumer does not know how the information in (1) is generated, or how the state change in (2) is effected.

A consumer may demonstrate uses of a service beyond the scope originally conceived by the provider (“co-creation of value”).

Representations of Service

In addition to these discussions of “service” in (more or less) plain English, we have two formal means of representing “service” – an OWL ontology (SOA-O) and a UML2 Profile (SoaML):

[code language=”xml”]</span>
<owl:Class rdf:about="#Element">
</owl:Class>
<owl:Class rdf:about="#Service">
<rdfs:subClassOf>
<owl:Class rdf:about="#Element"/>
</rdfs:subClassOf>
</owl:Class>
<owl:ObjectProperty rdf:about="#performs">
<rdfs:domain rdf:resource="#Element"/>
<rdfs:range rdf:resource="#Service"/>
</owl:ObjectProperty>

<owl:ObjectProperty rdf:about="#performedBy">
<owl:inverseOf>
<owl:ObjectProperty rdf:about="#performs"/>
</owl:inverseOf>
</owl:ObjectProperty>
<span style="color: #ffffff;">[/code]

and
SOA-O Service Class

Domains of Service

A service may apply (1) to a “real” world (e.g. social or business) domain or (2) to an IT domain. There is also a third (hybrid) sense of service:

A service [IT domain] may be provided in the service of another service [business domain].

Our concern is primarily in “real” world services – though, undoubtedly, software services will play an increasing role in service requests and service provisions.

At this point, we need to incorporate more “real” world thinking and technologies into our (so far deliberately abstract) description and model of service.

Previous: SOA-3 Overview

Next: SOA-3 XXX or SOA-3 Service + Supplementary Ontologies

Jim Amsden – Service oriented architecture Modeling Language (SoaML)

Jim Amsden is Senior Technical Staff Member, IBM. His papers provide a nice introduction to SoaML – a technology I’ll be using to visualize a vocabulary of Government Services derived from Schema.org.

Modeling with SoaML (2010)

Using SoaML Services Architecture (2012)

Integrating BPMN and SoaML (2014)

 

SoaML – Identifying services

Overview

SOA strives to be business-relevant – driven by the business and implemented to support the business. SOA solutions need to be connected to the business requirements that they fulfill. We need a way to formalize business requirements so that SOA can more closely resemble business services and how those services might meet business objectives – this ties the deployed SOA solution to its intended business value. We also need a way to isolate business concerns from the evolving SOA platforms that support them.

Models allow us to abstract away from the implementation details and focus on the issues that drive business and architectural decisions.

Usually one begins by describing the business motivation that establishes the business objectives. One then models high-level business processes that are business requirements to meet the objectives. We are now ready to create a model to meet these requirements – by identifying capabilities, exposing appropriate candidate capabilities as services, and then defining the architecture for how the services interact.

To identify services, one treats the business process as a Service Requirement contract – then service specifications and service providers are designed and connected together in a manner that fulfills the business requirements while addressing software architectural concerns.

This process of identifying candidate services from a business model is also known as domain decomposition.

SoaML provides several ways of identifying services. The requirements from the business process could be viewed as a service architecture, thus indicating the participants in the business processes, the service contracts that specify how they interact, and the choreography of their services and requests.

A service architecture is a formal specification of the business requirements that are performed by interacting service participants.

The example we will use in our series on SoaML is based on the Purchase Order Process example taken from the OMG SoaML standard, and it is based in the BEPL 1.1 specification.

Scenario: A consortium of companies has decided to collaborate to produce a reusable service for processing purchase orders. These are the goals of the project:

  • Establish a common means of processing purchase orders
  • Ensure that orders are processed in a timely manner and deliver the required goods
  • Help minimize stock on hand and inventory maintenance costs
  • Minimize production and shipping costs

We will skip over the discussion of how to identify services in Amsden’s original article, as our primary interest is using SoaML to model a vocabulary of government service, including a vocabulary derived from schema.org.

There are five main packages in the PurchaseOrderProcess model:

  1. org::ordermanagement – contains elements concerned with order management
  2. org::crm – contains the data model and common interfaces for some envisioned customer
  3. com::acme::credit – contains elements concerned with invoicing and credit management
  4. com::acme::productions – contains elements that are concerned with productions and scheduling
  5. com::acme::shipping – contains elements concerned with shipping

These packages divide the problem domain into different functional areas. This helps manage complexity, establishes required name spaces, facilitates reuse, and keeps separate concerns in different packages. Here’s the package dependencies diagram for our service model:

SoaML - package dependencies in service model of processing purchasing orders

This organization could be called the dominant organization of the service model. Perspective packages can be used to document other ways of organizing the same model elements.

Service identification consists of determining which capabilities should be exposed as services. The IBM SOMA method provides a Service Litmus Test that can be applied to capabilities to determine which ones should be exposed as services. The Service Litmus Test examines each capability and applies various configurable metrics to determine which one(s) should be exposed as services. See RUP for SOMA for details.

We close with Amsden’s figure that shows the service architecture for processing purchase orders at the end of the exercise of identifying services:

Service architecture for processing purchase orders

 

Summary

SoaML may be used to identify services that are connected to business requirements:

  • capture the business objectives necessary to realize the business mission
  • model the business processes that are necessary to meet the business objectives
  • use the business requirements and business processes to identify the required capabilities and the potential relationships between them

Capabilities are treated as candidate services. The capabilities that passed the service litmus test were used to identify the required service interfaces. This ties the service interfaces back to the business requirements.

The result is a formal structure for identifying business-relevant capabilities that are linked to the business objectives that that they are intended to fulfill.

Previous: Service oriented architecture Modeling Language

Next: SoaML – Specifying services

SoaML – Specifying services

In a previous post, we outlined an approach for identifying services that are connected to the business requirements of an enterprise.

Here we will model the specification of each service in detail. These specifications define the interfaces between consumers and producers of the service. These contracts include the provided and required interfaces, the roles that those interfaces play in the service specification, and the rules or protocols for how those roles interact.

Overview of service specifications

A service interface must specify everything that a potential consumer of the service needs:

  • to decide whether they are interested in using the service
  • to know how to use it

A service interface must also specify everything that a provider of the service needs:

  • to know to implement the service successfully

At the heart of SOA is the construction of service value chains that connect user needs with compatible provider capabilities.

A service interface defines the goals, needs, and expectations of user participants (i.e. consumers) as well as the value propositions, capabilities, and commitments of provider participants. Therefore, they provide the information necessary to determine compatible needs and capabilities.

A service interface includes:

  • The name of the service, suggesting its purpose
  • The provided and required interfaces, thereby defining the functional capabilities that are provided by the service and those that it requires of its users – Note: this is not about how the service is implemented, but rather the interaction between the consumers and providers of this service. Each functional capability includes:
    • Its name, which is often a verb phrase indicating what it does
    • Any required or optional service data inputs and outputs
    • Any pre-conditions that consumers are expected to meet before using the capability
    • Any post-conditions that consumers can expect and that providers must provide upon successful use of the capability
  • Any communication protocol or rule that specifies rules for how the functional capabilities are used or in what order
  • Any capabilities that consumers are expected to provide to be able to use or interact with the service
  • Requirements that any implementer must meet when providing the service
  • Constraints that reflect what successful use of the service is intended to accomplish and how it will be evaluated
  • Qualities that service consumers should expect and that providers are expected to provide, such as cost, availability, performance, footprint, suitability to the task, competitive information, etc
  • Policies for using the service, such as security and transaction scopes for maintaining security and integrity or for recovering from the inability to successfully perform the service or any required service

Qualities that service consumers should expect and policies for using a service may be specific to particular providers of a service, not the interface of a particular service itself.

A service interface tells you everything you need to know about a service – including the requirements that you have to meet to use the service (sometimes called the Use or Usage contract (see Daniels and Cheesman article), plus the requirements that an implementer of the service has to meet (sometimes called the Realization contract). This is the same information that we needed to capture for the business requirements, except that the subject area and level of detail are different.

Example

Returning to our example, Figure 1 shows the service interfaces that expose the capabilities required for processing purchase orders:

SoaML Specifying services - Capabilities

 

Figure 1.

Let’s elaborate on each of the identified service specifications in Figure 1. The presentation order is from a very simple service interface that has no protocol, to a service interface that represents a simple request-response protocol, to a more complex service interface that involves a multi-step protocol and interaction between the user and provider.

Scheduling service interface

The Scheduling service interface shown in Figure 2 is very simple.

SoaML Specifying services - Scheduling service interface

Figure 2.

The service provides two operations: the ability to respond to a production schedule request and the ability to create a shipping schedule. These operations were created by examining the functions of the capabilities the service interface is exposing. As far as we know, in this situation there is no protocol for using these operations. Either can be used in any order.

The Scheduling service interface is a simple UML interface defined in the productions package. It provides two service operations. Each of these operations can have pre-conditions and post-conditions, and they can raise exceptions. The parameters of the service operations are required to be either service data (DataType or MessageType) or primitive types. This ensures that the parameters make no assumptions about call-by-reference or call-by-value, where the service data is located (in what address space), whether the service user or provider is operating on a copy of the data or some persistent data source, and so on. All of this is required to ensure that the service is not constrained by where it can be deployed in relation to other services. The service data is defined below.

Shipping service

 

 

 

 

A Vocabulary of Government Service – Part I

Previously we described the inheritance hierarchy of Classes in Schema.org and visualized this hierarchy as an expandable/collapsible tree using d3.

Now we build upon that work to develop a vocabulary of Classes and their Properties for describing government service.

Seeding the Vocabulary

The starting point for seeding our vocabulary is Schema.org’s Class GovernmentService, used to describe a service that is provided by a government organization or by an organization that is funded by government.

Figure 1 illustrates the pathway to Class GovernmentService within Schema.org’s Inheritance Hierarchy.

Figure 1. Pathway to GovernmentService through Schema.org.

Class GovernmentService has one Property – serviceOperator that is expected to be of Type Organizationanother Class in Schema.org. GovernmentService is the Domain of serviceOperator and Organization is its Range.

Schema.org’s website represents the above in the form of a Table:

Properties from GovernmentService
Property Range Description
serviceOperator Organization The operating organization, if different from the provider. This enables the representation of services that are provided by an organization, but operated by another organization like a subcontractor.

Table 1. Properties of Class GovernmentService.

We may also represent the information in Table 1 as a Graph, where the Nodes are Classes and Properties, and where the Links are relations connecting them:

Source Node Target Node Link
GovernmentService serviceOperator hasProperty
serviceOperator Organization hasRange

Table 2. Graph of vocabulary for describing service that is provided by a government organization.

Extending the Vocabulary – Cycle 1

This start on a vocabulary for describing government service may be extended in a systematic fashion – first, by incorporating any SuperClass (and its Properties) that contains GovernmentService as a Subclass.

In this manner, our vocabulary extends to include Class Service, Intangible, and Thingas well as their respective Properties. (Note that these Classes are the points highlighted along the pathway in Figure 1).

Again, Schema.org’s website represents each of these SuperClasses in the form of a Table:

Properties from Service
Property Range Description
availableChannel ServiceChannel A means of accessing the service (e.g. a phone bank, a web site, a location, etc.)
produces Thing The tangible thing generated by the service, e.g. a passport, permit, etc.
provider Person  or
Organization
The service provider, service operator, or service performer; the goods producer. Another party (a seller) may offer those services or goods on behalf of the provider. A provider may also serve as the seller.
serviceArea AdministrativeArea The geographic area where the service is provided.
serviceAudience Audience The audience eligible for this service.
serviceType Text The type of service being offered, e.g. veterans’ benefits, emergency relief, etc.

Table 3.1. Properties of Class GovernmentService that are inherited from Class Service.

and

Properties from Thing
Property Range Description
additionalType URL An additional type for the item, typically used for adding more specific types from external vocabularies in microdata syntax. This is a relationship between something and a class that the thing is in. In RDFa syntax, it is better to use the native RDFa syntax – the ‘typeof’ attribute – for multiple types. Schema.org tools may have only weaker understanding of extra types, in particular those defined externally.
alternateName Text An alias for the item.
description Text A short description of the item.
image URL  or
ImageObject
An image of the item. This can be a URL or a fully described ImageObject.
name Text The name of the item.
potentialAction Action Indicates a potential Action, which describes an idealized action in which this thing would play an ‘object’ role.
sameAs URL URL of a reference Web page that unambiguously indicates the item’s identity. E.g. the URL of the item’s Wikipedia page, Freebase page, or official website.
url URL URL of the item.

Table 3.2. Properties of Class GovernmentService that are inherited from Class Thing.

Class Intangible has no Properties of its own – all of its Properties are inherited from Class Thing.

At the end of Cycle 1 of extending the vocabulary, our Graph is looking much more respectable (compared to Table 1):

At the end of Cycle 1 of extending the vocabulary, our Graph has become much richer (compared to Table 1):

Source Node Target Node Relation
Thing Intangible hasSubclass
Intangible Service hasSubclass
Service GovernmentService hasSubclass
Thing additionalType hasProperty
Thing alternateName hasProperty
Thing description hasProperty
Thing image hasProperty
Thing name hasProperty
Thing potentialAction hasProperty
Thing sameAs hasProperty
Thing url hasProperty
Service availableChannel hasProperty
Service produces hasProperty
Service provider hasProperty
Service serviceArea hasProperty
Service serviceAudience hasProperty
Service serviceType hasProperty
GovernmentService serviceOperator hasProperty
additionalType URL hasRange
alternateName Text hasRange
availableChannel ServiceChannel hasRange
description Text hasRange
image ImageObject hasRange
image URL hasRange
name Text hasRange
potentialAction Action hasRange
produces Thing hasRange
provider Organization hasRange
provider Person hasRange
sameAs URL hasRange
serviceArea AdministrativeArea hasRange
serviceAudience Audience hasRange
serviceOperator Organization hasRange
serviceType Text hasRange
url URL hasRange

Table 4. Graph of vocabulary for describing service that is provided by a government organization (Cycle 1).

We may serialize the Graph in Table 4 using various semantic technologies, including RDF/XML, RDFa, and Turtle.

Pruning

Note in Table 4 that Property image may be of type URL or ImageObject; here we’re going to use only “cool” URLs – both for the sake of having a persistent identifier for an image that may be modified from time to time and to avoid introducing the clutter of a complex entity like ImageObject – which is incidental to the semantics of a government service – into our vocabulary.

Also note in Table 4 that Property provider may be of type Organization or Person; here we’re going to restrict ourselves to providers of government service that are organizations and not individuals. We will bring Class Person (e.g. as an employee of an organization) into our vocabulary in a subsequent Cycle.

Visualizing

In a fairly traditional manner, our vocabulary for GovernmentService may be visualized as a basic Class Diagram using the Unified Modeling Language (UML):

Figure 2. Visualization of Vocabulary for GovernmentService (Cycle 1) using a UML Class Diagram.

In a more innovative fashion, we may also visualize our vocabulary GovernmentService as a Force-Directed Graph (with Thing, Intangible, Service and GovernmentService fixed in position in the corners of the graph:

Figure 3. Visualization of Graph of GovernmentService (Cycle 1), where o = Property, D = Domain, and R = Range.

See also this interactive version of Figure 3.

Note in Table 4 that several Properties are of type Text or URL – Schema.org treats Text, URL and a few other entities (Boolean, Date, DateTime, Number, Time) as a Datatype (as opposed to a Thing). We may streamline the visualization of our vocabulary by terminating any node corresponding to one of these Properties with a colored-symbol specific to its Datatype:

Figure 4. Legend for terminating a Property node whose Range is Datatype.

Here’s our streamlined visualization of our vocabulary for GovernmentService:

Figure 5. Visualization of Graph of GovernmentService (Cycle 1) using D3, where o = Property, D = Domain, and R = Range, terminating Property nodes with Range = Datatype.

See also this interactive version of Figure 5.

Coming Up:

A Vocabulary of Government Service – Part II

Part III: The Architecture of Service: the Service Organization and Service Channel

Part IV: The Service Audience and Administrative Area

Part V: The Service Action

A Vocabulary of Government Service – Part II

A Second Cycle of Developing a Vocabulary of Government Service

At the end of our first cycle of developing a vocabulary of government service, we had arrived at the following Graph:

Source Node Target Node Relation
Schema Thing hasSubclass
Thing Intangible hasSubclass
Intangible Service hasSubclass
Service GovernmentService hasSubclass
Thing additionalType hasProperty
Thing alternateName hasProperty
Thing description hasProperty
Thing image hasProperty
Thing name hasProperty
Thing potentialAction hasProperty
Thing sameAs hasProperty
Thing url hasProperty
Service availableChannel hasProperty
Service produces hasProperty
Service provider hasProperty
Service serviceArea hasProperty
Service serviceAudience hasProperty
Service serviceType hasProperty
GovernmentService serviceOperator hasProperty
additionalType URL hasRange
alternateName Text hasRange
availableChannel ServiceChannel hasRange
description Text hasRange
image URL hasRange
name Text hasRange
potentialAction Action hasRange
produces Thing hasRange
provider Organization hasRange
sameAs URL hasRange
serviceArea AdministrativeArea hasRange
serviceAudience Audience hasRange
serviceOperator Organization hasRange
serviceType Text hasRange
url URL hasRange

Table 1. Graph of a vocabulary of government service (Cycle 1).

Our second cycle through Schema.org to enrich  our vocabulary further looks to incorporate fully any Class that had defined the Range of some Property at the end of Cycle 1.  There are fifteen rows  in Table 1 where Relation = hasRange – though there are only eight unique Classes (URL, Text, ServiceChannel, Action, Thing, OrganizationAdministrativeArea, and Audience) occupying the Target Node.

Figure 1 illustrates our initial pathway from Schema -> Thing -> Intangible -> Service -> GovernmentService within Schema.org  – as well as the positions of these eight additional Classes within the Inheritance Hierarchy:

GovernmentService Classes at end of Cycle 1

Figure 1. Initial pathway from Schema -> Thing -> Intangible – > Service -> Government Service plus the position of Classes that defined the Range of Properties of Classes along this initial pathway.

These eight additional Classes fall into three categories:

  1. Classes that are included already in the vocabulary (e.g. Thing).
  2. Classes that are datatypes (e.g.  URL, Text) and whose inclusion would add no new Properties to the vocabulary.
  3. Classes that represent new entities (e.g. ServiceChannel, Action, OrganizationAdministrativeArea, and Audience) and whose inclusion would add new Properties to the vocabulary.

Only the third sort of Class offers an avenue for enriching our vocabulary.

Let’s take Class ServiceChannel as an example of how we want to proceed:

The first step is to take account of ServiceChannel’s position in Schema.org’s hierarchy of Classes. On its website, Schema.org asserts the equivalent of:

  • Thing, Intangible, hasSubclass
  • Intangible, ServiceChannel, hasSubclass

Here we note that the first assertion is already part of the vocabulary (Table 4 – Row 1); however, the second assertion is not and its addition to our Graph would enhance our vocabulary.

The second step is to take account of the Properties of Class ServiceChannel:

Properties from Class ServiceChannel
Property Range Description
availableLanguage Language A language someone may use with the item.
processingTime Duration Estimated processing time for the service using this channel.
providesService Service The service provided by this channel.
serviceLocation Place The location (e.g. civic structure, local business, etc.) where a person can go to access the service.
servicePhone ContactPoint The phone number to use to access the service.
servicePostalAddress PostalAddress The address for accessing the service by mail.
serviceSmsNumber ContactPoint The number to access the service by text message.
serviceUrl URL The website to access the service.

Table 2. Properties of Class ServiceChannel.

These eight Properties (availableLanguage, processingTime, providesService, serviceLocation, servicePhone, servicePostalAddress, serviceSmsNumber, serviceUrl) of Class ServiceChannel are new and so will be added to our vocabulary. Note that Class ServiceChannel also inherits all of the Properties of its superordinate Class Thing – but that these Properties are already included in our vocabulary and do not represent an opportunity for enhancement.

The third and final step is to take account of the Ranges of Class ServiceChannel‘s Properties – thereby adding five Classes (Language, Duration, Place, ContactPoint, and PostalAddress) to our vocabulary – (note that Class Service and Class URL are already included).

Quantitative Impact on Vocabulary

We may quantify the impact of adding any Class (ServiceChannel, Action, OrganizationAdministrativeArea, and Audience) to our vocabulary in Cycle 2 by using our vocabulary at the end Cycle 1 as a baseline:

  1. How many unique assertions of the form “Node_iNode_j, hasSubclass” are associated with the Class and how many of them are new?
  2. How many unique assertions of the form “Node_iNode_j, hasProperty” are associated with the Class and how many of them are new?
  3. How many unique assertions of the form “Node_iNode_j, hasRange” are associated with the Class and how many of them are new?
  4. How many unique Classes are referenced in #1 – #3 above and how many of them are new?
  5. How many unique Properties are referenced in #1 – #3 above are how many of them are new?

In the case of Class ServiceChannel, we observe:

  • There are two assertions of the form “Node_iNode_j, hasSubclass” – one assertion is already included in the vocabulary at the end of Cycle 1; one assertion is new and would be an enhancement to the vocabulary.
  • There are fifteen unique assertions of the form “Node_iNode_j, hasProperty” – eight unique assertions that derive from Class Thing are already included in the vocabulary; eight assertions that derive from Class ServiceChannel itself are new and would be enhancements to the vocabulary.
  • There are twenty-one unique assertions of the form “Node_iNode_j, hasRange”; thirteen unique assertions are already included in the vocabulary; eight unique assertions are new and would be enhancements to the vocabulary.
  • There are nineteen unique Classes standing in form Node_i or Node_j in assertions of the form “Node_i,Node_j, hasSubclass”, or Node_i in assertions of the form “Node_i,Node_j, hasProperty”; five of these unique Classes (Language, Duration, Place, ContactPoint, PostalAddress) are new.
  • There are twenty-four unique Properties of the form Node_j in assertions of the form “Node_i,Node_j, hasProperty” – eight of these unique Properties are new.

Note that this method of enriching our vocabulary of government service depends entirely on the structure of Schema.org – there is no model of government service that comes into the exercise.

Applying steps #1 – #5 above to the other Classes that had defined the Range of some Property in Cycle 1, we observe the following impacts of adding these Classes individually or altogether to our vocabulary:

New Assertions New Nodes
 Added Range hasSubclass hasProperty hasRange Classes Properties
ServiceChannel 1 8 8 5 8
Action 1 11 13 6 11
Organization 1 33 39 15 33
AdministrativeArea 2 15 19 11 15
Audience 1 2 2 0 2
Altogether 6 69 69 25 58

Table 3. Introduction of new components into vocabulary for GovernmentService in Cycle 2.

The Graph of our vocabulary at the end of Cycle 2 includes 25 + 58 = 83 additional Nodes and 6 + 69 + 69 = 144 additional assertions about the relations between these Nodes and/or between these Nodes and the Nodes of our vocabulary at the end of Cycle 1:

Assertions included in Cycle 1
Source Node Target Node Relation
Thing Intangible hasSubClass
Intangible Service hasSubClass
Service GovernmentService hasSubClass
Thing additionalType hasProperty
Thing alternateName hasProperty
Thing description hasProperty
Thing image hasProperty
Thing name hasProperty
Thing potentialAction hasProperty
Thing sameAs hasProperty
Thing url hasProperty
Service availableChannel hasProperty
Service produces hasProperty
Service provider hasProperty
Service serviceArea hasProperty
Service serviceAudience hasProperty
Service serviceType hasProperty
GovernmentService serviceOperator hasProperty
additionalType URL hasRange
alternateName Text hasRange
availableChannel ServiceChannel hasRange
description Text hasRange
image URL hasRange
name Text hasRange
potentialAction Action hasRange
produces Thing hasRange
provider Organization hasRange
sameAs URL hasRange
serviceArea AdministrativeArea hasRange
serviceAudience Audience hasRange
serviceOperator Organization hasRange
serviceType Text hasRange
url URL hasRange
Assertions added in Cycle 2
Thing Action hasSubClass
Thing Organization hasSubClass
Thing Place hasSubClass
Intangible Audience hasSubClass
Intangible ServiceChannel hasSubClass
Place AdministrativeArea hasSubClass
Action actionStatus hasProperty
Action agent hasProperty
Action endTime hasProperty
Action error hasProperty
Action instrument hasProperty
Action location hasProperty
Action object hasProperty
Action participant hasProperty
Action result hasProperty
Action startTime hasProperty
Action target hasProperty
Audience audienceType hasProperty
Audience geographicArea hasProperty
Organization address hasProperty
Organization aggregateRating hasProperty
Organization brand hasProperty
Organization contactPoint hasProperty
Organization department hasProperty
Organization dissolutionDate hasProperty
Organization duns hasProperty
Organization email hasProperty
Organization employee hasProperty
Organization event hasProperty
Organization faxNumber hasProperty
Organization founder hasProperty
Organization foundingDate hasProperty
Organization foundingLocation hasProperty
Organization globalLocationNumber hasProperty
Organization hasPOS hasProperty
Organization interactionCount hasProperty
Organization isicV4 hasProperty
Organization legalName hasProperty
Organization location hasProperty
Organization logo hasProperty
Organization makesOffer hasProperty
Organization member hasProperty
Organization memberOf hasProperty
Organization naics hasProperty
Organization owns hasProperty
Organization producer hasProperty
Organization review hasProperty
Organization seeks hasProperty
Organization subOrganization hasProperty
Organization taxID hasProperty
Organization telephone hasProperty
Organization vatID hasProperty
Place address hasProperty
Place aggregateRating hasProperty
Place containedIn hasProperty
Place event hasProperty
Place faxNumber hasProperty
Place geo hasProperty
Place globalLocationNumber hasProperty
Place hasMap hasProperty
Place interactionCount hasProperty
Place isicV4 hasProperty
Place logo hasProperty
Place openingHoursSpecification hasProperty
Place photo hasProperty
Place review hasProperty
Place telephone hasProperty
ServiceChannel availableLanguage hasProperty
ServiceChannel processingTime hasProperty
ServiceChannel providesService hasProperty
ServiceChannel serviceLocation hasProperty
ServiceChannel servicePhone hasProperty
ServiceChannel servicePostalAddress hasProperty
ServiceChannel serviceSmsNumber hasProperty
ServiceChannel serviceUrl hasProperty
actionStatus ActionStatusType hasRange
address PostalAddress hasRange
agent Organization hasRange
agent Person hasRange
aggregateRating AggregateRating hasRange
audienceType Text hasRange
availableLanguage Language hasRange
brand Organization hasRange
brand Brand hasRange
contactPoint ContactPoint hasRange
containedIn Place hasRange
department Organization hasRange
dissolutionDate Date hasRange
duns Text hasRange
email Text hasRange
employee Person hasRange
endTime DateTime hasRange
error Thing hasRange
event Event hasRange
faxNumber Text hasRange
founder Person hasRange
foundingDate Date hasRange
foundingLocation Place hasRange
geo GeoCoordinates hasRange
geo GeoShape hasRange
geograhicArea AdministrativeArea hasRange
globalLocationNumber Text hasRange
hasMap Map hasRange
hasMap URL hasRange
hasPOS Place hasRange
instrument Thing hasRange
interactionCount Text hasRange
isicV4 Text hasRange
legalName Text hasRange
location PostalAddress hasRange
location Place hasRange
logo URL hasRange
logo ImageObject hasRange
makesOffer Offer hasRange
member Organization hasRange
member Person hasRange
memberOf Organization hasRange
memberOf ProgramMembership hasRange
naics Text hasRange
object Thing hasRange
openingHoursSpecification OpeningHoursSpecification hasRange
owns OwnershipInfo hasRange
owns Product hasRange
participant Organization hasRange
participant Person hasRange
photo Photograph hasRange
photo ImageObject hasRange
processingTime Duration hasRange
producer Person hasRange
providesService Service hasRange
result Thing hasRange
review Review hasRange
seeks Demand hasRange
serviceLocation Place hasRange
servicePhone ContactPoint hasRange
servicePostalAddress PostalAddress hasRange
serviceSmsNumber ContactPoint hasRange
serviceUrl URL hasRange
startTime DateTime hasRange
subOrganization Organization hasRange
target EntryPoint hasRange
taxID Text hasRange
telephone Text hasRange
vatID Text hasRange

Table 4. Graph of vocabulary for describing service that is provided by a government organization (Cycle 2).

Our vocabulary for describing a service provided by a government organization now looks something like this (interactive version here):

Schema.org GovernmentService Cycle 2

Figure 5. Visualization of Graph of GovernmentService (Cycle 2), where o = Property, D = Domain, and R = Range (end of Cycle 1) and o = Property and R = Range (end of Cycle 2), terminating Property nodes with Range = Datatype.

After only two cycles through Schema.org, we see that our vocabulary of government service is already threatening to become unwieldy – the number of assertions in our Graph has increased dramatically, and many of the assertions added in Cycle 2 are less clearly relevant to describing government service. Proceeding with ingesting additional Classes and Properties into our vocabulary, using this methodology in a third, fourth, fifth Cycle of development, is an interesting exercise, but increasingly unproductive for our purposes.

Moving forward, then, we will adopt a model of service to guide our development of a vocabulary of government service using Schema.org.

Coming Up:

Part III: The Architecture of Service: the Service Organization and Service Channel

Part IV: The Service Audience and Administrative Area

Part V: The Service Action

 

A Conceptual Metaphor for Service-Seeking and Service-Using – Part I

Recently I participated in a discussion of how to improve access to mental health services for children and youth and their families.

One notion was to designate an agent to assist anyone who is wanting to access mental health services for themselves or someone they are caring for. In our discussion the agent was sometimes called a “navigator” – sometimes a “coach” – and sometimes a “connector” or “bridge” – which reminded me of some earlier reading and thinking I’d done on the use of metaphor(s) in this sort of planning exercise.

Without discounting the alternatives altogether, I want to make the case that the metaphor HELPER IS A NAVIGATOR is more apt and meaningful – not only as a framework for describing the job of the agent in evocative terms, but as a vehicle for understanding and even designing how an agent might assist people who are seeking to access mental health services.

My own view of how metaphor works is drawn heavily from the writings of George Lakoff, Mark Johnson and Zoltan Kovecses (see Further Readings below). In outline:

Conceptual Metaphor

Metaphor may be defined as understanding one conceptual domain in terms of another conceptual domain:

CONCEPTUAL DOMAIN A IS CONCEPTUAL DOMAIN B

Metaphorical linguistic expressions (ways of talking) make explicit , or are manifestations of, the conceptual metaphors (ways of thinking).

The conceptual domain from which we draw metaphorical linguistic expressions to understand another conceptual domain is called the source domain, while the conceptual domain that is understood in this way is the target domain.

A conceptual metaphor typically employs a more abstract concept as the target domain and a more concrete or physical concept as the source domain.

Our experiences with our own bodies and the physical world around us serve as a natural foundation for the comprehension of more abstract domains.

Conceptual Metaphor as a Set of Mappings

When we say CONCEPTUAL DOMAIN A “is understood in terms of” CONCEPTUAL DOMAIN B, we mean there is a set of systematic correspondences or mappings between the constituent elements of the source domain and the constituent elements of the target domain.

To know a metaphor is to understand the systematic mappings between a source and a target and to use linguistic expressions to reflect these mappings.

Metaphorical Mappings onto A JOURNEY

The writings of George Lakoff and his colleagues include extensive discussions of of two related metaphors – LIFE IS A JOURNEY and LOVE IS A JOURNEY. There is also a smaller body of discussion related to THERAPY IS A JOURNEY. This work gives us a good start on exploring the metaphor HELPER IS A NAVIGATOR.

Coming Up

Part II: The JOURNEY of LOVE and LIFE

Part III: The JOURNEY of TREATMENT and RECOVERY

Part IV: The Metaphor of Mental Health and Mental Illness

Part V: Navigating Mental Health Services

Suggested Readings

  • Neil Aronov and Stanley Brodsky,  The River Model: A metaphor and tool for training new psychotherapists (2009).George Lakoff, Women, fire and dangerous things: what categories reveal about the mind (1987).
  • George Lakoff, The contemporary theory of metaphor (1993).
  • George Lakoff and Mark Johnson, Metaphors we live by, 2nd edition (2003).
  • Tammie Ronen and Michael Rosenbaum, Beyond direct verbal instruction in Cognitive Behavioral Supervision (1998).
  • Dennis Tay, THERAPY IS A JOURNEY as a discourse metaphor (2011).
  • Zoltán Kövecses, Metaphor: A practical introduction (1987).
  • —–, A cognitive linguistic view of metaphor and therapeutic discourse (2001).
  • —–, Metaphor and emotion: Language, culture, and body in human feeling (2003).

Service-dominant (S-D) logic

Service-dominant (S-D) logic represents a departure from the traditional goods-dominant (G-D) logic, in which goods were the focus of exchange and services represented a special case of goods. It shifts the emphasis from the exchange of operand resources – usually tangible, inert resources – to an emphasis on operant resources – dynamic resources that act upon other resources.

Robert F. Lausch and Stephen L. Vargo have authored many papers on Service-dominant logic. In a series of posts I extract the foundational and derivative propositions of S-D logic from Vargo & Lusch, "Service-dominant logic: What it is, what it is not, what it might be" in The Service-dominant logic of marketing: Dialog, debate and directions, RF Lusch & SL Vargo eds. (2006) and Lusch, Vargo & O'Brient, "Competing through service: Insights from service-dominant logic" Journal of retailing, 83, (I, 2007) 5-18.

S-D logic views applied, specialized skills and knowledge as the focus of economic exchange and one of the foundations upon which society is built. If goods are involved in the exchange, they are seen as mechanism for service provision.

S-D logic defines service as “the application of specialized competencies (operant resources – knowledge and skills), through deeds, processes, and performances for the benefit of another entity or the entity itself – that is exchanged for service.”

It is important to note the we use the singular term, service, which we feel better reflects the notion of doing something beneficial, rather than the plural term, services, which implies immaterial goods, a sub-class of output.

The following eight foundational premises summarize S-D logic:

  1. The application of specialized skill(s) and knowledge is the fundamental unit of exchange.
    • Service is exchanged for service
  2. Indirect exchange masks the fundamental unit of exchange:
    • Microspecialization, organizations, goals, and money obscure the service-for-service nature of exchange
  3. Goods are distribution mechanisms for service provision:
    • “Activities render service; things render service”
    • Goods are appliances
  4. Knowledge is the fundamental source of competitive advantage:
    • Operant resources, especially know-how, are the essential component of differentiation
  5. All economies are services economies:
    • Service is only now becoming more apparent with increased specialization and outsourcing; it has always been what is exchanged
  6. The customer is always a co-creator of value:
    • There is no value until an offering is used – experience and perception are essential to value determination
  7. The enterprise can only make value propositions:
    • Since value is always determined by the customer (value-in-use), it cannot be embedded through manufacturing (value-in-exchange)
  8. A service-centred view is customer oriented and relational:
    • Operant resources being used for the benefit of the customer places the customer inherently in the center of value creation and implies relationship

S-D logic makes the consumer endogenous to the value-creation process. Value becomes a joint function of the actions of the provider(s) and the consumer(s), but is always determined by the consumer.

S-D logic advocates viewing the customer as an operant resource – a resource that is capable of acting on other resources, a collaborative partner who co-creates value with the firm – and promotes a “market with” philosophy.

In S-D logic, collaboration between the firm (and relevant partners) and the customer allows for a strategic orientation that informs the more tactical Four Ps:

Products are viewed in terms of service flows, in which the service is provided directly or indirectly through an object: promotion is reoriented toward conversation and dialog with the customer; price is replaced with a value proposition created by both sides of the exchange; and place is supplanted with value networks and processes.

S-D logic views the external environments as resources the firm draws upon for support by overcoming resistances and proactively co-creating these environments. This can be illustrated by viewing the ecosystem as an operant resource that is an active party in service provision.

Service-Dominant Marketing

Figure 1. Service-dominant marketing.

Next: Competing with S-D logic

Semantics of public service

Two major efforts to design and deploy a semantic data model of public service are currently underway:

Schema.org Government Services

In August 2013, Schema.org proposed a vocabulary for Civic Services that was “similar to the European Commission ISA Core Public Service vocabulary”. The hierarchy of schemas includes a vocabulary for Service and the specific subtype GovernmentService.

ISA Core Public Service Vocabulary Application Profile (CPSV-AP)

In 2013, the EC published a Core Public Service Vocabulary under ISA Action 1.1 Improving semantic interoperability in European eGovernment systems and reported on a pilot study of the CPSV  in four jurisdictions. The same year, the EC published a Federated Catalog of Public Services (FCOPS) under ISA Action 1.3 – Improving semantic interoperability in eGovernment systems.

Between November 2014 – January 2015, a Working Group is developing an ISA Core Public Service Vocabulary Application Profile (CVSP-AP) to refine the data model of business life-events and related public services. We will use the interim findings and recommendations of the Working Group to describe the data model of public services that is emerging from the EC’s ISA initiative.

CPSV-AP Graphical representation of classes and properties

Figure 1. Graphical representation of the relations among the classes and properties of the CPSV-AP.

A few definitions provided by the ISA may prove helpful before we compare the semantic data models of public service provided by Schema.org and the ISA:

Glossary
Public administration Public administrations are the competent authorities responsible for public services. They consist of national civil servants across the Member States and the European Commission. The federated catalog of public services will include all public authorities at supranational, national, regional and local levels.
Public administration portal A public administration portal is a portal owned by a public administration that provides information about what the public administration does and which public services they provide to citizens, businesses and other public administrations.
Point of single contact Point of Single Contact is a public administration portal (and a one-stop-shop) for service providers with two main goals: providing information and completing administrative procedures. It is necessary for the portal to describe the requirements, procedures and formalities which are necessary to perform or access the services within a Member State. It also needs to provide contact details of competent authorities, access to public registers, and online forms, and process the applications filed.
Service A service is a resource that represents the capability to bring a certain outcome and value to the service requester and is enabled by the service provider.
Public service A public service is a service rendered by a public administration to either business (A2B), citizens (A2C) or other public administrations (A2A).
Service model A service model is a semantic data model which describes how the public service is built. The description of the service is created by means of metadata (data about data) which identifies all the characteristics and specifications of the data structure of a service.
Services of general interest The concept Services of general (economic) interest (SG(E)I) is an official term used by the European Union for all services that are of specific interest to society. This includes all public services. The scope of the SGIs is broader than the scope of the public services in this document and can also include services which are often, but not always, in hands of private companies (e.g. water, electricity, mail).
Generic public service A generic public service is a service which is defined generically, i.e. it only contains information that applies to all the administrations that offer this service. They are typically defined by a coordinating body in a standardized way. These generic services detail the “what” but do not provide detail on “how” and “where” they are offered by a public administration. However, they can refer to the government level at which they are offered. Each service contains a number of fields to describe the content of the service (title, content and generic conditions, procedures, exceptions, documents and regulations). In addition, each service contains metadata; these fields serve to classify the service (competent authority/government level, authority/government level that delivers this service, theme, type and keyword). These services are constructed by a coordinating body as a unique list, agnostic of all public services offered by all executing public administrations. The outcome is a set of generic public services based on a standardized data model, taxonomy and ontology.
Specific public service Specific public services are the public services which are actually rendered by a specific public administration. A specific service may be linked to a generic public service (if the generic concept exists at Member State level). The specific service is the executable and actionable part of a generic public service offered by a public administration. The same generic service (e.g. issue and ID card) could be executable and offered in many local authorities in various ways (different local forms, different buildings and opening hours). In contrast to generic services, these specific services also detail the “how” and “where” they are offered by a public administration and how they can be rendered by business (A2B), citizens (A2C) or other public administrations (A2A). It will spell out in detail to which authority/building/office one needs to go, give contact details of the organisation that provides the service, forms that need to be filled in and how the service can be rendered electronically.
Catalog of public services A catalog of public services is a database or structured document that contains all the services which are provided by public administrations.
Federated architecture A federated architecture is a composition of autonomous (decentralized) organised systems. It is an approach to coordinate the exchange of information across the organised system. A mapping is created between the multiple autonomous systems which forms the federated architecture; this is achieved by defining guidelines and standardized mapping. In a federated catalog, content syndication is in place. The syndication will support the information exchange between the different systems.
Federated catalog of public services A federated catalog of public services is a collection of other catalogs of public services which are joined together in a standardized method. The database or structured document contains all the public services of the catalogs included.
Controlled vocabulary A controlled vocabulary is a code list which is used to organize or give structure to certain information. It contains predefined values for a certain subject. These vocabularies could be used for indexing schemes, subject headings, taxonomies, etc. These controlled vocabularies are used to give a structure to the federated catalog of public services and categorize the public services (generic and specific).
Taxonomy The taxonomy determines the classification of concepts, the division of ordered groups or categories. It is a science which defines a set of principles in order to classify concepts. In this case the definition of the controlled vocabularies could be seen as the taxonomy.
Ontology Ontology is the science of describing the relationship between concepts. This can be used to gain insight into a particular domain by modelling the concepts and ideas (conceptualization). The reasoning behind the federated catalog can be defined by describing the relationships between the multiple concepts (catalogs).
Semantic data model A semantic data model is a conceptual data model that represents data objects together with their properties and relationships and includes the capability to express information that enables parties to the information exchange to interpret meaning (semantics) from the instances, without the need to know the meta-model.
Interoperability Interoperability, for public service delivery, is the ability of disparate and diverse organisations to interact towards mutually beneficial and agreed common goals, involving the sharing of information and knowledge between the organisations, through the business processes they support, by means of the exchange of data between their respective Information and Communication Technology (ICT) systems.

 

A quick look under the hood of 211Ontario.ca

Overview

211’s telephone helpline and regional websites provide a gateway to community, social, non-clinical health and related government services.

The 211 Ontario 211 website classifies Services within a two-tier hierarchy:

Tier Classifier
1 Category of service
2 Sub-category of service

 

The 211 Ontario website also provides Details about Individual Organizations. In some cases, the Details about an Individual Organization concern one of its departments or programs.The mixing of different types of Details about Individual Organizations is a potential source of confusion.

The main value of the 211 Ontario website derives from the connections it asserts between Sub-categories of service and Details of individual organizations.

Soon we’ll explore the structure of 211 Ontario website using the tools of network science, the meaning of the 211 Ontario website using the tools of the Semantic Web. We’ll start here with some basic descriptions and statistics to get us oriented.

Categories of service

The Home Page of 211 Ontario’s  website includes a set of hyperlinks – with HREF attributes of the general form “http://211ontario.ca/topic/{var}” – that identify 18 distinct Categories of service:1

href attribute {var} Category of service
aboriginal-peoples Aboriginal Peoples
abuseassault Abuse/Assault
child-family-services Child / Family Services
community-programs Community Programs
disabilities Disabilities
emergency-crisis-services Emergency / Crisis Services
employment-training Employment / Training
food Food
francophones Francophones
government-legal Government / Legal
health-care Health Care
homelessness Homelessness
housing Housing
income-support Income Support
mental-health Mental Health
newcomers Newcomers
older-adults Older Adults
youth Youth

 

Sub-categories of service

Every URL associated with a Category of service resolves to a human-readable document which, in turn, includes a set of hyperlinks – with HREF attributes of the general form  “http://211ontario.ca/en/topic/Ontario/ ORGANIZATION/fht{nnn}/Ontario” – that identify a number of related Sub-categories of service:

Category of service Number of Sub-categories
Aboriginal Peoples 1
Abuse/Assault 6
Child/Family Services 10
Community Programs 9
Disabilities 15
Emergency/Crisis Services 10
Employment Training 16
Food 5
Francophones 1
Government/Legal 8
Health Care 15
Homelessness
5
Housing 6
Income Support 5
Mental Health 14
Newcomers 11
Older Adults 10
Youth 11
Total 158

 

A Sub-category of service may be associated with more than one Category of service – e. g. “Youth mental health” (fht322) is associated with both “Mental Health” and “Youth” – leaving us with 120 distinct Sub-categories of service:

href attribute Sub-category of service
fht254 Aboriginal peoples
fht263 Child abuse services
fht257 Counselling for abused women
fht258 Crisis lines for abused women
fht260 Sexual/Domestic assault treatment centres
fht261 Shelter for abused women
fht259 Victims of abuse support programs
fht262 Camps
fht264 Child care
fht265 Child mental health
fht96 Children with disabilities
fht266 Domestic abuse crisis services
fht326 Infant formula/Baby food
fht34 Parent/child programs
fht88 Pregnancy/Postnatal
fht267 Recreation for children/families
fht269 Community information
fht268 Community/Recreation centres
fht270 Computer access
fht281 Francophones
fht91 LGBTQ
fht271 Public libraries
fht272 United Way member agencies
fht273 Volunteer centres
fht97 Advocacy for people with disabilities
fht98 Assistive devices
fht6461 Disabilities employment programs
fht101 Disability associations
fht81 Health and developmental disabilities
fht67 Health and physical disabilities
fht102 Home repairs
fht302 Home support programs
fht103 Learning disabilities associations
fht327 Meals for seniors/people with disabilities
fht104 Ontario Disability Support Program
fht105 Parking permits for people with disabilities
fht106 Transportation for people with disabilities
fht95 Youth with disabilities
fht275 Crisis lines for abuse/violence
fht437 Distress lines
fht277 Elder abuse
fht278 Hospital emergency/Urgent care
fht279 In-person crisis services
fht141 Sexual assault support
fht280 Shelters for abuse
fht274 Victims of crime support programs
fht282 Academic upgrading
fht283 Adult literacy
fht284 Apprenticeship
fht54 Career counselling
fht286 Employer staffing assistance
fht58 International credentials
fht324 Internationally-trained professionals
fht61 Job search support/training
fht316 Mental health employment programs
fht289 Newcomer employment programs
fht65 Older workers
fht69 Self-employment/entrepreneurship
fht290 Summer employment
fht291 Work experience
fht292 Youth employment
fht142 Food banks
fht130 Free/low-cost meals
fht325 Home delivered meals
fht293 Community legal services
fht294 Consumer protection/Complaints
fht295 Elected officials
fht296 Human rights / Éducation
fht297 ID (identification)
fht298 Legal education/information
fht299 Service Canada sites
fht300 Service Ontario sites
fht301 Community Care Access Centres
fht80 Community health centres
fht83 Finding a medical professional
fht329 Home support programs
fht303 Hospice/palliative care
fht84 Hospitals
fht305 Long term care homes
fht107 Transportation to medical appointments
fht306 Walk-in medical clinics
fht90 Homeless/at-risk youth
fht328 Homeless meals
fht149 Homeless shelters
fht252 Street outreach
fht150 Help to find housing
fht330 Mental health housing programs
fht309 Retirement homes
fht310 Senior apartments
fht154 Supportive housing (semi-independent)
fht152 Transitional housing
fht220 Emergency financial assistance
fht221 Employment Insurance (EI)
fht311 Income programs for older adults
fht245 Social assistance
fht246 Workers compensation
fht312 Addiction counselling
fht313 Addiction support groups
fht314 Addiction treatment
fht315 Community mental health centres
fht307 Geriatric psychiatry
fht318 In-person crisis services
fht319 Psychiatric hospitals
fht321 Support groups
fht322 Youth mental health
fht131 Consulates/Embassies
fht287 English as a second language
fht288 French as a second language
fht331 Immigration/Sponsorship
fht332 Interpretation/Translation
fht438 Language Instruction for Newcomers in Canada (LINC)
fht334 Refugees
fht335 Settlement services
fht6457 Recreation for older adults
fht108 Transportation for older adults
fht6459 Recreation for youth
fht145 Shelters for youth
fht93 Young parents
fht5989 Youth advocacy/legal help
fht5990 Youth mental health

 

85 (70.8%) unique Sub-categories of service are associated with just one Category of service; 32 (26.7%) with two; and 3 (2.5%) with three.

Organizations

Every URL associated with a Sub-category of service resolves to a human-readable document which, in turn, includes a set of hyperlinks – with HREF attributes of the general form “http://211ontario.ca/detail/en/{id}” – to Details of individual organizations that provide the service.

Every URL associated with a Detail of an individual organization resolves to a human-readable document that may describe an entire organization or one or more of its sub-components. The 211 Ontario website contains 29,909 distinct documents corresponding to these Details of individual organizations.

Service<–>Organization Connections

The 211 Ontario database makes 74,585 connections between some Sub-category of service and some Detail about an individual organization. The number of connections made between a given Detail of an individual organization and a Sub-category of service ranges from 1 to 19 – see Table 1 and Figure 1. We see that 16,177 (54.09%) of the Details of individual organizations are connected to just one Sub-category of service. The distinction of being connected to the greatest number of Sub-categories of service belongs to “Pinecrest-Queensway Community Health Centre. Ottawa – Richmond Rd. Social Services.”

Connections to Sub-categories of service Number of Details of Organizations Percent Cumulative Percent
1 16,177 54.09% 54.09%
2 7,885 26.36% 80.45%
3 2,833 9.47% 89.92%
4 1,285 4.30% 94.22%
5 752 2.51% 96.73%
6 378 1.26% 98.00%
7 212 0.71% 98.71%
8 119 0.40% 99.10%
9 113 0.38% 99.48%
10 49 0.16% 99.65%
11 38 0.13% 99.77%
12 18 0.06% 99.83%
13 15 0.05% 99.88%
14 11 0.04% 99.92%
15 11 0.04% 99.96%
16 7 0.02% 99.98%
17 4 0.01% 99.99%
18 1 0.00% 100.00%
19 1 0.00% 100.00%
Total 29,909

Table 1.

Number of Details of Organizations loading on nSub-categories of service
Figure 1.

In Table 2 and Figure 2 we see that 44 (36.67%) distinct Sub-categories of service are connected with 0 – 199 Details of individual organizations. The distinction of being connected to the largest number of Details of individual organizations (2918) belongs to “Child care” (fht264).

Number of Details
of Organizations
Number of Sub-
categories of service
Percent Cumulative Percent
0 to 199 44 36.67% 36.67%
200 to 399 25 20.83% 57.50%
400 to 599 19 15.83% 73.33%
600 to 799 13 10.83% 84.17%
800 to 999 8 6.67% 90.83%
1000 to 1199 2 1.67% 92.50%
1200 to 1399 2 1.67% 94.17%
1400 to 1599 1 0.83% 95.00%
1600 to 1799 1 0.83% 95.83%
1800 to 1999 0 0.00% 95.83%
2000 to 2199 3 2.50% 98.33%
2200 to 2399 0 0.00% 98.33%
2400 to 2599 1 0.83% 99.17%
2600 to 2799 0 0.00% 99.17%
2800 to 2999 1 0.83% 100.00%
Total 120

Table 2.

Graph nSub-categories of service connecting to rangeOrganizations
Figure 2.

  1. The statistics reported here pertain to the state of the 211 Ontario website on or about September 28, 2014. For now our discussion is limited to web resources in English; 211 Ontario is working to provide French-language versions of these resources – the root URL of current French-language resources is “http://211ontario.ca/fr/

Government Service – Schema.org

Overview

A vocabulary for describing Government Service was included in Schema.org  version 1.0d (November 2013). Also see Vocabulary for describing Civic Services – draft, Civic Services – draft 01, Civic Services – draft 02, and Civic Services – RDFS – draft.

Government Service is a more specific type of Service.

In fact, the vocabulary for Government Service adds only one property to the vocabulary for Service:

serviceOperator – typeof Organization

The serviceOperator property enables the representation of a service that is provided by an organization, but operated by another organization, like a subcontractor.

Also note that Schema.org includes GovernmentOrganization, which is a more specific type of Organization, having no additional properties.

Thing > Intangible > Service > GovernmentService

A service provided by a government organization, e.g. food stamps, veterans benefits, etc.
Property Expected Type Description
Properties from GovernmentService
serviceOperator Organization The operating organization, if different from the provider. This enables the representation of services that are provided by an organization, but operated by another organization like a subcontractor.
Properties from Service
availableChannel ServiceChannel A means of accessing the service (e.g. a phone bank, a web site, a location, etc.)
produces Thing The tangible thing generated by the service, e.g. a passport, permit, etc.
provider Person
or Organization
The organization or agency that is providing the service.
serviceArea AdministrativeArea The geographic area where the service is provided.
serviceAudience Audience The audience eligible for this service.
serviceType Text The type of service being offered, e.g. veterans’ benefits, emergency relief, etc.
Properties from Thing
additionalType URL An additional type for the item, typically used for adding more specific types from external vocabularies in microdata syntax. This is a relationship between something and a class that the thing is in. In RDFa syntax, it is better to use the native RDFa syntax – the ‘typeof’ attribute – for multiple types. Schema.org tools may have only weaker understanding of extra types, in particular those defined externally.
alternateName Text An alias for the item.
description Text A short description of the item.
image URL URL of an image of the item.
name Text The name of the item.
potentialAction Action Indicates a potential Action, which describes an idealized action in which this thing would play an ‘object’ role.
sameAs URL URL of a reference Web page that unambiguously indicates the item’s identity. E.g. the URL of the item’s Wikipedia page, Freebase page, or official website.
url URL URL of the item.

Example 1

Without markup

<div>NYC Food Service Establishment Permit, issued by Department of Health and Mental Hygiene.
(issued through NYC Food Service Establishment Permit Service; valid in New York for 1 year).</div>

Microdata

<div itemscope itemtype="http://schema.org/GovernmentPermit">
 <span itemprop="name">NYC Food Service Establishment Permit</span>
 <div itemprop="issuedBy" itemscope itemtype="http://schema.org/GovernmentOrganization">
 <span itemprop="name">Department of Health and Mental Hygiene"</span>
 </div>
 <div itemprop="issuedThrough" itemscope itemtype="http://schema.org/GovernmentService">
 <span itemprop="name">NYC Food Service Establishment Permit Service</span>
 </div>
 <div itemprop="validIn" itemscope itemtype="http://schema.org/AdministrativeArea">
 <span itemprop="name">New York</span>
 </div>
 <time itemprop="validFor" content="P1Y">1 year</time>
</div>

RDFa

<div vocab="http://schema.org/" typeof="GovernmentPermit">
 <span property="name">NYC Food Service Establishment Permit</span>
 <div property="issuedBy" typeof="GovernmentOrganization">
 <span property="name">Department of Health and Mental Hygiene"</span>
 </div>
 <div property="issuedThrough" typeof="GovernmentService">
 <span property="name">NYC Food Service Establishment Permit Service</span>
 </div>
 <div property="validIn" typeof="AdministrativeArea">
 <span property="name">New York</span>
 </div>
 <time property="validFor" content="P1Y">1 year</time>
</div>

JSON-LD

<script type="application/ld+json">
{
 "@context": "http://schema.org",
 "@type": "GovernmentPermit",
 "issuedBy": {
 "@type": "GovernmentOrganization",
 "name": "Department of Health and Mental Hygiene\""
 },
 "issuedThrough": {
 "@type": "GovernmentService",
 "name": "NYC Food Service Establishment Permit Service"
 },
 "name": "NYC Food Service Establishment Permit",
 "validFor": "",
 "validIn": {
 "@type": "AdministrativeArea",
 "name": "New York"
 }
}
</script>

Example 2

Without Markup

This example shows a JSON-LD description of services that do not necessarily have a direct
human-oriented HTML description. It describes a GovernmentService named "Veterans Affairs Emergency Mental Health" its operator, service area and service details, such as its Veterans Crisis Line (including phone contact line
hours of operation, language and other details).

JSON-LD

<script type='application/ld+json'>
{
 "@context": "schema.org",
 "@type": "GovernmentService",
 "name": "Veterans Affairs Emergency Mental Health",
 "serviceType": "Psychiatric Emergency Services",
 "operator": {
 "@type": "GovernmentOrganization",
 "name": "US Department of Veterans Affairs"
 },
 "serviceArea": {
 "@type": "AdministrativeArea",
 "name": "Massachusetts"
 },
 "serviceAudience": {
 "@type": "CivicAudience",
 "name": "Veterans"
 },
 "availableChannel": {
 "@type": "ServiceChannel",
 "name": "Urgent Care Clinic",
 "availableLanguage": {
 "@type": "Language",
 "name": "Spanish"
 },
 "serviceLocation": {
 "@type": "Hospital",
 "name": "VA Boston -- West Roxbury",
 "address": {
 "@type": "PostalAddress",
 "streetAddress": "1400 VFW Parkway",
 "addressLocality": "West Roxbury",
 "addressRegion": "MA",
 "postalCode": "02132"
 }
 }
 }
}
</script>

Related additions in Schema.org version 1.0d

ContactPoint – e. g. now provides a mechanism for describing contact points for services which support users with hearing impairments.

Organization – a small but useful improvement, adding department and subOrganization properties that relate organizations to each other. This can be used when describing common situations,  when details such as opening hours or contact information vary by department.

Interoperability Solutions for European Public Administrations (ISA)

Overview

Administrative procedures have the reputation of being lengthy, time-consuming and costly. Electronic collaboration between Public administrations can make these procedures quicker, simpler and cheaper for all parties concerned, in particular when transactions need to be done cross-border and/or cross-sector.

Actions

The Interoperability Solutions for European Public Administrations (ISA) program of the European Commission facilitates such transactions through more than 40 Actions organized into five categories:

and four clusters:

Our interest in the Semantics of Service immediately engages us with two Actions falling within the Trusted Information Exchange cluster:

Common services – Action 1.1 – Improving semantic interoperability in European eGovernment systems.

Common frameworks – Action 1.3 – Accessing Member State information resources at European level.

Competing with S-D Logic

The foundational premises of S-D logic inform a “competing through service” strategy and allow for the development of nine derivative propositions addressing competing through service (see Table 1). The overall theme is that applied knowledge and collaboration are the key drivers for firms to more successfully compete through service. To accomplish this, the firm must view external environments, customers and partners as operant resources.

Proposition Rationale
1. Competitive advantage is a function of how one firm applies its operant resources to meet the needs of the customer relative to how another firm applies its operant resources. Since applied operant resources are what are exchanged in the market (FP1), they are the source of competitive advantage (FP4)
2. Collaborative competence is a primary determinant of a firm’s acquiring the knowledge for competitive advantage. The ability to integrate (FP9) operant resources (FP4) between organizations increases ability to gain competitive advantage through innovation.
The continued ascendance of information technology with associated decrease in communication and computation costs, provides firms opportunities for increased competitive advantage through innovative collaboration. Reduced barriers to technology utilization combined with the trends of open standards, specialization, connectivity, and network ubiquity increase the likelihood of collaboration with firms and customers (FP6, FP8).
4. Firms gain competitive advantage by engaging customers and value network partners in co-creation and co-production activities. Because the customer is always a co-creator of value (FP6), and the firm is a resource integrator (FP9), competitive advantage is enhanced by proactively engaging both customers and value-network partners.
5. Understanding how the customer uniquely integrates and experiences service-related resources (both private and public) is a source of competitive advantage through innovation. Since value is co-created (FP6) comprehending how customers combine resources (FP8, FP9) provides insight into competitive advantage.
6. Providing service co-production opportunities and resources consistent with the customer’s desired level of involvement leads to improved competitive advantage through enhanced customer experience. Expertise, control, physical capital, risk taking, psychic benefits, and economic benefits influence customers’ motivation, desire, and amount of participation (FP6, FP9) in service provision through collaboration (FP8).
7. Firms can compete more effectively through adoption of collaboratively developed, risk-based pricing value propositions. Appropriately shifting the economic risk of either firm or customer through co-created (FP6) value propositions (FP7) increase competitive advantage.
8a. The value network member that is the prime integrator is in a stronger competitive position.
8b. The retailer is generally in the best position to become the prime integrator.
The ability to effectively combine micro-specialized competencies into complex services (FP9) provides knowledge (FP1) for increased competitive advantage (FP4).
Firms that treat their employees as operant resources will be able to develop more innovative knowledge and skills and thus gain competitive advantage. Since competitive advantage comes from the knowledge and skills (FP4) of the employees, it can be enhanced by servant leadership and continual renewal.

S-D logic asserts that it is not products that are the aim of the customer’s acquisition, but rather the benefit available through the service of the provider. S-D logic inverts the role of goods and service by making service superordinate to goods. In S-D logic, service can be provided directly to another entity or network or through goods – appliances, the basis of FP3. Competition, then, is a function of how one firm provides applied operant resources that meet the needs of the customer relative to another firm providing such applied operant resources. In S-D logic, all competition occurs through service-provision.

Previous: Service Dominant (S-D) logic

Next: Knowledge, collaboration, and sustainable competitive advantage

Knowledge, collaboration, and sustainable competitive advantage

Derivative Proposition 1.

Competitive advantage is a function of how one firm applies its operant resources to meet the needs of the customer relative to how another firm applies its operant resources.

Service per se is not the primary source of sustainable competitive advantage. As FP4 indicates, the only true source of sustainable competitive advantage is knowledge – the operant resources that make the service possible.

S-D logic, grounded in Hunt’s (2000) resource-advantage theory, recognizes that competitive advantage is derived from superior competences.

It is unrealistic for a firm to remain static in their value propositions or offered services; hence, service innovations are instrumental. These innovations are dependent upon the collection of competences, which the firm can continually renew, create, integrate, and transform. However, given the integrative nature of service provision, there is one competence that S-D logic recognizes as pivotal to any firm that wants to have sustained competitive advantage – collaborative competence – because it assists in the development of two additional meta-competences that we contend are critical in complex, dynamic, and turbulent environments:

  • Absorptive competence. The ability of an organization to be able to comprehend from the external environment the important trends and know-how. This will assist in transforming these external environments into important resources the firm can draw upon for support. Collaborative competency will aid a firm in absorbing new information and knowledge from partners or improve its absorptive competence.
  • Adaptive competence. The ability of an organization to adjust to changing circumstances. Once again, by developing collaborative competence the entity is able to use its partner firms as mechanisms for adapting to change brought about by complex and turbulent environments and, thus, improve its adaptive competence.

Better collaborative competency, coupled with improved absorptive competence and adaptive competence, can be used by organizations to lower its relative resource cost and enhance its relative value proposition. Lower relative resource costs focuses on efficiency and enhanced relative value focuses on effectiveness.

S-D logic suggests that the only possible way to offer more efficient and effective solutions to the marketplace is to have superior collaborative competency because it leverages the firm’s ability to absorb information and knowledge from the environment, customers, and its value networks and enables firms to adapt to dynamic and complex environments.

Previous: Competing with S-D logic

Next: Collaboration and information technology

Collaboration and information technology

Derivative Proposition 2

Collaborative competence is a primary determinant of a firm’s acquiring the knowledge for competitive advantage.

Information technology, by facilitating the service-integration function, both within the firm and across the entire value-creation network including the customer, has a dramatic effect on the ability of all entities in the value-creation network to collaborate.

S-D logic recognizes technology as bundled, operant resources. New technologies are created by developing new operant resources, finding novel ways to embed operant resources in operand resources and/or finding ways to “liquefy” operant resources (i.e. unembed them from operant resources so that they can be employed separately). In reality, these processes usually occur in complementary combinations.

As unit computation and communication costs approach zero, more and more entities will be connected and collaboration will become increasingly feasible. Not only are the increased connections and collaborations with employees and suppliers but also with customers. Four factors are driving this trend:

  • Open standards. Open standards deal with co-production and collaboration. Information is increasingly symmetric versus asymmetric as more and more information and experiences are shared. Collaboration becomes the norm and innovation is stimulated.
  • Specialization. As individuals, organizations, and networks become more specialized they need others for what they themselves cannot do. Thus, more and more specialization leads to larger and larger markets. The consequence of intense specialization is increased interdependency among all entities that stimulates more collaboration that, in turn, stimulates innovation.
  • Connectivity. Connectivity makes the market system much more timely and quick in responding to changes in demand and supply. The market then becomes highly flexible.
  • Network ubiquity. The final force that has created an inflection point in the movement toward collaboration is network ubiquity. Increasingly, everyone and everything is connected to each other and each thing. Network ubiquity accelerates the consequences of open standards, specialization, and connectivity. The consequences are higher collaboration and more innovation.

Because of the convergence of these trends, it is logical that all entities (individuals, organizations, and households) will continue to look for ways to transform everything they do using information technology. To start, the mapping of processes consisting of all activities and tasks within and between entities should be undertaken. The goal is to discover ways to use information technology to take waste (usually time or effort) out of the value-creation process, redesign the system to eliminate points of system failure, and/or add valuable experiences to the service-provision process.

This mapping of activities that are involved in the co-production of service can be accomplished with a variety of techniques, often referred to as process mapping, service blueprinting, or activity mapping. All are based on industrial flowcharting; in all cases, the focus is on the mapping of processes and service flows, rather than merely a task, activity or function as it relates to a unit of output.

Service blueprinting also focuses on processes in the firm as it interacts with customers. A typical service blueprint breaks out into four components:

  1. Customer actions
  2. Onstage contact employee actions
  3. Backstage contact employee actions
  4. Support processes

The flowchart might use the horizontal axis to represent time and the vertical axis to model these components and their subcomponents. S-D logic suggests going a step further by mapping the customer’s role in value co-creation. CRM software could evolve to CEM (Customer Experience Management) software in recognition of the central role of customer experiences.

In sum, information technology is a pivotal force in enabling more collaboration and consequently innovation throughout the entire value network.

Previous: Knowledge, collaboration, and sustainable competitive advantage

Next: Collaboration: co-production and the co-creation of value

 

 

Co-creation of value

Derivative Proposition 4

 Firms gain competitive advantage by engaging customers and value network partners in co-creation and co-production activities.

One opportunity for organizations to compete through service is to identify innovative ways of co-creating value. Interactivity and doing things with the customer versus doing things to the customer is a hallmark of S-D logic. Goods may be instrumental in relationships, but they are not parties to the relationship; inanimate items of exchange cannot have relationships (Vargo and Lusch 2004). Consequently, S-D logic places a high priority on understanding customer experiences over time.

As parties specialize, they need to rely increasingly upon other entities for value co-creation—that is, they draw increasingly upon and are dependent on the resources of others. Some of these other resources are private and some public. For example, if one purchases an automobile but also  has access to well-built highways, public parks, enforced traffic laws, and so forth, then, over time, one obtains a different service experience than if these public resources were not present. Similarly, if one purchases an automobile and has access to a garage to keep the auto clean and in good condition the experience of using the auto is again altered. In short, the resources that are endogenous to value creation often include those traditionally categorized as belonging to the uncontrollable, “external” environment. This also suggests that the customer is a primary integrator of resources in the creation of value through service experiences that are interwoven with life experiences to enhance quality of life.

Previous:  Collaboration: co-production and the co-creation of value

Next: Co-production of the service offering

Co-production of the service offering

Derivative Proposition 5

Understanding how the customer uniquely integrates and experiences service-related resources (both private and public) is a source of competitive advantage through innovation.

Generally, customers are increasingly becoming involved in the co-production of many services (Bendapudi and Leone 2003). For example, compare the service of today’s supermarket in relation to that of the small corner grocer of 100 years ago. The corner grocer of yesterday would take the order, pick the groceries from the store or behind the counter, wrap and package the groceries, deliver the merchandise, and provide credit service. Today customers enter the store and navigate it without assistance, choose the merchandise they desire, move through a self check-out counter where they scan their own merchandise, pay electronically, bag their own groceries, transport the items to their car, and then drive home, unload, and stock their pantry. As this example illustrates, co-production is not new to retailing, but in a large part characterizes the historical evolution of retailing. It also illustrates that the retailer has considerable control and influence over customer experiences and thus should be a vital participant in the management, or as S-D logic states, in the co-creation and co-production of customer experiences.
Based upon the work of Lusch et al. (1992), we posit six key factors that contribute to the extent to which the customer is an active participant in the co-production of a service offering. Retailers and other organizations in order to develop innovative service strategies can use each factor.

  1.  Expertise.  An individual is more likely to participate in co-production if s/he has the requisite expertise (i.e., operant resources). Recognizing this, Home Depot and Lowe’s offer do-it-yourself (DIY) clinics to teach people such skills. It then offers to sell the tangible products needed to complete these projects.
  2. Control. Co-production is more common when a person wants to exercise control over either the process or outcome of the service. For instance, many households are practicing home schooling their children because they want to have more control over the educational process and outcomes, providing an opportunity for firms to provide the needs to complete these activities, such as educational software.
  3. Physical capital . Co-production is more likely if the party has the requisite physical capital. For example, for auto or home repair this might involve needed tools, space or both. Retailers such as Taylor Rental or U-Haul can provide some of the needed physical capital.
  4. Risk taking . Co-production involves physical, psychological, and/or social risk-taking. This does not imply that risks are necessarily increased with co-production, since co-production can also reduce risks. For instance, most Western medicines use a goods-dominant logic where the patient is someone that is passive and something is done to him or her in order to cure him or her. However, if the person becomes involved in managing their health and wellness, then the risks of poor health may decline.
  5. Psychic benefits . One of the primary reasons people engage in co-production is for pure enjoyment—the psychic (experiential) benefits. Activities like home gardening, gourmet cooking, personal fitness training, education, or learning a new skill, are all heavily service intense and are engaged in for psychic benefits. For example, Build-A-Bear is a retailer that allows customers to build a customized stuffed animal, which becomes a rewarding experience.
  6. Economic benefits . Perceived economic benefits plays a central role in co-production. Many people participate in co-production because it is a good use of their time. In fact, it can be argued that the rise of self-service retailing, from gasoline stations to mass merchandisers, is primarily driven by the economic benefits. Importantly, value that is created through co-production is tax-free.

The preceding six factors speak not only of the motivations behind the customer’s desire to be involved in co-production, but can also be used to help determine how much the customer wants to be part of service operations (Lusch et al. 1992). Furthermore, a firm may decide that it needs to provide certain services that may help the customer be part of service operations. These factors also are the source of many customer contacts or touch points, which form the basis of managing customer experiences (Smith and Wheeler 2002; Schmitt 2003). Thus, firms should consider mapping the entire experience process that is associated with its offerings to include the customer’s level of involvement in co-production activities and processes. This mapping can be the basis for the customer-experience management framework suggested by Schmitt (2003), which includes: (1) analyzing the experiential world of the customer, (2) building the experiential platform, (3) designing the brand experience, (4) structuring the customer interface, and (5) engaging in continuous innovation (Schmitt 2003, p. 25).

Previous: Co-creation of value

Next: Co-production, co-creation, and pricing

 

.

 

The prime integrator

Derivative Proposition 7

Firms can compete more effectively through the adoption of collaboratively developed, risk-based pricing value propositions.

S-D logic points toward collaboration and coordination as essential approaches to innovation and competition. They represent means for integrating activities and resources. Vargo and Lusch (2006), in the ninth foundational premise (FP9) identify resource integration as the essential role of the firm. Christensen et al. (2001) identify it as the most critical aspect of innovation. At one end of a coordination/integration continuum are transactional markets where the “invisiblehand” of the marketplace becomes the key coordination mechanism and integrator. At the other end of the continuum are relational markets (i.e., long-term relationships, partnerships, alliances, joint ventures, and networks), which are highly collaborative (Webster 1992). S-D logic embraces relational and collaborative markets. However, under a collaborative model of coordination, who should be the prime integrator?

etailers have a distinct advantage in being the customer’s closest link to the marketplace. As such, it is possible that within the value network the retailer may be positioned best to develop a core competence in market sensing. It can also be argued that investment in manufacturing is increasingly viewed as constraining market responsiveness (Vargo and Lusch 2004)—in fact, even firms historically considered to be primarily manufacturing firms are increasingly outsourcing the manufacturing process. Achrol (1991, pp. 88, 91) identifies “transorganizational firms,” which he refers to as “marketing exchange” and “marketing coalition” companies, both of which have “one primary function—all aspects of marketing.” Achrol and Kotler (1999) envision marketing as largely performing the role of a network integrator that develops skills in research, forecasting, pricing, distribution, advertising, and promotion, and they envision other network members as bringing other necessary skills to the network. Consider that the consumer is also faced with more and more choices and may be receptive to domesticating or taming the market by adopting and developing a relationship with a limited number of organizations (Vargo and Lusch 2004). Rifkin (2000) argues that consumers will develop relationships with organizations that can provide them with an entire host of related services over an extended period.

As such, S-D logic suggests retailing is best characterized as a service-integration function. This is somewhat different from the typical conceptualization of retailing representing

the final link in a directional distribution flowor supply chain. In S-D logic, the retailer is part of a value network comprising all the parties (including the customer) involved in value creation. The retailer differs from other network members by the fact that his exchange with the customer is direct. Since other network partners are increasingly retaining this direct exchange function, the retail/nonretail lines are often blurred. More generally, since all parties to value creation are service integrators, service-based competitive strategies are not limited to traditional retailers.

However, by redefining their role in terms of this integration function and becoming prime integrators rather than distributors, we believe retailers could remain the pivotal link in the value network. For instance, over the past 20 years a group of independent auto dealers has obtained multiple franchises operating as independent businesses but under a common ownership. One of these mega-dealers has the ability to sell a Mercedes, Honda, Ford, Toyota, Kia, Volvo, Chrysler, and so forth. However, the needs of an auto owner are much broader. They need financing, auto insurance, fuel, maintenance, parking, and places to stop for food and lodging, and also assistance on airline and other travel when use of a car is not economical or timely. The mega auto dealer could relatively easily move into this entire market space and be the household’s major provider of transportation services. Similarly, PETsMART could be the integrator for a household’s entire pet related needs; Home Depot for all the housing related needs; Office Depot for home business related needs, and so forth. This is consistent with Achrol and Kotler’s (1999) observation that marketing may become a customer-consulting function.

Previous: Co-production, co-creation, and pricing

Next: Competitive advantage of the prime integrator

Competitive advantage of the prime integrator

Derivative Proposition 8a

The value network member that is the prime integrator is in a stronger competitive position.

Derivative Proposition 8b

The retailer is generally in the best position to become the prime integrator.

While the network member who is the prime integrator is in a stronger competitive position, we posit it is the retailer who is generally in a unique position to become the prime integrator. In a sense, the history of retail competition is largely a history of managing the level and types of service (and value) that the customer co-creates. Furthermore, retail entrepreneurs and innovators offered different approaches to integrate the customer into the value co-creation process. Notable hypotheses in this area (i.e., The Wheel of Retailing, McNair 1958; Hollander 1960, and The Big Middle, Connolly 2004; Levy et al. 2005) provide a good lens to view this evolutionary phenomenon.

Hollander’s (1960) descriptive notion of a wheel of retailing alludes to such trade-offs as retailers changing their core offering from the entry phase (with assumed relatively low retailer input and relatively high customer input) through the trading-up phase (with an assumed more equal proportion of service load between the customer and retailer at the point of transaction) to the vulnerable phase (where it is assumed the retailer’s input is considerably greater than other phases). Conceptually, however, a firm would be vulnerable at any stage to competitors who are better at integrating resources and services to collaborate with the customer to produce and create higher value, and not just during the vulnerable stage mentioned earlier.

Levy et al. (2005) model the retail landscape along the dimensions of relative offering of the retailer along with relative price and refer to “The Big Middle” marketspace, the space where the largest number of customers is conceptually located and where the largest retailers compete. Under this model retailers … “tend to originate as either innovative [high relative offering, high relative price] or low-price [low relative offering, low relative price] retailers, and the successful ones eventually transition or migrate to the Big Middle [average relative offering, average relative price] (p. 85, items in brackets added).

While the authors, note the oversimplification of the scheme for expository purposes (p. 85), we suggest the model is indicative of the phenomena of retailers actively managing the level of service for which each value co-creator (marketer and customer) is responsible. Accordingly, the retailers’ management of the balance of co-creation responsibilities has always led them to follow a more service-centered view. Despite the advantageous role retailing may serve as a prime service-integrator, and the role that technology can play in aiding service-integration, S-D logic informs all organizations. In the following section, we point out how S-D logic can inform organizations about gaining competitive advantage by becoming more service-centered through the creation of a service culture.

Leveraging employees

One of the hallmarks of S-D logic is the superordination of operant resources in relation to operand resources in their relative roles in competitive strategy. That is, as discussed, it is knowledge and skills, including in some cases a firm’s knowledge used in designing and/or making appliances, which drives its success (Vargo and Lusch 2004; Lusch and Vargo 2006). This, of course, implies that the competitive advantage of the firm is more of a direct function of the comparative advantage of competences (c.f. Hunt 2002) than it is the direct comparative advantage of its units of output—that is, its goods. The other hallmark of S-D logic is the idea that value cannot be embedded in operand resources but rather must be co-created through collaboration between firm, customer, and other value-network partner’s operant resources (Vargo and Lusch 2004).

Besides operand and operant resources being differentiated in terms of their ability to cause changes in other resources, they differ in another important regard. Operand resources are typically depletable and static in nature, while operant recourses are capable of being rejuvenated, replenished, and newly created, and are thus dynamic in nature. That is, new, innovative knowledge and skills, often with increased capability for providing increased benefits, and thus increased marketability, can be created endlessly. None of this suggests that a specific set of competences cannot become obsolete, or at least “commoditized.” Indeed, today’s high technology often becomes tomorrow’s “unskilled” labor.

Organizations can reinvent themselves as “service” organizations and develop a service culture by treating employees as the type of resources they are—pure operant resources, rather than operand resources. Reinventing the firm as a service organization using S-D logic requires the organization’s culture and its leadership style to treat employees as operant resources. The leadership of many G-D logic organizations is based largely on the manipulation of rewards and punishments and is, accordingly, a coercive form of leadership. It is also based on asymmetric information with the leader and organization holding much information private and out of the reach of employees and, in turn, employees reacting similarly and withholding vital information from management. Employees are viewed as replaceable operand resources and treated largely in a transactional mode. It is not surprising that these firms find themselves unable to compete and, as such, laying-off or ridding themselves of their most important resources.

By contrast, S-D logic points to all participants in the value-creation process who are being viewed as operant resources. When employees are viewed and treated in this manner they become empowered in their role as value cocreators. Employees as operant resources become the primal source of innovation, organizational knowledge, and value. The role of the leader is to be a servant-leader who is there to serve the employees, rather than the employees serving the manager. Hence, employee–manager interaction comprises conversation and dialog and the development of norms of relational behavior such as trust, open communication, and solidarity. In addition, because of open communication, all information is shared and thus is symmetric. In this work environment, employees can develop new and innovative ways of providing service—that is, new competences that allow the firm to compete more effectively. Further, employees of these firms are (should be) assisted in this process of competence augmentation through internally and externally supported training and educational programs.

Previous: The prime integrator

Next: Managerial directions

 

Managerial directions

Derivative Proposition 9

Firms that treat their employees as operant resources will be able to develop more innovative knowledge and skills and thus gain competitive advantage.

Each of the nine propositions that wehave presented points directly to one or more managerial implications. However, none of these propositions will result in the achievement of competitive advantage unless the management adopts a service orientation. S-D logic is more than a series of premises and propositions; it is a revised logic of market exchange that informs a revised logic of competing through service. At the core of S-D logic (see Fig. 2) is the requirement that management should understand that value-creation for both the customer and the firm requires collaborating with customers (and other value-network partners). In turn, this requires recognizing that they are operant, rather than operand, resources. It also requires that management should understand that what it primarily brings to the market is its ability to serve some other party through the application of its own resources, primarily operant—that is through a collaborative effort with its own employees. In brief, the most fundamental implication is that firms gain competitive advantage by adopting a business philosophy based on the recognition that all entities collaboratively create value by serving each other.

Some look for boundary conditions that apply to this philosophy. For example, it has been argued that S-D logic is not applicable to a pure commodity type of business. But S-D logic also applies to commodity industries. Competitive advantage is not based on the commodities themselves, but rather on collaborative ability of the firm to allow the commodities to provide service for some other party. That is, competitive advantage is firm-based rather than product-based and thus, while the goods provided might be commodities, the firm can be highly differentiated. In fact, it could be argued that S-D logic is especially critical in commodity industries.

As Vargo and Lusch (2004) have indicated, many companies that are selling tangible output have found competitive advantage through the adoption of a service logic. Conversely, many firms typically characterized (i.e., by G-D logic classification schemas) as service organizations, such as the airlines, internal revenue service, health care providers, and so forth, have found themselves at a competitive disadvantage by adopting a G-D logic and focusing on output management versus process management. Stated alternatively, any organization can gain competitive advantage by adopting a service-dominant orientation.

Although we think of commodities in terms of goods (especially foodstuffs), S-D logic suggests that virtually all firms that focus on units of output will likely become commodity businesses. Likewise, all firms, including “goods” firms can transform themselves competitively by better understanding how they can serve. For example, retailers can focus on selling merchandise and enticing patronage by constantly cutting prices – that is, treating their business as a commodity – or they can focus on co-creating new kinds of value and service experiences with customers and, in all likelihood, sell at prices considerably in excess of their competitors that, on the surface, might appear to operate in the same business or market.

There is another, very central, managerial direction that S-D logic provides, as implied by the outer circle of Fig. 2. It is tied to understanding the nature and scope of available resources (internal and external), including those that might appear to be resistances until they are overcome by and integrated with the organizations’ other resources. We discussed some of this in conjunction with the idea of viewing the ecosystem as something to collaborate with in the co-creation of service and also in conjunction with the idea integrating firm, individual, and public resources – for example, to increase the value-in-use of an automobile. Unfortunately, most businesses (including retailers) tend to view external environments as resistances, if not countervailing forces rather than resources. For example, “big box” retailers are facing increased opposition as they enter communities for a variety of reasons, such as posing potential harm to small retailers, the social fabric of the community, land-use through construction, under provision of employee benefits, and so forth. It is possible to view these externalities as uncontrollable constraints. But it is also possible to view them as potential resources for the collaborative creation of a better value proposition for both the community and the firm. Consider a big box mass merchandiser on 20 acres that: (1) plants trees near the store and in the parking lot to better protect structures from heat; (2) opens its parking lot to a local farmer’s market for fresh produce; (3) sublets interior store space, not only to Bank of America and McDonald’s, but to small enterprising local entrepreneurs; (4) provides a room for community meetings; (5) provides part time work to community members that are disabled mentally or physically. A truly S-D retailer would view the entire community as a storehouse of resources to collaborate with to not only help the community but to provide the retailer with relative competitive advantage.

Previous: Competitive advantage of the prime integrator

 

211 Ontario

Adapted from About 211 Ontario

Mission

211’s telephone helpline and regional websites provide a gateway to community, social, non-clinical health and related government services. 211 helps to navigate the complex network of human services quickly and easily, 24 hours a day, 7 days a week.

By creating easy access to comprehensive, up-to-date information and data about human services, decision-makers – whether households, communities or governments – can make better informed decisions about the choices facing them, before problems spiral into a crisis.

Ontario 211 connects people to the right information and services, strengthens Ontario’s health and human services, and helps Ontarians to become more engaged with their communities.

211 in Ontario – Vision and Roadmap 2013 to 2015

Governance & Partnerships

211 in Ontario is governed by Ontario 211 Services, a non-profit agency with five full-time staff and a dedicated Board of Directors. They work in collaboration with seven Regional 211 Service Providers, and a unique network of data contributors to deliver 211 services though the phone and through online channels to all Ontario residents.

Funding

All three levels of government and United Ways fund Ontario 211. The Province of Ontario supports 211 through annual funding from the Ministry of Community and Social Services. The Ontario Trillium Foundation has been a generous contributor to our development. The federal government has provided support through Citizenship and Immigration Canada.

Ontario 211 is committed to open data

211’s goal is to be seen as the authoritative source for credible information about human services. Achieving that rests on 211’s continued high data quality, adoption of leading edge communications technology to improve access to that information, and open data practices that encourage collaboration to develop innovative uses contributing to the public good.

211’s information is the ultimate public resource. Ontario 211 is a public purpose body, which uses public funds to collect, organize and disseminate public information about human service organizations.

By providing open access to data, Ontario 211 collaborates with the broader public and professional communities who can examine how the human services system operates throughout Ontario. Meaningful analysis will identify successes in the social infrastructure as well as identify areas needing improvement.

Ferrario & Guarino on services science

Stephen L Vargo & Robert F Lusch – Readings

2004

2006

2007

2008

  • Vargo, SL and Lusch, RF – Service-dominant logic: Continuing the evolution – 2008
  • Why “service”? – 2008
  • The service-dominant mindset – 2008
  • From goods to service (s): Divergences and convergences of logics – 2008
  • Service-Dominant Logic, market theory and marketing theory – 2008
  • A service logic for service science – 2008
  • “Relationship” in Transition: An Introduction to the Special Issue on Relationship and Service-Dominant Logic

2010

  • From repeat patronage to value co-creation in service ecosystems: a transcending conceptualization of relationship – 2010
  • SD logic: accommodating, integrating, transdisciplinary – 2010

2011

2012

2014

2015