properly relate Product and Service (ProductOrService)

[elf-pavlik]

http://schema.org/Product
http://schema.org/Service

from reply on public-vocabs thread http://lists.w3.org/Archives/Public/public-vocabs/2014Sep/0229.html by @mfhepp

I suppose that "Service" was once added for some specific, but maybe only hypothetical use-case by one of the sponsors of schema.org.

In order to keep the vocabulary clean, however, I suggest to use Product (in the sense of ProductOrService) as long as the distinction between product and service does not really matter for processing the data. Many "products" are nowadays bundles of tangible objects and services anyway, so unless you need specific properties that do not make sense for schema:Product, I would minimize the use of schema:Service.

Note: In principle, we could make Service a subclass of Product, and/or include a superclass ProductOrService (which was the original name in GoodRelations anyway):

schema:ProductOrService
-> schema:Product
-> schema:SomeProducts
-> schema:IndividualProduct
-> schema:ProductModel
-> schema:Service

This has two caveats, though: First, the more special types SomeProducts, IndividualProduct, and ProductModel are then not available for services any longer. But on the contrary, the notion of individuals, models, and bags of products does not really fit to pure services anyway (or they do not matter that much). So this seems acceptable to me.

Second, if we want to add specializations for very important types of products and services (like Vehicle/Car; HotelRoom, etc.), we will have to make a strict decision on whether that type is a product or a service. That can lead to inconsistency in the vocabulary over time. For instance, I think that "Taxi" should be better placed beneath schema:Product etc. For me, this is the reason for rather sticking to the "ProductOrService" notion of schema:Product.

TODO

• http://schema.org/Product
• http://schema.org/Service
• http://schema.org/BroadcastService

[elf-pavlik]

I would also suggest coordinating it with @msporny's work on: https://web-payments.org/specs/source/vocabs/commerce.html (I mentioned some possible issues in http://lists.w3.org/Archives/Public/public-webpayments/2014Jan/0019.html)

I guess one may just need to specify types as:
{ "@type": ["payswarm:Asset", "schema:Product"] }
{ "@type": ["payswarm:Listing", "schema:Offer"] }

At the same time

• payswarm:Listing uses payswarm:asset to link to payswarm:Asset
• schema:Offer uses schema:itemOffered to link to schema:Product

also:

• payswarm:assetProvider and schema:seller

[elf-pavlik]

maybe also feedback from @tantek about possibilities for compatibility with http://microformats.org/wiki/h-product could come of help?

[msporny]

Thanks for the heads-up @elf-pavlik. I think we're going to try and re-use as much of schema.org as we can for the core terms used in the Web Payments and Credentials work. We will likely extend schema.org for mechanisms that are required by the Web Payments stuff, but don't make sense wrt. being integrated in schema.org. Unfortunately, we don't have the bandwidth to coordinate at the moment, so the schema.org folks should feel free to plod ahead and we'll eventually catch up w/ the vocabulary and make some change/extension proposals.

[elf-pavlik]

Thanks for chiming in @msporny! @mfhepp web-payments uses term pay:Asset which IMO closely matches gr:ProductOrService, maybe we could introduce schema:Asset as super type of schema:Product and schema:Service?

An asset describes a particular item that is provided as a part of a commercial transaction. It is usually an item that can be accessed or acquired on the basis of a sale or rental under the terms of a particular license. Examples of assets include web pages, crowd-funded loans or grants, music files, video streams, use of virtual machines by the hour, 3D printer files for on-demand manufacturing, radio spectrum and many other items that are capable of being transacted.

[dbs]

Or just align pay:Asset directly with schema:Product.

[elf-pavlik]

@dbs how does it help with accommodating schema:Service? to my understanding if we had schema:ProductOrService web payments could just reuse it. Since we don't, i find schema:Asset name shorter and nicer then schema:ProductOrService. Let's try to compare it side by side

Schema.org	GoodRelations	WebPayments
Offer, Demand	Offering	Offer
Product, Service	ProductOrService	Asset

It gets more complex when we look at predicates used to relate those types

Schema.org	GoodRelations	WebPayments
itemOffered	includes, includesObject	asset

IMO in current Schema.org itemOffered on Demand doesn't sound intuitive, as well as Demand for bike repair for most people will on first thought sound like asking for Service not Product.

I also won't even try to get into comparing modeling of prices and payment methods at this moment.

[elf-pavlik]

I also just spotted http://schema.org/BroadcastService (making checklist in original issue and adding it there!)

[dbs]

@elf-pavlik To requote a key piece of what you already quoted: "For me, this is the reason for rather sticking to the "ProductOrService" notion of schema:Product."

Let's keep it simple, and keep treating schema:Product as the equivalent of gr:ProductOrService, so pay:Asset can be the equivalent of schema:Product... there is no need for additional complexity. Notions of "intuitive" or "most people will on first thought" are hugely subjective and very likely trumped by clear examples.

[elf-pavlik]

👍 clear examples and documentation elaborating on all those nuances

currently http://schema.org/Service has no examples and states

A service provided by an organization, e.g. delivery service, print services, etc.
[...]
More specific Types

• GovernmentService
• Taxi

http://schema.org/Taxi

A taxi.

[mfhepp]

Note that the differences between GoodRelations and schema.org are only at the level of naming. Conceptually, they are 99% in alignment, with two minor exceptions:

1. There are a few "simpler" constructs in schema.org for which more advanced GR patterns have been added and it is a bit unclear whether the simple ones are deprecated or not. This mainly refers to opening hours, item availability, and price information.
2. The split of gr:Offering in demand and offer will be made in the next service release of GoodRelations, too, same as a few minor differences in domains and ranges (e.g. that eligibleRegions can already include schema:GeoShape in schema.org).

When I worked on the integration of GoodRelations into schema.org, I already implemented a few things that are still in the queue for GoodRelations, but they will be added there, too.

Martin

---

martin hepp http://www.heppnetz.de
mhepp@computer.org @mfhepp

On 21 Sep 2014, at 14:30, ☮ elf Pavlik ☮ notifications@github.com wrote:

@dbs how does it help with accommodating schema:Service? to my understanding if we had schema:ProductOrService web payments could just reuse it. Since we don't, i find schema:Asset name shorter and nicer then schema:ProductOrService. Let's try to compare it side by side

Schema.org GoodRelations WebPayments
Offer, Demand Offering Offer
Product, Service ProductOrService Asset
It gets more complex when we look at predicates used to relate those types

Schema.org GoodRelations WebPayments
itemOffered includes, includesObject asset
IMO in current Schema.org itemOffered on Demand doesn't sound intuitive, as well as Demand for bike repair for most people will on first thought sound like asking for Service not Product.

I also won't even try to get into comparing modeling of prices and payment methods at this moment.

—
Reply to this email directly or view it on GitHub.

[mfhepp]

I think this is the better option.
With proper documentation, I think we do not need to touch schema:Product, and we can keep schema:Service for things that are typically unrelated to commercial offers.

IMO, it is not essential to properly relate governmental services etc. with the Agent-Promise-Object-Compensation patterm of GoodRelations in schema.org, even if it theoretically fits into that frame.

Proper service modeling can be a rat hole, see USDL, UDDL, ...

Martin

---

martin hepp http://www.heppnetz.de
mhepp@computer.org @mfhepp

On 21 Sep 2014, at 13:54, Dan Scott notifications@github.com wrote:

Or just align pay:Asset directly with schema:Product.

—
Reply to this email directly or view it on GitHub.

[mfhepp]

If we want to advance the payments part of schema.org and GoodRelations, I think that trying to properly model financing options and leasing is much more important than new payment mechanisms. Future payment standards are important, but when looking at the information extraction bottleneck from databases in dynamic Web sites and search engines, such existing payment information is a much more urgent challenge.

Other open issues are taxes and service fees - the modeling of sales tax and fees that are not related to payment or delivery is insufficient in GR/schema.org as of now.

Also note that the current model allows adding new payment methods by simply defining a URI for an instance of schema:PaymentMethod.

This is why I cannot offer to work on the alignment of GoodRelations and web-payments until I will have finished this pretty long list of immediately needed extensions.

We should not close doors to the future at the conceptual level now, of course. But at least my priorities are pressing gaps in coverage for which a massive amount of information exists in current Web sites (e.g. property-value information, vehicles, ...).

Martin

martin hepp http://www.heppnetz.de
mhepp@computer.org @mfhepp

On 21 Sep 2014, at 13:26, ☮ elf Pavlik ☮ notifications@github.com wrote:

Thanks for chiming in @msporny! @mfhepp web-payments uses term pay:Asset which IMO closely matches gr:ProductOrService, maybe we could introduce schema:Asset as super type of schema:Product and schema:Service?

An asset describes a particular item that is provided as a part of a commercial transaction. It is usually an item that can be accessed or acquired on the basis of a sale or rental under the terms of a particular license. Examples of assets include web pages, crowd-funded loans or grants, music files, video streams, use of virtual machines by the hour, 3D printer files for on-demand manufacturing, radio spectrum and many other items that are capable of being transacted.

—
Reply to this email directly or view it on GitHub.

[elf-pavlik]

thank you @mfhepp for all this feedback! @danbri also suggested simple modifications to schema:Service description in http://lists.w3.org/Archives/Public/public-vocabs/2014Sep/0273.html

A service provided by an organization, e.g. delivery service,
print services, etc. (Note that a particular delivery or print job can
be modeled as a Product.)

I would also see need for short paragraph about schema:Service in http://schema.org/Product

@mfhepp what do you think about capturing all those explanations, and many other ones in a past into a single page linked from http://schema.org/docs/documents.html
we could also link to it from various pages with 'for more detailed explanation see >'. Similar to http://schema.org/docs/actions.html

I also propose using github wiki and Github Flavored Markdown, I already proposed including it into website generation in #133 and provided example of rich formating in #125 (i can help with polishing it once you have some content there!)

Placeholder wiki page: Schema.org Goods

[mfhepp]

I am planning to create an "ecommerce.html" document that describes GoodRelations in schema.org from a conceptual perspective, similar to http://wiki.goodrelations-vocabulary.org/Documentation/Conceptual_model and http://wiki.goodrelations-vocabulary.org/Documentation/Intro.

[danbri]

I see a lot of discussion here. Would any of you care to summarize where you think we are on this issue?

[elf-pavlik]

@danbri to lower confusion we can start with adding short notes to Service and Product as you suggested

A service provided by an organization, e.g. delivery service,
print services, etc. (Note that a particular delivery or print job can
be modeled as a Product.)

I would suggest adding something matching it to Product

"Any offered product or service. For example: a pair of shoes; a concert ticket; the rental of a car; a haircut; or an episode of a TV show streamed online. (Note that Service in schema.org represents general type of services. Please use Product for particular occurrences of such services, for example used in market transaction)"

@mfhepp at some point will produce more in depth explanations to include among others on http://schema.org/docs/documents.html

[elf-pavlik]

@mfhepp how do we model Offer/Demand for Action/Activity like:

• TravelAction
  • BusTrip
  • TrainTrip
  • Flight
  • Taxi
• ConsumeAction
  • EatAction (e.g. an apple)
  • DrinkAction (e.g. cup of coffee)
  • UseAction (e.g. bike from bikesharing pool)
  • LearnAction
• CreateAction
  • CookAction
  • TranslateAction
  • PhotographAction
  • FilmAction
  • TeachAction

I also understand that we sometimes also introduce Ticket but i ask for an Activity and not ticket for this Activity! IMO Ticket serves more in a way of Recipt minted with PriceSpecification (DataShape?) which one can use to ClaimAccess / PayAction

• FoodEvent -- EatAction & DrinkAction
• MusicEvent -- ListenAction
• TheaterEvent -- WatchAction
• SportsEvent -- WatchAction but also ExerciseAction (e.g. Yoga Class)
• EducationEvent -- LearnAction (sub: ConsumeAction) & TeachAction (sub: CreateAction)
• DanceEvent -- DanceAction

[elf-pavlik]

Possibly also worth track Web Payments IG work, they just published FPWD of Use Cases which includes e.g. "Discovery of Offer" http://www.w3.org/TR/web-payments-use-cases/

[github-actions]

This issue is being tagged as Stale due to inactivity.