ProfessionalService and Service have no stated relationship - clarify and better integrate Service into core schemas

[danbri]

Currently we have two similarly named types relating to service provision, and no stated relationship between them.

See also sub-issues: #812 (specific wording changes), #411 (serviceArea range)

1.) http://schema.org/ProfessionalService "Provider of professional services."

• Thing > Place > LocalBusiness > ProfessionalService
• Thing > Organization > LocalBusiness > ProfessionalService

Notes on ProfessionalService:

• This type and its subtypes have no properties defined especially for them (incoming or outgoing)
• Subtypes of ProfessionalService: AccountingService, Attorney, Dentist, Electrician, GeneralContractor, HousePainter, Locksmith, Notary, Plumber, RoofingContractor.
  • These are all subtypes of LocalBusiness, and so (like ProfessionalService itself) have multiple supertypes: Organization and Place

2.) http://schema.org/Service "A service provided by an organization, e.g. delivery service, print services, etc."

• Thing > Intangible > Service

Notes on Service:

• uses availableChannel to point to a ServiceChannel (which in turn has properties for online, local business, phone etc. channels of a service)
• uses provider to reference Person or Organization, (alongside 'review' for service reviews, aggregateRating for service ratings etc.)
• service-specific outgoing properties are: serviceArea (an AdministrativeArea), serviceOutput (a Thing), serviceType (Text).
• has one example, which is of an Order that has an 'orderedItem' which is a Service whose 'description' is "furnace installation".
  • related minor issue: orderedItem property should anticipate Service values.
• Service has 2 incoming properties: issuedThrough (on Permit), and providesService on ServiceChannel.
• Service type was added later for Civic Services. See http://blog.schema.org/2013/08/vocabulary-for-describing-civic-services.html (blog post), http://www.w3.org/wiki/WebSchemas/CivicServices (earlier design discussions).
• http://schema.org/Permit was also part of the Civic Services model. A Permit ("A permit issued by an organization, e.g. a parking pass.") is issuedThrough a Service, and can have temporal and geographic validity, as well as an audience.
  • http://schema.org/GovernmentPermit is a subtype of Permit: "A permit issued by a government agency.", see link for example which expressed that a GovernmentPermit was issuedBy a GovernmentOrganization named "Department of Health and Mental Hygiene", and issuedThrough a GovernmentService named "NYC Food Service Establishment Permit Service"
• Subtypes of Service:
  • BroadcastService ("A delivery service through which content is provided via broadcast over the air or online."; used for values of "publishedOn" in BroadcastEvent)
  • CableOrSatelliteService ("A service which provides access to media programming like TV or radio. Access may be via cable or satellite."; used for values of inBroadcastLineup on BroadcastChannel)
  • GovernmentService ("A service provided by a government organization, e.g. food stamps, veterans benefits, etc.")
  • Taxi ("A taxi.")
  • TaxiService ("A service for a vehicle for hire with a driver for local travel. Fares are usually calculated based on distance traveled.
    ")

[jvandriel]

Just so I don't later on blame myself for never having spoken it out loud.

Can't we deprecate schema.org/Service and have its subtypes be placed under schema.org/Product?

schema.org/Product is sort of shorthand for ProductOrService, which exists besides schema.org/Service and because of that confuses the heck out of folks, including myself.

The difference between when one should use schema.org/Product or schema.org/Service is still too vague, and causes many everyday implementers to overlook the fact that one can use schema.org/Product to describe the services a business offers.

Any chance we can simplify things for the elves?

[danbri]

@jvandriel can you elaborate on the specific properties from http://schema.org/Product that you find most relevant to http://schema.org/Service? /cc @mfhepp

[mfhepp]

I think there are two approaches for handling @jvandriel 's proposal:

1. We can make schema:Service a subtype of schema:Product. That would follow the original GoodRelations model, be a relatively simple solution, and point people to the intended broad notion of "product" in schema.org and GoodRelations (in essence "the role of being the object of an offer"). The only downside is that we pass along to schema:Service a few properties that are like "fax numbers for volcanoes", i.e. rarely applicable to services. But hey, who says that a service can't have a GTIN? The only "really problematic" properties are those that assume a product to be something physical, like weight, color, depth, etc. But on the other hand, there are many other products that do not need these, and we likely do not want to go down the ontological route of tangible vs. intangible products.
2. We could include schema:Service in the range of itemOffered and includesObject and all properties from schema:Product that are typically useful for services, too (likely many). We will add a lot of complexity and potential sources of errors by that second option. The properties currently having schema:Service in their range do not need to be updated due to the proposed change, for they will remain reserves for products that are services.

So I suggest #1 if you want to take action on this.

[mfhepp]

Note: My proposal #1 would also solve the lack of relationship between schema:ProfessionalService and schema:Service, because schema:ProfessionalService has makesOffer by virtue of being subclassOf schema:Organization, and the offer could include the schema:Service once it has been made a subtype of schema:Product.

I would not foster a direct link from an organization to its services without an offer entity. That would break the whole idea of GoodRelations and open just another modeling pattern instead of strengthening the agent-promise-object pattern in schema.org and GoodRelation (which we will also have in my upcoming hotel proposal and which we already have for vehicles sales and rental).

[rvguha]

That pattern does not work well for services, where there is no fixed list
of possible services. In those cases, we do need a direct link from the
Service provider to the service.

I would also like to deprecate or at least rename ProfessionalService.
Having both Service and ProfessionalService is extremely confusing.

guha

On Mon, Sep 28, 2015 at 11:02 AM, Martin Hepp notifications@github.com
wrote:

Note: My proposal #1 #1
would also solve the lack of relationship between
schema:ProfessionalService and schema:Service, because
schema:ProfessionalService has makesOffer by virtue of being subclassOf
schema:Organization, and the offer could include the schema:Service once it
has been made a subtype of schema:Product.

I would not foster a direct link from an organization to its services
without an offer entity. That would break the whole idea of GoodRelations
and open just another modeling pattern instead of strengthening the
agent-promise-object pattern in schema.org and GoodRelation (which we
will also have in my upcoming hotel proposal and which we already have for
vehicles sales and rental).

—
Reply to this email directly or view it on GitHub
#801 (comment)
.

[rvguha]

No, lets not make Service a Product. That kind of construct makes sense to
ontologists, but not to most developers.

This is exactly why we allow for multiple domains and ranges. We don't want
these kind of less than intuitive constructs.

guha

On Mon, Sep 28, 2015 at 10:58 AM, Martin Hepp notifications@github.com
wrote:

I think there are two approaches for handling @jvandriel
https://github.com/jvandriel 's proposal:

We can make schema:Service a subtype of schema:Product. That would
follow the original GoodRelations model, be a relatively simple solution,
and point people to the intended broad notion of "product" in
schema.org and GoodRelations (in essence "the role of being the object
of an offer"). The only downside is that we pass along to schema:Service a
few properties that are like "fax numbers for volcanoes", i.e. rarely
applicable to services. But hey, who says that a service can't have a GTIN?
The only "really problematic" properties are those that assume a product to
be something physical, like weight, color, depth, etc. But on the other
hand, there are many other products that do not need these, and we likely
do not want to go down the ontological route of tangible vs. intangible
products.
2.

We could include schema:Service in the range of itemOffered and
includesObject and all properties from schema:Product that are typically
useful for services, too (likely many). We will add a lot of complexity and
potential sources of errors by that second option. The properties currently
having schema:Service in their range do not need to be updated due to the
proposed change, for they will remain reserves for products that are
services.

So I suggest #1 #1 if you
want to take action on this.

—
Reply to this email directly or view it on GitHub
#801 (comment)
.

[vholland]

+1 to not making Service a Product. It would seem better to extend the domains for the following Product properties to include Service:

aggregateRating
award
category
offers
review

And extend itemOffered to allow for offering a Service.

[vholland]

There is already a way to directly associate a Service with a business using http://schema.org/provider.

While I appreciate the elegance of the agent-promise-object pattern, most authors don't understand it and something like the following requires more markup, which introduces more opportunity for error:

{
  "@context": "http://schema.org/"
  "@type": "Service",
  "name": "ACME delivery service",
  "offers": {
    "@type": "Offer",
    "seller": {
      "@type": "LocalBusiness",
      "name": "ACME Services"
    }
  }
}

As it stands, the markup is much simpler without the intermediate node:

{
  "@context": "http://schema.org/"
  "@type": "Service",
  "name": "ACME delivery service",
  "provider": {
    "@type": "LocalBusiness",
    "name": "ACME Services"
  }
}

[danbri]

(aside: don't use '#' to mean '#1' as it'll hyperlink to github issue number 1.)

• I prefer @mfhepp 's option (2.). It might make more work for us as maintainers but it leaves the Product type with a clearer identity and role. Services are inherently slippery (rather like actions, in fact).
• In general at schema.org when we have a choice between making more work for publishers/developers vs making work for search engines and the schema.org team, we make work for the latter. I think the choice between (1.) and (2.) is another case of just this. It will be work for us but we will live, and the situation will be easier on publishers.
• I also support the renaming of http://schema.org/ProfessionalService to avoid confusion. Any suggestions for new name?
• there may sometimes be situations where interposing an Offer between Service and (Local)Business is useful - e.g. http://schema.org/availabilityStarts http://schema.org/availabilityEnds and (potential transient) location information - e.g. "DanBri's Mobile VegeBurger Bar is in your area tonight!". However this raises another cleanup opportunity: Offer has both http://schema.org/availableAtOrFrom and http://schema.org/eligibleRegion - @mfhepp suggested elsewhere that we fold these under a common superproperty (areaServed) and rationalise the associated types. I believe we should do that.

[update : I've implemented that last part now, see below.]

[jvandriel]

"We don't want these kind of less than intuitive constructs."

What is less than intuitive for the folks I've been talking to over the years is that there's an overlap between schema.org/Product and schema.org/Service.

Now I'd like to avoid talking about how the 2 might be nested or which properties each should have as I'd like to zoom in on the overlap between the 2 types - because if schema.org/Product would only stand for a product things would be different but implementers are now forced to have to choose between using schema.org/Product or schema.org/Service - due to the fact that schema.org/Product can be used to describe a service as well - without any guidance on when one should use the one or the other.

Is there a distinct difference between the two we can highlight that will make it clear for implementers which type they should use when?

[danbri]

On the matter of dissolving ProfessionalService, I took a look and here's a sketch of new supertypes and/or names for the current subtypes of ProfessionalService:

• Dentist http://schema.org/MedicalOrganization already has Dentist and 7 others; Dentist doesn't need another parent type.
• something like LegalBusiness (or LegalService? at least that is quite specific, vs 'ProfessionalService'). Or we could just let AccountingService and Notary sit directly under LocalBusiness.
  • AccountingService
  • Attorney -> see "Attorney" type is ambiguous, consider "Law Firm" or "Law Office" as another type for the business #784 and https://lists.w3.org/Archives/Public/public-vocabs/2014Mar/0089.html - there are internationalization-related reasons to replace this with something broader.
  • Notary
• ConstructionBusiness - new supertype for this sub-cluster around homes + building.
  • Electrician
  • GeneralContractor
  • HousePainter
  • Locksmith
  • Plumber
  • RoofingContractor

[jvandriel]

"On the matter of dissolving ProfessionalService"

Besides having to do 'something' for legal like you pointed out, the rest looks good to me @danbri.

[mfhepp]

@vholland Your example without offer is just tiny bit simpler, but ... you end up with a situation where you suddenly have to use an entirely different pattern as soon as you want to add price information or any other details from Offer. In general, I would like to see the same basic patterns for simple and advanced use-cases alike, i.e. simplifications should ideally not introduce alternative patterns.

[rvguha]

Martin,

While I appreciate your sentiment, I think we need to be more flexible,
especially when it comes to patterns. Different patterns will make sense in
different contexts, for different kinds of services. I am inclined to allow
for multiple, alternative patterns, so long as the underlying semantics are
clear.

guha

On Tue, Sep 29, 2015 at 10:45 AM, Martin Hepp notifications@github.com
wrote:

@vholland https://github.com/vholland Your example without offer is
just tiny bit simpler, but ... you end up with a situation where you
suddenly have to use an entirely different pattern as soon as you want to
add price information or any other details from Offer. In general, I would
like to see the same basic patterns for simple and advanced use-cases
alike, i.e. simplifications should ideally not introduce alternative
patterns.

—
Reply to this email directly or view it on GitHub
#801 (comment)
.

[jvandriel]

I agree with @mfhepp on this one. Having multiple patterns doesn't seem like a good idea to me. I prefer consistency.

[mfhepp]

@rvguha Thanks for stepping in! I agree that the services area is slippery ground and applying the agent-promise-offer pattern might be seen as a stretch. I am "fighting" for the use of Offer in the general case because it offers a very natural point for adding more details, namely

• prices
• terms and conditions
• bundles (e.g. a product + services).

But again - I have no problem with deviating from that pattern for services because services are a rat hole from a conceptual modeling perspective, as we all know from DAML-S, WSMO, OWL-S, BPM ontologies, ... ;-)

[danbri]

/cc @mfhepp @pmika @chaals @scor @ajax-als @tilid @shankarnat

Ok folks, I have made a number of cleanup/polish/integration-oriented changes based on these discussions. Please review http://sdo-phobos.appspot.com/docs/releases.html#service-usability-fixes

See URL for hypertext version, but summarizing the fixes for #801 "Fix to #801: Broadened award, category, offers to be applicable on Service. Extended itemOffered to expect Service as a possible value. Added LegalService as a supertype for Notary, Attorney. Marked ProfessionalService as deprecated, with some explanation, and added a brief account of the relationship with Service to some of the more service-oriented local business types e.g. LegalService, HomeAndConstructionBusiness. A cluster of construction-related local businesses formerly treated as ProfessionalService continue as HomeAndConstructionBusiness subtypes. Marked Attorney as deprecated in favor of LegalService per #784. Added hoursAvailable to Service."

However please see the other changes for review there too as some are related.

[jvandriel]

Since your changes make it possible itemOffered and offers can be used with schema.org/Service might I suggest we also modify schema.org/Product's description so that it no longer contains "Any offered product or service." nor "a haircut"?

It was already confusing enough as it was but now it's becoming nearly impossible to decide whether to use schema.org/Product or schema.org/Service for services being offered.

With the way things are proposed now I'd prefer if schema.org/Product would be for 'just' products.
(if not, please tell me how I can explain the difference to implementers)

For the rest, +1

[mfhepp]

@jvandriel -1 actually, because there are a lot of Web sites that have a database that mixes products and services and they cannot easily activate one markup pattern for physical products and another one for related services.

As always, conceptual clarity is just one dimension of Web vocabulary engineering ;-)

I think the practical distinction between Product and Service should be that Service is for describing at a rather generic level the types of services provided by an Organization or Person, while Product is for detailed descriptions of specific types of goods and services. I am fine with removing "a haircut", though.

[jvandriel]

I actually have experience with what you mean to say with "they cannot easily activate one markup pattern for...", so I can certainly appreciate that POV.

But maybe something similar could also be stated in schema.org/Product's description, accompanied with saying that it's better to be more precise and to use schema.org/Service when describing services being offered? (instead of keeping schema.org/Service for generic services)

[danbri]

I suggest we close out our free-flowing discussions here for now, so that the existing bundle of changes made recently can be reviewed without confusion.

If anyone has specific textual changes to propose for improving /Product and /Service definitions (as suggested by @jvandriel ) I suggest we take that to a dedicated sub-issue, which I've just created -> #812. I think we're done with tweaks to the schemas.

So - everyone - please take a look at http://sdo-phobos.appspot.com/docs/releases.html#sdo-phobos
under #801 and note (and also in #411 which is closely related) here if you're supportive of the changes.

We'll do a final "do we ship this as a release?" round in the steering committee for the whole release, but it would be good to get indicators of support here first. Thanks!

/cc @tilid @scor @shankarnat @pmika @chaals @mfhepp @ajax-als @rvguha @vholland

[scor]

👍

[danbri]

Fixed in http://schema.org/docs/releases.html#v2.2 - thanks all